LLM Primer VI — Introdução da Série e Índice
Um passeio capítulo a capítulo por LLM Primer VI: Escalando Sistemas de IA — o volume que trata a inferência LLM como uma disciplina de engenharia em que largura de banda de memória, escalonamento e cifrões colidem.
Por que esta série existe
Uma H100 alugada por quatro a oito dólares por hora entrega 989 TFLOP/s de computação BF16. Um único usuário, gerando uma única resposta em tempo real contra um modelo de 70B nesse chip, consome cerca de 0,34 por cento dessa computação. O chip fica 99,7 por cento ocioso — não porque a carga de trabalho seja pequena, mas porque a carga é limitada por largura de banda de memória e as unidades de computação do chip não têm o que fazer enquanto a HBM transmite os pesos por elas. A engenharia de inferência é a disciplina de encontrar trabalho para essas unidades ociosas. É uma disciplina de batching, de contabilidade de KV cache, de quantização, de decodificação especulativa, de escalonamento e, no fim, de plataforma, orquestração e custo. Toda técnica deste volume é uma variação do mesmo movimento: converter desperdício limitado por banda em throughput sem quebrar a latência que o usuário efetivamente sente.
Para quem escrevi
Engenheiros de plataforma, SREs e arquitetos de infraestrutura que são donos da inferência LLM em escala — as pessoas que são acionadas quando a latência dispara, cujo item de orçamento é o pool de GPU e que precisam explicar ao financeiro por que a conta do mês passado dobrou em relação ao anterior. Também foi escrito para engenheiros de ML que treinaram o modelo e agora precisam servi-lo, e para engenheiros de backend que se veem, de repente, na posição de especialista de inferência mais próximo que o time tem. O livro assume fluência com sistemas distribuídos e contêineres; não assume familiaridade prévia com o interior de uma GPU nem com o padrão de memória do transformer. Isso ele constrói desde os primeiros princípios.
Como ler
Os dezesseis capítulos se dividem em seis partes. Os capítulos 1 e 2 nomeiam a carga de trabalho — o loop autoregressivo e o KV cache. Os capítulos 3 e 4 percorrem o silício que a executa, das H100s até a LPU da Groq. Os capítulos 5 e 6 percorrem as compressões do lado do modelo — quantização, poda, destilação — que reduzem o peso de banda. Os capítulos 7 a 9 percorrem as técnicas de runtime — batching, KV paginado, decodificação especulativa — que escondem o tempo ocioso. Os capítulos 10 a 13 percorrem a stack de serving — engines, plataformas, desagregação, autoscaling — que transforma essas técnicas em serviço. Os capítulos 14 a 16 percorrem o dinheiro: economia de tokens, self-host versus API e os movimentos de corte de custo que compõem. Os capítulos podem ser lidos em ordem ou por tópico, mas o enquadramento mecânico depende dos capítulos 1 e 2.
O passeio pelos 16 capítulos
Entre 23 de abril e 8 de maio, o passeio publica um capítulo por dia. Cada artigo destila as três ideias-chave do capítulo em uma leitura de cerca de cinco minutos, com o capítulo do livro fornecendo os exemplos trabalhados, o código e os quadros "In Plain English".
- 23 de abril — Capítulo 1 — A Mecânica da Geração de Tokens. O loop autoregressivo, prefill versus decoding, e por que um único usuário deixa uma H100 99,7 por cento ociosa.
- 24 de abril — Capítulo 2 — O Desafio do KV Cache. A fórmula de memória, os trade-offs MHA/GQA/MQA e por que a alocação ingênua destrói a concorrência.
- 25 de abril — Capítulo 3 — GPUs de Data Center para IA Generativa. H100, H200, B200, L40S, MI300X — lidas como perfis de banda e VRAM, não de FLOPs.
- 26 de abril — Capítulo 4 — Silício de IA Especializado e ASICs. LPU da Groq, Inferentia2, TPU v5p/v6 e Gaudi 3 — onde ASICs vencem e onde perdem.
- 27 de abril — Capítulo 5 — Desmistificando a Quantização. Por que FP16 → INT4 quadruplica o throughput, e o que AWQ, GPTQ, SmoothQuant e GGUF de fato fazem.
- 28 de abril — Capítulo 6 — Poda e Destilação de Conhecimento. Sparsidade 2:4 em Hopper e como os rótulos suaves de um professor viram um modelo aluno menor.
- 29 de abril — Capítulo 7 — Estratégias Avançadas de Batching. Do batching estático ao continuous batching em nível de iteração, e a dívida que o continuous batching cria.
- 30 de abril — Capítulo 8 — Gerenciamento de KV Cache de Próxima Geração. PagedAttention, eviction H2O, InfiniGen e a economia do prefix cache.
- 1 de maio — Capítulo 9 — Decodificação Especulativa. Draft, verify e a aritmética de quando a especulação compensa — EAGLE, Medusa, MTP.
- 2 de maio — Capítulo 10 — A Camada de Engine LLM. vLLM, TensorRT-LLM, SGLang, TGI, Ollama, e como escolher um engine por mecanismo, não por benchmark.
- 3 de maio — Capítulo 11 — A Camada de Plataforma e Orquestração. Ray Serve, KServe, BentoML, Triton — qual plataforma casa com qual cultura de ops.
- 4 de maio — Capítulo 12 — Serving Desagregado e Kubernetes. Separar prefill e decode em pools de GPU distintos, e as primitivas de Kubernetes que expressam isso.
- 5 de maio — Capítulo 13 — Autoscaling e Mitigação de Cold Start. Por que HPA é errado para LLMs, e como KEDA, Knative e CRIU compõem cold starts abaixo de 5 segundos.
- 6 de maio — Capítulo 14 — Economia de Tokens e Preços de API. Por que a saída é precificada acima da entrada e como os invisíveis tokens de raciocínio surpreendem a fatura.
- 7 de maio — Capítulo 15 — APIs Serverless vs. Infraestrutura Dedicada. A matemática do ponto de equilíbrio, mais o item de engenharia de plataforma que a maioria dos times subestima.
- 8 de maio — Capítulo 16 — Estratégias de Corte de Custo em Produção. Roteamento, compactação de contexto, batch APIs e cache semântico — os movimentos que compõem.
Sobre este livro e a série
A série LLM Primer é composta por sete volumes escritos por Sho Shimoda, publicados na Amazon KDP e lidos capítulo a capítulo aqui no blog da ReceiptRoller. A série defende que construir com LLMs é uma disciplina de sistemas e que essa disciplina se aprende melhor percorrendo cada camada da stack em prosa mecânica, em vez de em forma de checklist. O Volume VI é o volume de infraestrutura — aquele que responde, camada por camada, à pergunta sobre o que precisa ser verdade a respeito do hardware, do runtime e da plataforma para que uma funcionalidade LLM sobreviva ao tráfego real e a uma revisão de finanças.