Alojamiento de Qwen en Blackwell

Los racks NVIDIA GB200 NVL72 con GPU NVIDIA Blackwell interconectadas mediante NVLink de 72 vías son idóneos para implementar grandes modelos de mezcla de expertos (MoE). En esta publicación del blog, describimos la configuración de inferencia que ofrece servicio a los modelos Qwen3 235B postentrenados 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 interconectividad de alta velocidad de las GPU NVIDIA Blackwell. Con este hardware, gestionamos más tráfico a un costo menor sin sacrificar la precisión de los modelos subyacentes.

Implementación en GB200 NVL72

Los racks NVIDIA GB200 NVL72 se componen de 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 mediante NVLink y 18 ASIC de conmutación NVLink, lo que ofrece un ancho de banda de 1800 GB/s entre dos pares cualesquiera y comparte suficiente memoria para albergar modelos de un billón de parámetros. Además, los adaptadores ConnectX-7 InfiniBand proporcionan 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 postentrenar y servir modelos Qwen. En esta publicación del blog, nos centramos en Qwen3 235B, pero muchas de las técnicas de servicio y características de rendimiento analizadas 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 atención autorreferencial completa y la implementación de la capa MoE existente se puede adaptar fácilmente para dar cabida a los nuevos términos de puerta. Para mantener una tasa de decodificación constante y maximizar el rendimiento, hemos elegido separar el rellenado previo de la decodificación, implementando diferentes estrategias de paralelismo para los dos tipos de nodos. La comunicación entre el rellenador 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 rellenadores 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 publicación del blog, determinan las estrategias de fragmentación utilizadas. En comparación con las GPU NVIDIA Hopper, observamos mejoras núcleo por núcleo debido al mayor número de multiprocesadores de flujo, el mayor ancho de banda de memoria y las menores latencias punto a punto.

Ampliar

Nuestro TransferEngine, que implementa el rellenado previo desagregado, gestionó una fragmentación arbitraria y posiblemente no coincidente entre los rellenadores y los decodificadores. Las cachés de clave-valor se disponen en la memoria en orden HND, con los cabezales en la dimensión principal y los tokens mantenidos contiguos, para permitir que una caché de clave-valor fragmentada en un rellenador se divida aún más o se concatene sobre la marcha durante la transferencia al nodo decodificador.

Rellenadores

Los nodos de rellenado previo reciben los tokens de entrada de una solicitud, llenando las cachés de clave-valor y transfiriéndolas a los decodificadores para continuar con la generación de texto. El rellenado previo requiere un uso intensivo de computación, ya que miles de tokens pertenecientes a una secuencia se procesan al mismo tiempo.

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

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

Suponiendo una longitud de entrada de alrededor de 6000 tokens, a cada uno de los 128 expertos se le enrutan alrededor de 6000 * 8 / 128 = 375 tokens, lo que garantiza un problema denso para la multiplicación general de matrices (GEMM) de MoE. Dado que esto ya satura el rendimiento computacional del dispositivo, no se necesita paralelismo de datos para el rellenado previo.

A pesar del costo de aumento cuadrático de la atención, los rellenadores ofrecen un rendimiento constante, lo que permite una estimación aproximada de la cantidad de tokens de entrada que un nodo puede procesar en un segundo. Al depender de métricas que rastrean el número total de tokens de entrada de las solicitudes, el número de nodos de rellenado previo se puede escalar para garantizar que el rendimiento general del rellenado previo tenga el tamaño adecuado. Para evitar las colas, el número de réplicas de rellenado previo se adapta al número total de tokens de entrada recibidos.

Decodificadores

Los nodos decodificadores reciben las cachés de clave-valor de los rellenadores y generan tokens uno por uno. La decodificación generalmente está limitada por la memoria: con pocos tokens de entrada, la multiplicación de matrices está completamente limitada por el costo de cargar los pesos desde la HBM en los núcleos tensoriales. Además de emplear una estrategia de fragmentación diferente, es necesario ajustar varios núcleos para paralelizar mejor los cálculos y los accesos a la memoria.

A diferencia del rellenado previo, la fragmentación de la atención ya no es beneficiosa: dividir los cabezales de atención en múltiples dispositivos significaría que hay menos oportunidades de 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 administra sus propias cachés de clave-valor y solicitudes. Sin el paralelismo de tensores, el tamaño de la caché de clave-valor por token en un dispositivo es mayor. Sin embargo, se libera espacio en la memoria al ubicar a menos expertos en un solo nodo. A diferencia de Hopper, donde limitamos el paralelismo de tensores dentro de un solo dominio NVLink en un nodo de 8 GPU, en Blackwell descubrimos que es beneficioso expandirse a través de múltiples nodos dentro de un dominio, utilizando hasta 16 dispositivos.

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 costo de la atención. Para mantener una velocidad mínima de decodificación razonable, el número de nodos decodificadores se escala para mantener los tamaños de lote por decodificador por debajo de cierto umbral.

Al igual que con las implementaciones anteriores de Hopper, utilizamos la 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 intranodal e internodal

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. A pesar de que los dispositivos Blackwell se han implementado en nodos de 8 GPU, tiene mucho valor escalar a través de múltiples nodos mediante NVLink en comparación con la red InfiniBand, que es más lenta.

En los nodos de rellenado previo, dependemos de la comunicación de reducción total (all-reduce) dentro de las capas de atención y de una reducción paralela de expertos que se asemeja mucho a la reducción total. En 4 GPU, aprovechamos tanto NVLink como NVIDIA SHARP (Protocolo de Reducción y Agregació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 (broadcasts). En los nodos decodificadores, se utiliza una implementación personalizada de distribución y combinación de todos a todos (all-to-all) a través de NVLink. Los núcleos se han implementado internamente utilizando CuTeDSL y asignaciones cuMem o asignaciones de multidifusión (multicast).

Reducción total (All-Reduce)

Los rellenadores 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 en los rangos participantes. El paralelismo de tensores solo es efectivo cuando el costo de la sobrecarga de la reducción total se ve compensado por la latencia reducida de los problemas de multiplicación de matrices más pequeños. Esta suposición suele cumplirse en el rellenado previo.

En los sistemas NVIDIA HGX H200 y GB200 NVL72 de categoría para centros de datos, las GPU suelen estar conectadas mediante conmutadores NVLink. Además del enrutamiento, los conmutadores pueden realizar operaciones de reducción en los dispositivos conectados a través de SHARP. Tras crear asignaciones de memoria y registrarlas en un grupo de multidifusión mediante las API de CUDA, los núcleos pueden usar multicast.ld_reduce y multicast.st para agregar y transmitir 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 que utiliza estas primitivas.

En un sistema con N GPU que reducen B bytes, una implementación trivial haría que un par cargue 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 que se van a reducir entre los pares, y cada uno reduciría una porción de la entrada para luego transmitirla al resto. Esto da como resultado (N - 1) * (B / N) bytes leídos en un par y transmitidos al resto, para un total de (N - 1) * B * 2 lecturas y escrituras, lo que reduce el tráfico en los conmutadores.

Ampliar

Con SHARP, la reducción y la transmisió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 este realiza la reducción por sí mismo utilizando los datos de los pares. Para la transmisión, hay una mejora similar, ya que el número de transacciones entre una GPU y el conmutador a través de los canales NVLink se reduce drásticamente. Sin SHARP, el dispositivo acumulador realizaría (N - 1) * (B / N) transacciones a través de NVLink con el conmutador, y este leería 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 directa para un algoritmo. Aunque las transferencias se reducen en una fracción teórica de N / (2 * (N - 1)) (lo que equivale al 33 % con 4 pares), en la práctica observamos una mejora del 10 % tanto en las latencias de rellenado previo como de decodificación en los sistemas H200 y GB200 NVL72.

Ampliar

Distribución y combinación de MoE (MoE Dispatch - Combine)

Para los modelos MoE, los núcleos de distribución y combinación mueven y agrupan tokens para los posteriores problemas de GEMM de MoE entre pares, realizando una acumulación ponderada posteriormente en la combinación. Hemos adaptado nuestros núcleos de distribución y combinación existentes a Blackwell, portándolos a CuTeDSL, ajustando las asignaciones de bloques y especializándolos de forma agresiva entre el rellenado previo y la decodificación.

Paralelo de expertos (Expert Parallel)

El núcleo paralelo de expertos (EP) se utiliza en los rellenadores. Dado que sus entradas se replican en todos los rangos, el núcleo de distribución simplemente 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 la GEMM de MoE. 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, y luego realiza una reducción total en todos los rangos.

Para la decodificación, todo el núcleo se fusiona en uno solo. El núcleo de rellenado previo se divide en varios núcleos, ya que el enrutamiento y la reducción total requieren menos bloques que el paso de combinación local. Con CuTeDSL, pudimos crear una biblioteca genérica tanto para la reducción total de SHARP y NVLink como para la sincronización punto a punto, integrándola tanto en los núcleos de reducción total como en los paralelos de expertos.

Ampliar

En cuanto al rendimiento, observamos que Blackwell es sustancialmente más rápido que Hopper, debido a las velocidades de transferencia mejoradas, un mayor ancho de banda de memoria y un mejor rendimiento computacional. Fragmentados en 8 dispositivos y múltiples nodos en los sistemas GB200 (EP=8), los núcleos se vuelven más rápidos, ya que la acumulación local se ejecuta en muchos menos tokens en cada dispositivo y, con SHARP, el costo de la reducción en más rangos se 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 paralelo de expertos (Data Parallel and Expert Parallel)

El núcleo paralelo de datos y paralelo de expertos (DP-EP) se utiliza en los decodificadores paralelos de datos. Transmite diferentes tokens de todos los rangos a los expertos, transfiere los resultados a los rangos de origen y los acumula. Como implementa un problema disperso de todos a todos, se basa únicamente en 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 lo largo de todo un rack. La mayor parte del código se reutiliza. La única diferencia es el uso de controladores (handles) fabric para intercambiar información entre pares a través de 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 su lugar, están limitados por la latencia. Las latencias se encuentran en decenas de microsegundos y se mantienn relativamente estables a medida que aumenta el número de pares, lo que nos permite distribuir una implementación en un mayor número de dispositivos sin incurrir en una latencia adicional significativa.

GEMM de MoE

Los modelos MoE se benefician del paralelismo de expertos, ya que el costo de multiplicar todos los tokens con todos los expertos se puede paralelizar fácilmente en múltiples dispositivos. Con el paralelismo de tensores en los rellenadores, en los 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 además del 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 CUTLASS CUDA/C++ para la multiplicación de matrices. Los sometimos a pruebas comparativas (benchmarks) con entradas de decodificación dispersas con varios esquemas de cuantización y niveles de paralelismo para decidir la estrategia de fragmentación óptima para los decodificadores. En las pruebas comparativas siguientes, todos los expertos se activan con un solo token.

Ampliar

Descubrimos que escalar 128 expertos en más de 16 rangos produce rendimientos decrecientes con CUTLASS, ya que el costo de multiplicar 2 expertos no es sustancialmente menor que el de multiplicar 4. Hay una mejora clara en Blackwell sobre Hopper, incluso en la estrategia de escala de bloques subóptima. Dado que el aumento de latencia de aproximadamente 5 us entre EP=8 y EP=16 de la distribución y combinación se ve compensado por una disminución de más de 10 us en el costo de GEMM, en los sistemas GB200 se justifica fragmentar los decodificadores en 16 rangos, como lo confirman también las pruebas comparativas de extremo a extremo.

Cuantización

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

Hemos implementado Qwen3 235B con el esquema de cuantización MXFP8, convirtiendo los pesos estáticamente después de ajustar finamente (fine-tuning) el modelo. El impacto en la precisión fue similar al del ajuste de escala de bloques con cuantización estocástica, pero el rendimiento ofrecido mejoró enormemente, como lo ilustran las micropruebas comparativas de GEMM de MoE. También hemos considerado los esquemas de cuantización MXFP4 y NVFP4, aunque el impacto en la precisión sin el entrenamiento consciente de la cuantización (Quantization-Aware Training) fue demasiado significativo para la transición inicial de Hopper a Blackwell. Planeamos explorar estos formatos más a fondo en futuros trabajos.

Rendimiento de extremo a extremo

Comparamos mediante pruebas los decodificadores de las implementaciones de Blackwell Qwen3 235B con nuestras implementaciones anteriores de Hopper. En esta configuración, consideramos el escalado de bloques en ambas implementaciones para centrarnos en el impacto del paralelismo. Los rellenadores TP=4 se separaron para ambas arquitecturas con el fin de aislar el rendimiento de decodificación. La siguiente figura ilustra el rendimiento de decodificación suponiendo una tasa realista de aceptación de borradores proporcionada por nuestras capas MTP.

Ampliar

En Hopper, fragmentar la implementación en más de 8 GPU no es viable, ya que las latencias a través de InfiniBand, en particular en los 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 Hopper existentes y potenciando el rendimiento de los núcleos basados en NVLink. Seguiremos reduciendo el costo de servir a Qwen mejorando la cuantización y ajustando finamente el rendimiento de decodificación y el rendimiento de rellenado previo de los demás núcleos de la canalización.

Referencias

Publicación del blog sobre Transfer Engine

Publicación del blog sobre CuTeDSL

Publicación del blog sobre Prefill-Disagg

Publicación del blog sobre 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}
}