GPT-OSS 0. dienā

0. dienas atbalsts GPT‑OSS uz H200, pielāgojot ROSE ar FP8, notekcaurules uzmanību un MoE optimizācijām

AutoriPerplexity Engineering

Perplexity apņemas nodrošināt labākos AI modeļus interesentiem, kuri pieprasa precīzas un uzticamas atbildes un aģentu darbības. OpenAI nesen paziņoja par saviem atklātā svara modeļiem (gpt-oss-20b un gpt-oss-120b). Tāpat kā daudzi vadošie modeļi, Perplexity ir starp pirmajām organizācijām, kas novērtē gpt-oss-20b un gpt-oss-120b.

Šajā ierakstā mēs dalāmies ar mūsu iekšējās secināšanas (inference) steka infrastruktūras lēmumiem, kas padarīja iespējamu 0. dienas atbalstu. Mēs koncentrējamies uz šo modeļu apkalpošanu uz NVIDIA H200 GPU, detalizēti aprakstot kodola (kernel) izmaiņas, izvietošanas izvēles un ātruma un izmaksu kompromisus.

GPT-OSS uz Hopper

Atklātā svara modeļi tiek piegādāti, izmantojot MXFP4 kvantēšanu, kas palīdz tiem iekļauties patērētāju klases aparatūras atmiņā vai sasniegt maksimālo caurlaidību uz NVIDIA Blackwell. Tomēr sākotnējai novērtēšanai mēs vēlējāmies tos palaist uz esošajiem H200 Hopper klasteriem ar minimālām secināšanas dzinēja izmaiņām. Hopper nav īpašu FP4 tenzora kodolu, ko ieviesa Blackwell. Līdz ar to mēs nolēmām apkalpot modeļus ar FP8 precizitāti, lai samazinātu vajadzību pēc pielāgotiem kodoliem un vislabāk izmantotu pieejamo aparatūru.

Augstākajā līmenī transformatoru valodas modeļi (LLM) ir strukturāli vienkārši:

Ievades iegulšana (embedding)

Transformatoru slāņu secība. Katra satur uzmanības (attention) bloku un blīvu MLP vai retu MoE bloku.

Izvades logit projekcija

Ieviešot jaunu transformatora modeli, mēs galvenokārt ceram uzzināt, tādā mērā tie atbilst esošajiem modeļiem, lai identificētu nepieciešamās izmaiņas. OpenAI laipni dalījās ar savu modeļu pārskatu iepriekš, ļaujot mums attiecīgi pielāgot mūsu secināšanas iestatīšanu. Mēs atklājām, ka modelim bija nepieciešams diezgan liels skaits nelielu izmaiņu.

Uzmanība (Attention): GQA ar uzmanības notekcaurulēm (Attention Sinks)

Katrai uzmanības galviņai ir iepriekš apmācīts notekcaurules (sink) parametrs, kas tiek ņemts vērā Softmax

YaRN pozicionālais kodējums, līdzīgi kā DeepSeek-V3

QKV projekcijām ir nobīdes (biases), līdzīgi kā Qwen 2

Izvades projekcijai ir nobīde

MLP: Retais ekspertu maisījums (Sparse Mixture-of-Expert - MoE)

SwiGLU aktivizācijas funkcija, atšķirībā no vairuma atklātā svara modeļu

Softmax pēc Top-K ekspertu svariem

Ekspertiem ir nobīdes

Sagaidot, ka parametru skaits būs aptuveni 100B-200B, mēs nolēmām:

Paplašināt FlashInfer, lai atbalstītu uzmanības notekcaurules

Atkārtoti izmantot MoE ieviešanu, kas jau izveidota DeepSeek-V3 modeļu saimei

Izvēlēties FP8 128x128 bloku mērogošanu kā kvantēšanas shēmu, paplašinot DeepGEMM kodolus, lai atbalstītu nobīdes terminu.

Iekšējais secināšanas dzinējs

Mūsu secināšanas centienus atbalsta mūsu iekšējais secināšanas dzinējs ROSE. Mēs veidojam ROSE par elastīgu sistēmu, kas ļauj ātri ieviest jaunos modeļus. Turklāt, kad esam apņēmušies apkalpot modeli mērogā, tā nodrošina platformu veiktspējas optimizēšanai un uzlabošanai, lai sasniegtu vismodernāko līmeni.

ROSE nodrošina LLM dzinēju, kas var ielādēt modeli un ģenerēt tam atšifrētus tokenus, izmantojot vairākus dekoderus, tostarp spekulatīvos un MTP dekoderus. Paši modeļi sastāv no pielāgotu slāņu kopas, kas atbalsta dažādas konfigurācijas kvantēšanai un paralēlumam. Zem slāņiem tas apvieno gan Triton, gan CUDA kodolus, kas efektīvi īsteno un sapludina atsevišķu slāņu veiktos aprēķinus.

ROSE galvenokārt ir veidots Python valodā un balstās uz PyTorch modeļu definīcijām. Lai gan Python ļauj mums būt elastīgiem un pielāgoties jauniem modeļiem, mēs migrējam lielāko daļu veiktspējas ziņā jutīgo komponenšu, piemēram, apkalpošanu un pakešu plānošanu, uz Rust.

Lai ieviestu jaunu modeli, mēs vispirms definējam modeļa hierarhiju un izveidojam tam svara pārveidotāju. Kad visi svari ir ņemti vērā, mēs definējam uz priekšu vērstu gaitu (forward pass) vienkāršākajam TP=1 lietošanas gadījumam un nodrošinām, ka tas darbojas no gala līdz galam. Visbeidzot, mēs ieviešam un testējam atbalstu dažādām paralēlisma formām, pirms izlaižam jaunu konteineru un izvietojam modeli klasterī novērtēšanai. Pēc tam mēs iteratīvi uzlabojam veiktspēju, balstoties uz atgriezenisko saiti gan no informācijas paneļiem, gan detalizētākiem etalontestiem.

ROSE darbojas ar skaitliskiem tokeniem, un tam ir maz zināšanu par tērzēšanas formātiem ārpus integrācijas testiem. Paralēli mums nācās izpētīt apkārtējās infrastruktūras pielāgošanu, lai atbalstītu Harmony tokenizētāju un pareizi kartētu pieprasījumus ievades tokenu secībām.

Izmantojot GPT OSS modeli, mēs atklājām, ka mūsu dekoderiem, CUDA grafiku palīgdarbarīkiem vai apkārtējai infrastruktūrai nebija vajadzīgas nekādas izmaiņas, ļaujot mums koncentrēt savus spēkus uz modeļa pamatā esošo kodolu pielāgošanu.

GPT-OSS kodoli

Notekcaurules uzmanība (Sink Attention)

Notekcaurules uzmanība ievieš papildu nobīdes koeficientu pirms Softmax, kas tiek sakrāts ar Q un K reizinājumu:

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

Lai gan naiva ieviešana ir diezgan vienkārša, efektīvas uzmanības ieviešanas, piemēram, FlashInfer, paralelizē uzmanības aprēķinus gan starp neatkarīgām galviņām, gan KV secības garumā. Turklāt skaitliskajai stabilitātei Softmax tiek aprēķināts tiešsaistē, vienlaikus atņemot maksimālo elementu skaitliskajai stabilitātei:

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

Tiešsaistes ieviešana sekoja līdzi tekošajam maksimumam m, kas inicializēts ar -inf, un skalai d līdz 1. Inicializējot maksimumu ar pašreizējās galviņas notekcaurules vērtību, mēs nodrošinātu, ka tas pareizi uzkrājas Softmax. Mums bija jārūpējas par to, lai šis maksimums tiktu iekļauts tikai pirmajā blokā, ja uzmanība tika sadalīta vairākos blokos gar secības garumu.

Mēs esam pielāgojuši FlashInfer FA2 kodola veidni, ko izmanto gan iepriekšējai aizpildīšanai (prefill), gan atšifrēšanai (decode), lai iekļautu notekcaurules parametrus.

MoE

Galvenā atšķirība starp dažādu modeļu MoE slāni parasti ir maršrutēšanas shēma. Sagaidot būtisku mainīgumu, ROSE ievieš šo kodolu Triton, ļaujot mums to viegli pielāgot jauniem modeļiem. GPT-OSS gadījumā mums bija jāpielāgo svara vērtēšana (weight scoring), lai veiktu softmax tikai starp Top-K atlasītajiem ekspertiem, atšķirībā no dažiem DeepSeek stila modeļiem, kas aprēķina softmax visiem ekspertiem. Mēs atklājām, ka precizitātei ir izšķiroši svarīgi aprēķināt ekspertu svarus bfloat16 precizitātē.

Izaicinājums ar MoE slāni radās mūsu lēmuma dēļ atkārtoti izmantot esošos DeepGEMM kodolus, kuriem trūka atbalsta nobīdes terminiem. Par laimi, laika gaitā mēs tajos dziļi integrējāmies, veicot izmaiņas, lai tos labāk savienotu ar mūsu pielāgotajiem visu-pret-visu (all-to-all) nosūtīšanas kodoliem. Mēs pievienojām nobīdes atbalstu DeepGEMM, inicializējot WGMMA uzkrājēja reģistrus ar no atmiņas ielādētajām nobīdes vērtībām. Šī ir vienreizēja darbība MN bloka apstrādes laikā, tāpēc izmaksas, visticamāk, ir niecīgas, un L2 kešatmiņa nodrošina efektīvu piekļuvi šīm vērtībām.

Tā kā šie modeļi negūst tiešu labumu no datu paralēlisma, mēs atkārtoti izmantojām tikai TP nosūtīšanas un apvienošanas kodolus. Ievades dati nosūtīšanai tiek dublēti visos rangos, tāpēc nosūtīšana atlasa tokenus lokāli pieejamiem ekspertiem. Apvienošana veic svērto uzkrāšanu visā NVLink.

Veiktspējas pielāgojumi

Lai gan mūsu mērķis bija ātri ieviest modeļus, mēs vēlējāmies nodrošināt, ka veiktspēja joprojām ir saprātīga. Pēc pareizības pārbaudes pret OpenAI nodrošināto atsauces ieviešanu, mēs profilējām mūsu ieviešanu, izmantojot noklusējuma PyTorch profilētāju, uzmanot bloku un pavedienu alokācijas starp kodoliem. Funkcionalitāte, ko mēs izmantojām atkārtoti, tika izveidota modeļiem, kuru slēpto dimensiju izmērs bija lielāks – 7168, kas ir ievērojami lielāks nekā GPT-OSS modeļu 2880. Mēs specializējām kodolu palaidējus, lai izvēlētos labākus režģa izmērus, ievērojami palielinot caurlaidību.

Marķierizācija un kanāli

Harmony tērzēšanas formātam ir vairāki svarīgi jēdzieni sarunu strukturēšanai, pamatojuma saturam un funkciju izsaukumiem. Šajā formātā katrs ziņojums sastāv no galvenes un satura:

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

Galvene ietver metadatus — pats galvenais ir loma (sistēma, izstrādātājs, lietotājs, asistents, rīks), kanāls un saņēmējs, piemēram, to=functions.<function-name>, kad tiek izsaukts rīks.

Kanāli (piemēram, analīze, komentāri un galīgā atbilde) padara modelis izvades pārskatāmākas un segmentētākas. Tā kā formāts uzspiež šo atdalīšanu, modelis var pamatot caurskatāmi (un tikt pārbaudīts traucējummeklēšanai), neizplūdinot domāšanas ķēdi (chain-of-thought) ražošanas vidē. Saņēmēja tagi (to= galvenes) norāda izpildlaikam tieši, kuram aktoram vajadzētu saņemt nākamo datu kopu – neatkarīgi no tā, vai tā ir funkcija, pats modelis vai galalietotājs.

Mūsu secināšanas dzinējs ROSE ir neatkarīgs no formāta. Tas saņem ievades tokenu paketi un straumē atpakaļ izvades tokenus. Mūsu secināšanas stekā ievades formatēšanas uzdevumu tokenizētā promptā un LLM rezultātu parsēšanu atpakaļ strukturētos ziņojumos veic īpašs JSON API galalietas (frontend) serviss. Mēs integrējām Harmony, pievienojot šim priekšgalam jaunu, pievienojamu formatētāju/parsētāju, ļaujot aizmugurei palikt nemainīgai, kamēr priekšgals glīti pārvalda tērzēšanas formāta likumus, rīku izsaukumus un straumēšanu. Šī rūpju atdalīšana uztur arhitektūru modulāru, nodrošinot ātru jaunu formātu, atbilžu funkciju ieviešanu ar minimālām aizmugures izmaiņām.

Izmaksas un veiktspēja

Ņemot vērā GPT-OSS modeļu relatīvi mazo izmēru, mēs ierobežojam replikas izvietošanu uz viena mezgula, lai izvairītos no mezgulu savstarpējās saziņas pieskaitāmajām izmaksām. Mūsu ieviešana atbalsta elastīgas ekspertu paralēlisma (EP), datu paralēlisma (DP) un tenzora paralēlisma (TP) kombinācijas. Lai noteiktu optimālo izvietošanas iestatījumu, mēs veicām visu šardēšanas stratēģiju kombināciju etalontestēšanu visām pakešu izmērām no 1 līdz 128. Pateicoties Prefill-Decode Disaggregation, mēs varam atsevišķi apspriest veiktspējas un izmaksu kompromisu iepriekšējai aizpildīšanai un atšifrēšanai.

Izmaksu aprēķiniem mēs pieņemam nominālo H200 tirgus likmi $3.00/stundā (ņemiet vērā: šī nav mūsu faktiskā GPU cena).

Mēs atklājām, ka batch_size=1 un DP=1 iestatīšana nodrošina vislabāko iepriekšējas aizpildīšanas veiktspēju. Dažādas TP konfigurācijas pēc tam sniedz dažādus kompromisus starp pirmā tokena latentumu un izmaksām. Tabulas zemāk parāda iepriekšējas aizpildīšanas latentumu un izmaksas uz miljonu ievades tokenu dažādām konfigurācijām un ievades garumiem.

GPT-OSS 120B:

Ievades garums

8192

32768

65536

128000

EP1 DP1 TP1

0.364s, $0.037

2.421s, $0.062

7.375s, $0.094

23.902s, $0.156

EP2 DP1 TP2

0.190s, $0.039

1.245s, $0.063

3.786s, $0.096

12.116s, $0.158

EP4 DP1 TP4

0.165s, $0.067

0.900s, $0.092

2.449s, $0.125

7.165s, $0.187

EP8 DP1 TP8

0.179s, $0.145

0.839s, $0.171

2.003s, $0.204

5.119s, $0.267

GPT-OSS 120B priekšuzpildes latentums un izmaksas uz miljonu ievades tokenu atkarībā no paralelizācijas konfigurācijas un ievades garuma.

GPT-OSS 20B:

Ievades garums

8192

32768

65536

128000

EP1 DP1 TP1

0.239s, $0.024

1.610s, $0.041

4.895s, $0.062

16.037s, $0.104

EP2 DP1 TP2

0.127s, $0.026

0.833s, $0.042

2.522s, $0.064

8.143s, $0.106

EP4 DP1 TP4

0.108s, $0.044

0.593s, $0.060

1.616s, $0.082

4.766s, $0.124

EP8 DP1 TP8

0.116s, $0.094

0.547s, $0.111

1.310s, $0.133

3.365s, $0.175

GPT-OSS 20B priekšuzpildes latentums un izmaksas uz miljonu ievades tokenu atkarībā no paralelizācijas konfigurācijas un ievades garuma.

Atšifrēšanai (decode) mēs atklājām, ka EP4 DP1 TP4 ir labākā konfigurācija vairumā gadījumu. Četri grafiki zemāk ilustrē kompromisu starp atšifrēšanas ātrumu un izmaksām uz miljonu izvades tokenu gan 120B, gan 20B modeļiem 8192 un 32768 secības garumos.

Tikai dekodēšanas izmaksas uz miljonu izvades tokenu salīdzinājumā ar dekodēšanas ātrumu GPT-OSS 120B pie secības garuma 8 192, salīdzinot EP1, EP2, EP4 un EP8 konfigurācijas.
Tikai dekodēšanas izmaksas uz miljonu izvades tokenu salīdzinājumā ar dekodēšanas ātrumu GPT-OSS 120B pie secības garuma 32 768, salīdzinot EP1, EP2, EP4 un EP8 konfigurācijas.
Tikai dekodēšanas izmaksas uz miljonu izvades tokenu salīdzinājumā ar dekodēšanas ātrumu GPT-OSS 20B pie secības garuma 8 192, salīdzinot EP1, EP2, EP4 un EP8 konfigurācijas.
Tikai dekodēšanas izmaksas uz miljonu izvades tokenu salīdzinājumā ar dekodēšanas ātrumu GPT-OSS 20B pie secības garuma 32 768, salīdzinot EP1, EP2, EP4 un EP8 konfigurācijas.

Mēs esam apsvēruši arī mazākā 20B modeļa izmantošanu kā speculatīvās dekodēšanas melnraksta modeli lielākam 120B modelim. Tomēr, tā kā aktivizēto parametru skaits ir līdzīgs (3B pret 5B), iegūtais paātrinājums bija margināls.

Atsauces

Sadalīta iepriekšēja aizpildīšana un atšifrēšana

Sonar paātrināšana, izmantojot spekulācijas​

Zemāks latentums un augstāka caurlaidība ar vairāku mezglu DeepSeek izvietošanu

​Efektīva un pārnēsājama ekspertu maisījuma saziņa

​pplx-kernels

DeepGEMM

FlashInfer: Efektīvs un pielāgojams uzmanības dzinējs LLM secināšanas apkalpošanai

Efektīvi straumēšanas valodas modeļi ar uzmanības notekcaurulēm

DeepSeek-V3 tehniskais ziņojums​

​OpenAI Harmony atbildes formāts | OpenAI Cookbook​

Citāts

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