Memory bandwidth vs FLOPs

01 · Conceito

Conceito

Alugue uma única GPU classe H100, carregue o Qwen3.8-27B em bf16, abra uma janela de chat e cronometre a saída. Os tokens chegam a algumas dezenas por segundo enquanto a ficha técnica da placa anuncia throughput aritmético na casa dos petaflops. Nada está quebrado e nada está mal configurado. A máquina simplesmente está sendo paga na moeda errada.

Todo acelerador vende duas coisas, e elas têm preços independentes. A primeira é aritmética: operações de ponto flutuante por segundo, entregues pelos tensor cores espalhados pelos streaming multiprocessors. A segunda é tráfego de memória: bytes por segundo movidos entre a memória de alta banda e essas unidades de compute. Um módulo H100 SXM carrega 80 GB de HBM3 com pico informado pelo fabricante perto de 3,35 TB/s, e sua taxa densa em bf16 nos tensor cores é citada na ordem de mil teraflops. Trate ambos como números de fabricante em agosto de 2026, medidos sob condições do fabricante e essencialmente inatingíveis num kernel real. Ainda assim, a razão entre eles é o número que importa, porque diz quanta aritmética a máquina quer para cada byte que busca:

Alimente essa máquina com menos que algumas centenas de operações por byte e os tensor cores travam, esperando. Essa única razão, o ponto de equilíbrio da máquina, decide qual moeda cada kernel gasta.

Agora o exemplo trabalhado. A lição 7.3 estabeleceu que o decode avança uma posição por sequência a cada passo, através de todas as camadas, e que em batch 1 a arithmetic intensity de uma matriz de pesos é de cerca de uma operação por byte de peso. Os bytes não são abstratos. O Qwen3.8-27B guarda aproximadamente 27 bilhões de parâmetros em bfloat16, dois bytes cada, o que dá cerca de 54 GB de pesos, mas 54 GB são o artefato residente completo, não os bytes ativos exatos de um passo textual. Toda projeção do decoder, matriz de feed-forward com gate e a cabeça de linguagem não amarrada rodam, enquanto o embedding de entrada é um lookup de linha e a vision tower não roda em input apenas textual. O quociente de planejamento pelo checkpoint completo é:

Chame de cerca de 60 tokens por segundo. Isso não é um benchmark e não é uma medição que alguém aqui fez. É uma estimativa conservadora pelo tamanho do checkpoint derivada de uma alegação de bandwidth do fabricante, e ignora o trabalho de attention, as leituras crescentes de key-value da lição 7.2, as atualizações de estado do DeltaNet, o overhead de lançamento de kernel e toda ineficiência que fica entre a bandwidth de pico e a atingida. Uma taxa medida pode cair de qualquer lado desse quociente: tensors inativos do checkpoint reduzem os bytes ativos, enquanto cache, estado, kernels e bandwidth de pico não atingida acrescentam custo. Seu valor é a ordem de grandeza; um roofline exato usa bytes ativos medidos por token.

Aqui está o desvio errado, e ele é caro o bastante para as pessoas o cometerem com ordens de compra. O decode parece lento, então o time conclui que a GPU ficou sem aritmética e especifica uma peça com mais FLOPs. Rode a aritmética sobre a proposta, em vez disso. Sob essa heurística pelo tamanho do checkpoint a placa realiza aproximadamente duas operações por parâmetro para o multiply-accumulate, cerca de 54 bilhões de operações no total, contra um pico de mil teraflops. Isso dá algo como três décimos de um por cento da aritmética que a máquina pode entregar. Os tensor cores ficam ociosos por mais de 99 por cento do passo. Dobrá-los dobra a ociosidade. A correção é atacar bytes, e não operações, e todo remédio eficaz de decode neste curso é exatamente isso: pesos validados de bits mais baixos reduzem os bytes ativos, o batching amortiza uma leitura de pesos entre muitas sequências, e o speculative decoding verifica vários tokens candidatos por leitura.

O batching merece sua própria linha de aritmética porque é a alavanca mais barata e a mais mal compreendida. Fazer decode de 32 sequências independentes juntas ainda lê os pesos uma vez por passo, então a intensidade sobe de cerca de uma operação por byte para cerca de 32. O throughput total sobe aproximadamente 32 vezes enquanto a latência por sequência quase não se move. Mas 32 ainda está muito abaixo do ponto de equilíbrio de 300, então o passo continua limitado por bandwidth, só que de forma útil. É por isso que economia de serving e latência de chat são problemas diferentes com respostas diferentes, e por que um sistema afinado para um pode parecer quebrado quando medido pelo outro.

O lado do treinamento do livro-caixa corre no sentido oposto, o que vale manter em mente ao lado da lição 5.13. O custo de pré-treinamento é estimado como aproximadamente seis operações por parâmetro por token, uma fórmula que conta FLOPs porque o pré-treinamento processa batches enormes de tokens e portanto vive bem do lado rico em aritmética do ponto de equilíbrio. Os mesmos pesos que fizeram do treinamento um exercício de compra de FLOPs fazem do serving de fluxo único um exercício de compra de bandwidth. Um modelo, dois regimes de hardware, e uma decisão de compra que se inverte dependendo de qual fase você está pagando.

O modelo durável é uma máquina de duas moedas. Pergunte de qualquer kernel quantas operações ele realiza por byte que precisa mover, compare isso com o ponto de equilíbrio da máquina, e você sabe, antes de escrever uma linha de otimização, de qual recurso está carente. A lição 9.2 transforma essa comparação num único gráfico onde você pode posicionar cada kernel, e a lição 9.3 gasta a outra metade do orçamento de hardware, a capacidade em vez da bandwidth, no key-value cache.