Albergar Qwen en Blackwell

Os racks NVIDIA GB200 NVL72 con GPU NVIDIA Blackwell interconectadas mediante NVLink de 72 vías son idóneos para implementar grandes modelos de mestura de expertos (MoE). Nesta entrada do blog, describimos a configuración de inferencia que serve modelos Qwen3 235B post-adestrados que admiten unha parte do tráfico de Perplexity. Mostramos como adaptamos o noso motor de inferencia interno para aproveitar os núcleos tensoriais avanzados e a interconexión de alta velocidade das GPU NVIDIA Blackwell. Con este hardware, xestionamos máis tráfico a un custo inferior sen sacrificar a precisión dos modelos subxacentes.

Os racks GB200 NVL72 están composto por 18 nós con 2 CPU NVIDIA Grace basadas en ARM e 4 GPU basadas en Blackwell, cada unha equipada con 180 GB de HBM. As 72 GPU están interconectadas mediante NVLink e 18 ASIC de conmutación NVLink, o que ofrece un ancho de banda de 1800 GB/s entre calquera par de dispositivos e comparte memoria suficiente para albergar modelos dun billón de parámetros. Ademais, os adaptadores ConnectX-7 InfiniBand ofrecen un ancho de banda adicional de 400 Gb/s tanto dentro dos nós dun rack como entre os racks veciños.

Para xestionar o tráfico, optamos por post-adestrar e servir modelos Qwen. Nesta entrada do blog, centramosnos en Qwen3 235B, mais moitas das técnicas de servizo e características de rendemento tratadas son similares ás dos modelos máis novos Qwen3.5 397B e 122B aos que estamos a migrar. En canto ao paralelismo, a atención lineal é similar á autoatención completa e a implementación existente da capa MoE pódese adaptar facilmente para acomodar os novos termos de porta. Para manter unha taxa de descodificación consistente á vez que se maximiza o rendemento, escollimos desagregar o preenchimento da descodificación, implementando diferentes estratexias de paralelismo para os dous tipos de nós. A comunicación entre o preenchemento e a descodificación xestiónase a través de InfiniBand, mentres que o ancho de banda de NVLink resérvase para a comunicación dentro dos preenchementos e os descodificadores. As características de rendemento dos dispositivos Blackwell ao realizar a multiplicación de matrices e a comunicación entre dispositivos, exploradas nesta entrada do blog, determinan as estratexias de fragmentación utilizadas. En comparación coas GPU NVIDIA Hopper, observamos melloras núcleo por núcleo debido ao maior número de multiprocesadores de fluxo, o maior ancho de banda de memoria e as menores latencias entre pares.

Desprazamento separado de prefill e decode, con InfiniBand entre os nodos de prefill e de decodificación e NVLink dentro de cada despregamento.

O noso TransferEngine, que implementa o preenchimento desagregado, xestionou a fragmentación arbitraria e potencialmente non coincidente entre os preenchementos e os descodificadores. As cachés KV dispóñense na memoria en orde HND, coas cabezas na dimensión principal e os tokens mantidos contiguos, para permitir que unha caché KV fragmentada nun preenchemento se divida aínda máis ou se concierte en tempo de execución durante a transferencia ao nodo descodificador.

Os nós de preenchimento reciben os tokens de entrada dunha solicitude, énchenas cachés KV e transfírenas aos descodificadores para continuar coa xeración de texto. O preenchimento require un uso intensivo de recursos informáticos, xa que miles de tokens pertencentes a unha secuencia procésanse ao mesmo tempo.

En consecuencia, descubrimos que é axeitada unha implementación paralela de tensores, co modelo fragmentado en 4 GPU dentro dun único nodo GB200 e as proxeccións e expertos fragmentados (TP=4, EP=4). Dado que tanto a atención como os MLP están limitados pola computación, ambos se benefician do paralelismo, distribuíndo expertos e cabezas de atención en rangos separados. Un maior paralelismo produciría rendementos decrecentes, xa que a mellora do rendemento por albergar menos expertos en cada rango (16 fronte a 32) non compensaría o custo adicional dunha reducción total (all-reduce) de 8 vías e a sobrecarga de dividir o código do lado do host en dous nós, o que require comunicación a través de Ethernet.

Qwen3 235B ten só 4 cabezas de clave-valor, o que require que as proxeccións k e v se repliquen en pares de rangos se se utilizan 8 dispositivos. Poderiamos considerar unha fragmentación máis agresiva para reducir a cantidade de espazo de memoria necesario para almacenar os pesos en cada rango, liberando espazo para máis tokens na caché KV. Non obstante, descubrimos que unha implementación máis ampla non valía a pena.

Asumindo unha lonxitude de entrada de arredor de 6000 tokens, cada un dos 128 expertos ten arredor de 6000 * 8 / 128 = 375 tokens dirixidos a el, o que garante un problema denso para o GEMM de MoE. Dado que isto xa satura o rendemento computacional do dispositivo, non é necesario o paralelismo de datos para o preenchimento.

A pesar do custo crecente cuadrático da atención, os preenchementos ofrecen un rendemento consistente, o que permite unha estimación aproximada do número de tokens de entrada que un nodo pode procesar nun segundo. Baseándose en métricas que fan un seguimento do número total de tokens de entrada das solicitudes, os nós de preenchimento pódense escalar para garantir que o rendemento xeral de preenchimento teña o tamaño axeitado. Para evitar a formación de colas, o número de réplicas de preenchimento coincide co número total de tokens de entrada recibidos.

Os nós descodificadores reciben as cachés KV dos preenchementos e xeran tokens un a un. A descodificación está xeralmente limitada pola memoria: con poucos tokens de entrada, a multiplicación de matrices está enteiramente limitada polo custo de cargar os pesos desde a HBM aos núcleos tensoriais. Ademais de empregar unha estratexia de fragmentación diferente, hai que modificar varios núcleos para paralelizar mellor as operacións informáticas e os accesos á memoria.

A diferenza do preenchimento, fragmentar a atención xa non é beneficioso: dividir as cabezas de atención en varios dispositivos significaría que hai menos oportunidades de paralelismo dentro dun único dispositivo. En consecuencia, só se utilizan o paralelismo de datos e o paralelismo de expertos: os expertos frágmentanse en varios dispositivos, mais cada dispositivo xestiona as súas propias cachés KV e solicitudes. Sen paralelismo de tensores, o tamaño da caché KV por token nun dispositivo é maior. Non obstante, libérase espazo na memoria situando menos expertos nun único nodo. A diferenza de Hopper, onde limitamos o paralelismo de tensores dentro dun único dominio NVLink nun nodo de 8 GPU, en Blackwell descubrimos que é beneficioso expandirse a través de múltiples nós nun dominio, utilizando ata 16 dispositivos.

Para maximizar o rendemento, os descodificadores procesan un maior número de solicitudes simultaneamente. Aínda que as solicitudes adicionais xeran unha sobrecarga mínima nas capas MoE e outras proxeccións, aumentan desproporcionadamente o custo da atención. Para manter unha velocidade mínima de descodificación razoable, o número de nós descodificadores escala para manter os tamaños de lote por descodificador por debaixo dun determinado limiar.

Do mesmo xeito que nas implementacións anteriores de Hopper, utilizamos a descodificación especulativa con capas MTP adestradas internamente para aumentar as taxas de descodificación. Afortunadamente, o hardware subxacente e os marcos de programación son o suficientemente similares como para compartir totalmente a implementación entre as dúas arquitecturas.

A principal diferenza entre GB200 NVL72 e os nós Hopper anteriores é o gran dominio NVLink, que permite a comunicación entre pares máis aló do límite anterior de 8 dispositivos. Aínda que os dispositivos Blackwell implementáronse en nós de 8 GPU, ten moito valor escalar a través de múltiples nós a través de NVLink en comparación coa rede InfiniBand, que é máis lenta.

Nos nós de preenchimento, dependemos da comunicación de reducción total (all-reduce) dentro das capas de atención e dunha reducción paralela de expertos que se asemella moito á reducción total. A través de 4 GPU, aproveitamos tanto NVLink como NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): ademais do ancho de banda entre pares, tamén explotamos as reduccións nos conmutadores NVLink para reducir aínda máis as latencias e implementar difusións rápidas. Nos nós descodificadores, utilízase unha implementación personalizada de distribución e combinación de todos a todos (all-to-all dispatch and combine) a través de NVLink. Os núcleos implementáronse internamente usando CuTeDSL e mapeos cuMem ou mapeos de multidifusión (multicast).

Os preenchementos realizan unha operación de reducción total na proxección de saída da capa de atención, sumando as contribucións das cabezas fragmentadas nos rangos participantes. O paralelismo de tensores só é efectivo cando o custo da sobrecarga de reducción total se compensa coa menor latencia dos problemas de multiplicación de matrices máis pequenos. Esta suposición adoita cumplirse para o preenchimento.

Nos sistemas NVIDIA HGX H200 e GB200 NVL72 para centros de datos, as GPU adoitan conectarse mediante conmutadores NVLink. Ademais do encamiñamento, os conmutadores poden realizar operacións de reducción entre dispositivos conectados a través de SHARP. Despois de crear os mapeos de memoria e rexistralos nun grupo de multidifusión mediante as API de CUDA, os núcleos poden usar multicast.ld_reduce e multicast.st para agregar e difundir valores a través dos conmutadores. Para crear unha base e compoñentes reutilizables que se poidan fusionar noutros núcleos, mantemos internamente un núcleo de reducción total CuTeDSL utilizando estas primitivas.

Nun sistema con N GPUs reducindo B bytes, unha implementación trivial faría que un par cargase valores de todos os outros pares, para un total de N * (N - 1) * B bytes de tráfico de lectura. Unha implementación máis eficiente dividiría os datos que se van reducir entre os pares, de xeito que cada un reduza un anaco da entrada e logo o retransmita ao resto. Isto dá como resultado (N - 1) * (B / N) bytes lidos nun par e retransmitidos ao resto, para un total de (N - 1) * B * 2 lecturas e escrituras, reducindo o tráfico a través dos conmutadores.

Tráfico all-reduce de NVSwitch con acumulación no lado da GPU e redución asistida por switch.

Con SHARP, a reducción e a difusión pódense realizar de forma máis eficiente: en lugar de ler (N - 1) * (B / N) bytes nun dispositivo para a acumulación local, só se moven B / N desde o conmutador, xa que este realiza a reducción por si mesmo utilizando datos dos pares. Para a difusión, hai unha mellora similar, xa que o número de transaccións entre unha GPU e o conmutador a través das canles NVLink redúcese considerablemente. Sen SHARP, o dispositivo acumulador realizaría (N - 1) * (B / N) transaccións a través de NVLink co conmutador, co conmutador lendo a mesma cantidade de datos dos pares, para un total de 2 * (N - 1) * (B / N) transaccións. Con SHARP, realízanse B / N transaccións entre a GPU e o conmutador, e outras (N - 1) * (B / N) cos pares, para un total de B transaccións.

Debido á súa sinxeleza, SHARP é unha ferramenta valiosa, xa que ofrece unha implementación de hardware directa para un algoritmo. Aínda que as transferencias se reducen nunha fracción teórica de N / (2 * (N - 1)) (o que equivale ao 33% con 4 pares), na práctica observamos unha mellora do 10% tanto nas latencias de preenchimento como de descodificación nos sistemas H200 e GB200 NVL72.

Latencia de despacho de NVLink e NVLS en H200 e GB200 con TP=4 e 16K tokens.

Para os modelos MoE, os núcleos de distribución (dispatch) e combinación (combine) moven e agrupan tokens para os problemas posteriores de GEMM de MoE entre pares, realizando despois unha acumulación ponderada na combinación. Adaptamos os nosos núcleos de distribución e combinación existentes a Blackwell, portándoos a CuTeDSL, axustando a asignación de bloques e especializándoos de forma agresiva entre o preenchimento e a descodificación.

O núcleo paralelo de expertos (EP) utilízase nos preenchementos. Dado que as súas entradas están replicadas en todos os rangos, o núcleo de distribución só precisa seleccionar os tokens dirixidos aos expertos no rango actual. Agrega a información de encamiñamento e prepara os tokens en búferes utilizados como entradas para o GEMM de MoE. O núcleo de combinación realiza primeiro unha acumulación local entre as contribucións dos tokens dirixidos aos expertos no rango actual e, a continuación, realiza unha reducción total en todos os rangos.

Para a descodificación, todo o núcleo fúndese nun só. O núcleo de preenchimento divídese en varios núcleos, xa que o encamiñamento e a reducción total requiren menos bloques que o paso de combinación local. Con CuTeDSL, puidemos construír unha biblioteca xenérica tanto para SHARP como para a reducción total de NVLink e a sincronización entre pares, integrándoa tanto nos núcleos de reducción total como nos paralelos de expertos.

Latencia de despacho e combinación de prefill en paralelismo por expertos en H200 e GB200 en distintas configuracións de paralelismo por expertos.

En canto ao rendemento, observamos que Blackwell é substancialmente máis rápido que Hopper, grazas a unhas velocidades de transferencia melloradas, un maior ancho de banda de memoria e un mellor rendemento computacional. Fragmentados en 8 dispositivos e múltiples nós en GB200 (EP=8), os núcleos vólvense máis rápidos xa que a acumulación local se executa nun número moito menor de tokens en cada dispositivo e, con SHARP, o custo da reducción en máis rangos escala mellor. Non obstante, na práctica, limitamos o paralelismo a 4 dispositivos, xa que estas aceleracións non son universais en todos os núcleos.

O núcleo paralelo de datos e paralelo de expertos (DP-EP) utilízase nos descodificadores paralelos de datos. Difunde diferentes tokens de todos os rangos aos expertos, transferindo os resultados aos rangos de orixe e acumulándoos. Dado que implementa un problema disperso de todos a todos (sparse all-to-all), depende exclusivamente de NVLink.

En Hopper, este núcleo está limitado a 8 dispositivos dentro do dominio NVLink dun único nodo. Non obstante, nos sistemas GB200 podemos escalaro a través dun rack enteiro. A maior parte do código reutilízase. A única diferenza é o uso de identificadores (handles) fabric para intercambiar información entre pares a través de IMEX para a configuración inicial.

Latencia de despacho e combinación en GB200 en distintas configuracións de paralelismo de datos e paralelismo por expertos.

Dado que os tamaños de transferencia xerados durante a descodificación son pequenos, están lonxe de saturar o ancho de banda de NVLink e están limitados pola latencia. As latencias están nas dezenas de microsegundos e permanecen relativamente estables a medida que aumenta o número de pares, o que nos permite estender unha implementación a un maior número de dispositivos sen incorrer nunha latencia adicional significativa.

Os modelos MoE beneficianse do paralelismo de expertos, xa que o custo de multiplicar todos os tokens con todos os expertos se pode paralelizar facilmente en múltiples dispositivos. Co paralelismo de tensores nos preenchementos, nos problemas densos o beneficio é bastante directo, xa que cada rango agora ten que realizar menos operacións computacionais. No caso da descodificación, o paralelismo de datos ofrece un beneficio adicional ademais do paralelismo de expertos, xa que o maior número de solicitudes paralelas encamiña máis tokens a cada experto, densificando os problemas.

Na nossa implementación, actualmente dependemos dos núcleos CUTLASS CUDA/C++ para a multiplicación de matrices. Comparamos o seu rendemento en entradas de descodificación dispersas con varios esquemas de cuantización e niveis de paralelismo para decidir a estratexia de fragmentación óptima para os descodificadores. Nos benchmarks seguintes, todos os expertos actívanse cun único token.

Latencia de GEMM de MoE agrupado en distintas configuracións de paralelismo por expertos e esquemas de cuantización en H200 e GB200.

Descubrimos que escalar 128 expertos en máis de 16 rangos produce rendementos decrecentes con CUTLASS, xa que o custo de multiplicar 2 expertos non é substancialmente menor que o de multiplicar 4. Hai unha clara mellora en Blackwell sobre Hopper, mesmo na estratexia de escala de bloques subóptima. Dado que o aumento de latencia duns 5 us entre EP=8 e EP=16 de distribución/combinación é compensado por unha diminución de máis de 10 us no custo de GEMM, nos sistemas GB200 está xustificada a fragmentación dos descodificadores en 16 rangos, tal e como confirman tamén os benchmarks de extremo a extremo.

Blackwell introduce soporte de hardware para novos esquemas de cuantización de 8 e 4 bits. A diferenza de Hopper, que dependía de factores de escala por tensor ou por bloque, Blackwell require microescala para acadar o mellor rendemento de preenchimento e descodificación. Aínda que o esquema de escala de bloques utilizado para modelos como DeepSeek ou Kimi está dispoñible, a microescala é máis eficiente.

Implementamos Qwen3 235B co esquema de cuantización MXFP8, convertendo os pesos estaticamente despois de axustar finamente o modelo. O impacto na precisión foi similar ao impacto da escala de bloques con cuantización estocástica, mais o rendemento ofrecido foi moito mellor, tal e como ilustran os microbenchmarks de GEMM de MoE. tamén consideramos os esquemas de cuantización MXFP4 e NVFP4, aínda que o impacto na precisión sen adestramento consciente da cuantización (Quantization-Aware Training) foi demasiado significativo para a transición inicial de Hopper a Blackwell. Planeamos explorar estes formatos máis a fondo en traballos futuros.

Comparamos os descodificadores das implementacións de Blackwell Qwen3 235B e comparámolas coas nosas implementacións anteriores de Hopper. Nesta configuración, consideramos a escala de bloques en ambas as implementacións para centrarnos no impacto do paralelismo. Os preenchementos TP=4 separáronse para ambas as arquitecturas co fin de illar o rendemento de descodificación. A figura seguinte ilustra o rendemento de descodificación asumindo unha taxa de aceptación de borradores realista ofrecida polas nosas capas MTP.

Velocidade de decodificación e rendemento por GPU de Qwen3 235B FP8 en distintas configuracións de paralelismo por expertos en H200 e GB200, asumindo unha lonxitude de aceptación de borrador de 0.8.

En Hopper, fragmentar a implementación en máis de 8 GPU non é viable, xa que as latencias a través de InfiniBand, particularmente nos adaptadores EFA, son substancialmente máis lentas. Non obstante, en Blackwell, acadamos un rendemento substancialmente maior, grazas aos maiores dominios NVLink.

Acadamos unha implementación inicial en Blackwell xeneralizando os núcleos existentes de Hopper e impulsando o rendemento dos núcleos baseados en NVLink. Seguiremos reducindo o custo de servir Qwen mellorando a cuantización e axustando finamente o rendemento de descodificación e o rendemento de preenchimento dos outros núcleos da canalización (pipeline).

Entrada do blog de Transfer Engine

Entrada do blog de CuTeDSL

Entrada do blog de Prefill-Disagg

Entrada do blog de descodificación especulativa

CUTLASS

NVLink

BibTeX

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

Implementación en GB200 NVL72

Preenchementos

Descodificadores

Comunicación intra-nodo e inter-nodo

Reducción total (All-Reduce)

Distribución - Combinación de MoE (MoE Dispatch - Combine)

Paralelo de expertos

Paralelo de datos e paralelo de expertos

GEMM de MoE

Cuantización

Rendemento de extremo a extremo

Referencias

Cita