GPT-OSS på dag 0

Perplexity har forpliktet seg til å gjøre de beste KI-modellene tilgjengelige for nysgjerrige personer som krever nøyaktige og pålitelige svar og agenthandlinger. OpenAI kunngjorde nylig sine modeller med åpne vekter (gpt-oss-20b og gpt-oss-120b). Som med mange ledende modeller, er Perplexity blant de første organisasjonene som evaluerer gpt-oss-20b og gpt-oss-120b.

I dette innlegget deler vi infrastrukturbeslutningene for vår interne inferensstabel som gjorde Dag-0-støtte mulig. Vi fokuserer på å kjøre disse modellene på NVIDIA H200 GPU-er, og detaljerer kjerneendringene, distribusjonsvalgene og avvejningene mellom hastighet og kostnad.

GPT-OSS på Hopper

Modellene med åpne vekter leveres med MXFP4-kvantisering, noe som bidrar til at de får plass i minnet på maskinvare for forbrukermarkedet eller oppnår maksimal gjennomstrømning på NVIDIA Blackwell. For innledende evaluering ønsket vi imidlertid å kjøre dem på eksisterende H200 Hopper-klynger med minimale endringer i inferensmotoren. Hopper har ikke dedikerte FP4-tensorkjerner, som ble introdusert av Blackwell. Følgelig besluttet vi å betjene modellene med FP8-presisjon i stedet for å minimere behovet for egendefinerte kjerner og utnytte den tilgjengelige maskinvaren på best mulig måte.

På et overordnet nivå er transformator-LLM-er strukturelt enkle:

Inndataembedding

En sekvens av transformatorlag. Hvert lag inneholder en oppmerksomhetsblokk og en tett MLP- eller glissen MoE-blokk.

Utdatalogit-projeksjon

Når vi tar i bruk en ny transformatormodell, er vi først og fremst interessert i å finne ut i hvilken grad de samsvarer med eksisterende modeller for å identifisere hvilke endringer som kreves. OpenAI delte vennligst en oversikt over modellene sine på forhånd, slik at vi kunne finjustere inferensoppsettet vårt deretter. Vi fant ut at modellen krevde ganske mange små endringer.

Oppmerksomhet: GQA med oppmerksomhetssluk (Attention Sinks)

Hvert oppmerksomhetshode har en forhåndstrent slukparameter som regnes med i Softmax

YaRN-posisjonsenkoding, i likhet med DeepSeek-V3

QKV-projeksjoner har skjevheter (biases), i likhet med Qwen 2

Utdataprojeksjon har skjevhet

MLP: Glissen blanding av eksperter (Sparse Mixture-of-Expert - MoE)

SwiGLU-aktiveringsfunksjon, forskjellig fra de fleste modeller med åpne vekter

Softmax etter Top-K for ekspertvekter

Eksperter har skjevheter

Da vi forventet at antall parametere ville være rundt 100B–200B, besluttet vi å:

Utvide FlashInfer til å støtte oppmerksomhetssluk

Gjenbruke MoE-implementeringen som allerede er bygget for DeepSeek-V3-familien av modeller

Velge FP8 128x128 blokkskalering som kvantiseringsskjema, og utvide DeepGEMM-kjernene til å støtte en skjevhetsterm.

Intern inferensmotor

Vårt inferensarbeid støttes av vår interne inferensmotor, ROSE. Vi bygger ut ROSE til å være et fleksibelt rammeverk som gjør det raskt å ta i bruk nye modeller. I tillegg, når vi først har forpliktet oss til å betjene en modell i stor skala, gir den en plattform for å optimalisere og øke ytelsen for å nå det ypperste nivået.

ROSE eksponerer en LLM-motor som kan laste inn en modell og generere avkodede tokens for den gjennom flere avkodere, inkludert spekulative og MTP-avkodere. Selve modellene består av et egendefinert sett med lag som støtter ulike konfigurasjonsinnstillinger for kvantisering og parallellitet. Under lagene samler den både Triton- og CUDA-kjerner som effektivt implementerer og fuserer beregningene utført av individuelle lag.

ROSE er primært bygget i Python og er avhengig av PyTorch for modelldefinisjoner. Selv om Python gir oss fleksibilitet til å tilpasse oss nye modeller, migrerer vi de fleste ytelsessensitive komponenter, slik som betjening og satsvis planlegging (batch scheduling), til Rust.

For å ta i bruk en ny modell definerer vi først modellhierarkiet og bygger en vektomformer for det. Etter at det er tatt høyde for alle vekter, definerer vi en framoverretning (forward pass) for det enkleste TP=1-brukstilfellet og sikrer at det fungerer fra ende til annen. Til slutt implementerer og tester vi støtte for ulike former for parallellitet før vi frigiir en ny beholder og distribuerer modellen på en klynger for evaluering. Deretter itererer vi på ytelse, med støtte i tilbakemeldinger fra både dashbord og mer finkornede ytelsestester (benchmarks).

ROSE opererer på numeriske tokens, med liten kjennskap til chat-formater utenfor integrasjonstester. Parallelt måtte vi se på å justere den omliggende infrastrukturen for å støtte Harmony-tokenisereren og korrekt tilordne forespørsler til inndatatokensekvenser.

Med GPT OSS-modellen fant vi ut at det ikke var nødvendig med noen endringer i våre avkodere, CUDA-graframmeverk eller omliggende infrastruktur, noe som gjorde at vi kunne fokusere innsatsen på å finjustere kjernene som ligger til grunn for modellen.

Kjerner for GPT-OSS

Slukoppmerksomhet (Sink Attention)

Slukoppmerksomhet introduserer en ekstra skjevhetsfaktor før softmax, akkumulert med produktet av Q og K:

Selv om en naiv implementering er ganske triviell, vil effektive oppmerksomhetsimplementeringer, som FlashInfer, parallellisere beregningen av oppmerksomhet på tvers av både uavhengige hoder og på tvers av KV-sekvenslengden. I tillegg, for numerisk stabilitet, beregnes Softmax på nett (online) samtidig som det maksimale elementet trekkes fra for numerisk stabilitet:

Den nettet (online) implementeringen sporet et løpende maksimum m initialisert til -inf og en skala d til 1. Ved å initialisere maksimumet til slukverdien for det gjeldende hodet, sikret vi at det ble akkumulert inn i Softmax på riktig måte. Vi måtte passe på å sikre at dette maksimumet bare ble inkludert i den første chunk-en hvis oppmerksomheten ble delt på tvers av flere blokker langs sekvenslengden.

Vi har justert FlashInfer FA2-kjernemalen, som brukes til både prefill og avkoding, til å inkludere slukparameterne.

MoE

Hovedforskjellen mellom MoE-laget i ulike modeller er vanligvis rutingskjemaet. Siden vi forventet vesentlig variabilitet, implementerer ROSE denne kjernen i Triton, slik at vi enkelt kan tilpasse den til nye modeller. Når det gjelder GPT-OSS, måtte vi justere vektpoengberegningen for å utføre softmax bare på tvers av de utvalgte Top-K-ekspertene, i motsetning til noen modeller i DeepSeek-stil som beregner softmax på tvers av alle eksperter. Vi fant ut at det er kritisk for nøyaktigheten å beregne ekspertvektene i bfloat16-presisjon.

Utfordringen med MoE-laget skyldtes vår beslutning om å gjenbruke de eksisterende DeepGEMM-kjernene, som manglet støtte for skjevhetstermer. Heldigvis integrerte vi oss dypt med dem over tid, og gjorde endringer for å koble dem bedre sammen med våre egendefinerte all-to-all-utsendelseskjerner. Vi la til skjevhetsstøtte i DeepGEMM ved å initialisere WGMMA-akkumulatorregistrene til skjevhetsverdiene som ble lastet inn fra minnet. Dette skjer en enkelt gang under behandlingen av en MN-blokk, så kostnaden er sannsynligvis ubetydelig, og L2-mellomlageret sikrer effektiv tilgang til disse verdiene.

Siden disse modellene ikke har umiddelbar nytte av dataparallellitet, gjenbrukte vi utsendelses- og kombinasjonskjerner som kun bruker TP. Inndataene til utsendelsen replikeres på tvers av alle rangeringer, slik at utsendelsen velger tokens for de lokalt tilgjengelige ekspertene. Kombinasjon utfører den veide akkumuleringen på tvers av NVLink.

Ytelsesfinjusteringer

Selv om målet vårt var å få modellene raskt på plass, ønsket vi å sikre at ytelsen fortsatt var rimelig. Etter å ha sikret korrekthet mot en referanseimplementering levert av OpenAI, profilerte vi implementeringen vår ved hjelp av standard PyTorch-profilereren, og fulgte med på blokk- og trådtildelinger på tvers av kjernene. Funksjonaliteten vi gjenbrukte, ble bygget for modeller som hadde en større skjult dimensjon på 7168, betydelig større enn de 2880 i GPT-OSS-modellene. Vi spesialiserte kjernestarterne for å velge bedre rutenettdimensjoner, noe som økte gjennomstrømningen betydelig.

Tokenisering og kanaler

Harmony sin chat-format har flere viktige konsepter for strukturering av samtaler, resonnementinnhold og funksjonskall. I dette formatet består hver melding av en topptekst (header) og innhold:

Toppteksten inneholder metadata – viktigst av alt rollen (system, utvikler, bruker, assistent, verktøy), kanalen og en mottaker som to=functions.<function-name> når et verktøyskall påberopes.

Kanaler (som analyse, kommentarer og endelig svar) gjør modellens utdata mer gjennomsiktige og segmenterte. Fordi formatet håndhever dette skillet, kan modellen resonnere transparent (og inspiseres for feilsøking) uten at tankekjeden (chain-of-thought) lekker ut i produksjon. Mottaksetiketter (to= topptekster) forteller kjøretiden nøyaktig hvilken aktør som skal motta den neste nyttelasten – enten det er en funksjon, selve modellen eller sluttbrukeren.

Vår inferensmotor ROSE er formatagnostisk. Den mottar en sats med inndatatokens og strømmer tilbake utdatatokens. I vår inferensstabel håndteres oppgaven med å formatere inndata til en tokenisert ledetekst og analysere LLM-resultater tilbake til strukturerte meldinger av den dedikerte JSON API-frontendpointsjenesten. Vi integrerte Harmony ved å legge til en ny pluggbar formaterer/parser til denne frontenddelen, slik at backend kan forbli uendret mens frontend rent administrerer chat-formatregler, verktøyskall og strømming. Dette skillet mellom ansvarsområder holder arkitekturen modular, og muliggjør rask adopsjon av nye formater og svarfunksjoner med minimale backend-endringer.

Kostnad og ytelse

Gitt den relativt lille størrelsen på GPT-OSS-modellene, begrenser vi distribusjonen av en replika til en enkelt node for å unngå kommunikasjonskostnader på tvers av noder. Implementeringen vår støtter fleksible kombinasjoner av ekspertparallellitet (EP), dataparallellitet (DP) og tensorparallellitet (TP). For å bestemme det optimale distribusjonsoppsettet, kjørte vi ytelsestester på alle kombinasjoner av sharding-strategier på tvers av satsstørrelser (batch sizes) fra 1 til 128. Takket være Prefill-Decode Disaggregation kan vi diskutere avveiningen mellom ytelse og kostnad separat for prefill og avkoding.

For kostnadsestimater antas en nominell H200-markedspris på $3,00/time (merk: dette er ikke vår faktiske GPU-pris).

Vi oppdaget at innstilling av batch_size=1 og DP=1 gir best prefill-ytelse. Ulike TP-konfigurasjoner gir deretter ulike avveininger mellom ventetid for første token og kostnad. Tabellene nedenfor viser prefill-ventetid og kostnad per million inndatatokens for ulike konfigurasjoner og inndatalengder.

GPT-OSS 120B:

GPT-OSS 120B prefyll-latens og kostnad per million inndatatoken etter parallelle konfigurasjoner og inndatalengde.

GPT-OSS 20B:

GPT-OSS 20B prefyll-latens og kostnad per million inndatatoken etter parallelle konfigurasjoner og inndatalengde.

For avkoding oppdaget vi at EP4 DP1 TP4 er den beste konfigurasjonen for de fleste tilfeller. De fire plottene nedenfor illustrerer avveiningen mellom avkodingshastighet og kostnad per million utdatatokens for både 120B- og 20B-modellene ved sekvenslengder på 8192 og 32768.

Forstørr

Forstørr

Forstørr

Forstørr

Vi har også vurdert å bruke den mindre 20B-modellen som en spekulativ avkodingsmodell (draft model) for den større 120B-modellen. Men fordi antallet aktiverte parametere er likt (3B vs. 5B), var de resulterende hastighetsøkningene marginale.

Referanser

Disaggregert prefill og avkoding

Akselerering av Sonar gjennom spekulasjon​

Lavere ventetid og høyere gjennomstrømning med flernodet DeepSeek-distribusjon

​Effektiv og bærbar kommunikasjon for ekspertenes blanding (Mixture-of-Experts)

​pplx-kjerner

DeepGEMM

FlashInfer: Effektiv og tilpassbar oppmerksomhetsmotor for LLM-inferensbetjening

Effektive strømmende språkmodeller med oppmerksomhetssluk

DeepSeek-V3 teknisk rapport​

​OpenAI Harmony-svarformat | OpenAI Cookbook​

Sitat

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