GPT-OSS 1. den

Společnost Perplexity se zavázala zpřístupňovat ty nejlepší modely AI zvídavým lidem, kteří požadují přesné a důvěryhodné odpovědi a agentní akce. Společnost OpenAI nedávno oznámila své modely s otevřenými vahami (gpt-oss-20b a gpt-oss-120b). Stejně jako u mnoha předních modelů je Perplexity jednou z prvních organizací, které modely gpt-oss-20b a gpt-oss-120b vyhodnotily.

V tomto příspěvku sdílíme rozhodnutí ohledně infrastruktury našeho vlastního inferenčního zásobníku, díky nimž byla podpora od 1. dne možná. Zaměřujeme se na provozování těchto modelů na GPU NVIDIA H200 a podrobně popisujeme změny v jádrech, volby nasazení a kompromisy mezi rychlostí a cenou.

GPT-OSS na architektuře Hopper

Modely s otevřenými vahami jsou dodávány s kvantováním MXFP4, což jim pomáhá vejít se do paměti spotřebního hardwaru nebo dosáhnout maximální propustnosti na architektuře NVIDIA Blackwell. Pro počáteční vyhodnocení jsme je však chtěli spustit na stávajících clusterech H200 Hopper s minimálními změnami inferenčního engine. Hopper nemá vyhrazená jádra pro tenzory FP4, která byla představena v architektuře Blackwell. V důsledku toho jsme se rozhodli provozovat modely s přesností FP8, abychom minimalizovali potřebu vlastních jader a co nejlépe využili dostupný hardware.

Na obecné úrovni jsou transformátorové LLM strukturově jednoduché:

Vstupní vkládání (embedding)

Sekvence transformátorových vrstev. Každá obsahuje bloku pozornosti (attention) a hustý blok MLP nebo řídký blok MoE.

Výstupní projekce logitů

Při spouštění nového transformátorového modelu nás primárně zajímá zjištění, do jaké míry se shodují se stávajícími modely, abychom identifikovali potřebné změny. Společnost OpenAI s námi laskavě sdílela přehled svých modelů s předstihem, což nám umožnilo odpovídajícím způsobem upravit naše inferenční nastavení. Zjistili jsme, že model vyžadoval celkem řadu menších změn.

Pozornost: GQA s mechanismem Attention Sinks

Každá hlava pozornosti má předtrénovaný parametr propadu (sink), který se zohledňuje ve funkci Softmax.

Pozoziční kódování YaRN, podobné modelu DeepSeek-V3

Projekce QKV obsahují bias (posun), podobně jako u Qwen 2

Výstupní projekce obsahuje bias

MLP: Řídká směs expertů (Sparse Mixture-of-Expert – MoE)

Aktivační funkce SwiGLU, která se liší od většiny modelů s otevřenými vahami

Softmax po Top-K pro váhy expertů

Experti obsahují bias

Vzhledem k tomu, že jsme očekávali počet parametrů v rozmezí 100B–200B, rozhodli jsme se:

Rozšířit FlashInfer o podporu mechanismu attention sinks

Znovu použít implementaci MoE, která již byla vytvořena pro rodinu modelů DeepSeek-V3

Zvolit blokové škálování FP8 128x128 jako schéma kvantování a rozšířit jádra DeepGEMM o podporu členu bias.

Vlastní inferenční engine

Naše inferenční aktivity jsou podpořeny naším vlastním inferenčním enginem ROSE. Vyvíjíme ROSE tak, aby představoval flexibilní framework umožňující rychlé spouštění nových modelů. Jakmile se navíc zavážeme k provozování modelu ve velkém měřítku, poskytuje platformu pro optimalizaci a zvyšování výkonu na špičkovou úroveň.

ROSE poskytuje LLM engine, který dokáže načíst model a generovat pro něj dekódované tokeny prostřednictvím několika dekodérů, včetně spekulativních a MTP dekodérů. Samotné modely se skládají z vlastní sady vrstev, které podporují různé konfigurační volby pro kvantování a paralelismus. Pod vrstvami jsou integrována jak jádra Triton, tak CUDA, která efektivně implementují a slučují výpočty prováděné jednotlivými vrstvami.

ROSE je primárně napsán v jazyce Python a pro definice modelů spoléhá na PyTorch. Zatímco Python nám umožňuje být flexibilní a přizpůsobovat se novým modelům, většinu komponent citlivých na výkon, jako je obsluha požadavků (serving) a plánování dávkového zpracování, migrujeme do jazyka Rust.

Abychom spustili nový model, nejprve definujeme hierarchii modelu a sestavíme pro něj převaděč vah. Po zohlednění všech vah definujeme dopředný průchod (forward pass) pro nejjednodušší případ použití TP=1 a zajistíme jeho fungování end-to-end. Nakonec implementujeme a otestujeme podporu pro různé formy paralelismu předtím, než vydáme nový kontejner a nasadíme model na cluster k vyhodnocení. Poté iterujeme výkon na základě zpětné vazby z dashboardů a detailnějších benchmarků.

ROSE pracuje s číselnými tokeny a má jen malé povědomí o formátech chatů mimo integrační testy. Souběžně jsme se museli zabývat úpravou okolní infrastruktury tak, aby podporovala tokenizér Harmony a správně mapovala požadavky na vstupní sekvence tokenů.

U modelu GPT OSS jsme zjistili, že nebyly nutné žádné změny v našich dekodérech, nástrojích pro grafy CUDA ani v okolní infrastruktuře, což nám umožnilo soustředit naše úsilí na doladění jader tvořících základ modelu.

Jádra pro GPT-OSS

Sink Attention

Sink attention zavádí dodatečný faktor bias před funkcí softmax, který se sčítá se součinem Q a K:

Zatímco naivní implementace je poměrně triviální, efektivní implementace pozornosti, jako je FlashInfer, paraleizují výpočet pozornosti napříč nezávislými hlavami i délkou sekvence KV. Pro zajištění numerické stability se navíc Softmax počítá online a zároveň se odčítá maximální prvek:

Online implementace sledovala průběžné maximum m inicializované na -inf a škálu d na 1. Inicializací maxima na hodnotu propadu (sink) aktuální hlavy bychom zajistili, že se správně akumuluje do funkce Softmax. Museli jsme dbát na to, aby toto maximum bylo zahrnuto pouze v prvním bloku, pokud byla pozornost rozdělena na více bloků podél délky sekvence.

Upravili jsme šablonu jádra FlashInfer FA2, která se používá pro prefill i dekódování, tak, aby zahrnovala parametry propadu.

MoE

Hlavní rozdíl mezi vrstvou MoE různých modelů obvykle spočívá ve schématu routování. Protože ROSE očekává značnou variabilitu, implementuje toto jádro v jazyce Triton, což nám umožňuje jej snadno přizpůsobit novým modelům. V případě GPT-OSS jsme museli upravit skórování vah tak, aby se funkce softmax prováděla pouze napříč vybranými experty Top-K, na rozdíl od některých modelů ve stylu DeepSeek, které počítají softmax napříč všemi experty. Zjistili jsme, že pro přesnost je klíčové počítat váhy expertů v přesnosti bfloat16.

Výzva u vrstvy MoE pramenila z našeho rozhodnutí znovu použít stávající jádra DeepGEMM, která postrádala podporu pro členy bias. Naštěstí jsme s nimi v průběhu času hluboce integrovali a provedli změny, abychom je lépe propojili s našimi vlastními dispečerskými jádry typu all-to-all. Do DeepGEMM jsme přidali podporu bias inicializací akumulátorových registrů WGMMA na hodnoty bias načtené z paměti. Jedná se o jednorázovou operaci během zpracování bloku MN, takže náklady jsou pravděpodobně zanedbatelné a mezipaměť L2 zajišťuje efektivní přístup k těmto hodnotám.

Jelikož tyto modely nemají přímý užitek z datového paralelismu (Data Parallelism), znovu jsme použili dispečerské a kombinační jádra výhradně pro TP (tensor parallelism). Vstupy pro dispečer jsou replikovány napříč všemi ranky, takže dispečer vybírá tokeny pro lokálně dostupné experty. Kombinátor provádí váženou akumulaci napříč NVLink.

Optimalizace výkonu

I přesto, že naším cílem bylo modely rychle spustit, chtěli jsme zajistit, aby byl výkon stále přiměřený. Po ověření správnosti oproti referenční implementaci poskytnuté společností OpenAI jsme profilovali naši implementaci pomocí výchozího profilovače PyTorch a hlídali alokace bloků a vláken napříč jádry. Znovu použitá funkcionalita byla vytvořena pro modely, které měly větší skrytou dimenzi (hidden dimension) 7168, což je podstatně více než 2880 u modelů GPT-OSS. Specializovali jsme spouštěče jader tak, aby vybíraly lepší dimenze mřížky, což výrazně zvýšilo propustnost.

Tokenizace a kanály

Formát chatu Harmony má několik důležitých konceptů pro strukturování konverzací, obsahu uvažování a volání funkcí. V tomto formátu se každá zpráva skládá z hlavičky a obsahu:

Hlavička nese metadata – nejdůležitěji roli (systém, vývojář, uživatel, asistent, nástroj), kanál a příjemce, jako je to=functions.<function-name> při vyvolání volání nástroje.

Kanály (jako analýza, komentář a konečná odpověď) činí výstupy modelu transparentnějšími a segmentovanějšími. Protože formát vynucuje toto oddělení, model může transparentně uvažovat (a být kontrolován při ladění), aniž by docházelo k úniku řetězce myšlenek (chain-of-thought) do produkce. Značky příjemce (hlavičky to=) sdělují běhovému prostředí přesně to, který aktér by měl přijmout další datovou sadu – ať už se jedná o funkci, samotný model, nebo koncového uživatele.

Náš inferenční engine ROSE je nezávislý na formátu. Přijímá dávku vstupních tokenů a streamuje zpět výstupní tokeny. V našem inferenčním zásobníku je úkol formátování vstupů do tokenizovaného promptu a parazitování výsledků LLM zpět do strukturovaných zpráv zajišťován vyhrazenou front-endovou službou JSON API. Integrovali jsme Harmony přidáním nového připojitelného formátovače/parseru do tohoto front-endu, což umožňuje, aby back-end zůstal beze změn, zatímco front-end čistě spravuje pravidla formátu chatu, volání nástrojů a streamování. Toto oddělení zájmů udržuje architekturu modulární, což umožňuje rychlé přijetí nových formátů a funkcí odpovědí s minimálními změnami back-endu.

Náklady a výkon

Vzhledem k relativně malé velikosti modelů GPT-OSS omezujeme nasazení repliky na jediný uzlu, abychom se vyhnuli režii komunikace mezi uzly. Naše implementace podporuje flexibilní kombinace expertního paralelismu (EP), datového paralelismu (DP) a tenzorového paralelismu (TP). K určení optimálního nastavení nasazení jsme otestovali všechny kombinace strategií sharding napříč velikostmi dávek od 1 do 128. Díky disagregaci prefillu a dekódování (Prefill-Decode Disaggregation) můžeme diskutovat o kompromisu mezi výkonem a cenou pro prefill a dekódování samostatně.

Pro odhady nákladů předpokládáme nominální tržní sazbu za H200 ve výši 3,00 USD/hodinu (poznámka: toto není naše skutečná cena za GPU).

Zjistili jsme, že nastavení batch_size=1 a DP=1 přináší nejlepší výkon prefillu. Různé konfigurace TP pak poskytují odlišné kompromisy mezi latencí prvního tokenu a cenou. Následující tabulky uvádějí latenci prefillu a náklady na jeden milion vstupních tokenů pro různé konfigurace a délky vstupů.

GPT-OSS 120B:

Latence prefille GPT-OSS 120B a cena za milion vstupních tokenů podle konfigurace paralelismu a délky vstupu.

GPT-OSS 20B:

Latence prefille GPT-OSS 20B a cena za milion vstupních tokenů podle konfigurace paralelismu a délky vstupu.

Pro dekódování jsme zjistili, že EP4 DP1 TP4 je nejlepší konfigurací pro většinu případů. Následující čtyři grafy ilustrují kompromis mezi rychlostí dekódování a cenou za jeden milion výstupních tokenů pro modely 120B i 20B při délce sekvencí 8192 a 32768.

Zvětšit

Zvětšit

Zvětšit

Zvětšit

Zvažovali jsme také použití menšího modelu 20B jako návrhového modelu pro spekulativní dekódování (speculative decoding) pro větší model 120B. Vzhledem k tomu, že je však počet aktivovaných parametrů podobný (3B vs. 5B), byla dosažená zrychlení zanedbatelná.

Reference

Disagregovaný prefill a dekódování

Akcelerace Sonar prostřednictvím spekulace​

Nižší latence a vyšší propustnost při víceužlovém nasazení DeepSeek

​Efektivní a přenositelná komunikace Mixture-of-Experts

​pplx-kernels

DeepGEMM

FlashInfer: Efektivní a přizpůsobitelný engine pozornosti pro inferenční službu LLM

Efektivní streamovací jazykové modely s mechanismem Attention Sinks

Technická zpráva DeepSeek-V3​

​Formát odpovědi OpenAI Harmony | OpenAI Cookbook​

Citace

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