GPT-OSS el dia 0

Perplexity s'incompromet a posar els millors models d'IA a l'abast de les persones curioses que exigeixen respostes acurades i fiables i accions basades en agents. OpenAI ha anunciat recentment els seus models de pesos oberts (gpt-oss-20b i gpt-oss-120b). Com passa amb molts models líders, Perplexity és de les primeres organitzacions a avaluar gpt-oss-20b i gpt-oss-120b.

En aquesta publicació, compartim les decisions d'infraestructura de la nostra pila d'inferència pròpia que han fet possible el suport el dia 0. Ens centrem a executar aquests models en GPU NVIDIA H200, detallant els canvis al nucli, les opcions de desplegament i els compromisos entre velocitat i cost.

GPT-OSS a Hopper

Els models de pesos oberts es distribueixen amb quantització MXFP4, la qual cosa els ajuda a cabre a la memòria en maquinari de consum o a assolir un rendiment màxim a NVIDIA Blackwell. Tanmateix, per a l'avaluació inicial, volíem executar-los en clústers H200 Hopper existents amb un mínim de canvis al motor d'inferència. Hopper no té nuclis tensorials FP4 dedicats, introduïts per Blackwell. En conseqüència, vam decidir servir els models amb precisió FP8 per minimitzar la necessitat de nuclis personalitzats i aprofitar al màxim el maquinari disponible.

A un nivell general, els LLM de transformadors són estructuralment simples:

Incrustació d'entrada

Una seqüència de capes de transformadors. Cadascuna conté un bloc d'atenció i un bloc MLP dens o MoE dispers.

Projecció de logits de sortida

Quan posem en marxa un nou model de transformador, ens interessa principalment saber fins a quin punt coincideixen amb els models existents per identificar els canvis requerits. OpenAI amablement va compartir una visió general dels seus models amb antelació, permetent-nos ajustar la nostra configuració d'inferència en conseqüència. Vam veure que el model requeria força canvis petits.

Atenció: GQA amb Attention Sinks

Cada cap d'atenció té un paràmetre de buidatge preentrenat que es té en compte a Softmax

Codificació posicional YaRN, similar a DeepSeek-V3

Les projeccions QKV tenen biaixos, similars a Qwen 2

La projecció de sortida té biaix

MLP: barreja d'experts dispersos (MoE)

Funció d'activació SwiGLU, diferent de la majoria de models de pesos oberts

Softmax després de Top-K per als pesos d'experts

Els experts tenen biaixos

Esperant que el nombre de paràmetres sigui d'uns 100B-200B, vam decidir:

Ampliar FlashInfer per admetre buidatges d'atenció (attention sinks)

Reutilitzar la implementació de MoE ja creada per a la família de models DeepSeek-V3

Triar l'escala de blocs FP8 128x128 com a esquema de quantització, ampliant els nuclis DeepGEMM per admetre un terme de biaix.

Motor d'inferència propi

Els nostres esforços d'inferència estan respaldats pel nostre motor d'inferència propi, ROSE. Estem desenvolupant ROSE perquè sigui un marc flexible que permeti posar en marxa ràpidament nous models. A més, un cop ens comprometem a servir un model a escala, ofereix una plataforma per optimitzar i impulsar el rendiment per assolir l'estat de l'art.

ROSE exposa un motor LLM, que pot carregar un model i generar testimonis decodificats per a ell a través de múltiples decodificadors, inclosos els decodificadors especulatius i MTP. Els models en si estan compostos per un conjunt personalitzat de capes, que admeten diverses opcions de configuració per a la quantització i el paral·lelisme. Sota les capes, inclou tant nuclis Triton com CUDA que implementen i fusionen eficaçment els càlculs realitzats per capes individuals.

ROSE està construït principalment en Python i es basa en PyTorch per a les definicions de models. Tot i que Python ens permet ser flexibles i adaptar-nos a nous models, estem migrant la majoria de components sensibles al rendiment, com ara el servei i la planificació de lots, a Rust.

Per posar en marxa un nou model, primer definim la jerarquia del model i construïm un convertidor de pesos per a aquest. Un cop comptabilitzats tots els pesos, definim un pas endavant per al cas d'ús TP=1 més simple i ens assegurem que funcioni d'extrem a extrem. Finalment, implementem i proven el suport per a diverses formes de abans de llançar un nou contenidor i desplegar el model en un clúster per a l'avaluació. Després iterem sobre el rendiment, basant-nos en els comentaris dels taulers i de proves comparatives més detallades.

ROSE opera amb testimonis numèrics, amb poc coneixement dels formats de xat fora de les proves d'integració. Paral·lelament, vam haver d'analitzar l'ajust de la infraestructura circumdant per admetre el tokenitzador Harmony i assignar correctament les sol·licituds a seqüències de testimonis d'entrada.

Amb el model GPT OSS, vam comprovar que no calia fer cap canvi als nostres decodificadors, arnesos de grafs CUDA o infraestructura circumdant, la qual cosa ens va permetre centrar els nostres esforços a ajustar els nuclis que sustenten el model.

Nuclis per a GPT-OSS

Atenció de buidatge (Sink Attention)

L'atenció de buidatge introdueix un factor de biaix addicional abans de softmax, acumulat amb el producte de Q i K:

Tot i que una implementació ingenua és força trivial, les implementacions d'atenció eficients, com FlashInfer, paral·lelitzen el càlcul de l'atenció tant a través de caps independents com a través de la longitud de la seqüència KV. A més, per a la estabilitat numèrica, Softmax es calcula en línia mentre es resta l'element màxim per a l'estabilitat numèrica:

La implementació en línia va fer un seguiment d'un màxim en execució m inicialitzat a -inf i una escala d a 1. En inicialitzar el màxim al valor de buidatge del cap actual, ens asseguraríem que s'acumulés correctament a Softmax. Vam haver d'anar en compte per assegurar-nos que aquest màxim només s'inclogués al primer fragment si l'atenció es dividia en diversos blocs al llarg de la longitud de la seqüència.

Hem ajustat la plantilla del nucli FlashInfer FA2, utilitzada tant per al farciment previ com per a la descodificació, per incloure els paràmetres de buidatge.

MoE

La diferència principal entre la capa MoE de diferents models sol ser l'esquema d'encaminament. Esperant una variabilitat considerable, ROSE implementa aquest nucli a Triton, permetent-nos adaptar-lo fàcilment a nous models. En el cas de GPT-OSS, vam haver d'ajustar la puntuació de pesos per realitzar softmax només a través dels experts seleccionats Top-K, a diferència d'alguns models d'estil DeepSeek que calculen softmax a tots els experts. Vam trobar que és fonamental per a la precisió calcular els pesos dels experts amb una precisió de bfloat16.

El repte amb la capa MoE es va deure a la nostra decisió de reutilitzar els nuclis DeepGEMM existents, que no tenien suport per a termes de biaix. Afortunadament, amb el temps ens hi vam integrar profundament, fent canvis per connectar-los millor amb els nostres nuclis d'enviament all-to-all personalitzats. Vam afegir suport de biaix a DeepGEMM inicialitzant els registres acumuladors WGMMA als valors de biaix carregats de la memòria. Això és un fet puntual durant el processament d'un bloc MN, per la qual cosa el cost probablement és negligible i la memòria cau L2 garanteix un accés eficient a aquests valors.

Atès que aquests models no es beneficien directament del paral·lelisme de dades, hem reutilitzat els nuclis d'enviament i combinació exclusius de TP. Les entrades per a l'enviament es repliquen a tots els rangs, de manera que l'enviament selecciona els testimonis per als experts disponibles localment. La combinació realitza l'acumulació ponderada a través de NVLink.

Ajustaments de rendiment

Tot i que el nostre objectiu era posar en marxa els models ràpidament, volíem assegurar-nos que el rendiment fos raonable. Després de verificar la correcció respecte a una implementació de referència proporcionada per OpenAI, vam perfilar la nostra implementació utilitzant el profiler predeterminat de PyTorch, vigitant les assignacions de blocs i fils a través dels nuclis. La funcionalitat que hem reutilitzat es va crear per a models que tenien una dimensió oculta més gran de 7168, substancialment més gran que la de 2880 dels models GPT-OSS. Vam especialitzar els llançadors de nuclis per triar millors dimensions de quadrícula, augmentant significativament el rendiment.

Tokenització i canals

El format de xat d'Harmony té diversos conceptes importants per estructurar converses, contingut de raonament i trucades a funcions. En aquest format, cada missatge consta d'una capçalera i de contingut:

La capçalera porta metadades (el més important, el rol [sistema, desenvolupador, usuari, assistent, eina], el canal i un destinatari com ara to=functions.<function-name> quan s&#39;invoca una crida d&#39;eina).

Els canals (com ara l&#39;anàlisi, els comentaris i la resposta final) fan que les sortides del model siguin més transparents i segmentades. Com que el format força aquesta separació, el model pot raonar de manera transparent (i ser inspeccionat per a la depuració) sense filtrar la cadena de pensament a la producció. Les etiquetes de destinatari (capçaleres to=) indiquen exactament al temps d&#39;execució quin actor ha de rebre la càrrega útil següent, ja sigui una funció, el mateix model o l&#39;usuari final.

El nostre motor d&#39;inferència ROSE és agnòstic respecte al format. Rep un lot de testimonis d&#39;entrada i transmet de tornada testimonis de sortida. A la nostra pila d&#39;inferència, la tasca de formatar les entrades en un missatge tokenitzat i analitzar els resultats del LLM per convertir-los en missatges estructurats es gestiona mitjançant el servei frontal d&#39;API JSON dedicat. Vam integrar Harmony afegint un nou formatador/analitzador connectable a aquest frontal, permetent que el rerefons romangui sense canvis mentre el frontal gestiona netament les regles de format de xat, les trucades d&#39;eines i la transmissió. Aquesta separació de preocupacions manté l&#39;arquitectura modular, permetent l&#39;adopció ràpida de nous formats i funcions de resposta amb canvis mínims al rerefons.

Cost i rendiment

Atès la mida relativament petita dels models GPT-OSS, limitem el desplegament d&#39;una rèplica a un sol node per evitar la sobrecàrrega de comunicació entre nodes. La nostra implementació admet combinacions flexibles de paral·lelisme d&#39;experts (EP), paral·lelisme de dades (DP) i paral·lelisme de tensors (TP). Per determinar la configuració de desplegament òptima, vam comparar totes les combinacions d&#39;estratègies de particionament en mides de lot d&#39;1 a 128. Gràcies a la desagregació de farciment previ i descodificació, podem parlar per separat del compromís entre rendiment i cost per al farciment previ i la descodificació.

Per a les estimacions de costos, assumim una tarifa de mercat nominal de H200 de 3,00 $/hora (tingueu en compte que aquest no és el nostre preu real de GPU).

Hem descobert que configurar batch_size=1 i DP=1 produeix el millor rendiment de farciment previ. Les diferents configuracions de TP ofereixen llavors compensacions variables entre la latència del primer testimoni i el cost. Les taules següents presenten la latència de farciment previ i el cost per milió de testimonis d&#39;entrada per a diverses configuracions i longituds d&#39;entrada.

GPT-OSS 120B:

Latença de preemplenament i cost per milió de tokens d’entrada de GPT-OSS 120B segons la configuració de paral·lelisme i la longitud d’entrada.

GPT-OSS 20B:

Latença de preemplenament i cost per milió de tokens d’entrada de GPT-OSS 20B segons la configuració de paral·lelisme i la longitud d’entrada.

Per a la descodificació, hem descobert que EP4 DP1 TP4 és la millor configuració per a la majoria de casos. Els quatre gràfics següents il·lustren el compromís entre la velocitat de descodificació i el cost per milió de testimonis de sortida tant per als models de 120B com de 20B a longituds de seqüència de 8192 i 32768.

Amplia

Amplia

Amplia

Amplia

També hem considerat utilitzar el model més petit de 20B com a model esborrany de descodificació especulativa per al model més gran de 120B. Tanmateix, com que el nombre de paràmetres activats és similar (3B vs. 5B), les acceleracions obtingudes han estat marginals.

Referències

Farciment previ i descodificació desagregats

Accelerating Sonar Through Speculation​

Menor latència i major rendiment amb el desplegament de DeepSeek de diversos nodes

​Comunicació de barreja d&#39;experts eficient i portàtil

​pplx-kernels

DeepGEMM

FlashInfer: motor d&#39;atenció eficient i personalitzable per al servei d&#39;inferència LLM

Models de llenguatge de transmissió eficients amb buidatges d&#39;atenció

Informe tècnic de DeepSeek-V3​

​Format de resposta d&#39;OpenAI Harmony | Llibre de receptes d&#39;OpenAI​

Citació

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