GPT-OSS null-päeval

Null-päeva tugi GPT-OSS-ile H200-l ROSE-i kohandamisega FP8, aukudega tähelepanu ja MoE optimeerimistega

AutoridPerplexity Engineering

Perplexity on pühendunud parimate AI-mudelite kättesaadavaks tegemisele uudishimulikele inimestele, kes nõuavad täpseid ja usaldusväärseid vastuseid ning agentseid toiminguid. OpenAI teatas hiljuti oma avatud kaaludega mudelitest (gpt-oss-20b ja gpt-oss-120b). Nagu paljude juhtivate mudelite puhul, on ka Perplexity üks esimesi organisatsioone, kes hindab mudeleid gpt-oss-20b ja gpt-oss-120b.

Selles postituses jagame oma sisemise järeldustaristu arhitektuurilisi otsuseid, mis muutsid null-päeva (Day-0) toe võimalikuks. Keskendume nende mudelite käitamisele NVIDIA H200 graafikaprotsessoritel ning kirjeldame üksikasjalikult tuumamuudatusi, juurutusvalikuid ja kiiruse-kulude suhteid.

GPT-OSS Hopperil

Avatud kaaludega mudelid tarnitakse MXFP4-kvantimisega, mis aitab neil mahtuda tarbijaklassi riistvara mällu või saavutada maksimaalse läbilaskevõime NVIDIA Blackwellis. Esialgseks hindamiseks tahtsime neid aga käitada olemasolevatel H200 Hopperi klastritel minimaalsete järeldusmootori muudatustega. Hopperil puuduvad spetsiaalsed FP4-tensorsüdamikud, mida Blackwell tutvustas. Seetõttu otsustasime teenindada mudeleid selle asemel FP8-täpsusega, et minimeerida vajadust kohandatud tuumade järele ja kasutada olemasolevat riistvara parimal viisil.

Üldvaates on transformer-keelemudelid struktuuriliselt lihtsad:

Sisendi manustamine

Transformerikihtide jada. Igaüks sisaldab tähelepanuplokki ja tihedat MLP- või hõredat MoE-plokki.

Väljundi logitite projitseerimine

Uue transformermudeli kasutuselevõtul oleme peamiselt huvitatud sellest, et teada saada, mil määral need ühilduvad olemasolevate mudelitega, et tuvastada vajalikud muudatused. OpenAI jagas lahkelt oma mudelite ülevaadet ette, võimaldades meil oma järeldusseadistust vastavalt häälestada. Leidsime, et mudel vajas üsna palju väikseid muudatusi.

Tähelepanu: GQA tähelepanuaukudega (Attention Sinks)

Igal tähelepanupeal on eelnevalt treenitud augu (sink) parameeter, mida võetakse arvesse Softmaxis.

YaRN asukohakodeering, sarnaselt mudelile DeepSeek-V3

QKV-projektsioonidel on nihked (biases), sarnaselt mudelile Qwen 2

Väljundi projektsioonil on nihe

MLP: Hõre ekspertide segu (Sparse Mixture-of-Expert - MoE)

SwiGLU-aktiveerimisfunktsioon, mis erineb enamikust avatud kaaludega mudelitest

Softmax pärast Top-K-d ekspertkaalude jaoks

Ekspertidel on nihked

Oodates parameetrite arvuks umbes 100B–200B, otsustasime:

Laiendada FlashInferi, et toetada tähelepanuauke

Taaskasutada MoE teostust, mis oli juba ehitatud DeepSeek-V3 mudelipere jaoks

Valida kvantimisskeemiks FP8 128x128 ploki skaleerimine, laiendades DeepGEMM-tuumi nihkeliikme toetamiseks.

Sisemine järeldusmootor

Meie järeldustegevust toetab meie oma majasisene järeldusmootor ROSE. Ehitame ROSE-i paindliku raamistikuna, mis võimaldab uusi mudeleid kiiresti kasutusele võtta. Lisaks, kui oleme pühendunud mudeli suuremahulisele teenindamisele, pakub see platvormi jõudluse optimeerimiseks ja tõstmiseks tipptasemeni.

ROSE pakub LLM-mootorit, mis suudab laadida mudeli ja genereerida selle jaoks dekodeeritud tokeneid mitme dekoodri kaudu, sealhulgas spekulatiivsed ja MTP-dekoodrid. Mudelid ise koosnevad kohandatud kihikomplektist, mis toetab erinevaid konfiguratsiooniseadeid kvantimise ja paralleelsuse jaoks. Kihtide all pakub see nii Tritoni kui ka CUDA tuume, mis rakendavad ja liidavad tõhusalt üksikute kihtide sooritatud arvutusi.

ROSE on peamiselt kirjutatud Pythonis ja tugineb mudelmääratluste jaoks PyTorchi toele. Kuigi Python võimaldab meil olla paindlik ja kohaneda uute mudelitega, migreerime enamiku jõudlustundlikest komponentidest, nagu teenindamine ja partiide ajastamine (batch scheduling), Rusti.

Uue mudeli kasutuselevõtuks määratleme kõigepealt mudeli hierarhia ja ehitame sellele kaalumuunduri. Kui kõigi kaaludega on arvestatud, määratleme edasisuunamise (forward pass) kõige lihtsema TP=1 kasutusjuohu jaoks ja tagame selle toimimise algusest lõpuni. Lõpuks rakendame ja testime tuge erinevatele paralleelsuse vormidele enne uue konteineri avaldamist ja mudeli klastrisse hindamiseks juurutamist. Seejärel itereerime jõudlust, tuginedes nii juhtpaneelide kui ka peenemateraliste etalonvõrdluste tagasisidele.

ROSE töötab numbriliste tokenitega, teades vestlusvormingutest integreerimistestide väliselt vähe. Paralleelselt pidime uurima ümbritseva taristu kohandamist, et toetada Harmony tokenisaatorit ja kaardistada päringud õigesti sisendtokenite jadadeks.

GPT OSS-i mudeliga leidsime, et meie dekoodrites, CUDA graafikute raamistikes ega ümbritsevas taristus polnud vaja muudatusi teha, mis võimaldas meil keskenduda mudelit toetavate tuumade häälestamisele.

GPT-OSS-i tuumad

Aukudega tähelepanu (Sink Attention)

Aukudega tähelepanu toob enne Softmaxi sisse täiendava nihketeguri, mis summeeritakse Q ja K korrutisega:

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

Kuigi naiivne teostus on üsna lihtne, paralleelustavad tõhusad tähelepanu teostused, nagu FlashInfer, tähelepanu arvutamist nii sõltumatute peade kui ka KV jada pikkuse vahel. Lisaks arvutatakse numbrilise stabiilsuse tagamiseks Softmax veebipõhiselt (online), lahutades samal ajal numbrilise stabiilsuse tagamiseks maksimaalse elemendi:

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

Veebipõhine teostus jälgis jooksvat maksimumi m, mis oli lähtestatud väärtusele -inf, ja skaalat d väärtusele 1. Lähtestades maksimumi praeguse pea augu väärtusega, tagaksime selle õige kogunemise Softmaxi. Pidin hoolitsema selle eest, et see maksimum lisataks ainult esimesse tükki, kui tähelepanu jagati jada pikkuse ulatuses mitmeks plokiks.

Oleme kohandanud FlashInferi FA2 tuumamalli, mida kasutatakse nii eeltäitmiseks (prefill) kui ka dekodeerimiseks, et see sisaldaks augu parameetreid.

MoE

Erinevate mudelite MoE-kihi peamine erinevus on tavaliselt ruutimisskeem. Oodates märkimisväärset varieeruvust, rakendab ROSE selle tuuma Tritonissa, mis võimaldab meil seda hõlpsasti uute mudelitega kohandada. GPT-OSS-i puhul pidime kohandama kaalude hindamist, et teostada softmax ainult Top-K valitud ekspertide seas, erinevalt mõnedest DeepSeeki stiilis mudelitest, mis arvutavad softmaxi kõigi ekspertide seas. Leidsime, et täpsuse seisukohalt on kriitiline arvutada ekspertide kaalud bfloat16-täpsusega.

MoE-kihiga seotud väljakutse tulenes meie otsusest taaskasutada olemasolevaid DeepGEMM-tuume, millel puudus tugi nihkeliikmetele (bias terms). Õnneks integreerusime nendega aja jooksul sügavalt, tehes muudatusi, et neid paremini ühendada meie kohandatud „kõigilt-kõigile“ (all-to-all) dispetšertuumadega. Lisasime DeepGEMM-ile nihketoe, lähtestades WGMMA akumulaatori registrid mälust laaditud niheväärtustega. See on ühekordne tegevus MN-ploki töötlemise ajal, seega on kulu tõenäoliselt tühine ja L2-vahemälu tagab tõhusa juurdepääsu nendele väärtustele.

Kuna nendest mudelitest ei ole andmeparalleelsusest (Data Parallelism) otsest kasu, taaskasutasime ainult TP dispetšeri- ja kombineerimistuume. Dispetšeri sisendid on kõigi auastmete vahel dubleeritud, seega valib dispetšer tokenid kohapeal saadaval olevate ekspertide jaoks. Kombineerija teostab kaalutud akumulatsiooni üle NVLink.

Jõudluse häälestus

Isegi kui meie eesmärk oli mudelid kiiresti käivitada, tahtsime siiski tagada, et jõudlus oleks mõistlik. Pärast korrektuuri tagamist OpenAI pakutud etalonteostuse suhtes profileerisime oma teostust vaikimisi PyTorchi profileerija abil, jälgides plokkide ja lõimede jaotust tuumade vahel. Taaskasutatud funktsionaalsus oli ehitatud mudelite jaoks, mille varjatud dimensioon (hidden dimension) oli suurem – 7168, mis on oluliselt suurem kui GPT-OSS-i mudelite 2880. Spetsialiseerisime tuumakäivitajad valima paremaid ruudustiku dimensioone, mis suurendas läbilaskevõimet märkimisväärselt.

Tokeniseerimine ja kanalid

Harmony vestlusvormingul on vestluste struktureerimiseks, arutluskäigu sisuks ja funktsioonikutseteks mitu olulist kontseptsiooni. Selles vormingus koosneb iga sõnum päisest ja sisust:

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

Päis kannab metaandmeid – kõige olulisemalt rolli (süsteem, arendaja, kasutaja, assistent, tööriist), kanalit ja saajat, näiteks to=functions.<function-name> tööriistakutse kutsumisel.

Kanalid (nagu analüüs, kommentaarid ja lõplik vastus) teevad mudeli väljundid läbipaistvamaks ja segmenteeritsemaks. Kuna vorming nõuab seda eraldatust, saab mudel arutleda läbipaistvalt (ja seda saab silumiseks kontrollida), ilma et mõttekäik (chain-of-thought) tootmiskeskkonda lekiks. Saaja siltide (to= päised) abil teab käitusaeg täpselt, milline näitleja peaks järgmise kasuliku koormuse (payload) vastu võtma – olgu selleks siis funktsioon, mudel ise või lõppkasutaja.

Meie järeldusmootor ROSE on vormingust sõltumatu. See saab sisendtokenite paketi ja voogedastab väljundtokenid tagasi. Meie järeldustaristus tegeleb sisendite vormindamisega tokeniseeritud viibaks ja LLM-i tulemuste struktureeritud sõnumiteks parsimisega spetsiaalne JSON API esiotsa teenus. Integreerisime Harmony, lisades sellele esiotsale uue pistikprogrammina lisatava vormindaja/parseri, mis võimaldab taustaprogrammil muutumatuks jääda, samal ajal kui esiots haldab puhtalt vestlusvormingu reegleid, funktsioonikutseid ja voogedastust. Selline murede eraldatus hoiab arhitektuuri modulaarsena, võimaldades uute vormingute ja vastusefunktsioonide kiiret kasutuselevõttu minimaalsete taustaprogrammi muudatustega.

Kulu ja jõudlus

Arvestades GPT-OSS-i mudelite suhteliselt väikest suurust, piirame koopia juurutamist üheainsa sõlmega, et vältida sõlmedevahelise suhtluse lisakoormust. Meie teostus toetab eksperdiparalleelsuse (EP), andmeparalleelsuse (DP) ja tensorparalleelsuse (TP) paindlikke kombinatsioone. Optimaalse juurutusseadistuse määratlemiseks võrdlesime kõiki killustamisstrateegiate kombinatsioone partiisuurustega 1 kuni 128. Tänu eeltäitmise ja dekodeerimise eraldamisele (Prefill-Decode Disaggregation) saame jõudluse ja kulude suhet eeltäitmise ja dekodeerimise jaoks eraldi arutada.

Kuluhinnangute jaoks eeldame H200 nimihinnaks turul 3.00 $/tunnis (märkus: see ei ole meie tegelik GPU hind).

Avastasime, et parima eeltäitmisjõudluse tagab seadistus batch_size=1 ja DP=1. Erinevad TP-konfiguratsioonid pakuvad seejärel erinevaid kompromisse esimese tokeni latentsuse ja maksumuse vahel. Allolevad tabelid esitavad eeltäitmise latentsuse ja miljoni sisendtokeni maksumuse erinevate konfiguratsioonide ja sisendi pikkuste jaoks.

GPT-OSS 120B:

Sisendi pikkus

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 eeltäitmise latentsus ja maksumus miljoni sisendtoki kohta paralleelsuskonfiguratsiooni ja sisendi pikkuse järgi.

GPT-OSS 20B:

Sisendi pikkus

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 eeltäitmise latentsus ja maksumus miljoni sisendtoki kohta paralleelsuskonfiguratsiooni ja sisendi pikkuse järgi.

Dekodeerimise jaoks avastasime, et EP4 DP1 TP4 on enamikul juhtudel parim konfiguratsioon. Neli allolevat graafikut illustreerivad kompromissi dekodeerimiskiiruse ja miljoni väljundtokeni maksumuse vahel nii 120B kui ka 20B mudeli puhul jadade pikkustel 8192 ja 32768.

Ainult dekodeerimise maksumus miljoni väljundtoki kohta versus dekodeerimiskiirus GPT-OSS 120B puhul järjestuse pikkusel 8 192, võrreldes EP1, EP2, EP4 ja EP8 konfiguratsioone.
Ainult dekodeerimise maksumus miljoni väljundtoki kohta versus dekodeerimiskiirus GPT-OSS 120B puhul järjestuse pikkusel 32 768, võrreldes EP1, EP2, EP4 ja EP8 konfiguratsioone.
Ainult dekodeerimise maksumus miljoni väljundtoki kohta versus dekodeerimiskiirus GPT-OSS 20B puhul järjestuse pikkusel 8 192, võrreldes EP1, EP2, EP4 ja EP8 konfiguratsioone.
Ainult dekodeerimise maksumus miljoni väljundtoki kohta versus dekodeerimiskiirus GPT-OSS 20B puhul järjestuse pikkusel 32 768, võrreldes EP1, EP2, EP4 ja EP8 konfiguratsioone.

Oleme kaalunud ka väiksema 20B mudeli kasutamist suurema 120B mudeli spekulatiivse dekodeerimise (speculative decoding) kavandmudelina (draft model). Kuna aga aktiveeritud parameetrite arv on sarnane (vastavalt 3B vs 5B), oli sellest saadav kiiruse kasv marginaalne.

Viited

Eraldatud eeltäitmine ja dekodeerimine (Disaggregated Prefill and Decode)

Sonari kiirendamine spekulatsiooni abil (Accelerating Sonar Through Speculation)​

Madalam latentsus ja suurem läbilaskevõime mitmesõlmelise DeepSeeki juurutusega (Lower Latency and Higher Throughput with Multi-node DeepSeek Deployment)

​Tõhus ja kaasaskantav ekspertide segu side (Efficient and Portable Mixture-of-Experts Communication)

​pplx-kernels

DeepGEMM

FlashInfer: Tõhus ja kohandatav tähelepanumootor LLM-i järelduste teenindamiseks (FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving)

Tõhusad voogedastus-keelemudelid tähelepanuaukudega (Efficient Streaming Language Models with Attention Sinks)

DeepSeek-V3 tehniline aruanne (DeepSeek-V3 Technical Report)​

​OpenAI Harmony vastuse vorming | OpenAI Cookbook (OpenAI Harmony Response Format | OpenAI Cookbook)​

Tsitaat

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