Cómo ejecutar GPT-OSS-120B en GPUs de NVIDIA a más de 500 tokens por segundo

• Se optimizó GPT-OSS-120B, el LLM de código abierto de OpenAI, para lograr un rendimiento de más de 500 tokens por segundo en entornos de GPU de NVIDIA.
• Se realizaron pruebas paralelas de diversos frameworks de inferencia como TensorRT-LLM, vLLM y SGLang, con soporte para las arquitecturas Hopper y Blackwell.
• Se corrigieron bugs de compatibilidad e integró un formato de respuesta nuevo como Harmony, además de aplicar optimizaciones como enrutamiento con conocimiento del caché KV y decodificación especulativa basada en Eagle.
• Al comparar Tensor Parallelism y Expert Parallelism, se eligió Tensor Parallelism por su menor latencia, y en Blackwell se utilizó el backend MoE de TensorRT-LLM.
• Se planea seguir optimizando el rendimiento, incluyendo la decodificación especulativa (Speculative) con un modelo de “draft” más pequeño.

---

Visión general

• Cuando OpenAI lanzó GPT-OSS-120B, su último modelo de lenguaje de gran escala de código abierto, Baseten se propuso alcanzar el máximo rendimiento.
  • Baseten es el socio de lanzamiento oficial de OpenAI.
• Con datos públicos de usuarios reales de OpenRouter, validaron un rendimiento líder en entornos con GPU de NVIDIA frente a otros proveedores.
• Gracias al Flexible Inference Stack y la experiencia del equipo de ingeniería de modelos, aplicaron parches de optimización de forma rápida, casi por horas.
• En las pocas horas de redactar el blog, lograron un aumento adicional de más de 100 tokens por segundo y mantuvieron un 100% de tiempo de actividad.

Esfuerzos de optimización de rendimiento

• Se realizaron pruebas y benchmarking con distintos frameworks de inferencia como TensorRT-LLM, vLLM y SGLang.
• En paralelo, se aseguró compatibilidad con las arquitecturas de GPU Hopper y Blackwell.
• Se integró con componentes clave como el Flexible Inference Stack de Baseten y NVIDIA Dynamo.
• Se aplicaron técnicas de optimización de rendimiento ampliamente validadas, como KV cache-aware routing y Speculative decoding (basado en Eagle).

A continuación, se detallan los pasos clave para lograr simultáneamente un rendimiento SOTA y soporte de ventana de contexto completa.

Paso 1: Ejecución inicial de inferencia

• Cualquiera sea el enfoque, el punto de partida fue ejecutar la inferencia inicial (baseline inference) lo más rápido posible.
• Aprovechando la potencia de la GPU, varios ingenieros corrieron en paralelo experimentos con vLLM, SGLang y TensorRT-LLM.
• Se logró poner en marcha rápidamente el TensorRT-LLM, que mostró el mejor rendimiento.
• Se garantizó soporte de TensorRT-LLM tanto en Hopper (la de mayor cantidad de GPUs H100) como en Blackwell (donde B200 ofrece mejor velocidad).
• Gracias a la flexibilidad de Baseten Inference Runtime, resultó sencillo adaptar nuevos modelos de arquitectura y cambiar herramientas dentro del stack rápidamente.

Paso 2: Corrección de bugs de compatibilidad

• La aparición de nuevas arquitecturas de modelos suele venir acompañada de fallos frecuentes durante la integración de frameworks.
• GPT-OSS agregó nuevas tecnologías, como el formato de respuesta Harmony, lo que generó bugs al integrar con frameworks existentes.
• Para mantener velocidad y precisión a la vez, realizaron ajustes y pruebas repetidas, y contribuyeron al open source las correcciones efectivas.
• La colaboración de la comunidad open source global está haciendo que los caminos de optimización y las correcciones de bugs avancen con rapidez.

Paso 3: Optimización de la configuración del modelo

• Aunque OpenAI indica que GPT-OSS-120B funciona en una sola H100, en la práctica se favorece paralelizar entre 4~8 GPUs para mejor rendimiento.
• Tensor Parallelism destaca en latencia, mientras que Expert Parallelism destaca en throughput del sistema.
  • Como el objetivo de Baseten era optimizar la latencia, eligieron Tensor Parallelism.
• En Blackwell, se aplicó el TensorRT-LLM MoE Backend, mejorando el rendimiento de los kernels CUDA en comparación con el backend Triton anterior.
• Se publicaron configuraciones optimizadas para entornos Hopper y Blackwell, y en la Model API se adoptó la configuración basada en Blackwell.

Optimización de rendimiento adicional

• Aunque con la primera etapa de optimización ya alcanzaron niveles SOTA en throughput y latencia, aún hay margen para mejorar.
• La actualización principal prevista es la incorporación de Speculative Decoding.
  • Este método usa un modelo de “draft” más rápido que genera tokens candidatos, que luego son validados por el modelo principal.
  • Baseten recomienda Eagle 3, pero opera de forma dinámica con más de 10 algoritmos dentro del stack de inferencia según el escenario.
• La decodificación especulativa permite inferir varios tokens a la vez para lograr una mejora de velocidad más eficiente

[jjw951215]

Yo también quisiera que alguien me diera una H100 pequeña y bonita...

[GN⁺]

Opinión de Hacker News

• widely-available H100 GPUs
  Y con eso revisé el cajón de repuestos de casa, pero por más que buscaba no entendía por qué no había una GPU H100 de US$25,000.

  • En la ficha de productos de NVIDIA confirmé que la H100 está clasificada como GPU. Creo que hace falta una nomenclatura que distinga mejor entre “hardware de consumo orientado al gaming, con un uso de LLM muy limitado” y “hardware de nivel empresarial enfocado al entrenamiento de IA o a la inferencia de LLM como su objetivo principal y de negocio”.
  • Probé un modelo de 20B con Ollama en 8 tarjetas TitanX (de 2015). Ollama distribuyó de forma uniforme los 15 GB de VRAM entre las 8 tarjetas, y la velocidad de tokens fue más alta que la velocidad de lectura.
  • Este tipo de GPUs se pueden arrendar con mucha facilidad. Si no vas a tenerlas activas 24/7 por largo tiempo, suele ser más barato alquilar hosting que comprarlas. Como usuario personal rara vez necesitarás usar tarjetas de nivel datacenter de última generación; en esos casos Mac Studio o Strix Halo son suficientes, aunque algo más lentos.
  • Este comentario animó bastante mi día de hoy. Claramente viene desde la mirada de datacenter, y el hardware más rápido que tengo en casa probablemente sea un viejo iPhone 8.
  • Decir “No tengo una GPU de US$25,000 en casa” no significa que no se pueda comprar. Quiere decir solo que hay disponibilidad y “se puede conseguir”, no necesariamente que se tenga dinero suficiente para comprarla en ese momento.
• Probé GPT-OSS-120B en un MacBook Pro (M4, 128GB RAM) durante un vuelo transatlántico.
  Es rápido solo cuando la ventana de contexto es pequeña y el total de tokens es bajo. Si pasa de 10k tokens, casi todo se vuelve lento y termina en cola.
  MCPs, búsqueda web y parches de URL ya se volvieron muy importantes en la experiencia real de uso de LLM. Sin esas capacidades, la utilidad del LLM cae bastante.
  Las herramientas de codificación CLI/TUI configuradas para entorno offline (como opencode) no funcionaron de forma confiable con el modelo.
  Además de lo que ya se mencionó antes, los modelos OSS tienen estas otras peculiaridades:
  • Ya era posible guardar Wikipedia localmente y usarla, así que pronto se expondrá mucha data por MCP y las IAs van a buscar en local como si fuera búsqueda web. El 99% de la búsqueda web ocurre en ese mismo conjunto de 100 a 1000 sitios. En total, con unos pocos GB ya se puede cubrir, así que el tema de copyright sigue presente.
  • Me intriga saber si usaron Ollama, LMStudio o llama.cpp tweet de ggerganov.
  • Me pregunto cómo configuraste iogpu.wired_limit_mb. Con el valor por defecto, solo alrededor del 70% de RAM (unos 90GB) puede ser usado por los núcleos GPU. Para aprovechar más hay que cambiar esa configuración.
  • Lo hice con un procesador M2 Max. En charlas cortas vi más de 60 tokens/s, pero en sesiones largas bajó a 30. No parece problema de temperatura.
  • Creo que es un tema de prefill compute-bound y decode-bound (cuando la relación entre ancho de banda y cómputo del CPU es alta). Incluso con 10k de contexto, no tardó ni 0.5 segundos en sacar el primer token.
• Varios ingenieros probaron en paralelo vLLM, SGLang y TensorRT-LLM. Dicen que TensorRT-LLM es lo más rápido, pero suele ser el más difícil de configurar, no refleja bien la arquitectura nueva y además obliga a compilar el modelo directamente en un stack hardware-driver-library idéntico al de producción, así que es bastante engorroso. El multimodal estuvo casi imposible por un buen rato, y hasta modelos multimodales “representativos” de Llama no funcionaron bien. Me pregunto si vale la pena; por ejemplo, correr GPT-OSS-120B en H100 con vLLM funciona sin problema y entrega de forma constante 130~140 t/s. Por el título parecería que una sola GPU saca 500 t/s, pero en realidad es configuración de paralelismo tensor. También es un poco raro que se haya empacado TRT-LLM por separado para gpt-oss. TRT-LLM por sí solo ya es una herramienta bastante confusa.
  • Al experimentar con TRT-LLM hay muchos retos por el lado de DX. Cuando se hace multimodal, aún se usa mucho vLLM. Pero para tráfico de gran volumen y baja latencia como el que sirve nuestro sistema, en benchmarks TRT-LLM siempre fue mejor, así que invertimos bastante en este tooling.
• GPT-OSS 20B es realmente fácil de instalar. Gracias a Llama pude correrlo en mi Mac en 5 minutos.
  • Si tienes suficientes recursos de CPU, correr 120B no es difícil. En casa, descargué el archivo GGUF en el servidor de inferencia CPU, hice git pull y recompilé llama-server, y ya estaba listo; sin ajustes tuve 40 t/s, y alrededor de 50 t/s con un poco de tuning. Lamentablemente ya hay muchos modelos mejores que el 120B y no hace falta ejecutarlo, pero me parece enorme el esfuerzo de ggerganov y el equipo de llama.cpp para que uno pueda usar LLM incluso en entornos de cómputo personal.
  • Muchos dicen que configurar un LLM es complicado, pero ¿no bastaría con dejar que el propio LLM lo configure? Si algo tan simple no se puede hacer, ¿qué sentido tendría un LLM?
  • Ayer lo probé y en todas las sesiones seguía saliendo información incorrecta sobre los hechos. La velocidad y la conveniencia estaban bien, pero si sacrificas precisión eso no tiene sentido.
  • Si tienes suficiente memoria, 120B también se ejecuta muy fácilmente.
• Mientras leía esto, descubrí que no sabía que para que el modelo funcione bien se necesita una enorme preparación y tuning. Pensaba que con la configuración por defecto bastaba.
  • En mi opinión, las grandes compañías deberían colaborar de forma más activa con desarrolladores de motores de inferencia populares antes de lanzar sus LLM para que también se apoye su modelo. Si bien todo sigue siendo experimental, los desarrolladores sí están poniendo un gran esfuerzo para que puedas montar LLM incluso en hardware económico.
• En el AI Action Plan de EE. UU., “fomentar IA open source y con pesos abiertos” aparece justo después de “que la frontier AI proteja la libertad y los valores estadounidenses”. Tal vez no sea muy razonable, pero leer el modelo OSS de OpenAI en este momento me provocó un poco de escalofrío. Igual, me pareció buena señal que los desarrolladores de modelos OSS hablen de hardware: para la mayoría de desarrolladores el hardware es una barrera de entrada, así que se agradece que toquen ese tema.
  • También se menciona “hacer que la frontier AI proteja la libertad y los valores de EE. UU.”. Estoy todavía organizando mis ideas, así que les pido un poco de paciencia. Los modelos de IA siempre incorporan una cosmovisión y yo, en cambio, prefiero una visión occidental. Hay bastantes precedentes donde eso ha dado mejores sociedades. Al menos, que el modelo documente su visión del mundo y esté alineado con eso, y que no intente, sin que uno se dé cuenta, inducir cambios de pensamiento por ingeniería social.
• Me pregunto si conocen algún sitio que diga claramente qué modelos LLM funcionan bien por sistema operativo y por GPU. La fórmula más confiable que vi para estimar VRAM era parámetros × (precision/8) × 1.2 (referencia).
  • Intenté hacer una calculadora parecida, pero en la práctica hay demasiadas variables (tráfico de concurrencia, etc.). Esa fórmula sí es bastante aproximada, pero con mucha concurrencia es más seguro duplicar el resultado.
  • En Hugging Face, si ingresas hardware/software specs, hay una función que te muestra en cada página de detalle del modelo si ese modelo se puede usar o no configuración de huggingface.
  • En mi caso, como tengo buena conexión, descargar el archivo del modelo y probarlo directo en varios runners (llama.cpp, LM Studio, vLLM, SGLang, etc.) fue lo más rápido. Son demasiadas variables (runner/implementación/hardware) y ninguna calculadora me cuadró perfecto con la experiencia real. La única forma es probarlo.
  • Gracias a sus opiniones. Si estimar es difícil, pensé que sería útil que la comunidad armara un sitio DB para que se prueben y compartan combinaciones de runner, hardware, modelo, parámetros, cuantización, estado de funcionamiento, tokens/s y otros indicadores. Y si puedes filtrar por combinación hardware-runner, sería súper práctico.
• Quería decir que es sorprendentemente difícil encontrar cifras precisas del tamaño real del arreglo del modelo GPT-OSS-120B. En un lenguaje de tipado estático uno podría mirar de forma general el tamaño de arreglo, pero quería ver cómo fluye el resto de la data (más allá de los pesos) y qué tan ancho era el stream de salida. Me gustaría saber cuál es el máximo de ancho de banda de ‘salida de tokens’ en t/s de un Ethernet gigabit, y por eso estoy revisando el repositorio de GitHub gpt-oss, pero no se ve claro.
  • Me intriga qué aplicaciones hacen stream de logits para todos los tokens consecutivos (respetando el protocolo de muestreo). Además, normalmente hay que procesar y ajustar los logits antes de muestrear para luego alimentar la siguiente inferencia, sobre todo para cumplir sintaxis.
  • En la configuración del modelo en Hugging Face aparecen 2880 valores (producto del dtype).
• GPT-OSS corre más rápido en chips Blackwell gracias al soporte de fp4. Estamos construyendo un motor de entrenamiento/inferencia en Rust y sumando soporte fp8 y fp4 a cudarc y candle. PR de cudarc, PR de candle y estamos trabajando en el motor Mixlayer para soportar estos modelos.
  • Soy usuario de RTX Pro 6000 y quiero saber si ahora es posible inferir gpt-oss-120b. Los PRs ya parecen merged, pero me gustaría saber si ya se puede correr en la práctica.