GPT-OSS på Day 0

Perplexity er forpligtet til at gøre de bedste AI-modeller tilgængelige for nysgerrige personer, der kræver nøjagtige og troværdige svar og agenthandlinger. OpenAI annoncerede for nylig deres åbne vægtmodeller (gpt-oss-20b og gpt-oss-120b). Som med mange førende modeller er Perplexity blandt de første organisationer til at evaluere gpt-oss-20b og gpt-oss-120b.

I dette indlæg deler vi infrastrukturvalgene for vores interne inferensstack, som gjorde Day-0-understøttelse mulig. Vi fokuserer på at køre disse modeller på NVIDIA H200 GPU'er og beskriver kernewendringer, implementeringsvalg og afvejninger mellem hastighed og omkostninger.

GPT-OSS på Hopper

Modellerne med åbne vægte leveres med MXFP4-kvantisering, hvilket hjælper dem med at passe ind i hukommelsen på hardware i forbrugerklassen eller opnå maksimalt gennemløb på NVIDIA Blackwell. For den første evaluering ønskede vi dog at køre dem på eksisterende H200 Hopper-klynger med minimale ændringer af inferensmotoren. Hopper har ikke dedikerede FP4-tensor-kerner, som blev introduceret af Blackwell. Derfor besluttede vi i stedet at køre modellerne med FP8-præcision for at minimere behovet for tilpassede kerner og få mest muligt ud af den tilgængelige hardware.

På et overordnet niveau er transformer-LLM'er strukturelt enkle:

Input-indlejring

En sekvens af transformer-lag. Hvert lag indeholder en opmærksomhedsblok og en tæt MLP- eller sparsom MoE-blok.

Output-logit-projektion

Når vi introducerer en ny transformer-model, er vi primært interesserede i at finde ud af, i hvilket omfang de matcher eksisterende modeller, for at identificere de nødvendige ændringer. OpenAI delte venligst et overblik over deres modeller på forhånd, hvilket gjorde det muligt for os at tilpasse vores inferensopsætning derefter. Vi fandt ud af, at modellen krævede en del små ændringer.

Opmærksomhed (Attention): GQA med opmærksomhedsvaske (Attention Sinks)

Hvert opmærksomhedshoved har en prætrænet vaskeparameter (sink parameter), som indgår i Softmax

YaRN-positionskodning, svarende til DeepSeek-V3

QKV-projektioner har biases, svarende til Qwen 2

Output-projektion har bias

MLP: Sparsom Mixture-of-Expert (MoE)

SwiGLU-aktiveringsfunktion, forskellig fra de fleste modeller med åbne vægte

Softmax efter Top-K for ekspertvægte

Eksperter har biases

Da vi forventede, at antallet af parametre ville være omkring 100B-200B, besluttede vi at:

Udvide FlashInfer til at understøtte opmærksomhedsvaske (attention sinks)

Genbruge MoE-implementeringen, der allerede er bygget til DeepSeek-V3-familien af modeller

Vælge FP8 128x128 blok-skalering som kvantiseringsskema og udvide DeepGEMM-kernerne til at understøtte en biasterm.

Interne inferensmotor

Vores inferensarbejde understøttes af vores interne inferensmotor, ROSE. Vi opbygger ROSE til at være et fleksibelt rammeværk, der gør det muligt hurtigt at tage nye modeller i brug. Derudover, når vi først har forpligtet os til at køre en model i stor skala, udgør den en platform til at optimere og øge ydeevnen, så den når det nyeste niveau (state of the art).

ROSE exponerer en LLM-motor, som kan indlæse en model og generere dekodede tokens til den gennem flere dekodere, herunder spekulative og MTP-dekodere. Selve modellerne er sammensat af et tilpasset sæt lag, som understøtter forskellige konfigurationsmuligheder for kvantisering og parallelisme. Under lagene bundter den både Triton- og CUDA-kerner, som effektivt implementerer og fletter de beregninger, der udføres af individuelle lag.

ROSE er primært bygget i Python og er afhængig af PyTorch til modeldefinitioner. Mens Python giver os mulighed for at være fleksible og tilpasse os nye modeller, migrerer vi de fleste ydeevnefølsomme komponenter, såsom servering og batch-planlægning, til Rust.

For at tage en ny model i brug definerer vi først modelhierarki og bygger en vægtkonverter til den. Når der er taget højde for alle vægte, definerer vi et forward-pass for det enkleste TP=1-brugstilfælde og sikrer, at det fungerer end-to-end. Til sidst implementerer og tester vi understøttelse af forskellige former for parallelisme, før vi frigiver en ny container og udruller modellen på en klynger til evaluering. Derefter itererer vi over ydeevnen baseret på feedback fra både dashboards og finere benchmarks.

ROSE arbejder med numeriske tokens med et minimum af kendskab til chat-formater ud over integrationstests. Parallelt hermed var vi nødt til at se på tilpasning af den omgivende infrastruktur for at understøtte Harmony-tokenizeren og korrekt knytte forespørgsler til input-tokensekvenser.

Med GPT OSS-modellen fandt vi ud af, at der ikke var behov for ændringer af vores dekodere, CUDA-grafværktøjer eller den omgivende infrastruktur, hvilket gjorde det muligt for os at fokusere vores indsats på at finjustere kernerne bag modellen.

Kerner til GPT-OSS

Vask-opmærksomhed (Sink Attention)

Vask-opmærksomhed (sink attention) introducerer en ekstra bias-faktor før softmax, som akkumuleres med produktet af Q og K:

Selvom en naiv implementering er ret simpel, paralleliserer effektive opmærksomhedsimplementeringer, såsom FlashInfer, beregningen af opmærksomhed på tværs af både uafhængige hoveder og KV-sekvenslængden. Derudover beregnes Softmax for at opnå numerisk stabilitet online, mens det maksimale element også trækkes fra for at sikre numerisk stabilitet:

Online-implementeringen spores af et løbende maksimum m initialiseret til -inf og en skala d til 1. Ved at initialisere maksimum til det aktuelle hoveds vaskeværdi (sink value) ville vi sikre, at det blev akkumuleret korrekt i Softmax. Vi var nødt til at sørge for, at dette maksimum kun blev inkluderet i den første blok, hvis opmærksomheden blev opdelt på tværs af flere blokke langs sekvenslængden.

Vi har justeret FlashInfer FA2-kerneskabelonen, der bruges til både prefill og dekodning, til at inkludere vaskeparametrene (sink parameters).

MoE

Hovedforskellen mellem MoE-laget i forskellige modeller er normalt routingskemaet. Da ROSE forventer væsentlig variabilitet, implementerer den denne kerne i Triton, hvilket gør det nemt for os at tilpasse den til nye modeller. I tilfældet med GPT-OSS var vi nødt til at justere vægtscoring for kun at udføre softmax på tværs af de Top-K-udvalgte eksperter, i modsætning til nogle modeller i DeepSeek-stil, som beregner softmax på tværs af alle eksperter. Vi fandt ud af, at det er afgørende for nøjagtigheden at beregne ekspertvægtene i bfloat16-præcision.

Udfordringen med MoE-laget skyldtes vores beslutning om at genbruge de eksisterende DeepGEMM-kerner, som manglede understøttelse af biastermer. Heldigvis integrerede vi os med tiden tæt med dem og foretog ændringer for bedre at forbinde dem med vores tilpassede all-to-all-dispatch-kerner. Vi tilføjede bias-understøttelse til DeepGEMM ved at initialisere WGMMA-akkumulatorregistrene til de bias-værdier, der blev indlæst fra hukommelsen. Dette er en engangsforeteelse under behandlingen af en MN-blok, så omkostningerne er sandsynligvis ubetydelige, og L2-cachen sikrer effektiv adgang til disse værdier.

Da disse modeller ikke umiddelbart drager fordel af dataparallelisme, genbrugte vi TP-eneste dispatch- og combine-kerner. Inputs til dispatch replikeres på tværs af alle rangordener, så dispatch vælger tokens for de lokalt tilgængelige eksperter. Combine udfører den vægtede akkumulering på tværs af NVLink.

Ydeevnejusteringer

Selvom vores mål var at få modellerne hurtigt op at køre, ønskede vi at sikre, at ydeevnen stadig var rimelig. Efter at have sikret nøjagtighed mod en referencelimplementering leveret af OpenAI, profilerede vi vores implementering ved hjælp af standard PyTorch-profileren, hvor vi holdt øje med blok- og tråfallokeringer på tværs af kerner. Den funktionalitet, vi genbrugte, var bygget til modeller, der havde en større skjult dimension på 7168, hvilket er væsentligt større end de 2880 i GPT-OSS-modellerne. Vi specialiserede kerne-launchers til at vælge bedre gitterdimensioner, hvilket øgede gennemløbet markant.

Tokenisering og kanaler

Harmonys chat-format har flere vigtige koncepter til strukturering af samtaler, ræsonnementsindhold og funktionskald. I dette format består hver meddelelse af en header og indhold:

Headeren indeholder metadata – vigtigst af alt rollen (system, udvikler, bruger, assistent, værktøj), kanalen og en modtager såsom to=functions.<function-name>, når der kaldes et værktøjskald.

Kanaler (såsom analyse, kommentarer og endeligt svar) gør modellens output mere gennemsigtige og opdelte. Fordi formatet gennemtvinger denne adskillelse, kan modellen ræsonnere gennemsigtigt (og inspiceres til fejlfinding) uden at lække 'chain-of-thought' til produktion. Modtagertags (to= headers) fortæller kørtidsmiljøet nøjagtigt, hvilken aktør der skal modtage den næste nyttelast – uanset om det er en funktion, selve modellen eller slutbrugeren.

Vores inferensmotor ROSE er formatagnostisk. Den modtager en batch af input-tokens og streamer output-tokens tilbage. I vores inferensstack håndteres opgaven med at formatere inputs til en tokeniseret prompt og fortolke LLM-resultater tilbage til strukturerede meddelelser af den dedikerede JSON API-frontend-tjeneste. Vi integrerede Harmony ved at tilføje en ny plugbar formaterer/parser til denne frontend, hvilket gør det muligt for backend at forblive uændret, mens frontend rent håndterer chat-formatregler, funktionskald og streaming. Denne ansvarsadskillelse holder arkitekturen modulær og muliggør hurtig vedtagelse af nye formater og svarfunktioner med minimale ændringer i backend.

Omkostninger og ydeevne

I betragtning af GPT-OSS-modellernes relativt lille størrelse begrænser vi udrulningen af en replika til en enkelt node for at undgå kommunikationsoverhead mellem noder. Vores implementering understøtter fleksible kombinationer af ekspertparallelisme (EP), dataparallelisme (DP) og tensorparallelisme (TP). For at bestemme den optimale udrulningsopsætning benchmarkede vi alle kombinationer af sharding-strategier på tværs af batchstørrelser fra 1 til 128. Takket være Prefill-Decode Disaggregation er vi i stand til at diskutere afvejningen mellem ydeevne og omkostninger separat for prefill og dekodning.

For omkostningsoverslag antager vi en nominel H200-markedspris på $3.00/time (bemærk: dette er ikke vores faktiske GPU-pris).

Vi opdagede, at indstilling af batch_size=1 og DP=1 giver den bedste prefill-ydeevne. Forskellige TP-konfigurationer giver derefter forskellige afvejninger mellem latens for første token og omkostninger. Tabellerne nedenfor viser prefill-latens og omkostninger pr. million input-tokens for forskellige konfigurationer og inputlængder.

GPT-OSS 120B:

GPT-OSS 120B prefill-latenstid og omkostning pr. million inputtokens efter parallelitetskonfiguration og inputlængde.

GPT-OSS 20B:

GPT-OSS 20B prefill-latenstid og omkostning pr. million inputtokens efter parallelitetskonfiguration og inputlængde.

For dekodning opdagede vi, at EP4 DP1 TP4 er den bedste konfiguration i de fleste tilfælde. De fire grafer nedenfor illustrerer afvejningen mellem dekodningshastighed og omkostninger pr. million output-tokens for både 120B- og 20B-modellerne ved sekvenslængder på 8192 og 32768.

Udvid

Udvid

Udvid

Udvid

Vi har også overvejet at bruge den mindre 20B-model som en speculativ dekodningsmodel (draft model) til den større 120B-model. Men da antallet af aktiverede parametre er det samme (3B vs. 5B), var de resulterende hastighedsforøgelser marginale.

Referencer

Disaggregated Prefill and Decode

Accelerating Sonar Through Speculation​

Lower Latency and Higher Throughput with Multi-node DeepSeek Deployment

​Efficient and Portable Mixture-of-Experts Communication

​pplx-kernels

DeepGEMM

FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving

Efficient Streaming Language Models with Attention Sinks

DeepSeek-V3 Technical Report​

​OpenAI Harmony Response Format | OpenAI Cookbook​

Citering

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