Capítulo 10 — A Camada de Engine de LLM

Décimo post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que nomeia a fronteira entre o engine e a plataforma, e percorre os cinco engines que dominam essa camada em 2026.

Por que este capítulo existe

Os capítulos de 1 a 9 percorreram a máquina que uma única passagem direta toca: o laço autoregressivo, a KV cache, o substrato de GPU, a quantização que a encolhe, o batching que esconde seu tempo ocioso e a decodificação especulativa que quebra sua dependência sequencial. Nada disso se instala como uma biblioteca que se faz pip install e esquece. Alguém costura tudo em um runtime de um único nó que encapsula um modelo, é dono da KV cache, escala requisições em um batch contínuo e expõe uma API de inferência. Esse runtime é o engine. O capítulo 10 nomeia o trabalho da camada de engine, a distingue da camada de plataforma (capítulo 11) e percorre os cinco engines — vLLM, TensorRT-LLM, SGLang, TGI, Ollama — que fazem escolhas mecânicas diferentes no mesmo trabalho.

10.1 vLLM é o padrão nativo em Python

O vLLM é o engine que a maioria dos times de produção deve escolher primeiro, porque ele toma a decisão-padrão certa em cada eixo que um iniciante não saberia como pensar, e faz isso em Python. O PagedAttention colapsa a fragmentação de 60–80 por cento para poucos por cento, o que quase dobra o batch alcançável na mesma GPU. O batching contínuo se encaixa naturalmente por cima, com prefill em chunks misturando trabalho de prefill e decodificação na mesma iteração, de modo que a fronteira entre eles não é tempo morto. O compartilhamento de prefixo em copy-on-write vem de graça do desenho de block table. A interface é genuinamente offline-batch ou HTTP compatível com a da OpenAI em poucas linhas, e cada nova arquitetura de modelo chega rápido porque a comunidade é ampla. É o engine para se padronizar quando o operador não tem uma razão específica para escolher outro.

10.2 TensorRT-LLM compra throughput com um pipeline de build

O pitch do TensorRT-LLM é estreito. Se a frota é exclusivamente NVIDIA, se cada ponto percentual de throughput por dólar importa e se o time vai pagar o imposto de engenharia de compilar arquivos de engine específicos por modelo e por geração de hardware, o TRT-LLM extrai 15–35 por cento mais throughput que o vLLM no mesmo hardware. O mecanismo é no nível de kernel: baixa o grafo do transformer para uma IR específica da NVIDIA, funde kernels adjacentes (layernorm + matmul + ativação em um único launch), seleciona kernels ótimos por shape de uma biblioteca pré-ajustada, produz um engine serializado e o executa sob o Triton Inference Server. A fusão importa porque cada kernel launch tem overhead de 5–10 μs e uma passagem direta ingênua de um modelo 70B despacha milhares deles por token. O imposto é o próprio pipeline de build — um passo de compilação por modelo, por GPU e por regime de batch, cujo custo operacional a maioria dos times subestima. O SGLang é a outra especialização: o RadixAttention guarda a KV cache de cada prefixo de prompt que o engine já viu em uma árvore radix, de modo que duas requisições que compartilham um prefixo de k tokens compartilham a KV exatamente para esses k tokens, entre batches e ao longo do tempo. Em cargas agentivas com prompts de sistema longos e sufixos curtos variantes, o SGLang entrega 2–6× de throughput sobre o vLLM, e sua DSL de saída estruturada impõe schemas JSON no nível dos logits, garantindo que a saída valida.

10.3 A árvore de decisão passa pela forma da carga, não pelo throughput de manchete

Os cinco engines se abrem numa pequena árvore de decisão. Notebook de desenvolvedor ou borda com aceleradores misturados → Ollama. Frota de GPU de produção, exclusivamente NVIDIA, alto QPS, ROI de throughput justifica o pipeline de build → TensorRT-LLM. Hardware misto ou troca frequente de modelo, carga dominada por padrões estruturados com muito compartilhamento de prefixo (agentes, chamadas de ferramenta, prompts compartilhados longos) → SGLang. Hardware misto, chat genérico, integração profunda com o Hugging Face → TGI. Todo o resto → vLLM. A escolha não é permanente: os engines são intercambiáveis na fronteira da API — todos falam HTTP no estilo OpenAI — então um roteador da camada de plataforma consegue mover tráfego por modelo, por carga ou por região sem mudar o código cliente. Muitas pilhas de produção rodam dois ou três engines lado a lado. Cuidado com o benchmark de manchete: "tokens por segundo no Llama-2-7B em batch 1" responde a uma pergunta que nenhuma carga de produção faz. Faça benchmark no seu próprio modelo, na sua própria distribuição de prompts, no seu próprio perfil de concorrência; meio dia de esforço economiza meses.

O que o capítulo 10 prepara

Cada engine descrito neste capítulo para na mesma fronteira. Ele conhece kernels, blocos de KV e batching contínuo; ele não conhece réplicas, tenants, cadeias ou autenticação. O capítulo 11 percorre a camada de plataforma que trata dessas preocupações — Ray Serve, KServe, BentoML, Triton Inference Server — e mostra que a escolha é muito menos sobre features do que sobre qual modelo operacional se encaixa na infraestrutura e nas competências que o time já tem.

Próximo — Capítulo 11: A Camada de Plataforma e Orquestração. Ray Serve, KServe, BentoML, Triton — as quatro plataformas que ficam acima do engine, escolhidas por afinidade com a cultura de ops.