Capítulo 1 — A Mecânica da Geração de Tokens

Primeiro post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que sustenta que quase toda pergunta difícil no serving de LLMs desce de um único fato — o loop que produz cada token é limitado por largura de banda de memória, e a computação cara pela qual você pagou fica parada 99,7 por cento do tempo.

Por que este capítulo existe

Um LLM é, em operação, um preditor de próximo token envolto em um loop. Tokens entram, sai uma distribuição de probabilidade sobre o próximo token, um é escolhido, anexado e o loop roda de novo. Toda propriedade interessante de uma stack de inferência — batching, quantização, KV caching, decodificação especulativa, serving desagregado — descende de um olhar próximo dentro desse loop. O loop esconde duas cargas de trabalho que compartilham o mesmo caminho de código, mas estressam o hardware de formas opostas. Uma é limitada por computação. A outra é limitada por banda. Na mesma H100. No mesmo forward pass. Nomear essa divisão com precisão é o primeiro movimento do livro, e é o enquadramento ao qual todo capítulo posterior retorna.

1.1 O loop autoregressivo é sequencial por força

O token t+1 é função de todo token até e inclusive t. O modelo não pode prever t+2 antes de t+1 ter sido amostrado, porque a predição de t+2 exige que t+1 faça parte da entrada. Não existe kernel esperto que paralelize a geração de dois tokens consecutivos de uma única sequência; o caráter sequencial é imposto pela estrutura de dependência da computação. O custo em tempo de parede de uma completude de N tokens é, portanto, N vezes o custo de um passo mais overhead fixo. Toda otimização que se segue no livro — batches maiores, especulação à frente da trajetória, aritmética mais barata por passo — é uma resposta parcial à pergunta "dado que o loop precisa caminhar um token de cada vez, como fazemos cada passo mais rápido ou cada batch maior?" O modelo também não tem rascunho externo: ele pensa emitindo tokens. O loop é o único mecanismo pelo qual o modelo consegue pensar por mais tempo, e é por isso que chain-of-thought e decodificação especulativa vivem dentro da mesma contabilidade.

1.2 Prefill e decoding estressam o chip de formas opostas

O loop esconde duas fases. Prefill é o primeiro forward pass, que consome o prompt do usuário no formato [batch, sequence_length, hidden_dim]. Toda multiplicação de matriz opera sobre todas as posições da sequência de uma vez; a aritmética escala com o comprimento da sequência; os pesos são lidos da HBM uma vez e aplicados a muitas linhas de trabalho. A intensidade aritmética é alta. O prefill é limitado por computação e consegue usar os 989 TFLOP/s de BF16 da H100. Decoding é todo forward pass subsequente. O shape de entrada colapsa para [batch, 1, hidden_dim]. Os pesos de cada camada ainda precisam ser transmitidos da HBM, mas apenas uma linha de aritmética é executada contra eles. A intensidade aritmética despenca em três ordens de magnitude. Decoding é limitado por banda de memória. Em um modelo de 70B em BF16, o prefill sobre um prompt de 2.000 tokens roda próximo ao teto de computação do chip; o próximo forward pass — o primeiro passo de decode — roda contra os mesmos 140 GB de pesos para produzir um único token. O chip não mudou. A carga de trabalho, sim.

1.3 Um único usuário deixa 99,7 por cento da H100 ociosa

A consequência é que a geração em tempo real para um único usuário é o pior caso para um acelerador de fronteira. Um modelo de 70B em BF16 em uma H100 SXM decodifica a cerca de 24 tokens por segundo — velocidade de leitura razoável para o usuário — e a banda HBM3 de 3,35 TB/s do chip fica totalmente saturada movendo 140 GB de pesos por token. Mas, a essa taxa, as unidades de computação executam apenas cerca de 3,36 TFLOP/s dos 989 de que são capazes. A utilização de compute é de 0,34 por cento. O chip físico não está mal configurado; cada SM lê e multiplica em velocidade máxima, mas os tensor cores foram projetados para consumir tiles de muitas linhas contra cada tile de pesos, e um forward pass de um único token lhes entrega uma única linha. A capacidade de computação é denominada em uma unidade (operações por byte carregado) que a carga de trabalho não produz. Alguém ainda paga de quatro a oito dólares por hora pelo chip inteiro. A economia do serving de LLMs é, portanto, a economia de encontrar trabalho para a computação estacionada — via batching, via banda por token mais barata, via especulação, via hardware cujo ponto de equilíbrio combina com a carga de trabalho.

O que o Capítulo 1 prepara

O restante do livro é a resposta à assimetria nomeada aqui. O Capítulo 2 desmonta o KV cache — a estrutura de dados que permite ao decoding evitar recomputação quadrática e que, no processo, se torna o maior consumidor único de VRAM em um cluster de serving. Os capítulos 3 e 4 percorrem o substrato de hardware com a lente de banda-versus-computação. Os capítulos 5 e 6 encolhem o peso de banda por token encolhendo os pesos. O Capítulo 7 percorre o batching como alavanca no nível de sistema que converte desperdício limitado por banda em throughput. Os capítulos 8 e 9 mudam a forma do trabalho com gerenciamento de KV paginado e decodificação especulativa. Cada movimento é legível como uma tentativa de preencher a computação ociosa que este capítulo acabou de medir.

Próximo — Capítulo 2: O Desafio do KV Cache. O workspace que torna o decoding acessível, e a fórmula de memória que explica por que clusters de serving ficam sem VRAM antes de ficarem sem computação.