Hospedando Qwen no Blackwell

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

Implantação no GB200 NVL72

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, entregando 1800 GB/s de largura de banda entre quaisquer dois pares e compartilhando memória suficiente para hospedar modelos de um trilhão de parâmetros. Além disso, os adaptadores ConnectX-7 InfiniBand fornecem outros 400 Gb/s de largura de banda, tanto dentro dos nós de um rack quanto entre racks vizinhos.

Para gerenciar 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 novos 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 atual da camada MoE pode ser facilmente adaptada para acomodar os novos termos de porta. Para manter uma taxa de decodificação consistente enquanto maximizamos a vazão, escolhemos desagregar o preenchimento (prefill) da decodificação (decode), implantando diferentes estratégias de paralelismo para os dois tipos de nós. A comunicação entre o preenchedor e o decodificador é feita via InfiniBand, enquanto a largura de banda do NVLink é reservada para a comunicação dentro dos preenchedores e decodificadores. As características de desempenho dos dispositivos Blackwell ao realizar multiplicação de matrizes e comunicação entre dispositivos, exploradas nesta postagem de blog, determinem as estratégias de fragmentação usadas. Comparado às GPUs NVIDIA Hopper, vemos melhorias de kernel por kernel devido ao maior número de multiprocessadores de streaming, maior largura de banda de memória e menores latências ponto a ponto.

Expandir

Nosso TransferEngine, que implementa o preenchimento desagregado, lidou com fragmentação arbitrária e possivelmente incompatível entre preenchedores e decodificadores. Os caches KV são dispostos na memória em ordem HND, com as cabeças na dimensão principal e os tokens mantidos contíguos, para permitir que um cache KV fragmentado em um preenchedor seja dividido ou concatenado em tempo de execução durante a transferência para o nó decodificador.

Preenchedores

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

Consequentemente, descobrimos que uma implantação paralela de tensores é 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 por computação, ambos se beneficiam do paralelismo, distribuindo especialistas e cabeças de atenção em classificações separadas. Mais paralelismo teria gerado retornos decrescentes, pois a melhoria na vazão decorrente de hospedar 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 em dois nós, exigindo comunicação via Ethernet.

O Qwen3 235B tem apenas 4 cabeças de chave-valor, exigindo que as projeções k e v sejam replicadas entre pares de ranks se forem usados 8 dispositivos. Poderíamos ter considerado um sharding mais agressivo para reduzir a quantidade de memória necessária para armazenar pesos em cada rank, liberando espaço para mais tokens no cache KV. No entanto, constatamos que uma implantaçã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 a vazão computacional do dispositivo, o paralelismo de dados não é necessário para o preenchimento.

Apesar do custo de atenção que aumenta quadraticamente, os preenchedores entregam uma vazão consistente, permitindo uma estimativa aproximada do número de tokens de entrada que podem ser processados por um nó em um segundo. Contando com métricas que rastreiam o número total de tokens de entrada das solicitações, o número de nós preenchedores pode ser escalado para cima para garantir que a vazão geral de preenchimento seja dimensionada adequadamente. Para evitar filas, o número de réplicas de preenchedores é compatível com o número total de tokens de entrada recebidos.

Decodificadores

Os nós decodificadores recebem os caches KV dos preenchedores e geram tokens um a 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 de HBM para Tensor Cores. Além de empregar uma estratégia de fragmentação diferente, vários kernels precisam ser ajustados para paralelizar melhor as computações e os acessos à memória.

Ao contrário do prefill, o sharding da atenção já não é benéfico: dividir as heads de atenção entre vários dispositivos significaria haver menos oportunidades de paralelismo dentro de um único dispositivo. Consequentemente, apenas o paralelismo de dados e o paralelismo de experts são usados: os experts são shardados entre vários dispositivos, mas cada dispositivo gerencia seus próprios caches KV e requisiçõ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 colocar menos experts em um único nó. Ao contrário de Hopper, em que limitamos o paralelismo de tensor dentro de um único domínio NVLink em um nó de 8 GPUs, no Blackwell constatamos que expandir entre vários nós dentro de um domínio, usando até 16 dispositivos, é benéfico.

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

Da mesma forma que nas implantações anteriores do Hopper, usamos decodificação especulativa com camadas MTP treinadas internamente para impulsionar 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.

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

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 em vários nós via NVLink em comparação com a rede InfiniBand mais lenta.

Nos nós preenchedores, contamos com a comunicação all-reduce dentro das camadas de atenção e com uma redução paralela de especialistas que se assemelha muito ao all-reduce. Em 4 GPUs, aproveitamos tanto o NVLink quanto o NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): além da largura de banda ponto a ponto, também exploramos reduções em switches NVLink para reduzir ainda mais as latências e implementar transmissões rápidas. Nos nós decodificadores, é usada uma implementação personalizada de despacho e combinação all-reduce sobre o NVLink. Os kernels foram implementados internamente usando mapeamentos CuTeDSL e cuMem ou mapeamentos multicast.

All-Reduce

Os preenchedores realizam uma operação all-reduce na projeção de saída da camada de atenção, somando as contribuições das cabeças fragmentadas nas classificações participantes. O paralelismo de tensores só é eficaz quando o custo da sobrecarga do all-reduce é compensado pela latência reduzida dos problemas menores de multiplicação de matrizes. Esta suposição geralmente se sustenta para o preenchimento.

Em sistemas NVIDIA HGX H200 e GB200 NVL72 de nível de data center, as GPUs são normalmente conectadas por meio de switches NVLink. Além do roteamento, os switches podem realizar operações de redução em dispositivos conectados via SHARP. Após criar mapeamentos de memória e registrá-los em um grupo multicast usando as APIs CUDA, os kernels podem usar multicast.ld_reduce e multicast.st para agregar e transmitir valores pelos switches. Para criar uma base e componentes reutilizáveis que possam ser fundidos em outros kernels, mantemos internamente um kernel 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, transmitindo-a em seguida 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 nos switches.

Expandir

Com o SHARP, a redução e a transmissão podem ser executadas de forma mais eficiente: em vez de ler (N - 1) * (B / N) bytes em um dispositivo para acumulação local, apenas B / N são movidos do switch, pois ele próprio realiza a redução usando dados dos pares. Para a transmissão, há uma melhoria semelhante, pois o número de transações entre uma GPU e o switch pelos canais NVLink é bastante reduzido. Sem o SHARP, o dispositivo acumulador realizaria (N - 1) * (B / N) transações via NVLink com o switch, com o switch 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 executadas entre a GPU e o switch, 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)) (o que resulta em 33% com 4 pares), na prática observamos uma melhoria de 10% nas latências de preenchimento e decodificação em sistemas H200 e GB200 NVL72.

Expandir

Despacho e Combinação MoE (MoE Dispatch - Combine)

Para modelos MoE, os kernels de despacho e combinação movem e agrupam tokens para os problemas subsequentes de MoE GEMM entre pares, realizando uma acumulação ponderada posteriormente na combinação. Adaptamos nossos kernels de Despacho e Combinação existentes para o Blackwell, portando-os para o CuTeDSL, ajustando as alocações de blocos e especializando-os agressivamente entre preenchimento e decodificação.

Paralelo de Especialistas

O kernel paralelo de especialistas (EP) é usado em preenchedores. Como suas entradas são replicadas em todas as classificações, o kernel de despacho 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 kernel de combinação primeiro realiza uma acumulação local entre as contribuições dos tokens roteados para especialistas na classificação atual e, em seguida, realiza um all-reduce em todas as classificações.

Para a decodificação, todo o kernel é fundido em um só. O kernel de preenchimento é dividido em vários kernels, pois o roteamento e o all-reduce exigem menos blocos do que a etapa de combinação local. Com o CuTeDSL, pudemos construir uma biblioteca genérica para all-reduce do SHARP e do NVLink e sincronização ponto a ponto, compondo-a tanto no all-reduce quanto nos kernels paralelos de especialistas.

Expandir

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 vazão computacional. Fragmentados em 8 dispositivos e múltiplos nós em GB200s (EP=8), os kernels tornam-se mais rápidos à medida que a acumulação local é executada em muito menos tokens em cada dispositivo e, com o SHARP, o custo da redução em mais classificações escala melhor. No entanto, na prática, limitamos o paralelismo a 4 dispositivos, pois essas acelerações não são universais em todos os kernels.

Paralelo de Dados e Paralelo de Especialistas

O kernel paralelo de dados e paralelo de especialistas (DP-EP) é usado nos decodificadores paralelos 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 ele implementa um problema esparso de all-to-all, ele depende exclusivamente do NVLink.

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

Expandir

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

MoE GEMM

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 em vários dispositivos. Com o paralelismo de tensores em preenchedores, em problemas densos o benefício é bastante direto, pois cada classificação agora precisa realizar menos computações. No caso da decodificação, o paralelismo de dados fornece um benefício adicional além do 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 contamos com kernels CUTLASS CUDA/C++ para multiplicação de matrizes. Nós os avaliamos 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 os decodificadores. Nos benchmarks abaixo, todos os especialistas são ativados com um único token.

Expandir

Descobrimos que escalar 128 especialistas em mais de 16 classificações produz retornos 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 em relação ao Hopper, mesmo na estratégia subótima de dimensionamento de blocos. Como o aumento de latência de cerca de 5 us entre EP=8 e EP=16 de despacho/combinação é superado por uma diminuição de mais de 10 us no custo de GEMM, em sistemas GB200, fragmentar decodificadores em 16 classificações é justificado, conforme confirmado por benchmarks de ponta a ponta também.

Quantização

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

Implantamos 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 do dimensionamento de blocos 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 ciente da quantização (Quantization-Aware Training) tenha sido muito significativo para a transição inicial do Hopper para o Blackwell. Planejamos explorar esses formatos mais detalhadamente em trabalhos futuros.

Desempenho de Ponta a Ponta

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

Expandir

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

Alcançamos uma implementação inicial do Blackwell generalizando os kernels existentes do Hopper e impulsionando o desempenho dos kernels baseados em NVLink. Reduziremos ainda mais o custo de atendimento do Qwen melhorando a quantização e ajustando finamente o desempenho de decodificação e a vazão de preenchimento dos outros kernels no pipeline.

Referências

Postagem de blog do Transfer Engine

Postagem de blog do CuTeDSL

Postagem de blog sobre preenchimento desagregado

Postagem de blog de decodificação especulativa

CUTLASS

NVLink

Citação

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