GPT-OSS no día 0

Perplexity comprométese a achegar os mellores modelos de IA ás persoas curiosas que demandan respostas precisas e fiables, así como accións de axentes. OpenAI anunciou recentemente os seus modelos de peso aberto (gpt-oss-20b e gpt-oss-120b). Como ocorre con moitos modelos líderes, Perplexity atópase entre as primeiras organizacións en avaliar gpt-oss-20b e gpt-oss-120b.

Nesta publicación, compartimos as decisións de infraestrutura da nosa pila de inferencia interna que fixeron posible o soporte do día 0. Centrámonos na servizón destes modelos en GPU NVIDIA H200, detallando os cambios nos kernels, as opcións de implantación e as relacións de compromiso entre velocidade e custo.

GPT-OSS en Hopper

Os modelos de peso aberto envíanse empregando a cuantización MXFP4, o que axuda a que quepan na memoria de hardware de nivel de consumidor ou a acadar un rendemento máximo en NVIDIA Blackwell. Con todo, para a avaliación inicial, queríamos executalos en clústeres Hopper H200 existentes con mínimos cambios no motor de inferencia. Hopper non dispón de núcleos de tensor FP4 adicados, introducidos por Blackwell. Por conseguinte, decidimos servir os modelos con precisión FP8 para minimizar a necesidade de kernels personalizados e aproveitar ao máximo o hardware dispoñible.

A un nivel xeral, os LLM de transformadores son estruturalmente sinxelos:

Incrustación de entrada

Unha secuencia de capas de transformadores. Cada unha contén un bloque de atención e un bloque MLP denso ou MoE disperso.

Proxección de logit de saída

Ao implementar un novo modelo de transformadores, interesarnos principalmente coñecer ata que punto coinciden cos modelos existentes para identificar os cambios necesarios. OpenAI compartiu amablemente unha visión xeral dos seus modelos con antelación, o que nos permitiu adaptar a nosa configuración de inferencia en consecuencia. Vimos que o modelo requiriu unha cantidade considerable de pequenos cambios.

Atención: GQA con sumidoiros de atención

Cada cabeza de atención ten un parámetro de sumidoiro preentrenado que se ten en conta no Softmax

Codificación posicional YaRN, similar a DeepSeek-V3

As proxeccións QKV teñen sesgos, similares a Qwen 2

A proxección de saída ten sesgo

MLP: Mestura de expertos dispersos (MoE)

Función de activación SwiGLU, diferente da maioría dos modelos de peso aberto

Softmax despois de Top-K para os pesos dos expertos

Os expertos teñen sesgos

Esperando que o número de parámetros estea entre 100B e 200B, decidimos:

Ampliar FlashInfer para admitir sumidoiros de atención

Reutilizar a implementación de MoE xa construída para a familia de modelos DeepSeek-V3

Escoller a escala de bloques FP8 128x128 como esquema de cuantización, ampliando os kernels de DeepGEMM para admitir un termo de sesgo.

Motor de inferencia propio

Os nosos esforzos de inferencia están respaldados polo noso motor de inferencia interno, ROSE. Estamos a construír ROSE para que sexa un marco flexible que permita poñer en marcha novos modelos rapidamente. Ademais, unha vez que nos comprometemos a servir un modelo a grande escala, proporciona unha plataforma para optimizar e impulsar o rendemento para acadar o estado da arte.

ROSE expón un motor LLM, que pode cargar un modelo e xerar tokens decodificados para el a través de múltiples decodificadores, incluídos decodificadores especulativos e MTP. Os propios modelos están compostos dun conxunto personalizado de capas, que admiten varias opcións de configuración para a cuantización e o paralelismo. Debaixo das capas, inclúe tanto kernels Triton como CUDA que implementan e fusionan de forma eficiente os cálculos realizados polas capas individuais.

ROSE está construído principalmente en Python e baséase en PyTorch para as definicións dos modelos. Aínda que Python nos permite ser flexibles e adaptarnos a novos modelos, estamos a migrar a maioría dos compoñentes sensibles ao rendemento, como a servizón e a planificación de lotes, a Rust.

Para poñer en marcha un novo modelo, primeiro definimos a xerarquía do modelo e construímos un conversor de pesos para el. Unha vez que se teñen en conta todos os pesos, definimos unha pasada cara adiante para o caso de uso TP=1 máis sinxelo e asegurámonos de que funcione de extremo a extremo. Finalmente, implementamos e probamos o soporte para varias formas de antes de lanzar un novo contedor e despregar o modelo nun clúster para a súa avaliación. A continuación, iteramos sobre o rendemento, apoiándonos nos comentarios dos paneis e en probas de rendemento máis detalladas.

ROSE opera con tokens numéricos, cun coñecemento limitado dos formatos de chat fóra das probas de integración. En paralelo, tivemos que investigar a axuste da infraestrutura circundante para admitir o tokenizador Harmony e mapear correctamente as solicitudes ás secuencias de tokens de entrada.

Co modelo GPT OSS, atopamos que non se requiriron cambios nos nosos decodificadores, nas estruturas de grafos CUDA nin na infraestrutura circundante, o que nos permitiu centrar os nosos esforzos en axustar os kernels que sustentan o modelo.

Kernels para GPT-OSS

Atención de sumidoiros

A atención de sumidoiros introduce un factor de sesgo adicional antes de softmax, acumulado co produto de Q e K:

Aínda que unha implementación inxenuo é bastante trivial, as implementacións de atención eficientes, como FlashInfer, paralelizan o cálculo da atención tanto entre cabezas independentes como ao longo da lonxitude da secuencia KV. Ademais, para a estabilidade numérica, o Softmax calcúlase en liña mentres se resta tamén o elemento máximo para garantir a estabilidade numérica:

A implementación en liña fixo un seguimento dun máximo en execución m inicializado en -inf e dunha escala d en 1. Ao inicializar o máximo co valor de sumidoiro da cabeza actual, aseguraríamos que se acumulase correctamente no Softmax. Tivemos que coidar de garantir que este máximo só se incluíse no primeiro anaco se a atención se dividía en varios bloques ao longo da lonxitude da secuencia.

Axustamos o modelo de kernel FlashInfer FA2, usado tanto para o prefill como para a decodificación, para incluír os parámetros de sumidoiro.

MoE

A principal diferenza entre a capa MoE de diferentes modelos adoita ser o esquema de enrutamento. Agardando unha variabilidade substancial, ROSE implementa este kernel en Triton, o que nos permite adaptalo facilmente a novos modelos. No caso de GPT-OSS, tivemos que axustar a puntuación de peso para realizar softmax só nos expertos seleccionados Top-K, a diferenza dalgúns modelos de estilo DeepSeek que calculan softmax en todos os expertos. Vimos que é fundamental para a precisión calcular os pesos dos expertos en precisión bfloat16.

O reto coa capa MoE deuse pola nosa decisión de reutilizar os kernels de DeepGEMM existentes, aos que lles faltaba soporte para termos de sesgo. Afortunadamente, co tempo integramos profundamente con eles, facendo cambios para conectalos mellor cos nosos kernels de despacho personalizados de todos a todos. Engadimos soporte de sesgo a DeepGEMM inicializando os rexistros acumuladores WGMMA cos valores de sesgo cargados desde a memoria. Isto é unha operación única durante o procesamento dun bloque MN, polo que o custo é probablemente despreciable e a caché L2 garante un acceso eficiente a estes valores.

Dado que estes modelos non se benefician directamente do paralelismo de datos, reutilizamos os kernels de despacho e combinación exclusivos de TP. As entradas para o despacho replícanse en todos os rangos, polo que o despacho selecciona os tokens para os expertos dispoñibles localmente. A combinación realiza a acumulación ponderada a través de NVLink.

Axustes de rendemento

Aínda que o noso obxectivo era poñer en marcha os modelos rapidamente, queríamos asegurarnos de que o rendemento seguise sendo razoable. Despois de garantir a corrección fronte a unha implementación de referencia proporcionada por OpenAI, perfilamos a nosa implementación empregando o xerador de perfís predeterminado de PyTorch, vixiando as asignacións de bloques e fíos nos kernels. A funcionalidade que reutilizamos creouse para modelos que tiñan unha dimensión oculta maior de 7168, substancialmente maior que os 2880 dos modelos GPT-OSS. Especializamos os lanzadores de kernels para escoller mellores dimensións de cuadrícula, aumentando significativamente o rendemento.

Tokenización e canles

O formato de chat de Harmony ten varios conceptos importantes para estruturar conversas, contido de razonamento e chamadas a funcións. Neste formato, cada mensaxe consta dunha cabeceira e contido:

A cabeceira transporta metadatos —máis importante o rol (sistema, programador, usuario, asistente, ferramenta), a canle e un destinatario como to=functions.<function-name> ao invocar unha chamada a función.

As canles (como a análise, os comentarios e a resposta final) fan que as saídas do modelo sexan máis transparentes e segmentadas. Debido a que o formato impón esta separación, o modelo pode razonar de forma transparente (e ser inspeccionado para a depuración) sen filtrar a cadea de pensamento na produción. As etiquetas de destinatario (cabeceiras to=) indican ao tempo de execución exactamente que actor debe recibir a seguinte carga útil, xa sexa unha función, o propio modelo ou o usuario final.

O noso motor de inferencia ROSE é independente do formato. Recibe un lote de tokens de entrada e transmite de volta os tokens de saída. Na nosa pila de inferencia, a tarefa de formatear as entradas nun aviso tokenizado e analizar os resultados do LLM de novo en mensaxes estruturadas é xestionada polo servizo frontend da API JSON adicado. Integramos Harmony engadindo un novo formateador/analisador conectable a este frontend, o que permite que o backend permaneza invariable mentres o frontend xestiona limpamente as regras de formato de chat, as chamadas a funcións e a transmisión. Esta separación de intereses mantén a arquitectura modular, permitindo a adopción rápida de novos formatos e funcións de resposta con cambios mínimos no backend.

Custo e rendemento

Dado o tamaño relativamente pequeno dos modelos GPT-OSS, limitamos a implantación dunha réplica a un único nodo para evitar a sobrecarga de comunicación entre nodos. A nosa implementación admite combinacións flexibles de paralelismo de expertos (EP), paralelismo de datos (DP) e paralelismo de tensores (TP). Para determinar a configuración de implantación óptima, avaliamos todas as combinacións de estratexias de fragmentación en tamaños de lote de 1 a 128. Grazas á desagregación de prefill e decodificación, podemos falar da relación de compromiso entre rendemento e custo por separado para o prefill e a decodificación.

Para as estimacións de custos, asumimos unha tarifa de mercado nominal de H200 de 3,00 $/hora (nota: este non é o noso prezo real de GPU).

Descubrimos que configurar batch_size=1 e DP=1 produce o mellor rendemento de prefill. As diferentes configuracións de TP proporcionan entón compensacións variadas entre a latencia do primeiro token e o custo. As táboas seguintes presentan a latencia de prefill e o custo por millón de tokens de entrada para varias configuracións e lonxitudes de entrada.

GPT-OSS 120B:

Latencia de prechegado de GPT-OSS 120B e custo por millón de tokens de entrada segundo a configuración de paralelismo e a lonxitude de entrada.

GPT-OSS 20B:

Latencia de prechegado de GPT-OSS 20B e custo por millón de tokens de entrada segundo a configuración de paralelismo e a lonxitude de entrada.

Para a decodificación, descubrimos que EP4 DP1 TP4 é a mellor configuración para a maioría dos casos. Os catro gráficos seguintes ilustran a relación de compromiso entre a velocidade de decodificación e o custo por millón de tokens de saída para os modelos de 120B e 20B en lonxitudes de secuencia de 8192 e 32768.

Ampliar

Ampliar

Ampliar

Ampliar

Tamén consideramos empregar o modelo máis pequeno de 20B como modelo de borrador de decodificación especulativa para o modelo máis grande de 120B. Con todo, debido a que o número de parámetros activados é similar (3B fronte a 5B), as aceleracións resultantes foron marxinais.

Referencias

Prefill e decodificación desagregados

Aceleración de Sonar mediante especulación​

Menor latencia e maior rendemento coa implantación de DeepSeek en varios nodos

​Comunicación de expertos en mestura eficiente e portátil

​pplx-kernels

DeepGEMM

FlashInfer: Motor de atención eficiente e personalizable para a servizón de inferencia LLM

Modelos de linguaxe en fluxo eficientes con sumidoiros de atención

Informe técnico de DeepSeek-V3​

​Formato de resposta de OpenAI Harmony | Libro de receitas de OpenAI​

Cita

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