GPT-OSS na nulti dan

Podrška nultog dana za GPT-OSS na H200 prilagođavanjem ROSE sa FP8, pažnjom sa slivom i MoE optimizacijama

AutoriPerplexity Engineering

Perplexity je posvećen tome da najbolje AI modele učini dostupnim radoznalim osobama koje zahtevaju tačne i pouzdane odgovore i radnje agenata. OpenAI je nedavno najavio svoje modele sa otvorenim tešinama (gpt-oss-20b i gpt-oss-120b). Kao i kod mnogih vodećih modela, Perplexity je među prvim organizacijama koje procenjuju gpt-oss-20b i gpt-oss-120b.

U ovom postu delimo odluke o infrastrukturi našeg sopstvenog steka za inferenciju koji je omogućio podršku nultog dana (Day-0). Fokusiramo se na opsluživanje ovih modela na NVIDIA H200 GPU-ovima, detaljno opisujući izmene kernela, izbore primene i kompromise između brzine i cene.

GPT-OSS na Hopper-u

Modeli sa otvorenim tešinama se isporučuju korišćenjem MXFP4 kvantizacije, što im pomaže da stanu u memoriju na hardveru potrošačkog nivoa ili da postignu vršni protok na NVIDIA Blackwell-u. Međutim, za inicijalnu procenu, želeli smo da ih pokrenemo na postojećim H200 Hopper klasterima uz minimalne izmene mašine za inferenciju. Hopper nema namenske FP4 tenorske jezgre, koje su uvedene sa Blackwell-om. Posledično, odlučili smo da opslužujemo modele sa FP8 preciznošću umesto toga, kako bismo minimizirali potrebu za prilagođenim kernelima i najbolje iskoristili dostupni hardver.

Na visokom nivou, transformer Jezički modeli (LLM) su strukturalno jednostavni:

Ulazno ugnježđivanje (embedding)

Niz slojeva transformera. Svaki sadrži blok pažnje i gust MLP ili retki MoE blok.

Projekcija izlaznog logita

Prilikom uvođenja novog modela transformera, prvenstveno smo zainteresovani da saznamo u kojoj meri se oni poklapaju sa postojećim modelima kako bismo identifikovali potrebne izmene. OpenAI je ljubazno unapred podelio pregled svojih modela, omogućavajući nam da u skladu s tim prilagodimo podešavanje inferencije. Utvrdili smo da su modelu zaista potrebne brojne male izmene.

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

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

YaRN poziciono kodiranje, slično DeepSeek-V3 modelu

QKV projekcije imaju otpuste (biases), slično Qwen 2 modelu

Izlazna projekcija ima otpust (bias)

MLP: Retka mešavina stručnjaka (Sparse Mixture-of-Expert - MoE)

SwiGLU aktivaciona funkcija, drugačija od većine modela sa otvorenim tešinama

Softmax nakon Top-K za težine stručnjaka

Stručnjaci imaju otpuste (biases)

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

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

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

Izaberemo FP8 128x128 blok skaliranje kao šemu kvantizacije, proširujući DeepGEMM kernele da podržavaju termin otpusta (bias).

Sopstvena mašina za inferenciju

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

ROSE izlaže LLM mašinu, koja može da učita model i generiše 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 integriše i Triton i CUDA kernele koji efikasno implementiraju i stapaju izračunavanja koja vrše pojedinačni slojevi.

ROSE je prvenstveno napravljen u Python jeziku 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 osetljivih na performanse, kao što su opsluživanje i raspoređivanje serija (batch scheduling), migriramo na Rust.

Da bismo uveli novi model, prvo definišemo hijerarhiju modela i gradimo konvertor težina za njega. Nakon što se vodi računa o svim težinama, definišemo prosleđivanje unapred (forward pass) za najjednostavniji TP=1 slučaj upotrebe i osiguravamo da radi od kraja do kraja (end-to-end). Na kraju, implementiramo i testiramo podršku za različite oblike paralelizma pre nego što objavimo novi kontejner i primenimo model na klaster radi procene. Zatim vršimo iteracije na performansama, oslanjajući se na povratne informacije sa kontrolnih tabli (dashboards) i preciznijih benčmarka.

ROSE radi sa numeričkim tokenima, uz malo poznavanja formata ćetanja van integracionih testova. Paralelno, morali smo da istražimo prilagođavanje okolne infrastrukture kako bismo podržali Harmony tokenajzer i pravilno mapirali zahteve na sekvence ulaznih tokena.

Sa GPT OSS modelom, utvrdili smo da nisu potrebne nikakve izmene na našim deoderima, CUDA grafičkim okruženjima ili okolnoj infrastrukturi, što nam je omogućilo da usmerimo naše napore na prilagođavanje kernela koji podržavaju model.

Kerneli za GPT-OSS

Pažnja sa slivom (Sink Attention)

Pažnja sa slivom uvodi dodatni faktor otpusta pre Softmax funkcije, 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 sekvence. 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 vrednost 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 komad ako je pažnja bila podeljena na više blokova duž dužine sekvence.

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

MoE

Glavna razlika između MoE sloja različitih modela je obično šema usmeravanja. Očekujući značajnu varijabilnost, ROSE implementira ovaj kernel u Triton-u, što nam omogućava da ga lako prilagodimo novim modelima. U slučaju GPT-OSS-a, morali smo da prilagodimo bodovanje težina kako bismo izvršili softmax samo preko Top-K odabranih stručnjaka, za razliku od nekih modela u DeepSeek stilu koji izračunavaju softmax preko svih stručnjaka. Utvrdili smo da je ključno za tačnost da se težine stručnjaka 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 termine otpusta (bias). Srećom, tokom vremena smo se duboko integrisali sa njima, praveći izmene kako bismo ih bolje povezali sa našim prilagođenim all-to-all kernelima za otpremanje. Dodali smo podršku za otpuste u DeepGEMM inicijalizacijom WGMMA akumulatorskih registara na vrednosti otpusta učitane iz memorije. Ovo je jednokratna radnja tokom obrade MN bloka, tako da je trošak verovatno zanemarljiv, a L2 keš osigurava efikasan pristup ovim vrednostima.

Pošto ovi modeli nemaju direktne koristi od paralelizma podataka (Data Parallelism), ponovo smo iskoristili TP-only kernele za otpremanje i kombinovanje. Ulazi u otpremanje su replikovani u svim rangovima, tako da otpremanje bira tokene za lokalno dostupne stručnjake. Kombinovanje obavlja ponderisanu akumulaciju preko NVLink-a.

Podešavanja performansi

Iako je naš cilj bio da brzo uvedemo modele, želeli smo da osiguramo da performanse i dalje budu razumna. Nakon što smo osigurali ispravnost u odnosu na referentnu implementaciju koju je obezbedio OpenAI, profilisali smo našu implementaciju koristeći podrazumevani PyTorch profajler, vodeći računa o alokacijama blokova i niti širom kernela. Funkcionalnost koju smo ponovo iskoristili bila je napravljena 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.

Tokenizacija i kanali

Harmony format ćetanja 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 metapodatke — što je najvažnije ulogu (sistem, programer, korisnik, asistent, alat), kanal i primaoca kao što je to=functions.<function-name> prilikom pozivanja alata.

Kanali (kao što su analiza, komentar i konačni odgovor) čine izlaze modela transparentnijim i segmentiranim. Zato š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) tačno govore izvršnom okruženju koji akter treba da primi sledeći korak — bilo da je to funkcija, sam model ili krajnji korisnik.

Naša mašina za inferenciju ROSE je agnostična u pogledu formata. Ona prima seriju ulaznih tokena i strimuje nazad izlazne tokene. U našem steku za inferenciju, zadatak formatiranja ulaza u tokenizovani prompt i parsiranja rezultata LLM-a nazad u struktuirane poruke obavlja namenski prednji servis JSON API-ja. Integrisali smo Harmony dodavanjem novog zamenljivog formatera/parsera ovom prednjem delu, omogućavajući pozadinskom delu da ostane nepromenjen dok prednji deo uredno upravlja pravilima formata ćetanja, pozivima alata i strimovanjem. Ova odvojenost odgovornosti održava arhitekturu modularnom, omogućavajući brzo usvajanje novih formata, funkcija odgovora uz minimalne izmene pozadinskog dela.

Cena i performanse

S obzirom na relativno malu veličinu GPT-OSS modela, ograničavamo primenu replike na jedan čvor kako bismo izbegli preopterećenje komunikacije između čvorova. Naša implementacija podržava fleksibilne kombinacije paralelizma stručnjaka (EP), paralelizma podataka (DP) i tenorskog paralelizma (TP). Da bismo odredili optimalnu postavku primene, napravili smo benčmark za sve kombinacije strategija deljenja (sharding) u veličinama serija od 1 do 128. Zahvaljujući razdvajanju popunjavanja i dekodiranja (Prefill-Decode Disaggregation), u mogućnosti smo da odvojeno razgovaramo o kompromisu između performansi i troškova za popunjavanje i dekodiranje.

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

Otkrili smo da postavljanje batch_size=1 i DP=1 daje najbolje performanse popunjavanja. Različite TP konfiguracije zatim pružaju različite kompromise između latencije prvog tokena i cene. Tabele ispod prikazuju latenciju popunjavanja i cenu 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 latencija prefilla i cena po milion ulaznih tokena po konfiguraciji paralelizma i dužini ulaza.

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 latencija prefilla i cena po milion ulaznih tokena po konfiguraciji paralelizma i dužini ulaza.

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 cene po milion izlaznih tokena za modele od 120B i 20B pri dužinama sekvenci od 8192 i 32768.

Cena samo za dekodiranje po milion izlaznih tokena u odnosu na brzinu dekodiranja za GPT-OSS 120B pri dužini sekvence 8.192, uz poređenje konfiguracija EP1, EP2, EP4 i EP8.
Cena samo za dekodiranje po milion izlaznih tokena u odnosu na brzinu dekodiranja za GPT-OSS 120B pri dužini sekvence 32.768, uz poređenje konfiguracija EP1, EP2, EP4 i EP8.
Cena samo za dekodiranje po milion izlaznih tokena u odnosu na brzinu dekodiranja za GPT-OSS 20B pri dužini sekvence 8.192, uz poređenje konfiguracija EP1, EP2, EP4 i EP8.
Cena samo za dekodiranje po milion izlaznih tokena u odnosu na brzinu dekodiranja za GPT-OSS 20B pri dužini sekvence 32.768, uz poređenje konfiguracija EP1, EP2, EP4 i 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.

Reference

Razdvojeno popunjavanje i dekodiranje (Disaggregated Prefill and Decode)

Ubrzavanje Sonar-a kroz spekulaciju​

Manja latencija i veći protok sa višenenskom DeepSeek primenom

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

​pplx-kernels

DeepGEMM

FlashInfer: Efikasan i prilagodljiv mašinski program za pažnju za LLM inferenciju

Efikasni strimujući jezički modeli sa slivovima pažnje (Attention Sinks)

Tehnički izveštaj za DeepSeek-V3​

​Format odgovora OpenAI Harmony | OpenAI kuvar​

Citiranje

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}
}