GPT-OSS nultog dana

Perplexity je posvećen tome da najbolje AI modele učini dostupnim radoznalim ljudima koji zahtijevaju tačne i pouzdane odgovore i agentske akcije. OpenAI je nedavno najavio svoje modele sa otvorenim tegovima (gpt-oss-20b i gpt-oss-120b). Kao i kod mnogih vodećih modela, Perplexity je među prvim organizacijama koje procjenjuju gpt-oss-20b i gpt-oss-120b.

U ovom postu dijelimo odluke o infrastrukturi našeg internog stek-a za inferenciju koje su omogućile podršku nultog dana (Day-0). Fokusiramo se na posluživanje ovih modela na NVIDIA H200 GPU-ovima, detaljno opisujući izmjene kernela, izbore za primjenu i kompromise između brzine i cijene.

Modeli sa otvorenim tegovima se isporučuju korišćenjem MXFP4 kvantizacije, što im pomaže da stanu u memoriju na hardveru potrošačkog ranga ili da ostvare vršni protok na NVIDIA Blackwell-u. Međutim, za inicijalnu procjenu, željeli smo da ih pokrenemo na postojećim H200 Hopper klasterima uz minimalne izmjene mašine za inferenciju. Hopper nema namjenske FP4 tenorske jezgre (tensor cores), koje je uveo Blackwell. Posljedično, odlučili smo da poslužujemo modele sa FP8 preciznošću umjesto toga kako bismo smanjili potrebu za prilagođenim kernelima i najbolje iskoristili dostupni hardver.

Na visokom nivou, transformatorski JE-i (LLM) su strukturalno jednostavni:

Ulazno ugrađivanje (input embedding)

Niz transformatorskih slojeva. Svaki sadrži blok pažnje (attention block) i gusti MLP ili rijetki MoE blok.

Projekcija izlaznog logita

Prilikom uvođenja novog transformatorskog modela, prvenstveno nas zanima da saznamo u kojoj mjeri se oni podudaraju sa postojećim modelima kako bismo identifikovali potrebne izmjene. OpenAI je ljubazno unaprijed podijelio pregled svojih modela, omogućavajući nam da u skladu sa tim prilagodili našu postavku inferencije. Utvrdili smo da model zaista zahtijeva priličan broj malih izmjena.

Pažnja (Attention): GQA sa slivovima pažnje (Attention Sinks)

Svaka glava pažnje ima unaprijed obučeni parametar sliva koji se uzima u obzir u Softmax-u

YaRN poziciono kodiranje, slično kao kod DeepSeek-V3

QKV projekcije imaju pristrasnosti (biases), slično kao Qwen 2

Izlazna projekcija ima pristrasnost

MLP: Rijetka mješavina stručnjaka (Sparse Mixture-of-Expert - MoE)

SwiGLU funkcija aktivacije, drugačija od većine modela sa otvorenim tegovima

Softmax nakon Top-K za stručne tegove

Stručnjaci imaju pristrasnosti

Očekujući da će broj parametara biti oko 100B-200B, odlučili smo da:

Proširimo FlashInfer da podržava slivove pažnje (attention sinks)

Ponovo iskoristimo MoE implementaciju već napravljenu za porodicu modela DeepSeek-V3

Izaberemo FP8 128x128 blok skaliranje kao šemu kvantizacije, proširujući DeepGEMM kernele da podržavaju član pristrasnosti.

Naši napori u vezi sa inferencijom su podržani našom internom mašinom za inferenciju, ROSE. Gradimo ROSE tako da bude fleksibilan okvirom koji omogućava brzo uvođenje novih modela. Pored toga, jednom kada se obavežemo na posluživanje modela u velikom obimu, ona pruža platformu za optimizaciju i poboljšanje performansi kako bi se dostigao najsavremeniji nivo.

ROSE izlaže LLM mašinu, koja može učitati model i generisati dekodirane tokene za njega kroz više dekodera, uključujući spekulativne i MTP dekodere. Sami modeli se sastoje od prilagođenog skupa slojeva, koji podržavaju različite postavke konfiguracije za kvantizaciju i paralelizam. Ispod slojeva, ona kombinuje i Triton i CUDA kernele koji efikasno implementiraju i stapaju izračunavanja koja vrše pojedinačni slojevi.

ROSE je prvenstveno napravljen u Python-u i oslanja se na PyTorch za definicije modela. Iako nam Python omogućava da budemo fleksibilni i da se prilagođavamo novim modelima, većinu komponenti osjetljivih na performanse, kao što su posluživanje i zakazivanje serija (batch scheduling), migriramo na Rust.

Da bismo uveli novi model, prvo definišemo hijerarhiju modela i gradimo konvertor tegova za njega. Nakon što su svi tegovi obračunati, definišemo prosljeđivanje unaprijed (forward pass) za najjednostavniji slučaj upotrebe TP=1 i osiguravamo da radi od kraja do kraja. Konačno, implementiramo i testiramo podršku za različite oblike paralelizma prije nego što izdamo novi kontejner i primijenimo model na klasteru radi procjene. Zatim iteriramo na performansama, oslanjajući se na povratne informacije iz kontrolnih tabli (dashboards) i preciznijih benčmarka.

ROSE radi na numeričkim tokenima, sa malo znanja o formatima ћаскања (chat) van integracionih testova. Paralelno, morali smo da istražimo prilagođavanje okolne infrastrukture kako bismo podržali Harmony tokenizator i ispravno mapirali zahtjeve na ulazne nizove tokena.

Sa GPT OSS modelom, otkrili smo da nisu potrebne nikakve izmjene na našim dekođerima, CUDA grafovskim okvirom ili okolnoj infrastrukturi, što nam je omogućilo da usmjerimo naše napore na prilagođavanje kernela koji podržavaju model.

Pažnja sa slivom uvodi dodatni faktor pristrasnosti prije softmax-a, akumuliran sa proizvodom Q i K:

plaintext

attn = softmax(q @ k^T * sm_scale + sink) * V

Iako je naivna implementacija prilično trivijalna, efikasne implementacije pažnje, kao što je FlashInfer, paralelizuju izračunavanje pažnje i preko nezavisnih glava i preko dužine KV niza. Pored toga, radi numeričke stabilnosti, Softmax se izračunava onlajn uz istovremeno oduzimanje maksimalnog elementa radi numeričke stabilnosti:

plaintext

softmax(x) = e^x / sum(e^x) = e ^ (x - max(x)) / sum(e ^ (x - max(x))

Onlajn implementacija je pratila tekući maksimum m inicijalizovan na -inf i skalu d na 1. Inicijalizacijom maksimuma na vrijednost sliva trenutne glave, osigurali bismo da se on ispravno akumulira u Softmax. Morali smo da vodimo računa da osiguramo da ovaj maksimum bude uključen samo u prvi dio ako je pažnja podijeljena na više blokova duž dužine niza.

Prilagodili smo predložak FlashInfer FA2 kernela, koji se koristi i za predpopunjavanje (prefill) i za dekodiranje, tako da uključuje parametre sliva.

Glavna razlika između MoE sloja različitih modela je obično šema rutiranja. Očekujući značajnu varijabilnost, ROSE implementira ovaj kernel u Triton-u, omogućavajući nam da ga lako prilagodimo novim modelima. U slučaju GPT-OSS-a, morali smo da prilagodimo bodovanje tegova kako bismo izvršili softmax samo preko Top-K odabranih stručnjaka, za razliku od nekih modela u stilu DeepSeek-a koji izračunavaju softmax preko svih stručnjaka. Utvrdili smo da je od ključne važnosti za tačnost da se stručni tegovi izračunaju u bfloat16 preciznosti.

Izazov sa MoE slojem bio je zbog naše odluke da ponovo iskoristimo postojeće DeepGEMM kernele, kojima je nedostajala podrška za članove pristrasnosti. Srećom, s vremenom smo se duboko integrisali sa njima, praveći izmjene kako bismo ih bolje povezali sa našim prilagođenim all-to-all dispečerskim kernelima. Dodali smo podršku za pristrasnost u DeepGEMM inicijalizacijom WGMMA akumulatorskih registara na vrijednosti pristrasnosti učitane iz memorije. Ovo je jednokratna radnja tokom obrade MN bloka, tako da je trošak vjerovatno zanemarljiv, a L2 keš osigurava efikasan pristup ovim vrijednostima.

Budući da ovi modeli nemaju direktne koristi od Data Paralelizma, ponovo smo iskoristili TP-only dispečerske i kombinovane kernele. Ulazi u dispečer su replikovani preko svih rangova, tako da dispečer bira tokene za lokalno dostupne stručnjake. Kombinovanje (Combine) vrši ponderisanu akumulaciju preko NVLink-a.

Iako nam je cilj bio da brzo uvedemo modele, željeli smo da osiguramo da performanse i dalje budu razumne. Nakon što smo osigurali tačnost u odnosu na referentnu implementaciju koju je obezbijedio OpenAI, profilisali smo našu implementaciju koristeći podrazumijevani PyTorch profiler, pazeći na alokacije blokova i tredova (threads) širom kernela. Funkcionalnost koju smo ponovo iskoristili izgrađena je za modele koji su imali veću skrivenu dimenziju od 7168, što je znatno veće od 2880 kod GPT-OSS modela. Specijalizovali smo pokretače kernela da biraju bolje dimenzije mreže, značajno povećavajući protok.

Harmony format ћаскања (chat) ima nekoliko važnih koncepata za strukturiranje razgovora, sadržaja razmišljanja i poziva funkcija. U ovom formatu, svaka poruka se sastoji od zaglavlja i sadržaja:

plaintext

<|start|>{header}<|message|>{content}<|end|>

Zaglavlje nosi metadate — što je najvažnije, ulogu (sistem, programer, korisnik, asistent, alat), kanal i primaoca kao što je to=functions.<function-name> prilikom pozivanja poziva alata.

Kanali (kao što su analiza, komentar i konačni odgovor) čine izlaze modela preglednijim i segmentiranim. Pošto format nameće ovu odvojenost, model može transparentno da razmišlja (i da se pregleda radi otklanjanja grešaka) bez curenja lanca misli u produkciju. Oznake primalaca (to= zaglavlja) govore izvršnom okruženju tačno koji akter treba da primi sljedeći korisni teret (payload) — bilo da je to funkcija, sam model ili krajnji korisnik.

Naša mašina za inferenciju ROSE jeagnostička u odnosu na format. Ona prima seriju ulaznih tokena i strimuje izlazne tokene nazad. U našem steku za inferenciju, zadatak formatiranja ulaza u tokenizovani upit i parsiranja rezultata LLM-a nazad u strukturirane poruke obavlja namjenski frontend servis sa JSON API-jem. Integrisali smo Harmony dodavanjem novog formatera/parsera koji se može priključiti na ovaj frontend, omogućavajući pozadinskom dijelu (backend) da ostane nepromijenjen dok frontend uredno upravlja pravilima formata ћаскања (chat), pozivima alata i strimovanjem. Ova podjela odgovornosti održava arhitekturu modularnom, omogućavajući brzo usvajanje novih formata i funkcija odgovora uz minimalne izmjene pozadinskog dijela.

S obzirom na relativno malu veličinu GPT-OSS modela, ograničavamo primjenu replike na jedan čvor kako bismo izbjegli režijske troškove komunikacije između čvorova. Naša implementacija podržava fleksibilne kombinacije paralelizma stručnjaka (EP), paralelizma podataka (DP) i tenorskog paralelizma (TP). Da bismo utvrdili optimalnu postavku primjene, izvršili smo benčmarking svih kombinacija strategija šardiranja u rasponu veličina serija od 1 do 128. Zahvaljujući razdvajanju predpopunjavanja i dekodiranja (Prefill-Decode Disaggregation), u mogućnosti smo da zasebno razgovaramo o kompromisu između performansi i cijene za predpopunjavanje i dekodiranje.

Za procjene troškova, pretpostavljamo nominalnu tržišnu cijenu H200 od 3,00 $/sat (napomena: ovo nije naša stvarna cijena GPU-a).

Otkrili smo da postavljanje batch_size=1 i DP=1 daje najbolje performanse predpopunjavanja. Različite TP konfiguracije zatim pružaju različite kompromise između latencije prvog tokena i cijene. Tabele ispod predstavljaju latenciju predpopunjavanja i cijenu po milion ulaznih tokena za različite konfiguracije i dužine ulaza.

GPT-OSS 120B:

Dužina ulaza	8192	32768	65536	128000
EP1 DP1 TP1	0,364 s, 0,037 $	2,421 s, 0,062 $	7,375 s, 0,094 $	23,902 s, 0,156 $
EP2 DP1 TP2	0,190 s, 0,039 $	1,245 s, 0,063 $	3,786 s, 0,096 $	12,116 s, 0,158 $
EP4 DP1 TP4	0,165 s, 0,067 $	0,900 s, 0,092 $	2,449 s, 0,125 $	7,165 s, 0,187 $
EP8 DP1 TP8	0,179 s, 0,145 $	0,839 s, 0,171 $	2,003 s, 0,204 $	5,119 s, 0,267 $

Затезање GPT-OSS 120B и трошак по милиону улазних токена у зависности од конфигурације паралелизма и дужине улаза.

GPT-OSS 20B:

Dužina ulaza	8192	32768	65536	128000
EP1 DP1 TP1	0,239 s, 0,024 $	1,610 s, 0,041 $	4,895 s, 0,062 $	16,037 s, 0,104 $
EP2 DP1 TP2	0,127 s, 0,026 $	0,833 s, 0,042 $	2,522 s, 0,064 $	8,143 s, 0,106 $
EP4 DP1 TP4	0,108 s, 0,044 $	0,593 s, 0,060 $	1,616 s, 0,082 $	4,766 s, 0,124 $
EP8 DP1 TP8	0,116 s, 0,094 $	0,547 s, 0,111 $	1,310 s, 0,133 $	3,365 s, 0,175 $

Затезање GPT-OSS 20B и трошак по милиону улазних токена у зависности од конфигурације паралелизма и дужине улаза.

Za dekodiranje, otkrili smo da je EP4 DP1 TP4 najbolja konfiguracija za većinu slučajeva. Četiri grafikona ispod ilustruju kompromis između brzine dekodiranja i cijene po milion izlaznih tokena za modele od 120B i 20B pri dužinama niza od 8192 i 32768.

Трошак само за декодирање по милиону излазних токена у односу на брзину декодирања за GPT-OSS 120B при дужини секвенце 8.192, уз поређење конфигурација EP1, EP2, EP4 и EP8.

Трошак само за декодирање по милиону излазних токена у односу на брзину декодирања за GPT-OSS 120B при дужини секвенце 32.768, уз поређење конфигурација EP1, EP2, EP4 и EP8.

Трошак само за декодирање по милиону излазних токена у односу на брзину декодирања за GPT-OSS 20B при дужини секвенце 8.192, уз поређење конфигурација EP1, EP2, EP4 и EP8.

Трошак само за декодирање по милиону излазних токена у односу на брзину декодирања за GPT-OSS 20B при дужини секвенце 32.768, уз поређење конфигурација EP1, EP2, EP4 и EP8.

Takođe smo razmotrili korišćenje manjeg modela od 20B kao modela nacrta za spekulativno dekodiranje za veći model od 120B. Međutim, pošto je broj aktiviranih parametara sličan (3B naspram 5B), rezultujuća ubrzanja su bila marginalna.

Razdvojeno predpopunjavanje i dekodiranje

Ubrzavanje Sonar-a putem spekulacije

Manja latencija i veći protok uz višestruku primjenu DeepSeek-a

Efikasna i prenosiva komunikacija mješavine stručnjaka (Mixture-of-Experts)

pplx-kernels

DeepGEMM

FlashInfer: Efikasna i prilagodljiva mašina pažnje za posluživanje LLM inferencije

Efikasni jezički modeli strimovanja sa slivovima pažnje (Attention Sinks)

Tehnički izvještaj za DeepSeek-V3

Format odgovora za OpenAI Harmony | OpenAI kuvar (Cookbook)

BibTeX

@online{perplexity2025GptOssOnDay0,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Vladimir Zaytsev and Kevin Hu and Lauren Kolm and Jesse Dwyer},
  title = {{GPT-OSS on day 0}},
  date = {2025-08-08},
  url = {https://www.perplexity.ai/hub/blog/gpt-oss-on-day-0}
}

GPT-OSS na Hopper-u

Interna mašina za inferenciju

Kerneli za GPT-OSS

Pažnja sa slivom (Sink Attention)

MoE

Optimizacije performansi

Токенизација и канали

Troškovi i performanse

Reference

Цитирање