Hospedando Qwen no Blackwell

Os racks NVIDIA GB200 NVL72 com GPUs NVIDIA Blackwell interconectadas via NVLink de 72 vias são adequados exclusivamente para a implementação de grandes modelos de mistura de especialistas (MoE). Nesta postagem de blog, descrevemos a configuração de inferência que atende aos modelos Qwen3 235B pós-treinados que suportam uma parcela do tráfego da Perplexity. Mostramos como adaptamos nosso mecanismo de inferência interno para alavancar os núcleos tensores avançados e a interconexão de alta velocidade das GPUs NVIDIA Blackwell. Com esse hardware, lidamos com mais tráfego a um custo menor sem sacrificar a precisão dos modelos subjacentes.

Os racks GB200 NVL72 são compostos por 18 nós com 2 CPUs NVIDIA Grace baseadas em ARM e 4 GPUs baseadas em Blackwell, cada uma equipada com 180 GB de HBM. As 72 GPUs são interconectadas via NVLink e 18 ASICs de comutação NVLink, fornecendo 1800 GB/s de largura de banda entre quaisquer dois pares e compartilhando memória suficiente para hospedar modelos de trilhões de parâmetros. Além disso, os adaptadores ConnectX-7 InfiniBand fornecem 400 Gb/s adicionais de largura de banda tanto dentro dos nós de um rack quanto entre racks vizinhos.

Para lidar com o tráfego, optamos por pós-treinar e servir modelos Qwen. Nesta postagem de blog, focamos no Qwen3 235B, mas muitas das técnicas de atendimento e características de desempenho discutidas são semelhantes às dos modelos mais recentes Qwen3.5 397B e 122B para os quais estamos migrando. Em termos de paralelismo, a atenção linear é semelhante à autoatenção completa e a implementação existente da camada MoE pode ser facilmente adaptada para acomodar os novos termos de porta. Para manter uma taxa de decodificação consistente enquanto maximizamos o rendimento, optamos por desagregar o prefill da decodificação, implementando diferentes estratégias de paralelismo para os dois tipos de nós. A comunicação entre o prefiller e o decodificador é feita via InfiniBand, enquanto a largura de banda NVLink é reservada para a comunicação dentro dos prefillers e decodificadores. As características de desempenho dos dispositivos Blackwell ao realizar multiplicação de matrizes e comunicação entre dispositivos, exploradas nesta postagem, determinam as estratégias de fragmentação usadas. Em comparação com as GPUs NVIDIA Hopper, observamos melhorias núcleo a núcleo devido ao maior número de multiprocessadores de streaming, maior largura de banda de memória e menores latências ponto a ponto.

Pré-preenchimento e decodificação desagregados, com InfiniBand entre os nós de pré-preenchimento e decodificação e NVLink dentro de cada implantação.

Nosso TransferEngine, que implementa prefill desagregado, lidou com fragmentação arbitrária e possivelmente incompatível entre prefillers e decodificadores. Os caches KV são dispostos na memória em ordem HND, com cabeçalhos na dimensão principal e tokens mantidos contíguos, para permitir que um cache KV fragmentado em um prefiller seja ainda mais dividido ou concatenado durante a transferência para o nó do decodificador.

Os nós de prefill recebem os tokens de entrada de uma solicitação, populando caches KV e transferindo-os para os decodificadores para continuar a geração de texto. O prefill é computacionalmente intensivo, pois milhares de tokens pertencentes a uma sequência são processados ao mesmo tempo.

Consequentemente, descobrimos que uma implementação de paralelismo de tensor é adequada, com o modelo fragmentado em 4 GPUs dentro de um único nó GB200 e projeções e especialistas fragmentados (TP=4, EP=4). Como tanto a atenção quanto os MLPs são limitados pela computação, ambos se beneficiam do paralelismo, distribuindo especialistas e cabeçalhos de atenção entre classificações separadas. Um paralelismo adicional teria rendimentos decrescentes, pois a melhoria de rendimento proveniente da hospedagem de menos especialistas em cada classificação (16 em vez de 32) não compensaria o custo adicional de um all-reduce de 8 vias e a sobrecarga de dividir o código do lado do host entre dois nós, exigindo comunicação via Ethernet.

O Qwen3 235B possui apenas 4 cabeçalhos chave-valor, exigindo que as projeções k e v sejam replicadas entre pares de classificações se 8 dispositivos forem usados. Poderíamos ter considerado uma fragmentação mais agressiva para reduzir a quantidade de Espaço de memória necessário para armazenar pesos em cada classificação, liberando Espaço para mais tokens no cache KV. No entanto, descobrimos que uma implementação mais ampla não valia a pena.

Assumindo um comprimento de entrada de cerca de 6000 tokens, cada um dos 128 especialistas tem cerca de 6000 * 8 / 128 = 375 tokens roteados para ele, garantindo um problema denso para o MoE GEMM. Como isso já satura o rendimento computacional do dispositivo, o paralelismo de dados não é necessário para o prefill.

Apesar do custo quadraticamente crescente da atenção, os prefillers entregam um rendimento consistente, permitindo uma estimativa aproximada para o número de tokens de entrada que podem ser processados por um nó em um segundo. Com base em métricas que rastreiam o número total de tokens de entrada das solicitações, o número de nós de prefill pode ser aumentado para garantir que o rendimento geral do prefill seja dimensionado adequadamente. Para evitar filas, o número de réplicas de prefiller é correspondido ao número total de tokens de entrada recebidos.

Os nós do decodificador recebem os caches KV dos prefillers e geram tokens um por um. A decodificação é geralmente limitada pela memória: com poucos tokens de entrada, a multiplicação de matrizes é inteiramente limitada pelo custo de carregar pesos da HBM para os núcleos tensores. Além de empregar uma estratégia de fragmentação diferente, vários núcleos precisam ser ajustados para paralelizar melhor os cálculos e acessos à memória.

Ao contrário do prefill, fragmentar a atenção não é mais benéfico: dividir os cabeçalhos de atenção entre vários dispositivos significaria que há menos oportunidades de paralelismo dentro de um único dispositivo. Consequentemente, apenas o paralelismo de dados e o paralelismo de especialistas são usados: os especialistas são fragmentados entre vários dispositivos, mas cada dispositivo gerencia seus próprios caches KV e solicitações. Sem paralelismo de tensor, o tamanho do cache KV por token em um dispositivo é maior. No entanto, Espaço é liberado na memória ao localizar menos especialistas em um único nó. Ao contrário do Hopper, onde limitamos o paralelismo de tensor dentro de um único domínio NVLink em um nó de 8 GPUs, no Blackwell descobrimos que expandir entre vários nós dentro de um domínio, usando até 16 dispositivos, é benéfico.

Para maximizar o rendimento, os decodificadores processam um número maior de solicitações simultaneamente. Embora solicitações adicionais incorram em uma sobrecarga mínima nas camadas MoE e outras projeções, elas aumentam desproporcionalmente o custo da atenção. Para manter uma velocidade de decodificação mínima razoável, o número de nós decodificadores é dimensionado para manter os tamanhos de lote por decodificador abaixo de um determinado limite.

Semelhante às implantações anteriores do Hopper, usamos decodificação especulativa com camadas MTP treinadas internamente para aumentar as taxas de decodificação. Felizmente, o hardware subjacente e as estruturas de programação são semelhantes o suficiente para compartilhar totalmente a implementação entre as duas arquiteturas.

A principal diferença entre o GB200 NVL72 e os nós Hopper anteriores é o grande domínio NVLink, que permite a comunicação ponto a ponto além do limite anterior de 8 dispositivos. Embora os dispositivos Blackwell tenham sido implantados em nós de 8 GPUs, há muito valor em escalar entre vários nós via NVLink em comparação com a rede InfiniBand mais lenta.

Nos nós de prefill, confiamos na comunicação all-reduce dentro das camadas de atenção e em uma redução paralela de especialistas que se assemelha muito ao all-reduce. Em 4 GPUs, aproveitamos o NVLink e o NVIDIA SHARP (Protocolo de Agregação e Redução Hierárquica Escalável): além da largura de banda ponto a ponto, também exploramos reduções em comutadores NVLink para reduzir ainda mais as latências e implementar transmissões rápidas. Nos nós decodificadores, é usada uma implementação personalizada de dispatch e combine all-to-all sobre NVLink. Os núcleos foram implementados internamente usando CuTeDSL e mapeamentos cuMem ou mapeamentos multicast.

Os prefillers realizam uma operação all-reduce na projeção de saída da camada de atenção, somando as contribuições dos cabeçalhos fragmentados entre as classificações participantes. O paralelismo de tensor só é eficaz quando o custo da sobrecarga do all-reduce é compensado pela latência reduzida dos problemas de multiplicação de matrizes menores. Essa suposição geralmente vale para o prefill.

Em sistemas NVIDIA HGX H200 e GB200 NVL72 de nível de datacenter, as GPUs geralmente são conectadas via comutadores NVLink. Além do roteamento, os comutadores podem realizar operações de redução entre dispositivos conectados via SHARP. Após criar mapeamentos de memória e registrá-los em um grupo multicast usando as APIs CUDA, os núcleos podem usar o multicast.ld_reduce e multicast.st para agregar e transmitir valores através dos comutadores. Para criar uma base e componentes reutilizáveis que possam ser fundidos em outros núcleos, mantemos internamente um núcleo all-reduce CuTeDSL usando essas primitivas.

Em um sistema com N GPUs reduzindo B bytes, uma implementação trivial faria com que um par carregasse valores de todos os outros pares, para um total de N * (N - 1) * B bytes de tráfego de leitura. Uma implementação mais eficiente dividiria os dados a serem reduzidos entre os pares, com cada um reduzindo uma fatia da entrada e, em seguida, transmitindo-a para o restante. Isso resulta em (N - 1) * (B / N) bytes lidos em um par e transmitidos para o restante, para um total de (N - 1) * B * 2 leituras e gravações, reduzindo o tráfego sobre os comutadores.

Tráfego de all-reduce do NVSwitch com acumulação no lado da GPU e redução assistida pelo switch.

Com o SHARP, a redução e a transmissão podem ser realizadas com mais eficiência: em vez de ler (N - 1) * (B / N) bytes em um dispositivo para acúmulo local, apenas B / N são movidos do comutador, pois ele realiza a própria redução usando dados dos pares. Para a transmissão, há uma melhoria semelhante, já que o número de transações entre uma GPU e o comutador sobre canais NVLink é bastante reduzido. Sem o SHARP, o dispositivo acumulador realizaria (N - 1) * (B / N) transações sobre NVLink com o comutador, com o comutador lendo a mesma quantidade de dados dos pares, para um total de 2 * (N - 1) * (B / N) transações. Com o SHARP, B / N transações são realizadas entre a GPU e o comutador, e outras (N - 1) * (B / N) com os pares, para um total de B transações.

Devido à sua simplicidade, o SHARP é uma ferramenta valiosa, pois fornece uma implementação de hardware direta para um algoritmo. Embora as transferências sejam reduzidas por uma fração teórica de N / (2 * (N - 1)) (que equivale a 33% com 4 pares), na prática observamos uma melhoria de 10% nas latências de prefill e decodificação em sistemas H200 e GB200 NVL72.

Latência de dispatch de NVLink e NVLS em H200 e GB200 com TP=4 e 16K tokens.

Para modelos MoE, os núcleos de dispatch e combine movem e agrupam tokens para os problemas subsequentes de MoE GEMM entre pares, realizando um acúmulo ponderado posteriormente no combine. Adaptamos nossos núcleos existentes de Dispatch e Combine para Blackwell, portando-os para CuTeDSL, ajustando as alocações de bloco e especializando-os agressivamente entre prefill e decodificação.

O núcleo de paralelo de especialistas (EP) é usado em prefillers. Como suas entradas são replicadas em todas as classificações, o núcleo de dispatch precisa simplesmente selecionar os tokens roteados para especialistas na classificação atual. Ele agrega informações de roteamento e prepara tokens em buffers usados como entradas para o MoE GEMM. O núcleo de combine primeiro realiza um acúmulo local entre as contribuições de tokens roteados para especialistas na classificação atual, depois realiza um all-reduce em todas as classificações.

Para a decodificação, todo o núcleo é fundido em um. O núcleo de prefill é dividido em vários núcleos, pois o roteamento e o all-reduce exigem menos blocos do que a etapa de combine local. Com o CuTeDSL, pudemos construir uma biblioteca genérica tanto para o SHARP quanto para o all-reduce NVLink e sincronização ponto a ponto, compondo-a em ambos os núcleos, all-reduce e paralelo de especialistas.

Latência de dispatch e combine de pré-preenchimento com paralelismo de especialistas em H200 e GB200 em diferentes configurações de paralelismo de especialistas.

Em termos de desempenho, observamos que o Blackwell é substancialmente mais rápido que o Hopper, devido a velocidades de transferência aprimoradas, maior largura de banda de memória e melhor rendimento computacional. Fragmentados em 8 dispositivos e vários nós em GB200s (EP=8), os núcleos tornam-se mais rápidos à medida que o acúmulo local é executado em muito menos tokens em cada dispositivo e, com o SHARP, o custo de redução entre mais classificações escala melhor. No entanto, na prática, limitamos o paralelismo a 4 dispositivos, pois esses aumentos de velocidade não são universais em todos os núcleos.

O núcleo de paralelo de dados e paralelo de especialistas (DP-EP) é usado nos decodificadores de paralelo de dados. Ele transmite diferentes tokens de todas as classificações para especialistas, transferindo os resultados para as classificações de origem e acumulando-os. Como implementa um problema all-to-all esparso, ele depende exclusivamente do NVLink.

No Hopper, esse núcleo é limitado a 8 dispositivos dentro do domínio NVLink de um único nó. No entanto, em sistemas GB200, podemos escalá-lo em todo um rack. A maior parte do código é reutilizada. A única diferença é o uso de identificadores fabric para trocar informações de pares sobre IMEX para a configuração inicial.

Latência de dispatch e combine do GB200 em diferentes configurações de paralelismo de dados e de especialistas.

Como os tamanhos de transferência incorridos durante a decodificação são pequenos, eles estão longe de saturar a largura de banda NVLink e, em vez disso, são limitados pela latência. As latências estão na casa dos microssegundos e permanecem relativamente estáveis à medida que o número de pares aumenta, permitindo-nos espalhar uma implementação em um número maior de dispositivos sem incorrer em latência adicional significativa.

Os modelos MoE se beneficiam do paralelismo de especialistas, pois o custo de multiplicar todos os tokens com todos os especialistas pode ser facilmente paralelizado entre vários dispositivos. Com o paralelismo de tensor em prefillers, em problemas densos o benefício é bastante direto, pois cada classificação agora precisa realizar menos cálculos. No caso da decodificação, o paralelismo de dados oferece um benefício adicional sobre o paralelismo de especialistas, pois o maior número de solicitações paralelas roteia mais tokens para cada especialista, densificando os problemas.

Em nossa implementação, atualmente confiamos em núcleos CUTLASS CUDA/C++ para multiplicação de matrizes. Nós os comparamos em entradas de decodificação esparsas com vários esquemas de quantização e níveis de paralelismo para decidir a estratégia de fragmentação ideal para decodificadores. Nos benchmarks abaixo, todos os especialistas são ativados com um único token.

Latência de GEMM do MoE agrupado em diferentes configurações de paralelismo de especialistas e esquemas de quantização em H200 e GB200.

Descobrimos que escalar 128 especialistas em mais de 16 classificações gera rendimentos decrescentes com o CUTLASS, pois o custo de multiplicar 2 especialistas não é substancialmente menor do que multiplicar 4. Há uma melhoria clara no Blackwell sobre o Hopper, mesmo na estratégia de escala de bloco subótima. Como o aumento de latência de cerca de 5 us entre EP=8 e EP=16 de dispatch/combine é superado por uma diminuição de mais de 10 us no custo de GEMM, em sistemas GB200, a fragmentação de decodificadores em 16 classificações é justificada, conforme confirmado por benchmarks de ponta a ponta também.

O Blackwell introduz suporte de hardware para novos esquemas de quantização de 8 e 4 bits. Ao contrário do Hopper, que dependia de fatores de escala por tensor ou por bloco, o Blackwell requer microescala para atingir o melhor rendimento de prefill e decodificação. Embora o esquema de escala de bloco usado para modelos como DeepSeek ou Kimi esteja disponível, a microescala é mais eficiente.

Implementamos o Qwen3 235B com o esquema de quantização MXFP8, convertendo os pesos estaticamente após o ajuste fino do modelo. O impacto na precisão foi semelhante ao impacto da escala de bloco com quantização estocástica, mas o desempenho entregue foi muito melhor, conforme ilustrado pelos microbenchmarks do MoE GEMM. Também consideramos os esquemas de quantização MXFP4 e NVFP4, embora o impacto na precisão sem o Treinamento com Consciência de Quantização tenha sido muito significativo para a transição inicial do Hopper para o Blackwell. Planejamos explorar esses formatos mais detalhadamente em trabalhos futuros.

Comparamos os decodificadores das implantações Blackwell Qwen3 235B e os comparamos com nossas implantações Hopper anteriores. Nesta configuração, consideramos a escala de bloco em ambas as implantações para focar no impacto do paralelismo. Prefillers TP=4 foram separados para ambas as arquiteturas para isolar o desempenho de decodificação. A figura abaixo ilustra o rendimento de decodificação assumindo uma taxa de aceitação de rascunho realista entregue por nossas camadas MTP.

Velocidade de decodificação e throughput por GPU do Qwen3 235B FP8 em diferentes configurações de paralelismo de especialistas em H200 e GB200, assumindo comprimento de aceitação do draft de 0,8.

No Hopper, fragmentar a implementação em mais de 8 GPUs não é viável, pois as latências sobre o InfiniBand, particularmente em adaptadores EFA, são substancialmente mais lentas. No entanto, no Blackwell, alcançamos um rendimento substancialmente maior, graças aos domínios NVLink maiores.

Alcançamos uma implementação inicial de Blackwell generalizando os núcleos Hopper existentes e aumentando o desempenho dos núcleos baseados em NVLink. Reduziremos ainda mais o custo de servir o Qwen aprimorando a quantização e ajustando o desempenho da decodificação e o rendimento de prefill dos outros núcleos no pipeline.

Postagem de blog do Mecanismo de Transferência

Postagem de blog CuTeDSL

Postagem de blog sobre Prefill-Disagg

Postagem de blog sobre Decodificação 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}
}

Implementando no GB200 NVL72

Prefillers

Decodificadores

Comunicação Intra-nó e Inter-nó

All-Reduce

MoE Dispatch - Combine

Paralelo de Especialistas

Paralelo de Dados e Paralelo de Especialistas

MoE GEMM

Quantização

Desempenho de ponta a ponta

Referências

Citação