Alojamiento de Qwen en Blackwell

Los racks NVIDIA GB200 NVL72 con GPU NVIDIA Blackwell interconectados mediante NVLink de 72 vías son especialmente adecuados para implementar modelos de gran mezcla de expertos (MoE). En esta entrada de blog, describimos la configuración de inferencia que sirve modelos Qwen3 235B post-entrenados que respaldan una parte del tráfico de Perplexity. Mostramos cómo adaptamos nuestro motor de inferencia interno para aprovechar los núcleos tensoriales avanzados y la interconexión de alta velocidad de las GPU NVIDIA Blackwell. Con este hardware, gestionamos más tráfico a un menor coste sin sacrificar la precisión de los modelos subyacentes.

Implementación en GB200 NVL72

Los racks GB200 NVL72 están compuestos por 18 nodos con 2 CPU NVIDIA Grace basadas en ARM y 4 GPU basadas en Blackwell, cada una equipada con 180 GB de HBM. Las 72 GPU están interconectadas a través de NVLink y 18 ASIC de conmutación NVLink, ofreciendo 1800 GB/s de ancho de banda entre dos pares cualesquiera y compartiendo suficiente memoria para alojar modelos de un billón de parámetros. Además, los adaptadores InfiniBand ConnectX-7 ofrecen un ancho de banda adicional de 400 Gb/s tanto dentro de los nodos de un rack como entre racks vecinos.

Para gestionar el tráfico, optamos por post-entrenar y servir modelos Qwen. En esta entrada de blog, nos centramos en Qwen3 235B, pero muchas de las técnicas de servicio y características de rendimiento discutidas son similares a las de los modelos más nuevos Qwen3.5 397B y 122B a los que estamos migrando. En términos de paralelismo, la atención lineal es similar a la auto-atención completa y la implementación existente de la capa MoE puede adaptarse fácilmente para acomodar los nuevos términos de puerta (gate terms). Para mantener una tasa de decodificación constante mientras maximizamos el rendimiento, hemos elegido desagregar el prellenado de la decodificación, desplegando diferentes estrategias de paralelismo para los dos tipos de nodos. La comunicación entre el prellenador y el decodificador se gestiona a través de InfiniBand, mientras que el ancho de banda de NVLink se reserva para la comunicación dentro de los prellenadores y decodificadores. Las características de rendimiento de los dispositivos Blackwell al realizar la multiplicación de matrices y la comunicación entre dispositivos, exploradas en esta entrada de blog, determinan las estrategias de fragmentación utilizadas. En comparación con las GPU NVIDIA Hopper, observamos mejoras núcleo a núcleo debido al mayor número de multiprocesadores de transmisión, un mayor ancho de banda de memoria y menores latencias punto a punto.

Ampliar

Nuestro TransferEngine, que implementa el prellenado desagregado, gestiona la fragmentación arbitraria y posiblemente no coincidente entre prellenadores y decodificadores. Las cachés KV están dispuestas en la memoria en orden HND, con los encabezados en la dimensión principal y los tokens mantenidos contiguos, para permitir que una caché KV fragmentada en un prellenador se divida o concatene aún más durante la transferencia al nodo decodificador.

Prellenadores

Los nodos prellenadores reciben los tokens de entrada de una solicitud, poblando las cachés KV y transfiriéndolas a los decodificadores para continuar con la generación de texto. El prellenado es intensivo en términos computacionales, ya que miles de tokens pertenecientes a una secuencia se procesan al mismo tiempo.

En consecuencia, descubrimos que un despliegue de paralelismo tensorial es adecuado, con el modelo fragmentado a través de 4 GPU dentro de un único nodo GB200 y las proyecciones y expertos fragmentados (TP=4, EP=4). Dado que tanto la atención como los MLP están limitados por el cómputo, ambos se benefician del paralelismo, distribuyendo expertos y cabezales de atención a través de rangos separados. Un mayor paralelismo habría producido rendimientos decrecientes, ya que la mejora en el rendimiento al alojar menos expertos en cada rango (16 frente a 32) no habría compensado el coste adicional de una reducción total de 8 vías y la sobrecarga de dividir el código del lado del host en dos nodos, lo que requeriría comunicación a través de Ethernet.

Qwen3 235B solo tiene 4 cabezales clave-valor, lo que requiere que las proyecciones k y v se repliquen a través de pares de rangos si se utilizan 8 dispositivos. Podríamos haber considerado una fragmentación más agresiva para reducir la cantidad de memoria necesaria para almacenar pesos en cada rango, liberando Espacio para más tokens en la caché KV. Sin embargo, descubrimos que un despliegue más amplio no valía la pena.

Asumiendo una longitud de entrada de alrededor de 6000 tokens, cada uno de los 128 expertos tiene alrededor de 6000 * 8 / 128 = 375 tokens enrutados hacia él, asegurando un problema denso para MoE GEMM. Dado que esto ya satura el rendimiento computacional del dispositivo, no se necesita paralelismo de datos para el prellenado.

A pesar del coste cuadráticamente creciente de la atención, los prellenadores ofrecen un rendimiento constante, lo que permite una estimación aproximada del número de tokens de entrada que pueden ser procesados por un nodo en un segundo. Al confiar en métricas que rastrean el número total de tokens de entrada de las solicitudes, el número de nodos prellenadores se puede escalar para asegurar que el rendimiento general del prellenado esté dimensionado adecuadamente. Para evitar colas, el número de réplicas de prellenadores coincide con el número total de tokens de entrada recibidos.

Decodificadores

Los nodos decodificadores reciben las cachés KV de los prellenadores y generan tokens uno a uno. La decodificación generalmente está limitada por la memoria: con pocos tokens de entrada, la multiplicación de matrices está totalmente limitada por el coste de cargar los pesos desde HBM a los Tensor Cores. Además de emplear una estrategia de fragmentación diferente, varios núcleos deben ajustarse para paralelizar mejor los cálculos y los accesos a la memoria.

A diferencia del prellenado, la fragmentación de la atención ya no es beneficiosa: dividir los cabezales de atención a través de múltiples dispositivos significaría que hay menos oportunidades para el paralelismo dentro de un solo dispositivo. En consecuencia, solo se utilizan el paralelismo de datos y el paralelismo de expertos: los expertos se fragmentan en múltiples dispositivos, pero cada dispositivo gestiona sus propias cachés KV y solicitudes. Sin paralelismo tensorial, el tamaño de la caché KV por token en un dispositivo es mayor. Sin embargo, se libera Espacio en la memoria al ubicar menos expertos en un solo nodo. A diferencia de Hopper, donde limitamos el paralelismo tensorial dentro de un único dominio NVLink en un nodo de 8 GPU, en Blackwell descubrimos que expandirse a través de múltiples nodos dentro de un dominio, usando hasta 16 dispositivos, es beneficioso.

Para maximizar el rendimiento, los decodificadores procesan un mayor número de solicitudes simultáneamente. Aunque las solicitudes adicionales incurren en una sobrecarga mínima en las capas MoE y otras proyecciones, aumentan desproporcionadamente el coste de la atención. Para mantener una velocidad de decodificación mínima razonable, el número de nodos decodificadores se escala para mantener los tamaños de lote por decodificador por debajo de cierto umbral.

De manera similar a los despliegues anteriores de Hopper, utilizamos decodificación especulativa con capas MTP entrenadas internamente para aumentar las tasas de decodificación. Afortunadamente, el hardware subyacente y los marcos de programación son lo suficientemente similares como para compartir completamente la implementación entre las dos arquitecturas.

Comunicación intra-nodo e inter-nodo

La principal diferencia entre GB200 NVL72 y los nodos Hopper anteriores es el gran dominio NVLink, que permite la comunicación punto a punto más allá del límite anterior de 8 dispositivos. Aunque los dispositivos Blackwell se han desplegado en nodos de 8 GPU, hay mucho valor en escalar a través de múltiples nodos sobre NVLink en comparación con la red InfiniBand más lenta.

En los nodos prellenadores, confiamos en la comunicación de reducción total (all-reduce) dentro de las capas de atención y en una reducción paralela de expertos que se asemeja mucho a la reducción total. A través de 4 GPU, aprovechamos tanto NVLink como NVIDIA SHARP (Protocolo de agregación y reducción jerárquica escalable): además del ancho de banda punto a punto, también explotamos las reducciones en los conmutadores NVLink para reducir aún más las latencias e implementar transmisiones rápidas. En los nodos decodificadores, se utiliza una implementación personalizada de despacho y combinación de todos a todos (all-to-all) sobre NVLink. Los núcleos han sido implementados internamente utilizando asignaciones CuTeDSL y cuMem o asignaciones de multidifusión.

Reducción total

Los prellenadores realizan una operación de reducción total en la proyección de salida de la capa de atención, sumando las contribuciones de los cabezales fragmentados a través de los rangos participantes. El paralelismo tensorial solo es efectivo cuando el coste de la sobrecarga de la reducción total se compensa con la latencia reducida de los problemas de multiplicación de matrices más pequeños. Esta suposición generalmente se cumple para el prellenado.

En los sistemas NVIDIA HGX H200 y GB200 NVL72 de grado de centro de datos, las GPU generalmente están conectadas a través de conmutadores NVLink. Además del enrutamiento, los conmutadores pueden realizar operaciones de reducción en dispositivos conectados a través de SHARP. Después de crear asignaciones de memoria y registrarlas en un grupo de multidifusión utilizando las API de CUDA, los núcleos pueden usar multicast.ld_reduce y multicast.st para agregar y difundir valores a través de los conmutadores. Para crear una base y componentes reutilizables que puedan fusionarse en otros núcleos, mantenemos internamente un núcleo de reducción total CuTeDSL utilizando estas primitivas.

En un sistema con N GPU reduciendo B bytes, una implementación trivial haría que un par cargara valores de todos los demás pares, para un total de N * (N - 1) * B bytes de tráfico de lectura. Una implementación más eficiente dividiría los datos a reducir entre los pares, con cada uno reduciendo una porción de la entrada, y luego difundiéndola al resto. Esto resulta en (N - 1) * (B / N) bytes leídos en un par y difundidos al resto, para un total de (N - 1) * B * 2 lecturas y escrituras, reduciendo el tráfico sobre los conmutadores.

Ampliar

Con SHARP, la reducción y la difusión se pueden realizar de manera más eficiente: en lugar de leer (N - 1) * (B / N) bytes en un dispositivo para la acumulación local, solo se mueven B / N desde el conmutador, ya que realiza la reducción en sí misma utilizando datos de los pares. Para la difusión, existe una mejora similar, ya que el número de transacciones entre una GPU y el conmutador a través de canales NVLink se reduce considerablemente. Sin SHARP, el dispositivo acumulador realizaría (N - 1) * (B / N) transacciones sobre NVLink con el conmutador, con el conmutador leyendo la misma cantidad de datos de los pares, para un total de 2 * (N - 1) * (B / N) transacciones. Con SHARP, se realizan B / N transacciones entre la GPU y el conmutador, y otras (N - 1) * (B / N) con los pares, para un total de B transacciones.

Debido a su simplicidad, SHARP es una herramienta valiosa, ya que proporciona una implementación de hardware sencilla para un algoritmo. Aunque las transferencias se reducen en una fracción teórica de N / (2 * (N - 1)) (que equivale al 33% con 4 pares), en la práctica observamos una mejora del 10% tanto en las latencias de prellenado como de decodificación en los sistemas H200 y GB200 NVL72.

Ampliar

Despacho - Combinación MoE

Para los modelos MoE, los núcleos de despacho y combinación mueven y agrupan tokens para los problemas subsiguientes de MoE GEMM entre pares, realizando una acumulación ponderada después en la combinación. Hemos adaptado nuestros núcleos existentes de despacho y combinación a Blackwell, portándolos a CuTeDSL, ajustando las asignaciones de bloques y especializándolos agresivamente entre el prellenado y la decodificación.

Experto paralelo

El núcleo experto paralelo (EP) se utiliza en los prellenadores. Dado que sus entradas se replican en todos los rangos, el núcleo de despacho solo necesita seleccionar los tokens enrutados a los expertos en el rango actual. Agrega información de enrutamiento y prepara los tokens en búferes utilizados como entradas para MoE GEMM. El núcleo de combinación primero realiza una acumulación local entre las contribuciones de los tokens enrutados a los expertos en el rango actual, luego realiza una reducción total a través de todos los rangos.

Para la decodificación, todo el núcleo se fusiona en uno. El núcleo de prellenado se divide en múltiples núcleos, ya que el enrutamiento y la reducción total requieren menos bloques que el paso de combinación local. Con CuTeDSL, pudimos construir una biblioteca genérica tanto para SHARP como para la reducción total de NVLink y la sincronización punto a punto, componiéndola en ambos núcleos, el de reducción total y el de experto paralelo.

Ampliar

En cuanto al rendimiento, observamos que Blackwell es sustancialmente más rápido que Hopper, debido a mejores velocidades de transferencia, mayor ancho de banda de memoria y mejor rendimiento computacional. Fragmentado en 8 dispositivos y múltiples nodos en GB200 (EP=8), los núcleos se vuelven más rápidos ya que la acumulación local se ejecuta con muchos menos tokens en cada dispositivo y, con SHARP, el coste de la reducción en más rangos escala mejor. Sin embargo, en la práctica, limitamos el paralelismo a 4 dispositivos, ya que estas aceleraciones no son universales en todos los núcleos.

Paralelo de datos y experto paralelo

El núcleo paralelo de datos y experto paralelo (DP-EP) se utiliza en los decodificadores paralelos de datos. Difunde diferentes tokens desde todos los rangos a los expertos, transfiriendo los resultados a los rangos de origen y acumulándolos. Dado que implementa un problema disperso de todos a todos, depende únicamente de NVLink.

En Hopper, este núcleo está limitado a 8 dispositivos dentro del dominio NVLink de un solo nodo. Sin embargo, en los sistemas GB200 podemos escalarlo a través de todo un rack. La mayor parte del código se reutiliza. La única diferencia es el uso de identificadores de fabric para intercambiar información entre pares sobre IMEX para la configuración inicial.

Ampliar

Dado que los tamaños de transferencia incurridos durante la decodificación son pequeños, están lejos de saturar el ancho de banda de NVLink y, en cambio, están limitados por la latencia. Las latencias se sitúan en decenas de microsegundos y permanecen relativamente estables a medida que aumenta el número de pares, lo que nos permite distribuir un despliegue en un mayor número de dispositivos sin incurrir en una latencia adicional significativa.

MoE GEMM

Los modelos MoE se benefician del paralelismo de expertos, ya que el coste de multiplicar todos los tokens con todos los expertos puede paralelizarse fácilmente en múltiples dispositivos. Con el paralelismo tensorial en los prellenadores, en problemas densos el beneficio es bastante directo, ya que cada rango ahora tiene que realizar menos cálculos. En el caso de la decodificación, el paralelismo de datos proporciona un beneficio adicional sobre el paralelismo de expertos, ya que el mayor número de solicitudes paralelas enruta más tokens a cada experto, densificando los problemas.

En nuestra implementación, actualmente dependemos de los núcleos CUDA/C++ de CUTLASS para la multiplicación de matrices. Los evaluamos en entradas de decodificación dispersas con varios esquemas de cuantificación y niveles de paralelismo para decidir la estrategia de fragmentación óptima para los decodificadores. En los puntos de referencia a continuación, todos los expertos se activan con un solo token.

Ampliar

Descubrimos que escalar 128 expertos a más de 16 rangos produce rendimientos decrecientes con CUTLASS, ya que el coste de multiplicar 2 expertos no es sustancialmente menor que multiplicar 4. Hay una clara mejora en Blackwell sobre Hopper, incluso en la estrategia de escalado de bloques subóptima. Dado que el aumento de latencia de aproximadamente 5 us entre EP=8 y EP=16 de despacho/combinación es superado por una disminución de más de 10 us en el coste de GEMM, en los sistemas GB200, la fragmentación de los decodificadores en 16 rangos está justificada, como lo confirman también los puntos de referencia de extremo a extremo.

Cuantificación

Blackwell introduce soporte de hardware para nuevos esquemas de cuantificación de 8 y 4 bits. A diferencia de Hopper, que dependía de factores de escalado por tensor o por bloque, Blackwell requiere microescalado para lograr el mejor rendimiento de prellenado y decodificación. Si bien el esquema de escalado de bloques utilizado para modelos como DeepSeek o Kimi está disponible, el microescalado es más eficiente.

Hemos desplegado Qwen3 235B con el esquema de cuantificación MXFP8, convirtiendo los pesos estáticamente después de ajustar el modelo. El impacto en la precisión fue similar al impacto del escalado de bloques con cuantificación estocástica, pero el rendimiento ofrecido fue mucho mejor, como lo ilustran los micro-benchmarks de MoE GEMM. También hemos considerado los esquemas de cuantificación MXFP4 y NVFP4, aunque el impacto en la precisión sin un entrenamiento consciente de la cuantificación fue demasiado significativo para la transición inicial de Hopper a Blackwell. Planeamos explorar estos formatos más a fondo en trabajos futuros.

Rendimiento de extremo a extremo

Evaluamos los decodificadores de los despliegues de Blackwell Qwen3 235B y los comparamos con nuestros despliegues anteriores de Hopper. En esta configuración, consideramos el escalado de bloques en ambos despliegues para centrarnos en el impacto del paralelismo. Los prellenadores TP=4 se separaron para ambas arquitecturas con el fin de aislar el rendimiento de la decodificación. La siguiente figura ilustra el rendimiento de decodificación asumiendo una tasa de aceptación de borrador realista proporcionada por nuestras capas MTP.

Ampliar

En Hopper, fragmentar el despliegue en más de 8 GPU no es viable, ya que las latencias a través de InfiniBand, particularmente en adaptadores EFA, son sustancialmente más lentas. Sin embargo, en Blackwell, logramos un rendimiento sustancialmente mayor, gracias a los dominios NVLink más grandes.

Logramos una implementación inicial de Blackwell generalizando los núcleos de Hopper existentes y aumentando el rendimiento de los núcleos basados en NVLink. Seguiremos reduciendo el coste de servir a Qwen mejorando la cuantificación y ajustando el rendimiento de la decodificación y el rendimiento del prellenado de los otros núcleos en la tubería.

Referencias

Entrada de blog de Transfer Engine

Entrada de blog de CuTeDSL

Entrada de blog de Prefill-Disagg

Entrada de blog de decodificación especulativa

CUTLASS

NVLink

Citación

@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}