GPT-OSS pirmoje dienoje

Pirmosios dienos GPT‑OSS palaikymas H200 plokštėje pritaikant ROSE su FP8, gaudyklės dėmesiu ir MoE optimizavimu

AutoriaiPerplexity Engineering

Perplexity siekia pateikti geriausius dirbtinio intelekto modelius smalsiems naudotojams, kurie reikalauja tikslių bei patikimų atsakymų ir agentinių veiksmų. „OpenAI“ neseniai paskelbė apie savo atviro svorio modelius (gpt-oss-20b ir gpt-oss-120b). Kaip ir daugelis pirmaujančių modelių, „Perplexity“ yra viena iš pirmųjų organizacijų, įvertinusių gpt-oss-20b ir gpt-oss-120b.

Šiame įraše dalijamės mūsų vidinio išvedimo steko infrastruktūros sprendimais, kurie užtikrino „Day-0“ palaikymą. Dėmesį sutelkiame į šių modelių pateikimą naudojant „NVIDIA H200“ GPU, detaliai aptardami branduolio pakeitimus, diegimo parinktis ir greičio bei sąnaudų kompromisus.

GPT-OSS „Hopper“ architektoje

Atviro svorio modeliai pateikiami naudojant MXFP4 kvantavimą, kuris padeda jiems tilpti į vartotojo lygio aparatinės įrangos atmintį arba pasiekti didžiausią pralaidumą naudojant „NVIDIA Blackwell“. Tačiau pirminiam įvertinimui norėjome juos paleisti esamuose „H200 Hopper“ klasteriuose su minimaliais išvedimo variklio pakeitimais. „Hopper“ neturi specialių FP4 tenzoriaus branduolių, kuriuos pristatė „Blackwell“. Todėl nusprendėme modeliui naudoti FP8 tikslumą, kad sumažintume pritaikytų branduolių poreikį ir kuo geriau išnaudotume turimą aparatinę įrangą.

Apibendrinant galima teigti, kad „transformer“ tipo dideli kalbos modeliai (LLM) savo struktūra yra paprasti:

Įvesties įterpinys

„Transformer“ sluoksnių seka. Kiekviename jų yra dėmesio blokas ir tankusis MLP arba retasis MoE blokas.

Išvesties logitų proekcija

Paleisdami naują „transformer“ modelį, mes daugiausia siekiame sužinoti, kiek jis atitinka esamus modelius, kad nustatytume reikiamus pakeitimus. „OpenAI“ maloniai iš anksto pasidalijo savo modelių apžvalga, todėl galėjome atitinkamai pakoreguoti savo išvedimo sąranką. Nustatėme, kad modeliui tikrai reikėjo nemažai smulkių pakeitimų.

Dėmesys: GQA su dėmesio „gaudyklėmis“ (angl. Attention Sinks)

Kiekviena dėmesio galvutė turi iš anksto apmokytą gaudyklės parametrą, kuris įtraukiamas į „Softmax“

„YaRN“ pozicinė koduotė, panaši į „DeepSeek-V3“

QKV proekcijos turi poslinkius, panašiai kaip „Qwen 2“

Išvesties proekcija turi poslinkį

MLP: Retųjų ekspertų mišinys (angl. Sparse Mixture-of-Expert, MoE)

„SwiGLU“ aktyvavimo funkcija, besiskirianti nuo daugelio atviro svorio modelių

„Softmax“ po „Top-K“ ekspertų svoriams

Ekspertai turi poslinkius

Tikėdamiesi, kad parametrų skaičius bus apie 100B–200B, nusprendėme:

Išplėsti „FlashInfer“, kad palaikytų dėmesio gaudykles

Pakartotinai naudoti MoE diegimą, kuris jau buvo sukurtas „DeepSeek-V3“ modelių šeimai

Pasirinkti FP8 128x128 blokinį mastelį kaip kvantavimo schemą, išplečiant „DeepGEMM“ branduolius, kad jie palaikytų poslinkio narį.

Vidinis išvedimo variklis

Mūsų išvedimo pastangas palaiko mūsų vidinis išvedimo variklis ROSE. Kuriame ROSE kaip lanksčią sistemą, leidžiančią greitai paleisti naujus modelius. Be to, kai įsipareigojame aptarnauti modelį mastu, tai suteikia platformą optimizuoti ir padidinti našumą, kad būtų pasiektas aukščiausias lygis.

ROSE pateikia LLM variklį, kuris gali įkelti modelį ir generuoti jam dekoduotus žetonus per kelis dekoderius, įskaitant spėliojimo ir MTP dekoderius. Patys modeliai susideda iš pasirinktinio sluoksnių rinkinio, kuris palaiko įvairias konfigūracijos parinktis kvantavimui ir lygiagretinimui. Po sluoksniais apjungiami ir „Triton“, ir „CUDA“ branduoliai, kurie efektyviai įgyvendina ir sujungia atskirų sluoksnių atliekamus skaičiavimus.

ROSE visų pirma parašytas Python kalba ir modelių apibrėžimams remiasi PyTorch. Nors Python leidžia mums būti lanksčių ir prisitaikyti prie naujų modelių, daugumą našumui jautrių komponentų, tokių kaip aptarnavimas ir paketų planavimas, perkeliame į Rust.

Norėdami paleisti naują modelį, iš pradžių apibrėžiame modelio hierarchiją ir sukuriame jam svorių keitiklį. Kai visi svoriai yra įvertinti, apibrėžiame tiesioginį praleidimą paprasčiausiam TP=1 naudojimo atvejui ir užtikriname, kad jis veiktų nuo pradžios iki galo. Galiausiai įgyvendiname ir išbandome palaikymą įvairioms lygiagretinimo formoms, prieš išleisdami naują konteinerį ir diegdami modelį klasteryje vertinimui. Tada kartojame veiksmus siekdami geresnio našumo, remdamiesi atsiliepimais iš valdymo skydelių ir smulkesnių palyginamųjų testų.

ROSE veikia su skaitmeniniais žetonais, turėdamas mažai žinių apie pokalbio formatus, išskyrus integravimo testus. Lygiagrečiai turėjome panagrinėti galimybę pritaikyti esamą infrastruktūrą, kad ji palaikytų „Harmony“ žetonizatorių ir teisingai susietų užklausas su įvesties žetonų sekomis.

Naudodant GPT OSS modelį paaiškėjo, kad jokių pakeitimų mūsų dekoderiams, „CUDA graph“ įrankiams ar supančiai infrastruktūrai nereikėjo, todėl galėjome sutelkti savo pastangas ties modelį palaikančių branduolių koregavimu.

GPT-OSS branduoliai

Gaudyklės dėmesys (angl. Sink Attention)

Gaudyklės dėmesys prieš „Softmax“ įveda papildomą poslinkio koeficientą, kuris sumuojamas su Q ir K sandauga:

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

Nors supaprastintas įgyvendinimas yra gana nesudėtingas, efektyvūs dėmesio įgyvendinimai, tokie kaip „FlashInfer“, lygiagrečiai atlieka dėmesio skaičiavimus tiek tarp nepriklausomų galvučių, tiek per KV sekos ilgį. Be to, siekiant skaitinio stabilumo, „Softmax“ apskaičiuojamas internetiniu būdu, kartu atimant didžiausią elementą:

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

Internetinis įgyvendinimas stebėjo veikiantį maksimumą m, inicijuotą į -inf, ir mastelį d, nustatytą į 1. Inicijuodami maksimumą dabartinės galvutės gaudyklės reikšme, užtikrintume, kad jis būtų teisingai įtrauktas į „Softmax“. Turėjome pasirūpinti, kad šis maksimumas būtų įtrauktas tik į pirmąjį bloką, jei dėmesys buvo padalintas į kelis blokus išilgai sekos ilgio.

Koregavome „FlashInfer FA2“ branduolio šabloną, naudojamą tiek generavimo pradžioje (prefill), tiek dekodavimui, kad jis apimtų gaudyklės parametrus.

MoE

Pagrindinis skirtingų modelių MoE sluoksnio skirtumas paprastai yra nukreipimo schema. Tikėdamasis didelių skirtumų, ROSE šį branduolį įgyvendina „Triton“ aplinkoje, todėl galime lengvai jį pritaikyti naujiems modeliams. GPT-OSS atveju turėjome pakoreguoti svorių vertinimą, kad „softmax“ būtų atliekamas tik tarp „Top-K“ atrinktų ekspertų, skirtingai nuo kai kurių „DeepSeek“ tipo modelių, kurie „softmax“ skaičiuoja visiems ekspertams. Nustatėme, kad tikslumui užtikrinti labai svarbu ekspertų svorius skaičiuoti bfloat16 tikslumu.

Iššūkis su MoE sluoksniu kilo dėl mūsų sprendimo pakartotinai naudoti esamus „DeepGEMM“ branduolius, kuriuose nebuvo poslinkio narių palaikymo. Laimei, bėgant laikui glaudžiai su jais integruokimės, atlikdami pakeitimus, kad geriau sujungtume juos su mūsų pritaikytais „all-to-all“ paskirstymo branduoliais. Pridėjome poslinkio palaikymą prie „DeepGEMM“, inicijuodami „WGMMA“ kaupiklio registrus poslinkio reikšmėmis, įkeltomis iš atminties. Tai vienkartinis veiksmas apdorojant MN bloką, todėl sąnaudos greičiausiai yra nereikšmingos, o L2 spartioji atmintinė užtikrina veiksmingą prieigą prie šių reikšmių.

Kadangi šie modeliai tiesiogiai negauna naudos iš duomenų lygiagretinimo, mes pakartotinai naudojome tik TP skirtus paskirstymo ir sujungimo branduolius. Paskirstymo įvestys yra replikuojamos visuose ranguose, todėl paskirstymas atrenka žetonus vietoje pasiekiamiems ekspertams. Sujungimas atlieka svertinį kaupimą per NVLink.

Našumo koregavimai

Nors mūsų tikslas buvo greitai paleisti modelius, norėjome užtikrinti, kad našumas išliktų priimtinas. Įsitikinę teisingumu, palyginti su „OpenAI“ pateiktu etaloniniu įgyvendinimu, atlikome savo įgyvendinimo profiliavimą naudodami numatytąjį „PyTorch“ profiliuoklį, stebėdami blokų ir gijų paskirstymą branduoliuose. Pakartotinai panaudotas funkcionalumas buvo sukurtas modeliams, kurių didesnis paslėptas matmuo buvo 7168 – gerokai didesnis nei GPT-OSS modelių 2880. Optimizavome branduolių paleidiklius, kad parinktume geresnių tinklų matmenis, taip smarkiai padidindami pralaidumą.

Tokenizavimas ir kanalai

„Harmony“ pokalbio formatas turi kelias svarbias koncepcijas, skirtas pokalbiams, argumentavimo turiniui ir funkcijų iškvietimams struktūrizuoti. Šiame formate kiekvieną pranešimą sudaro antraštė ir turinys:

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

Antraštėje pateikiami metaduomenys – svarbiausia rolis (sistema, kūrėjas, naudotojas, asistentas, įrankis), kanalas ir gavėjas, pavyzdžiui, to=functions.<function-name>, kai iškviečiamas įrankis.

Kanalai (tokie kaip analizė, komentarai ir galutinis atsakymas) padaro modelio išvestis labiau suprantamas ir suskirstytas į segmentus. Kadangi formatas reikalauja šio atskyrimo, modelis gali argumentuoti skaidriai (ir būti tikrinamas derinimo tikslais), neįtraukdamas minties grandinės į gamybinę aplinką. Gavėjo žymos (to= antraštės) tiksliai nurodo vykdymo terpei, kuris aktorius turėtų gauti kitą duomenų paketą – ar tai būtų funkcija, pats modelis, ar galutinis naudotojas.

Mūsų išvedimo variklis ROSE yra nepriklausomas nuo formato. Jis gauna įvesties žetonų paketą ir srautu grąžina išvesties žetonus. Mūsų išvedimo steke įvesties formatavimo į žetonizuotą užklausą ir LLM rezultatų analizavimo į struktūrizuotus pranešimus užduotį atlieka specialiai tam skirta JSON API priekinės dalies tarnyba. Integravome „Harmony“ pridėdami naują prijungiamą formatavimo / analizavimo įrankį prie šios priekinės dalies, leisdami galinei daliai likti nepakeistai, kol priekinė dalis švariai tvarko pokalbio formato taisykles, įrankių iškvietimus ir srautinį perdavimą. Toks rūpesčių atskyrimas išlaiko architektūrą moduliatyvią, leidžiančią greitai pritaikyti naujus formatus ir atsakymo funkcijas su minimaliais galinės dalies pakeitimais.

Sąnaudos ir našumas

Atsižvelgdami į santykinai mažą GPT-OSS modelių dydį, ribojame replikos diegimą vienu mazgu, kad išvengtume tarpmazginio ryšio pridėtinės išlaidos. Mūsų įgyvendinimas palaiko lanksčius ekspertų lygiagretinimo (EP), duomenų lygiagretinimo (DP) ir tenzoriaus lygiagretinimo (TP) derinius. Norėdami nustatyti optimalią diegimo sąranką, atlikome visų skaidymo strategijų derinių etaloninius testus, naudodami paketo dydžius nuo 1 iki 128. Dėl paruošiamojo generavimo ir dekodavimo disagregavimo galime atskirai aptarti našumo ir sąnaudų kompromisą paruošiamajam generavimui ir dekodavimui.

Sąnaudų sąmatoms darome prielaidą, kad vardinė H200 rinkos kaina yra 3,00 USD per valandą (pastaba: tai nėra mūsų tikroji GPU kaina).

Nustatėme, kad nustačius batch_size=1 ir DP=1 pasiekiamas geriausias paruošiamojo generavimo našumas. Skirtingos TP konfigūracijos užtikrina skirtingus kompromisus tarp pirmojo žetono delsos ir sąnaudų. Žemiau pateiktose lentelėse pateikiama paruošiamojo generavimo delsa ir sąnaudos milijonui įvesties žetonų įvairioms konfigūracijoms bei įvesties ilgiams.

GPT-OSS 120B:

Įvesties ilgis

8192

32768

65536

128000

EP1 DP1 TP1

0,364s, 0,037 USD

2,421s, 0,062 USD

7,375s, 0,094 USD

23,902s, 0,156 USD

EP2 DP1 TP2

0,190s, 0,039 USD

1,245s, 0,063 USD

3,786s, 0,096 USD

12,116s, 0,158 USD

EP4 DP1 TP4

0,165s, 0,067 USD

0,900s, 0,092 USD

2,449s, 0,125 USD

7,165s, 0,187 USD

EP8 DP1 TP8

0,179s, 0,145 USD

0,839s, 0,171 USD

2,003s, 0,204 USD

5,119s, 0,267 USD

GPT-OSS 120B prefikso vėlinis ir kaina už milijoną įvesties žetonų pagal lygiagretumo konfigūraciją ir įvesties ilgį.

GPT-OSS 20B:

Įvesties ilgis

8192

32768

65536

128000

EP1 DP1 TP1

0,239s, 0,024 USD

1,610s, 0,041 USD

4,895s, 0,062 USD

16,037s, 0,104 USD

EP2 DP1 TP2

0,127s, 0,026 USD

0,833s, 0,042 USD

2,522s, 0,064 USD

8,143s, 0,106 USD

EP4 DP1 TP4

0,108s, 0,044 USD

0,593s, 0,060 USD

1,616s, 0,082 USD

4,766s, 0,124 USD

EP8 DP1 TP8

0,116s, 0,094 USD

0,547s, 0,111 USD

1,310s, 0,133 USD

3,365s, 0,175 USD

GPT-OSS 20B prefikso vėlinis ir kaina už milijoną įvesties žetonų pagal lygiagretumo konfigūraciją ir įvesties ilgį.

Dekodavimui nustatėme, kad EP4 DP1 TP4 yra geriausia konfigūracija daugeliu atvejų. Keturios diagramos žemiau iliustruoja kompromisą tarp dekodavimo greičio ir sąnaudų milijonui išvesties žetonų tiek 120B, tiek 20B modeliams 8192 ir 32768 sekos ilgiams.

Tik dekodavimo kaina už milijoną išvesties žetonų, palyginti su dekodavimo sparta GPT-OSS 120B modeliui esant 8 192 sekos ilgiui, lyginant EP1, EP2, EP4 ir EP8 konfigūracijas.
Tik dekodavimo kaina už milijoną išvesties žetonų, palyginti su dekodavimo sparta GPT-OSS 120B modeliui esant 32 768 sekos ilgiui, lyginant EP1, EP2, EP4 ir EP8 konfigūracijas.
Tik dekodavimo kaina už milijoną išvesties žetonų, palyginti su dekodavimo sparta GPT-OSS 20B modeliui esant 8 192 sekos ilgiui, lyginant EP1, EP2, EP4 ir EP8 konfigūracijas.
Tik dekodavimo kaina už milijoną išvesties žetonų, palyginti su dekodavimo sparta GPT-OSS 20B modeliui esant 32 768 sekos ilgiui, lyginant EP1, EP2, EP4 ir EP8 konfigūracijas.

Taip pat apsvarstėیم galimybę naudoti mažesnį 20B modelį kaip spėjamojo dekodavimo juodraščio modelį didesniam 120B modeliui. Tačiau kadangi aktyvuotų parametrų skaičius yra panašus (3B vs. 5B), gautas greitėjimas buvo nedidelis.

Literatūra

Atsietas paruošiamasis generavimas ir dekodavimas

„Sonar“ spartinimas per spėliojimą​

Mažesnė delsa ir didesnis pralaidumas naudojant kelių mazgų „DeepSeek“ diegimą

​Efektyvus ir nešiojamas ekspertų mišinio ryšys

​pplx-kernels

DeepGEMM

„FlashInfer“: efektyvus ir pritaikomas dėmesio variklis LLM išvedimo aptarnavimui

Efektyvūs srautiniai kalbos modeliai su dėmesio gaudyklėmis

„DeepSeek-V3“ techninė ataskaita​

​„OpenAI Harmony“ atsakymo formatas | „OpenAI Cookbook“​

Citata

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