NVIDIA, CUDA, Hopper e Blackwell

01 · Conceito

Conceito

Uma pergunta de compra chega com prazo: a empresa vai servir o Qwen3.8-27B, e a escolha é entre alugar aceleradores de geração Hopper com 80 GB ou pagar substancialmente mais por peças de geração Blackwell da classe 192 GB. O material do fabricante compara os dois por throughput aritmético, que a lição 9.1 estabeleceu ser a moeda que o decode de fluxo único não gasta. A decisão gira, em vez disso, em torno de duas linhas da lição 9.3, capacidade e bandwidth, e esta lição desenvolve as duas.

Primeiro, o formato da máquina, porque o vocabulário reaparece em todo relatório de profiling. Uma GPU programável em CUDA é uma malha de streaming multiprocessors, cada um um escalonador sobre muitas vias aritméticas mais um bloco de memória compartilhada gerenciada por software e um banco de registradores. Uma peça H100 SXM carrega da ordem de 130 deles, um número de fabricante em agosto de 2026 que varia por SKU e por binning. Dentro de cada SM ficam os tensor cores, unidades de função fixa que consomem pequenos tiles de matriz e emitem produtos acumulados, e essencialmente toda a aritmética de um transformer cai ali. Em torno dos SMs fica a hierarquia de memória contra a qual o roofline da lição 9.2 é desenhado: registradores, memória compartilhada e L1, uma L2 compartilhada, e então a memória de alta banda empilhada ao lado do die. A Hopper acrescentou uma quarta geração de tensor cores com um caminho de FP8 e lógica de escala por tensor, e a Blackwell acrescentou uma quinta geração estendendo isso ao FP4. Os construtores de engine da lição 8.6 existem em grande parte para escolher qual desses caminhos cada camada toma.

Agora a aritmética que decide a compra. Pegue primeiro a peça Hopper, reaproveitando o orçamento da lição 9.3 sem rederivá-lo. Uma peça de 80 GB reporta aproximadamente 79,6 GiB utilizáveis; os pesos em bf16 do Qwen3.8-27B são cerca de 54 GB, que são 50,3 GiB; uma reserva de runtime perto de 6 GiB cobre contexto, ativações e fragmentação. O pool fica em cerca de 23,3 GiB, o que, a 656 MiB por sequência de 8.192 tokens, cache mais o estado constante do DeltaNet, sustenta cerca de 36 conversas concorrentes e comporta exatamente uma sequência no contexto nativo completo de 262.144 tokens. É um encaixe apertado, e é por isso que implantações nessa peça recorrem a pesos em FP8 ou dividem o modelo entre duas placas, o que arrasta consigo os custos de interconnect da lição 9.9.

Agora a peça classe Blackwell, com 192 GB de HBM3e informados pelo fabricante. A capacidade utilizável é de cerca de 178,8 GiB. Os pesos custam os mesmos 50,3 GiB, porque pesos são um encargo fixo que não escala com a placa, e uma reserva ligeiramente maior, de 8 GiB, deixa

para o pool. A 656 MiB por sequência de 8.192 tokens isso são cerca de 188 conversas concorrentes, e a 16.528 MiB por sequência em contexto nativo completo são cerca de sete. A concorrência subiu aproximadamente cinco vezes a partir de um aumento de capacidade de cerca de 2,4 vezes, e a alavancagem vem inteiramente de o encargo fixo dos pesos ser pago uma única vez em qualquer das placas. Cada gibibyte adicional na peça maior vai para usuários. Essa não linearidade é o fato mais importante na seleção de acelerador para um modelo desse porte, e ela é invisível em qualquer comparação construída sobre throughput aritmético.

A bandwidth é o segundo eixo e responde a uma pergunta diferente: não quantos usuários, mas quão rápido cada um lê. Aplicando o limite da lição 9.1 a um número informado pelo fabricante perto de 8 TB/s,

contra cerca de 62 na peça Hopper. Para uma carga com os mesmos bytes ativos, aproximadamente 2,4 vezes a bandwidth eleva o roof de bandwidth em cerca de 2,4 vezes. Os quocientes de 54 GB acima são heurísticas pelo tamanho do checkpoint a partir de alegações do fabricante, não throughput medido nem limite rígido.

Aqui está o desvio errado clássico, e ele costuma aparecer na mesma reunião. Alguém nota que a peça mais nova suporta FP4 e conclui que a inferência será, portanto, duas vezes mais rápida de novo, de graça. Separe os dois efeitos. Uma representação FP4 validada pode reduzir o tráfego ativo de pesos muito abaixo de bf16, mas a redução exata dos bytes ativos depende da representação e do runtime. Isso pode melhorar o decode limitado por bandwidth, porém o GGUF Q4_K_M fixado de 17,1 GB não é evidência para um layout FP4 de servidor. Tensor cores FP4 também elevam o teto plano de compute, o que acelera o prefill e o time to first token. Esse é um efeito aritmético e também é real, mas ajuda uma fase diferente. Nenhum dos dois é grátis: o formato precisa ter uma receita de quantização validada para este modelo, e o Qwen3.8-27B é uma arquitetura híbrida cujas 48 camadas de Gated DeltaNet são mais novas que a maioria das bibliotecas de kernel, então a cobertura de FP4 para elas deve ser verificada na versão específica da stack, e não presumida de uma tabela de marketing. Testes de regressão de qualidade contra o próprio conjunto de benchmarks do model card são o mínimo antes de uma mudança de formato ir para produção.

O hábito que vale manter é precificar uma peça pelas duas linhas que decidem a sua carga de trabalho: quanto pool sobra depois de um encargo fixo de pesos, e quantos bytes por segundo cruzam a soleira. A lição 9.5 leva essas mesmas duas linhas a um fabricante cuja proposta inteira é a primeira delas.