Guia de Engenharia de LLM: 45 conceitos para sistemas de produção

Viacheslav Dubrov

2026-03-13 · Atualizado 2026-08-31 · 75 min · Engenharia de modelos · Infraestrutura de IA

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Um serviço de LLM pode falhar o seu SLO de latência porque a descodificação está limitada pela largura de banda da memória, porque a cache KV consumiu o orçamento do batch ou porque a fila está a mascarar ambos os problemas. Uma execução de fine-tuning pode falhar por uma versão diferente da mesma razão: o estado do modelo já não cabe no hardware. A correção certa decorre do bottleneck, não da lista mais longa de técnicas.

Este é um guia de referência para engenheiros que já conhecem os conceitos básicos de ML e de sistemas e precisam de relacionar um sintoma em produção com a parte relevante da stack. Abrange 45 conceitos de hardware, inferência, treino, deployment, aplicações e operações. Use cada entrada para identificar o mecanismo, a consequência prática e a condição que limita o resultado citado; depois consulte o deep dive associado ou use o seu próprio benchmark para tomar a decisão.

Nota sobre o âmbito

Este é um guia de referência, não um tutorial linear. Comece pela parte que corresponde à decisão que tem em mãos.

Como utilizar este guia como hub

Esta página é deliberadamente abrangente. Use-a como mapa e, quando a decisão se tornar concreta, avance para os artigos mais aprofundados.

Comece pelo bottleneck, use a stack mais pequena que o exponha, faça benchmark da carga de trabalho real e só acrescente complexidade quando os números o justificarem.

Parte I — Fundamentos do hardware

A intensidade aritmética, a hierarquia de memória da GPU e os termos de hardware abordados nesta parte explicam muitas das escolhas apresentadas mais à frente no guia.

1. Memory-bound vs compute-bound e o modelo roofline

O ponto de partida para o desempenho de LLMs é a intensidade aritmética: por cada byte de dados que a GPU carrega da memória, quantos cálculos úteis executa? Este rácio determina se uma operação é compute-bound (à espera do processador) ou memory-bound (à espera de que os dados sejam carregados).

Todas as GPUs têm um limiar de «intensidade crítica» em que o seu débito máximo de computação iguala a largura de banda da memória. Numa NVIDIA H100 SXM com Tensor Cores BF16 ou FP16 densos (989 TFLOPS; a especificação de 1 979 TFLOPS assume sparsity estruturada):

$\frac{989 \text{ TFLOPS}}{3.35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

O decode com batch de um token e o prefill longo ou com batch suficiente encontram-se normalmente em lados opostos deste limiar:

• O decode é memory-bound. Gerar tokens um a um implica carregar da memória a matriz de pesos de vários gigabytes para a multiplicar por um único token novo. Numa análise simplificada, densa e de 16 bits, com batch de um token, a operação tem cerca de 1 FLOP/byte, aproximadamente 295 vezes abaixo do limiar roofline da H100. Esta diferença explica por que razão o decode não consegue aproximar-se do débito máximo de computação neste regime.
• O prefill longo ou com batch suficiente é frequentemente compute-bound. Processar muitos tokens do prompt permite reutilizar os pesos em multiplicações de matrizes de grandes dimensões, o que pode elevar a intensidade aritmética acima do limiar roofline. Prompts curtos e batches pequenos podem, pelo contrário, ficar limitados pelo tráfego de memória ou pelo overhead de lançamento de kernels.

Assim, para acelerar o decode, trabalhe na largura de banda da memória: reduza o tamanho dos pesos com quantização, diminua o overhead de memória do KV com GQA e PagedAttention, e aumente a intensidade com batching. Em pre-fills longos ou bem agrupados em batch, uma computação matricial mais rápida e computação com menor precisão podem ajudar; faça o profiling de workloads com pre-fill curto separadamente.

2. Hierarquia de memória da GPU

Uma GPU tem quatro camadas de memória, dispostas como uma pirâmide: uma memória principal (HBM) grande mas lenta na base, e registos minúsculos mas muito rápidos no topo. A movimentação de dados através desta hierarquia é uma importante limitação de desempenho.

Da mais rápida para a mais lenta, numa H100:

1. Os registos são a memória mais rápida e estão ligados diretamente às threads de processamento. No WGMMA da Hopper, a matriz A pode vir dos registos ou da memória partilhada, enquanto a matriz B vem da memória partilhada.
2. A SRAM (memória partilhada) é uma memória de trabalho rápida, integrada no chip e local a cada SM.
3. A cache L2 é uma camada partilhada de 50 MB. Pode fornecer dados reutilizados entre SMs sem outra leitura da HBM.
4. A HBM3 é a memória principal de 80 GB que contém os pesos do modelo e a cache KV, com ~3,35 TB/s de largura de banda.

A FlashAttention e a fusão de kernels reduzem o tráfego da HBM ao manter ou combinar trabalho intermédio no chip. A PagedAttention resolve um problema diferente: mapeia blocos KV lógicos para blocos não contíguos da memória física da GPU, reduzindo a fragmentação e permitindo a partilha de blocos.

3. Glossário do hardware de GPU

Os termos abaixo surgem ao longo do resto deste guia.

HBM (High Bandwidth Memory) empilha dies de DRAM ligados por vias através do silício (TSVs), junto ao die da GPU. Entre as gerações incluem-se HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s) e HBM3e (H200/B200, 4,8–8 TB/s). A largura de banda da HBM é uma limitação direta do TPOT em regimes de decode limitados pela memória.

GDDR (Graphics DDR) é a memória gráfica tradicional utilizada em GPUs de consumo e de workstation, como a RTX 4090 e a L40S. Tem uma largura de banda inferior à da HBM, mas um custo por GB mais baixo. A GDDR6X na RTX 4090 disponibiliza cerca de 1 TB/s, em comparação com os 3,35 TB/s de largura de banda HBM3 da H100.

Um SM (Streaming Multiprocessor) é o bloco de computação básico de uma GPU NVIDIA. Cada SM contém CUDA cores, Tensor Cores, memória partilhada e um warp scheduler. A H100 tem 132 SMs; a A100 tem 108.

Os Tensor Cores são unidades especializadas de multiply-accumulate matricial dentro de cada SM. Aceleram as operações matmul de precisão mista que dominam a computação de transformers. Os Tensor Cores da H100 SXM disponibilizam 494,5 TFLOPS TF32 densos ou 989 TFLOPS TF32 esparsos; inclua sempre a precisão e o modo de esparsidade ao comparar este valor.

Os CUDA Cores são unidades de uso geral para operações de vírgula flutuante e inteiras. Tratam operações elemento a elemento, funções de ativação e outro trabalho não matricial enquanto os Tensor Cores executam operações matriciais suportadas.

Um warp é um grupo de 32 threads que executam em lockstep num SM, constituindo a unidade de scheduling mais pequena da NVIDIA. A warp specialization atribui warps diferentes à movimentação de dados e à computação, permitindo que as tarefas se sobreponham.

NVLink é a interligação de alta velocidade entre GPUs da NVIDIA dentro de um nó. O NVLink 4.0 no H100 disponibiliza 900 GB/s de largura de banda bidirecional; o NVLink 5.0 no B200 atinge 1,8 TB/s. Esta largura de banda é importante para o paralelismo de tensores, porque as GPUs trocam resultados parciais em cada camada do transformer.

InfiniBand é uma fabric de rede de alta velocidade para comunicação entre nós. Os adaptadores InfiniBand da classe ConnectX fornecem a fabric entre nós para tráfego de paralelismo de pipeline ou de treino distribuído; a largura de banda depende do adaptador e da configuração das portas.

RDMA (Remote Direct Memory Access) permite que um dispositivo aceda à memória de outra máquina sem encaminhar o percurso dos dados através de nenhum dos CPUs. O GPUDirect RDMA suporta transferências directas entre GPUs através de vários nós, incluindo transferências de KV cache em serving desagregado.

NVMe (Non-Volatile Memory Express) é a interface de SSD utilizada para descarregar o KV cache e para o descarregamento de parâmetros do ZeRO-Infinity quando a memória da GPU e do CPU é insuficiente. A largura de banda sequencial depende da unidade e da carga de trabalho e continua muito abaixo da largura de banda da HBM.

TFLOPS e PFLOPS correspondem, respectivamente, a biliões e quatriliões de operações de vírgula flutuante por segundo. Um TFLOPS equivale a $10^{12}$ FLOPS. O H100 atinge 989 TFLOPS de tensores TF32 esparsos, enquanto o FlashAttention-3 reporta cerca de 1,2 PFLOPS em FP8; estes valores utilizam formatos diferentes e não devem ser comparados como se fossem uma única métrica.

Parte II — Fundamentos da inferência

A inferência transforma um modelo num serviço visível para o utilizador. Os conceitos seguintes distinguem o trabalho que atrasa o primeiro token daquele que torna mais lentos todos os tokens seguintes e evidenciam os limites de memória subjacentes a ambos.

4. Latência: TTFT, TPOT e percentis

Time to First Token (TTFT) é o atraso de ponta a ponta entre o envio do pedido e o primeiro token de saída. Inclui o tempo em fila, a tokenização, o escalonamento, o prefill do prompt, o primeiro passo de decode e a entrega pela rede. Prompts mais longos normalmente aumentam a componente de prefill, mas qualquer uma destas fases pode ser dominante. Os objectivos dependem do produto; o MLPerf Inference v5.0 utiliza um limite P99 de TTFT de $\leq$ 450 ms para o seu cenário interactivo com Llama 2 70B.

Time Per Output Token (TPOT) é o intervalo médio entre tokens consecutivos após o primeiro. Corresponde à fase de decode. O decode com batch de tamanho um ou de baixa intensidade é normalmente limitado pela largura de banda da memória, enquanto batches suficientemente grandes podem tornar-se limitados pelo compute:

$\text{TPOT} = \frac{\text{E2E Latency} - \text{TTFT}}{\text{Output Tokens} - 1}$

Esta definição requer pelo menos dois tokens de saída; o TPOT não está definido para uma resposta com um único token.

A velocidade média de leitura silenciosa de um adulto em inglês é de cerca de 238 palavras por minuto para textos não ficcionais (Brysbaert, 2019). Os objectivos de streaming devem ainda assim resultar de testes do produto; o MLPerf utiliza um limite P99 de TPOT de $\leq$ 40 ms para o seu cenário interactivo.

A latência P50 vs P99 é importante porque a mediana oculta a cauda. Um sistema com um P50 bom e um P99 mau pode ter problemas de batching, preempção, filas ou enviesamento da carga de trabalho; são necessários traces para os distinguir.

5. Throughput: tokens por segundo e o compromisso com a latência

O throughput mede-se em tokens de saída por segundo entre pedidos concorrentes. Os pedidos por segundo são, por si só, uma métrica menos robusta, porque uma resposta de 10 tokens e uma resposta de 1 000 tokens têm custos muito diferentes. Os valores publicados em benchmarks variam consoante o modelo, a precisão, o hardware, os comprimentos do prompt e da saída, a concorrência e o SLO. Compare vLLM, SGLang e TensorRT-LLM com o mesmo harness, em vez de combinar os resultados de destaque de cada um.

O compromisso é o seguinte: com baixa concorrência, cada pedido obtém uma latência excelente, mas a GPU fica subutilizada. Aumentar o batch size aumenta o throughput quase linearmente até a computação ficar saturada; a partir daí, a latência aumenta acentuadamente. O goodput, isto é, a taxa de pedidos por segundo que cumpre os seus objetivos de SLO, relaciona o throughput bruto com aquilo que os utilizadores realmente experienciam.

6. KV cache: o bottleneck por detrás da maioria dos outros bottlenecks

Durante a geração autoregressiva, cada novo token atende a todos os tokens anteriores. A KV cache armazena as projeções Key e Value de cada token em cada camada, evitando a recomputação de $O(n^2)$. Sem ela, gerar o token $n$ exigiria voltar a executar o modelo sobre todos os $n-1$ tokens anteriores.

A KV cache pode tornar-se a principal fonte de pressão sobre a memória variável com sequências longas ou elevada concorrência, porque cresce linearmente com o comprimento da sequência, o batch size e o número de camadas:

$KVcache = 2 \times L \times h_{kv} \times d_h \times s \times B \times \text{bytes}$

onde:

• $L$ = número de camadas
• $h_{kv}$ = número de cabeças KV
• $d_h$ = dimensão da cabeça
• $s$ = comprimento da sequência
• $B$ = batch size
• $\text{bytes}$ = bytes por elemento em cache, definidos pela precisão da KV cache

Exemplos concretos com FP16 e batch size 1: o Llama 3.1 8B, com 8 192 tokens, usa cerca de 1,0 GB de KV cache; com 128K tokens, 16 GB. O Llama 3.1 70B, com 128K tokens, precisa de cerca de 40 GB para uma única sequência, metade da VRAM de uma H100. Com elevada concorrência ou contexto longo, a KV cache pode exceder a memória ocupada pelos pesos do modelo; o resultado depende do comprimento da sequência, do batch size ativo, da precisão da KV e do número de cabeças KV. Implementações ingénuas desperdiçam 60–80% da memória KV alocada devido à fragmentação — o problema que a PagedAttention foi criada para resolver.

As principais otimizações são a GQA (menos cabeças KV), a quantização da KV cache (FP8/INT8), a PagedAttention (alocação baseada em blocos, com menos de 4% de desperdício) e o offloading da KV cache para CPU ou NVMe.

7. Prefill vs decode: duas fases, dois bottlenecks

A fase de prefill processa o prompt de entrada em paralelo e preenche a KV cache. Prefills longos ou suficientemente agrupados em batches tornam-se frequentemente limitados pela computação, porque usam multiplicações de matrizes grandes; pre-fills curtos podem continuar limitados pelo tráfego de memória ou pelo overhead de lançamento dos kernels. O prefill contribui para o time to first token (TTFT), juntamente com o enfileiramento, a tokenização, o scheduling, o primeiro passo de decode e a entrega através da rede. A fase de decode gera um token de cada vez. Cada passo lê os pesos do modelo e a KV cache a partir de HBM, fazendo com que o decode com batch size 1 seja limitado pela largura de banda da memória e constitua o principal fator do tempo por token de saída (TPOT).

O prefill em chunks divide o prompt em chunks de tamanho fixo, em vez de o processar todo de uma vez. Um scheduler pode intercalar esses chunks com o trabalho de decode, evitando que um prompt longo monopolize uma iteração. O Sarathi-Serve apresenta melhores compromissos entre throughput e latência nas cargas de trabalho testadas, mas o ganho depende do modelo, do hardware, da distribuição dos comprimentos dos pedidos, do tamanho dos chunks e da baseline de comparação. O overhead adicional de scheduling e os kernels mais pequenos podem aumentar o TTFT do novo pedido.

O serving desagregado coloca o prefill e o decode em pools de GPUs separados, permitindo que cada pool seja otimizado para um bottleneck diferente. O Splitwise e o DistServe descrevem este padrão. Os pools transferem dados da KV cache através de uma interligação rápida, como RDMA, pelo que o custo de comunicação passa a fazer parte do design.

8. GQA e MQA: reduzir a KV cache

A Multi-Head Attention (MHA) standard atribui a cada cabeça de query a sua própria cabeça K e V. A Multi-Query Attention (MQA) partilha uma única cabeça KV entre todas as cabeças de query, o que representa uma redução extrema. A Grouped-Query Attention (GQA) é o compromisso prático: grupos de cabeças de query partilham uma cabeça KV.

O Llama 3 70B usa 64 cabeças de query, mas apenas 8 cabeças KV, o que corresponde a uma redução de 8x da KV cache face à mesma arquitetura com uma cabeça KV por cabeça de query. O Llama 3.1 405B usa 128 cabeças de query e 8 cabeças KV, uma redução de 16x pelo mesmo cálculo (Meta, 2024). Ainslie et al. relatam uma qualidade da GQA próxima da MHA nos modelos testados, aproximando-se da velocidade da MQA. Uma KV cache mais pequena pode suportar batches maiores, mas o ganho efetivo de latência e throughput continua a depender do kernel e da carga de trabalho.

9. Quantização: trocar bits por velocidade e memória

A quantização reduz a precisão dos pesos e/ou das ativações do modelo. Os principais compromissos são:

AWQ (Activation-Aware Weight Quantization) identifica os canais de pesos mais salientes a partir das magnitudes das ativações e aplica escalamento por canal para os proteger. As necessidades de calibração dependem do modelo e da configuração; numa comparação OPT-6.7B INT3-g128, o AWQ utilizou 16 sequências de calibração, enquanto o GPTQ utilizou 192. Num setup reproduzível, indique tanto o número de sequências como o respetivo comprimento. GPTQ utiliza informação aproximada de segunda ordem para a quantização por camada. bitsandbytes pode quantizar durante o carregamento do modelo, sem uma passagem de pré-processamento separada; o seu formato NF4 é a base do fine-tuning QLoRA. O FP8 em hardware da classe Hopper reduz para metade a memória ocupada pelos pesos face a FP16/BF16, mas a qualidade e a velocidade continuam a depender do modelo, da calibração e do kernel.

O kernel de serving pode ser tão importante como o algoritmo de quantização. A Secção 10 apresenta um resultado Marlin com limites definidos e explica por que razão o ganho depende da configuração de serving.

Parte III — Otimizações de inferência

As otimizações desta parte resolvem restrições diferentes. O FlashAttention reduz o tráfego de HBM da atenção; o PagedAttention melhora a alocação de KV; o continuous batching impede que sequências concluídas mantenham capacidade ocupada no batch.

10. Kernels CUDA e fusão de kernels

Um kernel CUDA é uma função escrita para a GPU que é executada em paralelo por milhares de threads. Quando a CPU chama um kernel, a GPU distribui o trabalho pelos seus SMs: cada SM executa vários warps de 32 threads, e cada thread processa uma parte dos dados. Todas as operações na inferência de LLMs, desde a multiplicação de matrizes até à amostragem de tokens, acabam por ser um lançamento de kernel. Uma única passagem forward por um modelo 70B desencadeia centenas ou milhares de lançamentos de kernels, e a diferença entre um kernel ingénuo e um otimizado pode determinar se o sistema cumpre o seu SLO de latência.

As principais categorias de kernels em serving de LLMs:

• Kernels GEMM para multiplicação de matrizes, que dominam o cálculo tanto no prefill como no decode.
• Kernels de atenção, como o FlashAttention, que organizam os cálculos em tiles para permanecerem em SRAM, em vez de fazerem spill para HBM.
• Kernels fundidos que combinam várias operações (como add + layer norm ou projeção QKV) num único lançamento, evitando as viagens intermédias de ida e volta à HBM.
• Kernels de amostragem que convertem logits em IDs de tokens através de amostragem top-k, top-p ou por temperatura.

A qualidade dos kernels pode determinar se os pesos comprimidos proporcionam um ganho de velocidade. O artigo do Marlin reporta até 2,8x de speedup end-to-end face à sua baseline FP16 nas configurações vLLM testadas com INT4 apenas nos pesos. Esse resultado é específico dos modelos, GPUs, tamanhos de batch e setup de serving do artigo, pelo que não constitui um ganho universal do INT4.

O Triton reduz a barreira à criação de kernels personalizados ao disponibilizar programação de GPU através de Python, em vez de CUDA C++ puro. Isto torna a otimização ao nível do kernel acessível a ML engineers, e não apenas a especialistas em GPUs. A maioria das otimizações apresentadas mais adiante nesta parte (FlashAttention, kernels fundidos, PagedAttention) consiste em kernels melhores ou em formas mais inteligentes de orquestrar os lançamentos de kernels.

A fusão de kernels combina operações sequenciais num único kernel GPU e evita escritas intermédias na HBM. Entre as fusões comuns encontram-se a projeção QKV, attention com softmax, add com RMSNorm (FlashNorm) e a ativação SwiGLU (DeepFusionKernel). A Triton torna estes kernels acessíveis através de Python. Os ganhos exatos no número de launches e na utilização dependem do grafo do modelo, do compilador, da GPU e do serving framework; por isso, faça profiling da stack em produção em vez de assumir uma percentagem universal.

11. FlashAttention: dividir a attention em tiles para caber na SRAM

A attention standard materializa a matriz de attention completa $N \times N$ na HBM, o que consome $O(N^2)$ de memória e gera muito tráfego de memória. A ideia por detrás da FlashAttention é nunca materializar esta matriz. A técnica divide as matrizes Q, K e V em blocos que cabem na SRAM, calcula a attention parcial dentro de cada tile e combina os resultados através de um softmax online (acompanhando incrementalmente o máximo e a soma acumulados entre blocos). O consumo de memória passa de $O(N^2)$ para $O(N)$ e as leituras da HBM diminuem uma ordem de grandeza.

Cada versão visa o bottleneck da sua geração de GPU:

• FlashAttention v1 (A100, 2022) demonstrou que a combinação de tiling com softmax online funciona. O artigo reportou um speedup de 2–4x face à attention standard, mas apenas 25–40% de utilização da GPU, porque o escalonamento dos kernels deixava muitos SM inativos.
• FlashAttention v2 (A100, 2023) reformulou o paralelismo para dividir o trabalho pela dimensão da sequência, em vez de pelo batch e pelas heads. Atingiu 50–73% de utilização na A100, sendo aproximadamente 2x mais rápida do que a v1.
• FlashAttention v3 (H100 Hopper, 2024) introduziu warp specialization (warps separados para movimentação de dados e cálculo) e pipelining GEMM-softmax para sobrepor carregamentos de memória ao cálculo. O artigo reporta até 740 TFLOPS/s em FP16 (75% de utilização) e perto de 1,2 PFLOPS/s em FP8 na H100. Teve destaque no NeurIPS 2024.
• FlashAttention v4 (B200 Blackwell, 2026) aborda um novo bottleneck: na Blackwell, o throughput dos tensor cores aumenta tão rapidamente que as operações que não são matmul (exponenciais do softmax e reescala) se tornam o fator limitante. A FA4 emula a exponencial por software, utilizando aproximações polinomiais em unidades FMA, aplica reescala condicional para reduzir o overhead e armazena os valores intermédios na memória tensor dedicada da Blackwell (TMEM), em vez de os guardar em registos. O artigo reporta cerca de 1,6 PFLOPS na B200 em BF16, 1,3x mais rápida do que a cuDNN 9.13 e 2,7x mais rápida do que a Triton nos testes realizados.

12. FlashDecoding: paralelizar o bottleneck do decode

A FlashAttention standard mantém a GPU ocupada dividindo o trabalho pelo batch size e pelo query length. Durante o decode, o modelo gera exatamente 1 token de cada vez (query length = 1). Se o produto do batch size pelo número de attention heads for inferior ao número total de SM da GPU (108 numa A100), a maior parte da GPU fica inativa enquanto algumas unidades percorrem sequencialmente o histórico de tokens.

FlashDecoding resolve este problema ao adicionar uma nova dimensão de paralelização: o próprio comprimento da sequência KV. Divide a cache KV em blocos mais pequenos e distribui-os por todos os processadores da GPU que, de outro modo, estariam inativos, para serem avaliados em paralelo; em seguida, combina os cálculos parciais através de uma redução log-sum-exp.

No benchmark batch-one do Stanford com o CodeLlama-34B, para comprimentos de sequência entre 512 e 64K tokens, o FlashDecoding atingiu até 8x de aceleração de ponta a ponta face às baselines testadas e manteve a latência da atenção praticamente constante até aos 64K. Este resultado está limitado ao hardware e ao benchmark em questão, não constituindo uma garantia geral para a descodificação.

13. Batching contínuo vs batching estático

O batching estático espera que todas as sequências de um batch terminem antes de iniciar o seguinte, pelo que as sequências curtas desperdiçam ciclos da GPU enquanto ficam inativas depois de atingirem o fim da sequência. O batching contínuo (introduzido pelo artigo da Orca, OSDI 2022) opera ao nível de cada iteração: em cada passo de descodificação, as sequências concluídas são removidas e são inseridas novas sequências.

No benchmark da Anyscale com o OPT-13B, o batching estático otimizado atingiu 4x o seu baseline ingénuo, o batching contínuo atingiu 8x e o vLLM, com batching contínuo e PagedAttention, atingiu 23x (Anyscale, 2023). O batching contínuo também aumenta a pressão sobre a alocação da KV, razão pela qual é frequentemente combinado com gestão de memória paginada.

14. PagedAttention: memória virtual para a cache KV

O PagedAttention do vLLM aplica a ideia de memória virtual dos sistemas operativos à gestão da cache KV. A cache KV é dividida em blocos de tamanho fixo (normalmente 16 tokens), os blocos são alocados conforme os tokens são gerados e as posições lógicas (sequenciais) são mapeadas para localizações físicas (dispersas) na memória através de tabelas de blocos. Vários pedidos que partilhem um prefixo (prompts de sistema, beam search) podem apontar para os mesmos blocos físicos.

Os sistemas anteriores desperdiçavam 60–80% da memória da cache KV devido à fragmentação e à pré-alocação. O PagedAttention reduz esse valor para <4%, permitindo aumentar o débito em 2–4x com a mesma latência e até 24x face ao HuggingFace Transformers (vLLM Blog, 2023).

15. Descodificação especulativa: vários tokens por passagem forward

Na descodificação especulativa, um modelo draft pequeno gera $K$ tokens candidatos e, em seguida, o modelo target grande atribui pontuações a todas as posições $K$ numa única passagem forward. O descodificador aceita os tokens do modelo draft da esquerda para a direita, com probabilidades derivadas das distribuições do modelo target e do modelo draft. Após a primeira rejeição, faz uma amostragem de correção a partir da distribuição target residual e descarta os restantes tokens do modelo draft. Este passo modificado de amostragem por rejeição preserva a distribuição de saída do modelo target dentro das limitações numéricas do hardware; a correspondência exata dos tokens, por si só, não o garante.

O ganho é mais plausível com batches de serving pequenos e comprimentos de draft curtos, quando o scoring do draft é dominado pelo tráfego de pesos, KV-cache ou comunicação, e não pelo compute adicional dos tokens. O artigo original sobre speculative sampling reportou um speedup de descodificação de 2–2,5x na configuração Chinchilla de 70B testada; o EAGLE-3 reportou até 6,5x nos seus testes. Entre as variantes contam-se o Medusa (cabeças de previsão adicionais, sem um modelo separado), o prompt lookup decoding (correspondência de n-gramas com o input, sem uma passagem forward separada pelo draft model) e o EAGLE (extrapolação ao nível das features).

Com batches grandes, o trabalho adicional de geração e verificação do draft pode eliminar o ganho. A speculative decoding é mais promissora quando o serving batch é suficientemente pequeno e a aceitação do draft é elevada; faça benchmark ao ciclo completo de serving, e não apenas ao kernel de verificação.

16. Cache de prefixos e reutilização do KV cache

Em vez de descartar o KV cache quando um pedido termina, o cache de prefixos mantém-no disponível para reutilização em novos pedidos que partilhem os mesmos tokens de prefixo. Isto elimina prefill redundante para system prompts, exemplos few-shot, contexto RAG e histórico de conversas multi-turno.

O Automatic Prefix Caching do vLLM calcula hashes dos blocos KV e utiliza uma tabela hash global para pesquisa. O RadixAttention do SGLang mantém uma árvore radix de tensores KV em cache, com granularidade ao nível dos tokens. Ambos dependem de prefixos repetidos e idênticos ao nível dos tokens; por isso, reporte a hit rate juntamente com a latência ou o throughput.

17. Streaming na prática

O streaming envia os tokens para o cliente à medida que são gerados, em vez de esperar pela resposta completa. Muitos frameworks de serving expõem esta funcionalidade através de Server-Sent Events: o cliente abre uma ligação HTTP de longa duração e o servidor envia cada token ou batch de tokens como um evento data:. O TTFT determina quando o utilizador vê os primeiros resultados; o TPOT contribui para determinar quão fluida é a experiência. Defina o objetivo através de testes do produto e do modelo de interação escolhido.

No lado do cliente, o streaming obriga a tomar decisões de buffering. Renderizar token a token pode causar instabilidade visual, sobretudo com Markdown ou blocos de código que precisam de contexto de vários tokens para serem formatados corretamente. Os padrões comuns são o buffering ao nível das palavras (acumular tokens até encontrar um limite de whitespace), o buffering ao nível das linhas (esperar por uma nova linha antes de renderizar) e o buffering adaptativo (renderizar imediatamente prosa e aplicar buffering a blocos de código). Na OpenAI Chat Completions API, stream_options: {"include_usage": true} adiciona um chunk final de usage antes da mensagem data: [DONE]. Os servidores compatíveis com OpenAI podem comportar-se de forma diferente, por isso valide a implementação selecionada.

O Chunked prefill é uma forma de evitar que prefills longos bloqueiem a entrega de tokens a utilizadores concorrentes. O scheduling com prioridade ao decode pode proteger os pedidos em curso, enquanto o serving desagregado isola o prefill e o decode em pools de GPU separados.

Parte IV — Arquitetura do modelo

A arquitetura define a pegada de memória, o comportamento da atenção e a dinâmica de treino que as secções de serving e treino têm de acomodar.

18. Fundamentos da arquitetura Transformer

Um transformer moderno apenas com decoder (GPT, Llama) é composto por uma pilha de camadas idênticas, cada uma com dois sub-blocos: atenção e feed-forward. Cada sub-bloco é envolvido por uma ligação residual e normalização. Os principais componentes são:

A atenção multi-head permite que cada token atribua pesos à informação dos tokens visíveis de acordo com a máscara de atenção. A entrada é projetada em três matrizes: Queries (o que estou a procurar?), Keys (o que contenho?) e Values (que informação transporto?). Os scores de atenção são então calculados como:

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

O produto escalar $QK^T$ mede a semelhança entre cada par de tokens. Dividir por $\sqrt{d_k}$ impede que os produtos escalares cresçam demasiado (o que faria com que a softmax entrasse em regiões com gradientes que tendem para zero). A softmax converte os scores em probabilidades, e a multiplicação por $V$ produz uma combinação ponderada dos vetores de valores. Executar este processo em paralelo em várias heads permite ao modelo prestar atenção a relações diferentes em simultâneo (uma head para sintaxe, outra para resolução de correferências, e assim por diante).

A Feed-Forward Network (FFN) transforma cada representação de token de forma independente, depois de a atenção misturar informação entre tokens. Os LLM modernos utilizam frequentemente SwiGLU em vez da FFN original com ReLU e duas matrizes:

$\text{SwiGLU}(x) = \left(\text{Swish}(xW_{gate}) \odot xW_{up}\right)W_{down}$

A SwiGLU tem três matrizes de pesos, contra duas numa FFN com ReLU, e utiliza a função Swish suave. Llama, Mistral e Qwen utilizam-na; Gemma utiliza uma GeGLU aproximada. A regra familiar dos dois terços aplica-se a um bloco convencional de MHA completa com $d_{ff} \approx 4d$: as duas matrizes da FFN contribuem com cerca de $8d^2$ parâmetros, contra cerca de $4d^2$ na atenção. Não é uma estimativa geral para arquiteturas SwiGLU/GQA. No Llama 3 8B, $d=4{,}096$, $d_{ff}=14{,}336$ e oito heads de key/value fazem com que a FFN tenha $3d \times d_{ff} \approx 176$M parâmetros por camada, contra cerca de 42M parâmetros das projeções de atenção: cerca de 81% desses pesos de projeção, antes dos embeddings e da normalização.

As ligações residuais adicionam a saída de cada sub-bloco à sua entrada: $\text{Output} = \text{Input} + \text{Sublayer}(\text{Input})$. O caminho de atalho melhora a propagação do sinal e dos gradientes através de pilhas profundas.

A RMSNorm é comum nas famílias modernas de LLM. A LayerNorm recentra os valores subtraindo a média e redimensiona-os pelo desvio-padrão. A RMSNorm dispensa a subtração da média e apenas redimensiona os valores; o artigo reporta acelerações de 7–64% nos modelos testados, sem penalização de desempenho nessas experiências. A colocação pre-norm, que normaliza antes da atenção ou da FFN, também é comum porque melhora a estabilidade dos gradientes.

Estimativa do número de parâmetros para um modelo apenas com decoder:

$\text{Total} \approx V \times d + 12 \times L \times d^2$

onde $V$ é o tamanho do vocabulário, $d$ é a dimensão oculta e $L$ é o número de camadas. O termo $V \times d$ corresponde à matriz de embeddings de entrada; o termo $12 \times d^2$ aproxima os pesos da atenção e da FFN em cada camada. Para o Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$), a estimativa é de cerca de $0.53B + 6.44B = 6.97B$ parâmetros. O total publicado de 8,03B é superior porque a aproximação omite detalhes arquiteturais, como a largura exata da FFN e a projeção de saída separada.

19. Modelos apenas com decoder para geração de uso geral

O Transformer original (2017) tinha um encoder e um decoder. Desde então, o campo dividiu-se em três famílias arquiteturais, e uma delas tornou-se o padrão da IA generativa.

Os modelos apenas com encoder (BERT, RoBERTa) usam atenção bidirecional: cada token atende a todos os outros tokens em ambas as direções. Isto produz representações ricas para tarefas de compreensão (classificação, NER, similaridade semântica), mas não permite gerar texto de forma autoregressiva. Os modelos apenas com encoder continuam a ser comuns como backbone de modelos de embeddings, rerankers e classificadores leves (por exemplo, os routers baseados em BERT no RouteLLM).

Os modelos encoder-decoder (T5, BART, o Transformer original) separam a compreensão da geração. O encoder processa toda a entrada com atenção bidirecional; em seguida, o decoder gera a saída de forma autoregressiva, enquanto atende às representações do encoder através de cross-attention. Isto oferecia uma vantagem natural em tarefas sequence-to-sequence, como a tradução, nas quais a entrada e a saída são sequências diferentes. O T5 da Google mostrou que qualquer tarefa de NLP podia ser formulada como text-to-text, e os modelos encoder-decoder continuam a suportar alguns sistemas especializados (Whisper para reconhecimento de fala, FLAN-T5 para seguir instruções).

Os modelos apenas com decoder (GPT, Llama, Mistral, Gemini) usam atenção causal (unidirecional): cada token atende apenas aos tokens anteriores. São comuns na geração de texto de uso geral porque um único objetivo de language model causal escala sobre texto não emparelhado, enquanto, durante a inferência, as instruções, as demonstrações few-shot e a consulta são tratadas como tokens num único prefixo. O bloco decoder repetido também evita uma stack de encoders separada e um caminho de cross-attention. Os modelos encoder-decoder continuam a ser úteis quando uma tarefa beneficia de codificar a entrada separadamente e gerar com base nessa representação, incluindo tradução e reconhecimento de fala.

20. Mixture of experts

O MoE substitui o FFN denso de cada camada do transformer por vários expert FFNs mais pequenos, além de um gating router leve. O router calcula uma pontuação para cada expert (normalmente, um softmax sobre projeções lineares aprendidas) e seleciona os $k$ experts com maior pontuação por token. Apenas os experts ativados fazem computação, pelo que um modelo pode ter uma capacidade total enorme, mantendo baixo o custo por token. Trata-se de computação condicional esparsa: o total de parâmetros determina o que o modelo pode representar; os parâmetros ativos determinam quanto custa executá-lo.

O shared expert no DeepSeek-V3 é ativado para todos os tokens. Fornece uma representação de base sobre a qual os routed experts se podem especializar.

O treino de MoE tem três problemas recorrentes: desequilíbrio da carga, colapso dos especialistas e overhead de comunicação para paralelismo de especialistas. Os modelos MoE tradicionais adicionam uma loss auxiliar para penalizar o routing desequilibrado, mas essa loss pode competir com o objetivo principal. O DeepSeek-V3 utiliza sobretudo uma estratégia sem loss auxiliar, aplicada ao nível do batch: termos de bias fora da backpropagation reduzem o score dos especialistas sobrecarregados e aumentam o score dos especialistas subutilizados. Também aplica uma loss de equilíbrio complementar, extremamente pequena e ao nível da sequência, para evitar um desequilíbrio extremo dentro de uma sequência. O artigo relata um melhor equilíbrio do routing sem o compromisso associado à loss auxiliar principal na sua configuração.

21. Tokenização: BPE, SentencePiece e tiktoken

Os LLM não veem texto. Veem sequências de IDs de tokens inteiros. Um tokenizer divide o texto bruto em tokens (subword pieces) e associa cada um a um ID. A escolha do tokenizer afeta a qualidade do modelo, a velocidade de inferência e a equidade multilingue.

O Byte Pair Encoding (BPE) é o algoritmo mais comum. Iterativamente, funde os pares adjacentes mais frequentes no corpus de treino. Um exemplo simplificado:

1. Começar com um vocabulário ao nível dos caracteres: [l, o, w, e, r, _]
2. O par mais frequente é (l, o) → fundi-lo em lo → vocabulário: [l, o, w, e, r, _, lo]
3. O par seguinte mais frequente é (lo, w) → fundi-lo em low → o vocabulário adiciona low
4. Continuar até o vocabulário atingir o tamanho pretendido (por exemplo, 128K tokens)

Palavras comuns como “the” tornam-se tokens únicos, enquanto palavras raras como “defenestration” são divididas em subword pieces como ["def", "en", "est", "ration"]. O compromisso é entre o tamanho do vocabulário e o comprimento da sequência.

Três implementações de tokenizers abrangem a maior parte dos usos em produção:

• SentencePiece é treinado diretamente sobre texto Unicode bruto, sem um pre-tokenizer específico de cada língua. Preserva os espaços através do meta-símbolo ▁ e pode, opcionalmente, recorrer a tokens de bytes UTF-8. Suporta modelos BPE e unigram e é utilizado pelo Llama 1/2, T5 e Mistral.
• tiktoken é o tokenizer da OpenAI, baseado em Rust e que utiliza BPE ao nível dos bytes. No benchmark GPT-2 publicado, foi 3–6x mais rápido do que a configuração GPT2TokenizerFast testada. O Llama 3 mudou do SentencePiece para o algoritmo do tiktoken.
• Hugging Face Tokenizers é uma biblioteca amplamente utilizada, baseada em Rust, que suporta BPE, WordPiece e Unigram.

A fertilidade mede quantos tokens um tokenizer produz por palavra ou por outra unidade de texto escolhida. Varia consoante o tokenizer exato, a língua, o sistema de escrita, a normalização, o domínio e a amostra. Meça-a com tráfego representativo, em vez de extrapolar a partir de um único tokenizer ou de uma única língua.

22. Janelas de contexto e codificações posicionais

A janela de contexto é o número máximo de tokens que um modelo consegue processar numa única passagem forward. Este valor aumentou significativamente:

A self-attention não mascarada é equivariantes a permutações: se reordenarmos os tokens de entrada, as saídas são reordenadas da mesma forma. A máscara causal de um decoder já limita cada token ao seu prefixo, pelo que inverter uma frase não produz estados ocultos idênticos. As codificações posicionais adicionam informação explícita sobre a posição e a distância relativa dentro desse prefixo visível.

Existem três abordagens comuns:

• RoPE (Rotary Position Embeddings) roda os vetores de query e key por ângulos dependentes da posição, fazendo com que o seu produto escalar dependa da posição relativa. O conteúdo do token continua a determinar o score de atenção; a RoPE adiciona informação posicional sem embeddings de posição absoluta aprendidos. É utilizada por famílias de modelos open source, incluindo Llama, Mistral e Qwen.

• ALiBi (Attention with Linear Biases) dispensa alterações aos embeddings e adiciona diretamente uma penalização aos scores de atenção: quanto mais afastados estiverem dois tokens, maior será o bias negativo. Não tem parâmetros posicionais aprendidos. No artigo original, um modelo de 1,3B treinado com sequências de 1.024 tokens teve um desempenho comparável, com 2.048 tokens, ao de um modelo com posições sinusoidais treinado com 2.048 tokens. O comportamento para além dos modelos e comprimentos testados no artigo depende do modelo.

• YaRN (Yet another RoPE extensioN) estende um modelo RoPE para além do contexto de treino. Agrupa as dimensões de frequência em três categorias e aplica uma escala diferente a cada uma. O artigo reporta 10x menos tokens de fine-tuning e 2,5x menos passos de treino do que a sua baseline de interpolação posicional.

Parte V — Treino e alinhamento

Esta parte distingue o objetivo que cria capacidades, as técnicas que permitem adaptar o treino ao hardware disponível e os métodos que moldam posteriormente o comportamento de um modelo.

23. Pretraining, fine-tuning e alinhamento

O pretraining consiste na previsão auto-supervisionada do token seguinte sobre um corpus de grandes dimensões. O seu custo computacional abrange várias ordens de grandeza; o Llama 3 405B, por exemplo, utilizou $3.8 \times 10^{25}$ FLOPs. O fine-tuning supervisionado (SFT) adapta o modelo pré-treinado a dados anotados específicos da tarefa. O RLHF / RLAIF utiliza dados de preferências para moldar o comportamento: um pipeline convencional de RLHF recolhe comparações, treina um modelo de recompensa e, em seguida, otimiza a policy. O RLAIF substitui parte das avaliações humanas por feedback gerado por IA.

A computação depende do tamanho do modelo, do comprimento da sequência, do volume de dados, do otimizador e do método. O PPO também mantém mais estado do modelo do que o SFT, porque uma configuração típica inclui modelos de política, de referência, de recompensa e crítico. Abordei o enquadramento completo da decisão de fine-tuning no Guia de fine-tuning de LLMs.

24. LoRA e QLoRA: fine-tuning eficiente em parâmetros

LoRA congela os pesos pré-treinados e injeta matrizes treináveis de baixa ordem $A$ ($r \times k$) e $B$ ($d \times r$), de forma que o peso atualizado seja $W_0 + BA$. O artigo sobre LoRA reduziu o GPT-3 175B a cerca de 18 milhões de parâmetros treináveis na configuração testada. O rank é um parâmetro de afinação, não uma regra determinada pela complexidade da tarefa; selecione-o através de uma varredura de qualidade e memória. Os adapters LoRA podem ser fundidos nos pesos base após o treino, evitando um caminho separado para o adapter durante a inferência.

QLoRA carrega o modelo base com quantização NF4 de 4 bits, enquanto treina os adapters LoRA em BF16. O NormalFloat4 coloca mais níveis de quantização perto de zero, onde a densidade dos pesos é maior. O artigo fez fine-tuning de um modelo de 65B numa única GPU de 48 GB e reportou resultados próximos dos seus baselines de 16 bits. Os compromissos entre tempo de execução e memória dependem da stack testada.

25. Treino com precisão mista

Cada formato de vírgula flutuante distribui os seus bits por três campos: sinal (sempre 1 bit), expoente (define o intervalo dinâmico) e mantissa (define a precisão). Mais bits no expoente significam um intervalo mais amplo de magnitudes representáveis; mais bits na mantissa significam distinções mais finas entre valores próximos. Os formatos inteiros não têm expoente e representam apenas números inteiros igualmente espaçados dentro de um intervalo fixo.

O BF16 tem o mesmo intervalo que o FP32 porque o intervalo é definido pelo campo do expoente, e o BF16 mantém os 8 bits do expoente do FP32. Em contrapartida, abdica de bits da mantissa (7 em vez de 23), trocando precisão por uma redução de 2x na memória e evitando muitos dos problemas de intervalo que afectam o treino em FP16. O FP16 tem apenas 5 bits de expoente, limitando o seu intervalo finito a cerca de 65K. Muitos gradientes são, pelo contrário, demasiado pequenos para FP16 e sofrem underflow, aproximando-se de zero. O loss scaling multiplica a loss antes da retropropagação, para que esses gradientes permaneçam representáveis, e depois remove essa escala antes do passo do optimizador; o scaling dinâmico reduz o factor se ocorrer overflow. O maior intervalo do expoente do BF16 evita geralmente este requisito.

Os formatos inteiros são pouco comuns na aritmética principal do treino, porque a retropropagação necessita de um intervalo dinâmico amplo. São amplamente utilizados em inferência, onde os pesos congelados podem ser mapeados para escalas calibradas. A quantização INT4 dos pesos reduz um modelo 7B de cerca de 14 GB para 3,5 GB antes do overhead de runtime; a qualidade tem de ser medida para o modelo e o método escolhidos.

O treino em FP8 no H100 através do Transformer Engine usa E4M3 quando a precisão é importante e E5M2 quando é necessário um intervalo mais amplo. O artigo sobre FP8-LM relata que a sua framework de precisão mista treinou o GPT-175B 75% mais depressa do que a baseline Megatron-LM em BF16 e 37% mais depressa do que o NVIDIA Transformer Engine, na configuração H100 testada. O DeepSeek-V3 utilizou precisão mista em FP8 e reportou cerca de $5,6 milhões de dólares em custos de computação equivalentes a aluguer para a sua execução final de treino, excluindo I&D e infra-estrutura.

26. Gradient checkpointing

Cada camada da passagem forward produz uma saída intermédia chamada activation:

$\text{Input} \rightarrow [\text{Layer 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Layer 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Layer 3}] \rightarrow \text{output}$

Normalmente, todas as activations têm de permanecer em memória, porque a retropropagação precisa delas para calcular os gradientes. Num transformer profundo, as activations armazenadas podem ocupar mais memória do que os próprios pesos do modelo.

O gradient checkpointing troca computação por memória, descartando a maioria dessas activations e recalculando-as durante a retropropagação. A estratégia padrão (Chen et al., 2016) divide uma rede com $n$ camadas em $\sqrt{n}$ segmentos equidistantes e guarda apenas a activation de fronteira de cada segmento. Essas fronteiras guardadas são os «checkpoints». Todas as activations intermédias de um segmento são descartadas imediatamente.

Quando a passagem backward chega a uma camada dentro de um segmento, as suas activations são recalculadas a partir do checkpoint mais próximo. Na estratégia com segmentos equidistantes, a memória ocupada pelas activations guardadas diminui de $O(n)$ para $O(\sqrt{n})$. A poupança de memória efectiva e o overhead de recomputação dependem do modelo, das fronteiras dos checkpoints, do comprimento da sequência, do framework e da implementação; por isso, meça ambos na execução de treino alvo. O FlashAttention aplica o mesmo princípio dentro da attention, não materializando a matriz de attention completa. Active-o no HuggingFace com gradient_checkpointing=True.

27. Fases do DeepSpeed ZeRO

No paralelismo de dados standard, cada GPU mantém uma cópia completa dos pesos do modelo, dos gradientes e dos estados do optimizer. Com o Adam, cada parâmetro ocupa 2 bytes para o peso FP16 + 4 bytes para o peso-mestre FP32 + 4 bytes para o momentum + 4 bytes para a variância + 2 bytes para o gradiente, ou seja, 16 bytes por parâmetro. Um modelo com 7.5B parâmetros precisa de ~120 GB por GPU, e todas as GPUs armazenam a mesma informação. Em 64 GPUs, isso corresponde a 64 cópias idênticas de 120 GB. Um desperdício considerável.

O DeepSpeed ZeRO (Zero Redundancy Optimizer) elimina esta duplicação, distribuindo estes componentes pelas GPUs em vez de os replicar:

• Fase 1 — particionar os estados do optimizer. Cada GPU armazena apenas 1/N dos estados do optimizer (os pesos-mestre FP32 e o primeiro e segundo momentos do Adam, 12 bytes/parâmetro). Quando uma GPU precisa de actualizar um peso, actualiza apenas a sua fracção e transmite o resultado. Sob os pressupostos abaixo, a memória diminui de ~120 GB para ~41.3 GB por GPU.
• Fase 2 — particionar também os gradientes. Os gradientes (2 bytes/parâmetro) deixam de ser sujeitos a all-reduce para todas as GPUs. Cada GPU recebe apenas a fracção de gradiente de que precisa através de reduce-scatter. Sob os mesmos pressupostos, a memória diminui para ~28.1 GB por GPU.
• Fase 3 — particionar também os pesos do modelo. Cada GPU mantém apenas 1/N dos pesos FP16. Antes da passagem forward ou backward de cada camada, a GPU chama all-gather para reconstruir temporariamente os pesos completos da camada a partir das restantes GPUs, efectua os cálculos e descarta os pesos reunidos. Sob os mesmos pressupostos, a memória diminui para ~15.0 GB por GPU.

Estes são valores aproximados do estado do modelo para um modelo com 7.5B parâmetros em 8 GPUs (world size $N=8$), com pesos e gradientes FP16 e pesos mestre, momentum e variância do Adam em FP32. Excluem ativações, buffers temporários de all-gather, fragmentação do allocator e overhead da framework/runtime. O limite do cálculo é $7.5B \times$ bytes por parâmetro, sendo cada estado dividido por $N$ apenas quando a tabela o assinala como particionado.

O compromisso é a comunicação. O Estágio 1 acrescenta overhead mínimo e o Estágio 2 substitui all-reduce por reduce-scatter, com um custo semelhante. O Estágio 3 necessita de chamadas all-gather antes de cada camada, tanto no forward como no backward, correspondendo a aproximadamente 1,5x o volume de comunicação da paralelização de dados normal.

ZeRO-Infinity prolonga o Estágio 3, fazendo offload dos estados particionados para a RAM da CPU e até para SSDs NVMe, o que pode tornar possível treinar modelos com biliões de parâmetros em clusters de GPUs limitados. O offload para armazenamento acrescenta custos de transferência através de PCIe e do armazenamento; o impacto medido depende da unidade, da topologia PCIe, do particionamento, do prefetch, da sobreposição de transferências e da carga de trabalho. Utilize-o para satisfazer requisitos de capacidade, em vez de assumir uma desaceleração fixa, e faça profiling da configuração-alvo.

28. FSDP: sharding nativo do PyTorch

Fully Sharded Data Parallel (FSDP) é a resposta integrada do PyTorch ao DeepSpeed ZeRO-3. Faz sharding dos parâmetros, gradientes e estados do otimizador entre GPUs, com a mesma ideia fundamental. A mecânica para cada camada consiste num ciclo simples:

1. All-gather dos parâmetros completos de todas as GPUs (reconstruir temporariamente a camada completa).
2. Calcular o forward ou backward dessa camada.
3. Libertar imediatamente os parâmetros obtidos. Cada GPU mantém apenas o seu próprio shard.
4. Reduce-scatter dos gradientes, para que cada GPU receba apenas a sua fatia de gradientes atribuída.

Como o FSDP é nativo do PyTorch, integra-se diretamente com as ferramentas de debugging, profilers e torch.compile do PyTorch. O desempenho face ao DeepSpeed ZeRO-3 depende da política de wrapping, da topologia de comunicação, das definições de offload e do tamanho do modelo; por isso, compare-os no mesmo cluster.

FSDP2 (2024–2025) é uma reescrita que melhora a integração com torch.compile para permitir uma melhor fusão de kernels, acrescenta suporte para treino em FP8 através do TorchAO e simplifica a API. Tanto o FSDP como o DeepSpeed estão disponíveis através do HuggingFace Accelerate, que permite alternar entre ambos alterando apenas uma opção de configuração.

29. Leis de escala e a armadilha da Chinchilla

A escala de Chinchilla (DeepMind, 2022) identificou, nas suas condições, uma alocação quase ótima em termos de computação de cerca de 20 tokens de treino por parâmetro. Esse objetivo não inclui o custo de serving a jusante. Se um modelo mais pequeno, treinado com mais dados, atingir a qualidade necessária, poderá custar menos ao longo de um ciclo de vida de inferência de grande volume.

Uma estratégia para reduzir o custo do ciclo de vida consiste em treinar um modelo mais pequeno com muito mais dados:

Este é o rácio apresentado de tokens por parâmetro dividido pelo valor aproximado de 20 tokens por parâmetro indicado no artigo da Chinchilla. Trata-se de um rácio descritivo, não de um multiplicador de qualidade ou custo medido.

Num modelo servido em grande volume, investir mais computação no treino de um modelo mais pequeno pode reduzir o custo do ciclo de vida. O Llama 3 8B ilustra esta estratégia, mas a sua vantagem depende da qualidade necessária e do volume de inferência previsto. «Chinchilla-optimal» refere-se à eficiência da computação de treino, que é um objetivo diferente do custo do ciclo de vida.

30. RLHF, DPO, GRPO e o panorama do alinhamento

O alinhamento orienta um modelo pré-treinado para seguir as instruções, preferências e políticas de segurança pretendidas. Por si só, não garante veracidade nem um comportamento seguro. Os métodos abaixo estabelecem compromissos entre a complexidade de implementação, os requisitos de dados, a exploração e a estabilidade do treino.

O pipeline clássico de RLHF: SFT → recolher pares de preferências humanas → treinar um modelo de recompensa com esses pares → fazer fine-tuning da policy com PPO (Proximal Policy Optimization). O PPO mantém 4 cópias do modelo em memória em simultâneo (policy, referência, modelo critic/value e modelo de recompensa) e é sensível aos hiperparâmetros. Também é suscetível a reward hacking, em que o modelo explora particularidades do modelo de recompensa — por exemplo, respostas verbosas e com um tom confiante — em vez de melhorar genuinamente a qualidade.

DPO (Direct Preference Optimization) dispensa o modelo de recompensa aprendido e o ciclo de RL online, otimizando diretamente uma loss sobre pares de preferências. Isto simplifica o pipeline de treino. O DPO standard é offline: treina com um dataset fixo e não explora novas respostas durante o ciclo de atualização. A relevância desta limitação depende da tarefa e da cobertura dos dados.

GRPO (Group Relative Policy Optimization, DeepSeek) elimina o critic aprendido do PPO, gerando várias completions por prompt e usando recompensas relativas ao grupo como baseline. Isto reduz a carga de estados do modelo face a uma configuração típica de PPO. Ao contrário do DPO, o GRPO é on-policy: o modelo gera respostas novas durante o treino. O DeepSeek-R1 combina GRPO com RLVR (reinforcement learning from verifiable rewards), usando verificações como respostas de problemas matemáticos, compilação de código e testes unitários. Estas recompensas são mais fáceis de auditar do que um score de preferências aprendido, mas testes incompletos e objetivos proxy podem continuar a ser explorados.

31. Distillation: comprimir conhecimento entre modelos

A knowledge distillation transfere capacidades de um teacher de grandes dimensões para um student mais pequeno. A distillation baseada em logits treina o student para corresponder à distribuição de saída do teacher. Na distillation baseada em dados, o teacher gera exemplos com os quais o student faz fine-tuning. Os métodos baseados em dados são comuns para LLMs porque podem funcionar entre arquiteturas e com teachers acessíveis apenas através de APIs, mas o seu valor é limitado pela qualidade do teacher, pela cobertura dos dados, pela filtragem e pelo custo de geração.

O DeepSeek-R1 selecionou uma mistura de aproximadamente 800 000 exemplos — cerca de 600 000 relacionados com raciocínio e 200 000 não relacionados com raciocínio — e utilizou-a para fazer distillation de modelos Qwen2.5 e Llama 3 com entre 1,5B e 70B parâmetros. Na avaliação do artigo:

• DeepSeek-R1-Distill-Qwen-32B obtém 72,6% no AIME 2024 e 94,3% no MATH-500, acima dos valores reportados no artigo para o OpenAI o1-mini.
• DeepSeek-R1-Distill-Qwen-7B obtém 55,5% no AIME 2024, acima do resultado do QwQ-32B-Preview apresentado no artigo, apesar de utilizar um modelo mais pequeno.

Nas experiências com modelos pequenos do DeepSeek-R1, a destilação superou o GRPO aplicado diretamente aos modelos base testados. Este resultado favorece a destilação nesta configuração; não estabelece uma hierarquia universal entre destilação e RL.

32. Geração de dados sintéticos

Os dados de treino gerados por LLM são utilizados segundo vários padrões recorrentes:

• Self-Instruct parte de um pequeno conjunto inicial de instruções escritas por humanos: o LLM gera novas instruções, entradas e saídas, que são filtradas e adicionadas novamente ao conjunto. O projeto Alpaca utilizou 52 000 exemplos gerados a partir de 175 sementes. Stanford reportou um custo de geração de dados inferior a $500 and fine-tuning under$100, o que colocou o custo inicial de reprodução abaixo de $600; a comparação com o GPT-3.5 foi uma avaliação limitada do projeto, não uma equivalência abrangente.
• Evol-Instruct (WizardLM) recebe instruções existentes e faz evoluir iterativamente a sua complexidade ao longo de vários eixos (adicionando restrições, aprofundando o raciocínio e tornando os problemas mais concretos), produzindo exemplos de treino progressivamente mais difíceis.
• O Phi-4 da Microsoft (14B) utilizou dados sintéticos em grande parte do pré-treino, incluindo geração, crítica, auto-revisão e inversão de instruções. O seu relatório técnico compara o desempenho resultante em STEM e programação com o de modelos maiores nos benchmarks selecionados.

O risco relevante neste contexto é o colapso do modelo: quando os modelos são treinados recursivamente com dados sintéticos de gerações anteriores, as caudas da distribuição original desaparecem progressivamente. O modelo sobrestima padrões comuns e perde variações raras, mas importantes (Shumailov et al., 2024). Um estudo independente da Ahrefs sobre classificação recolheu, em abril de 2025, uma página inglesa recém-detetada por domínio, num total de 900 000 páginas, e classificou 74,2% como contendo algum texto gerado por IA. Esse estudo da empresa não constitui um censo da Web. A mitigação começa pela combinação de dados sintéticos e reais, pela filtragem e pelo rastreio da linhagem, para que o material gerado recursivamente possa ser quantificado.

Parte VI — Escalonamento e disponibilização

Quando uma carga de trabalho deixa de caber num único dispositivo ou de cumprir o seu SLO, as decisões passam por determinar como dividir o trabalho, qual o runtime que disponibiliza os controlos necessários e se todos os pedidos precisam do mesmo modelo.

33. Quatro formas de paralelismo

Tensor Parallelism (TP) divide matrizes de pesos individuais entre GPUs e, normalmente, comunica após cada camada. Ligações intra-nó rápidas, como NVLink, tornam-no mais prático dentro de um nó. Mais shards reduzem a memória e a computação por dispositivo, mas aumentam a comunicação; por isso, selecione o grau com base num benchmark de latência.

Paralelismo de pipeline (PP) distribui sequencialmente as camadas por várias GPUs, transferindo as ativações entre estágios. O seu padrão de comunicação pode funcionar entre nós, mas as bolhas do pipeline e os tempos desiguais dos estágios reduzem a utilização. As implementações de grande escala combinam frequentemente TP dentro de um nó e PP entre nós.

Paralelismo de dados (DP) replica o modelo servido, de modo que cada réplica processa pedidos independentes sem comunicação entre réplicas por pedido. É eficiente quando o modelo cabe e o tráfego pode ser equilibrado. No treino, o DP é frequentemente combinado com ZeRO ou FSDP para fazer shard do estado.

Paralelismo de experts (EP) distribui os experts de um MoE por várias GPUs, usando comunicação all-to-all para encaminhar tokens. O desempenho depende do equilíbrio dos tokens, da colocação dos experts e da topologia de interligação; o tráfego all-to-all pode tornar-se o principal bottleneck.

Heurística inicial para escolher o paralelismo:

• O modelo cabe numa GPU: comece por réplicas independentes e meça a escalabilidade do DP.
• O modelo cabe num único nó: teste TP dentro do nó e, em seguida, replique o grupo se o tráfego o exigir.
• O modelo ocupa vários nós: teste uma combinação de TP e PP tendo em conta a interligação e o objetivo de latência.
• Mixture of experts: adicione EP apenas quando a colocação dos experts o exigir.

34. Comparação de frameworks de serving

vLLM disponibiliza alocação paginada de KV, continuous batching, uma API compatível com OpenAI e vários modos de paralelismo. O suporte de modelos e hardware muda frequentemente; valide, por isso, o modelo-alvo face à matriz de compatibilidade atual.

SGLang combina RadixAttention para reutilização de prefixos, um scheduler personalizado e geração estruturada. Os ganhos de throughput publicados dependem da carga de trabalho e da configuração; compare-o com vLLM e TensorRT-LLM usando prompts, outputs, hardware e SLOs idênticos.

TensorRT-LLM visa uma latência baixa por pedido através de fusão de CUDA graphs e otimização de kernels, com suporte nativo para FP8/FP4. Os valores publicados são específicos do hardware e do modelo. A contrapartida é uma curva de aprendizagem mais acentuada e uma superfície de deployment específica da NVIDIA.

TGI integra-se no ecossistema Hugging Face e suporta vários backends de hardware. Consulte o estado atual de manutenção e funcionalidades do repositório antes de o selecionar para um novo deployment.

Ollama privilegia um workflow local simples para modelos. Use-o pela conveniência no desenvolvimento; avalie outra stack de serving quando forem importantes a elevada concorrência ou o controlo explícito de SLOs.

llama.cpp é um runtime portátil em C/C++ com caminhos para ARM, x86, Metal, CUDA, ROCm e Vulkan. O GGUF suporta vários níveis de quantização. O desempenho varia bastante consoante o modelo, a quantização, o contexto e o backend; use a ferramenta de benchmark local para a máquina-alvo.

35. Seleção de GPUs para inferência

A tabela compara características de hardware publicadas. O suporte de precisão do fabricante não torna diretamente comparáveis os valores de pico de computação entre formatos; selecione primeiro com base no encaixe em memória e faça benchmark da carga de trabalho-alvo. Consulte separadamente os preços atuais na cloud, pois variam consoante o fornecedor, a região, o compromisso e a disponibilidade.

Selecione primeiro com base na capacidade de memória e, depois, no débito medido para o objetivo de latência. A capacidade de 141 GB da H200 pode simplificar algumas implementações de modelos de grande dimensão, enquanto a B200 acrescenta suporte para FP4, 180 GB de HBM3e e uma geração mais recente do NVLink. GPUs mais pequenas baseadas em GDDR podem ser económicas para modelos quantizados quando os limites de memória e de interligação são compatíveis com a carga de trabalho.

AWQ e GPTQ disponibilizam modelos de 4 bits através da desquantização das operações matriciais suportadas para um formato de computação como FP16 ou BF16. A compatibilidade e a velocidade continuam a depender da arquitetura do modelo, do formato de quantização, do backend de serving, do kernel e da GPU; por isso, consulte a matriz de suporte do backend e faça benchmark do artefacto exato. Hopper (H100/H200) e Ada (L40S/4090) aceleram nativamente FP8, e Blackwell (B200) acrescenta Tensor Cores com suporte nativo para FP4. Todas as GPUs listadas suportam operações matriciais INT8.

A descodificação de LLMs é frequentemente limitada pela largura de banda da memória, pelo que a capacidade e a largura de banda da HBM podem ser mais importantes do que os TFLOPS de pico em cargas de serving. Compare as GPUs mantendo constantes o modelo, a precisão, a distribuição do batch, o comprimento do contexto e o objetivo de latência.

36. Cascading e routing de modelos

O routing de modelos escolhe qual LLM trata cada consulta com base na complexidade ou capacidade previstas. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) reporta uma redução de 85% nos custos na sua configuração MT-Bench, mantendo 95% da qualidade de referência do GPT-4. A rentabilidade do routing depende dos preços atuais, da composição do tráfego, dos erros do router e do nível mínimo de qualidade.

Os routers vão desde classificadores leves a avaliadores baseados em LLMs. Cascading é a variante sequencial: uma consulta começa num modelo mais barato e escala para outro quando uma função de pontuação rejeita a resposta. FrugalGPT reporta até 98% de redução nos custos ou até 4% de aumento da precisão no conjunto de modelos avaliado. Um cascade de produção requer critérios de escalonamento calibrados e monitorização das consultas que o modelo barato aceita incorretamente.

Parte VII — Aplicações

As aplicações têm as suas próprias superfícies de falha. A recuperação pode falhar antes de a geração começar, os agentes podem escolher uma ação inválida e uma alteração ao prompt pode melhorar uma tarefa enquanto prejudica outra.

37. Modelos de embeddings vs modelos generativos

Os modelos de embeddings codificam texto em vetores de dimensão fixa que captam o significado semântico. Ao contrário dos modelos generativos, que produzem sequências de tokens, geram um único vetor denso para a entrada, normalmente com algumas centenas a vários milhares de dimensões. As suas arquiteturas de base incluem transformers bidirecionais apenas de encoder e modelos derivados de decoders, adaptados para aprendizagem de representações. Uma camada de pooling agrega frequentemente as representações por token num único vetor através de mean pooling, de um token especial de classificação ou de um método específico do modelo baseado no último token. O fine-tuning contrastivo aproxima textos semanticamente semelhantes e afasta textos diferentes.

Os sistemas de embeddings atuais abrangem diferentes necessidades de deployment. Qwen3-Embedding-8B permite configurar as dimensões de saída e suporta muitos idiomas. Gemini Embedding 2 aceita texto, imagens, vídeo, áudio e documentos. pplx-embed-v1-4B estuda embeddings densos de menor precisão. OpenAI text-embedding-3-large suporta embeddings mais curtos através do seu parâmetro dimensions. Estes são exemplos, não uma ordenação: avalie o idioma, a modalidade, a tarefa, a dimensão e o custo de serving num único conjunto de retrieval.

Matryoshka Representation Learning (MRL, Kusupati et al., NeurIPS 2022) torna flexíveis as dimensões dos embeddings. Com o nome inspirado nas bonecas russas de encaixe, o MRL estrutura um embedding de modo que as suas primeiras $m$ dimensões sejam tão informativas como as de um modelo treinado independentemente com $m$ dimensões. Durante o treino, o MRL agrega as losses sobre um conjunto $O(\log d)$ escolhido de dimensões de prefixo, normalmente metades sucessivas; o exemplo de 2048 dimensões do artigo usa $\{8, 16, \ldots, 1024, 2048\}$. A loss agregada leva as dimensões iniciais a transportar informação semântica geral, enquanto as dimensões posteriores acrescentam detalhes mais finos.

Depois do treino, um embedding MRL pode ser truncado para uma dimensão de prefixo suportada. A OpenAI indica que o text-embedding-3-large com 256 dimensões supera o text-embedding-ada-002 com 1.536 dimensões na comparação MTEB citada. Isto representa uma redução de 6x no armazenamento bruto dos vetores; a latência da pesquisa e o custo da base de dados também dependem do índice, dos metadados, da filtragem e do hardware.

O modelo de embeddings é um componente importante de um pipeline de RAG, juntamente com o parsing, o chunking, a pesquisa, o reranking e a geração. Se a evidência relevante não for recuperada, um gerador mais potente não consegue recuperá-la de forma fiável.

38. Arquitetura de RAG em produção

A Retrieval-Augmented Generation fornece a um LLM documentos recuperados no momento da query. Pode disponibilizar evidência atual ou privada que não existe nos pesos do modelo, mas a recuperação não garante que a resposta utilize essa evidência corretamente. Um sistema de RAG em produção é um pipeline com várias fases, e cada fase requer uma avaliação independente.

O pipeline de ingestão é executado offline. Os documentos em bruto (PDFs, HTML, Markdown, bases de dados) são primeiro analisados e convertidos em texto limpo, o que é mais difícil do que parece: só a análise de PDFs pode fazer perder tabelas, cabeçalhos e formatação. De seguida, o texto é dividido em chunks, que são incorporados e indexados de forma independente.

A divisão em chunks afeta tanto o recall da recuperação como o contexto disponível para o gerador. Os tamanhos adequados dependem da estrutura do documento, da granularidade das queries, dos limites do embedder e dos limites do reranker. As abordagens comuns incluem tamanho fixo com sobreposição, divisão recursiva ao longo das fronteiras do documento e chunking semântico por similaridade entre embeddings. Compare-as com etiquetas de relevância ao nível da página ou da secção, em vez de adotar universalmente um único intervalo de tokens.

Cada chunk é depois convertido em embedding com um modelo como os apresentados na Secção 37 e armazenado numa base de dados vetorial (Pinecone, Weaviate, Qdrant, pgvector, entre outras).

O pipeline de recuperação é executado no momento da query. Comece por estabelecer uma baseline mensurável e, em seguida, adicione etapas quando a análise de erros mostrar que estas resolvem uma falha real:

• A pesquisa híbrida combina recuperação vetorial densa com recuperação esparsa, como BM25, frequentemente agregadas através de Reciprocal Rank Fusion (RRF). A pesquisa densa lida com paráfrases semânticas; a pesquisa esparsa deteta identificadores exatos, códigos de erro e acrónimos. Os benchmarks dos fornecedores reportam melhorias face a baselines apenas vetoriais, mas a dimensão do ganho depende do corpus e das etiquetas de relevância.
• O reranking passa os candidatos recuperados por um modelo que atribui uma pontuação conjunta à query e ao documento. Isto pode melhorar a relevância ao nível mais fino, à custa de outra chamada ao modelo. O número de candidatos, o número retido e a latência devem ser afinados em conjunto. Abordei o pipeline completo com várias etapas em Building a Modern Search Ranking Stack.
• A transformação da query reescreve a query do utilizador antes da recuperação para melhorar o recall. O HyDE (Hypothetical Document Embeddings) faz com que o LLM gere uma resposta hipotética, que é depois convertida em embedding e usada na recuperação. A expansão multi-query gera várias formulações da mesma pergunta. O step-back prompting faz primeiro uma pergunta mais geral para obter um contexto mais abrangente.

Os modos de falha mais comuns são:

• Falha de recuperação — o documento correto existe, mas não é recuperado. Teste a divisão em chunks, a transformação da query, a pesquisa híbrida e a filtragem por metadados face à falha.
• Corrupção do contexto — os chunks irrelevantes recuperados induzem o LLM em erro. Teste o reranking, os filtros de contexto e conjuntos retidos mais pequenos.
• Lost-in-the-middle — nas configurações testadas de resposta a perguntas com vários documentos e de recuperação de pares chave-valor, Liu et al. concluíram que o desempenho das respostas era geralmente mais elevado quando a informação relevante aparecia perto do início ou do fim da entrada, e mais baixo quando aparecia no meio.

GraphRAG (Microsoft, 2024) complementa a recuperação vetorial com um grafo de entidades e relações extraído. Destina-se a perguntas ao nível do corpus e a perguntas centradas em relações, que a recuperação de chunks planos pode não conseguir responder. A contrapartida é o trabalho adicional de extração, indexação, armazenamento e avaliação.

Os guias para profissionais publicam intervalos de latência para embedding, pesquisa, reranking e geração, mas esses valores variam consoante a região, o corpus, o hardware e o modelo. Meça cada etapa em traces e avalie a alteração na qualidade antes de aceitar a latência adicional.

39. Arquiteturas de agentes e chamadas a ferramentas

Os agentes baseados em LLM usam modelos para selecionar e encadear chamadas a ferramentas em torno de um estado em evolução. Três padrões de orquestração úteis são:

• ReAct — intercala a seleção de ações com observações. Pode adaptar-se após cada resultado de uma ferramenta, mas um histórico crescente aumenta o custo em tokens e a latência.
• ReWOO — planeia chamadas a ferramentas com placeholders, executa trabalho independente em paralelo e, depois, sintetiza os resultados. O artigo apresenta poupanças de tokens face ao ReAct, mas o plano fixo requer um caminho explícito de recuperação quando uma ferramenta falha.
• Planner-executor — separa o planeamento da execução e pode adicionar uma política de replaneamento após uma falha. Permite especializar os modelos, mas acrescenta estado de orquestração e outra fronteira de decisão.

Function calling é um mecanismo comum para invocar ferramentas. As APIs expõem definições de ferramentas e devolvem argumentos estruturados, reduzindo a necessidade de analisar texto livre. Argumentos válidos segundo o schema podem ainda selecionar a ferramenta errada ou conter valores inválidos. O parallel function calling pode reduzir o número de round trips quando as operações são independentes.

Structured output e constrained decoding impõem um schema restringindo os tokens disponíveis em cada passo de geração. Engines como o xgrammar, utilizado no vLLM e no SGLang, podem eliminar muitas falhas de sintaxe e de parsing, com baixo overhead nas configurações suportadas. Não garantem que os valores extraídos ou as decisões estejam corretos. O Schema-Guided Reasoning (SGR) utiliza a ordem dos campos e a estrutura do schema para tornar o estado intermédio inspecionável antes da decisão final. Os seus três padrões são Cascade (passos sequenciais), Routing (union types como comutadores semânticos) e Cycle (listas limitadas).

A qualidade da seleção de ferramentas, a latência de ponta a ponta e o custo em tokens tendem a degradar-se à medida que aumentam o conjunto de ferramentas e a profundidade das ações. Meça essas curvas com as descrições reais das ferramentas e a distribuição de falhas observada. Frameworks como o LangGraph podem tornar explícitos o estado e os caminhos de recuperação, mas não eliminam a necessidade de avaliação.

40. Engenharia de prompts para produção

A criação de prompts para produção é um problema de avaliação: altere uma parte do prompt ou do contexto e, depois, meça a qualidade da tarefa e os modos de falha. As técnicas abaixo são pontos de partida comuns, não uma ordem universal.

Os exemplos few-shot são frequentemente eficazes para controlar o formato da saída. Comece com 3–5 exemplos que cubram entradas vazias, consultas ambíguas e respostas com várias partes e, depois, meça o resultado num conjunto de validação separado. Os exemplos devem abranger a distribuição real das entradas, em vez de cobrirem apenas o caminho de sucesso. Mais exemplos consomem contexto e não garantem ganhos adicionais.

Prompting de cadeia de pensamento (CoT) pede a um modelo que exponha o raciocínio intermédio antes de responder. Kojima et al. relataram melhorias com o sufixo «Let’s think step by step» nas tarefas de raciocínio que testaram, mas o efeito varia consoante o modelo e as APIs de raciocínio mais recentes podem não expor os registos ocultos. Em produção, prefira uma decomposição da tarefa que possa ser inspecionada ou uma justificação concisa quando tal for útil para o avaliador. A self-consistency (Wang et al., 2023) amostra vários percursos de raciocínio e agrega as respostas, trocando um custo de inferência adicional por maior robustez em tarefas adequadas.

A saída estruturada com esquemas JSON explícitos (Secção 39) elimina muitas falhas de parsing. Engines de constrained decoding, como xgrammar, podem impor a gramática suportada durante a geração; a exatidão factual e a validade semântica continuam a exigir avaliação, e as funcionalidades de esquema não suportadas podem continuar a precisar de tratamento.

O encadeamento de prompts divide uma tarefa em etapas focadas, por exemplo, classificar a intenção → obter contexto → gerar resposta → validar a saída. Pode localizar falhas, permitir modelos diferentes por etapa e expor estado intermédio passível de cache. Também acrescenta interfaces e latência, pelo que deve ser comparado com uma baseline de chamada única.

A temperature altera a distribuição de amostragem. Valores baixos são um ponto de partida razoável para classificação ou extração; valores mais altos podem aumentar a diversidade na ideação. O comportamento exato difere entre APIs de modelos e interage com top_p, top_k e os valores predefinidos do fornecedor; por isso, faça uma varredura das definições suportadas na tarefa, em vez de copiar um intervalo.

A separação entre mensagens do sistema e do utilizador mantém a política persistente separada do conteúdo específico de cada pedido. Os chat templates e o instruction tuning atribuem prioridades diferentes a estes papéis, mas não transformam uma mensagem do sistema numa fronteira de enforcement. Coloque o comportamento estável na mensagem do sistema, mantenha os dados não confiáveis no conteúdo do utilizador ou das ferramentas e imponha também fora do modelo as restrições rígidas, como a remoção de PII.

A engenharia de contexto alarga o trabalho de prompt à composição de documentos obtidos, resultados de ferramentas, histórico da conversa e exemplos. Liu et al. identificaram um efeito de lost-in-the-middle nos modelos de contexto longo que testaram; por isso, a posição deve fazer parte da avaliação, em vez de ser considerada irrelevante. Abordei o fluxo de trabalho mais amplo em Context Engineering for AI Agents.

Parte VIII — Operações em produção

As operações em produção transformam os conceitos anteriores em limites de admissão, testes de carga, alertas e decisões de capacidade sob tráfego real.

41. Rate limiting para pedidos com custo variável

O rate limiting tradicional, baseado em pedidos por segundo, pressupõe custos aproximadamente iguais por pedido. Os LLM quebram esse pressuposto. Um prompt de classificação com 10 tokens e a análise de um documento com 100K tokens utilizam o mesmo endpoint da API, mas diferem no custo em quatro ordens de grandeza. Limitar a taxa por RPS permite que pedidos dispendiosos passem sem controlo ou priva desnecessariamente os pedidos baratos.

Os sistemas de produção precisam de rate limiting baseado em tokens em várias dimensões. A OpenAI documenta limites de pedidos e tokens por nível de utilização. A Anthropic separa os limites de tokens de entrada e de tokens de saída. As quotas e os algoritmos exatos podem mudar, por isso deve tratar a documentação do fornecedor como a fonte de verdade; o ponto arquitetural é orçamentar pedidos e tokens de forma independente.

O padrão prático de implementação é uma hierarquia de limites multidimensional (utilizador → aplicação → organização → global), com níveis de prioridade para acesso premium. Ao nível do pedido, a técnica relevante é a reserva de orçamento de tokens: estime o total de tokens (entrada + max_tokens) no momento da admissão, desconte-o do bucket e ajuste o valor quando o pedido terminar, com base na utilização real. Isto impede que uma rajada de pedidos com gerações longas esgote a capacidade antes de estes começarem sequer a produzir saída.

Em deployments self-hosted, o equivalente é o throughput provisionado: reservar capacidade de GPU dedicada para as taxas de tokens pretendidas. Em deployments com vLLM, isso significa configurar o controlo de admissão em torno dos slots de decode ativos e da pressão sobre a KV cache, em vez de considerar apenas a contagem de pedidos. Como explicado na Secção 5, tanto o throughput como a admissão precisam de limites conscientes dos tokens.

42. Modos de falha a considerar

A disponibilização de LLM acrescenta modos de falha associados ao comprimento variável das sequências, à memória KV e ao trabalho de decode de longa duração. Conceba e faça load testing das proteções antes de o tráfego de produção depender delas.

Out of Memory (OOM) é uma falha comum. Um modelo 70B em FP16 precisa de cerca de 140 GB apenas para os pesos, e a KV cache de uma única sequência Llama 3.1 70B com contexto de 128K pode acrescentar cerca de 40 GB, segundo os pressupostos da Secção 6. A diferença entre “caber na memória” e ocorrer um “OOM sob carga” é menor do que parece, porque um batch de pedidos com contexto longo pode consumir mais memória KV do que o esperado. A prevenção combina uma reserva de memória medida com quantização e alocação paginada de KV. Para workloads com elevada pressão sobre a KV, o LMCache pode descarregar dados KV para a memória da CPU ou para o disco; use os resultados publicados como ponto de partida e faça benchmark da hierarquia de memória local.

Preemption ocorre quando a pressão sobre a KV cache obriga o scheduler a expulsar ou recalcular trabalho. A estratégia exata depende da versão e da configuração do serving. Do lado do utilizador, o sintoma é uma latência end-to-end mais elevada, sem um erro evidente na aplicação. Monitorize as contagens de preemption e correlacione-as com a utilização de KV, a profundidade da fila e os comprimentos dos pedidos.

A latência de cauda pode aumentar subitamente quando prefill grandes atrasam o trabalho de decode. O chunked prefill (Secção 7) e o scheduling consciente do comprimento procuram reduzir esta interferência. Os artigos sobre o scheduler Learning-to-Rank e o CascadeInfer reportam melhorias face às respetivas baselines nos workloads avaliados, mas o resultado exato depende da distribuição dos comprimentos dos pedidos e da configuração do scheduler.

As falhas em cascata podem começar quando pedidos lentos fazem crescer a fila, os clientes upstream atingem o timeout e as tentativas de retry acrescentam ainda mais carga. As proteções incluem controlo de admissão, limites de concorrência por tenant, limites de saída, orçamentos de retry e circuit breakers no gateway. Pools de prefill e decode desagregados podem ajudar quando os load tests revelam uma interferência persistente entre fases.

43. Monitorização de sistemas LLM

A monitorização de LLM é diferente da monitorização tradicional de APIs em alguns aspetos fundamentais. Cada pedido tem um custo variável, duas fases distintas com bottlenecks diferentes e uma pegada de memória que depende tanto do comprimento da entrada como do comprimento da geração. As métricas padrão, como a latência dos pedidos e a taxa de erros, não captam a maior parte do que é relevante.

Goodput é o número de pedidos por segundo que cumprem todos os limiares de SLO definidos, como TTFT, TPOT e latência total. É uma medida combinada útil, porque o throughput bruto pode parecer saudável enquanto os SLO de latência falham: um sistema que processa 100 pedidos por segundo, mas não cumpre os limiares em 40% deles, tem um goodput de 60 pedidos por segundo. Otimizar para o goodput mantém visível a distribuição do desempenho, em vez de reportar apenas a média.

O vLLM expõe um endpoint Prometheus em /metrics com pedidos em execução e em espera, utilização da cache KV, distribuições do comprimento das gerações e estatísticas da prefix-cache. Os nomes das métricas podem mudar entre versões, por isso associe os dashboards à versão instalada. Uma stack típica utiliza Prometheus para as métricas, Grafana para a visualização e traces compatíveis com OpenTelemetry entre os componentes da aplicação e de serving.

Os padrões de alerta úteis incluem os seguintes. Derive os respetivos limiares a partir de testes de carga, em vez de copiar estes exemplos sem alterações:

• Picos no número de preempções — o runtime está a trocar ou a recalcular trabalho, o que aumenta a latência sem gerar um erro na aplicação.
• Utilização da cache KV a aproximar-se da zona de preempção testada — aumente a capacidade ou reduza a carga antes que as evictions se propaguem.
• Profundidade da fila persistentemente acima do envelope de batching testado — o controlo de admissão deve começar a rejeitar pedidos ou a atribuir-lhes menor prioridade.
• TTFT a aumentar enquanto o TPOT permanece estável — esta divergência aponta primeiro para pressão na fila, na admissão, na rede ou no prefill, e não para o throughput de decode. Utilize traces e métricas da fila para distinguir entre estas causas.

44. Otimização de custos: uma estratégia cumulativa

Os preços dos providers e os rácios de preço entre input e output mudam. Consulte as tarifas atuais antes de tomar uma decisão de compra; o tier do modelo e o comprimento do output podem dominar a fatura mesmo antes das otimizações de infraestrutura.

É possível combinar várias abordagens, mas apenas depois de medir quais se aplicam à carga de trabalho:

1. Quantização de FP16 para INT4 reduz a memória dos pesos em 75%. A redução da fatura depende da velocidade do kernel, do batch size e da utilização do hardware (Secção 9).
2. Model routing encaminha o tráfego elegível para modelos mais baratos. Meça a taxa de falsos positivos do router e a qualidade end-to-end antes de aumentar a quota tratada pelo modelo mais barato (Secção 36).
3. Prompt caching reduz o trabalho repetido sobre prefixes. Os descontos dos providers e o tratamento dos rate limits mudam ao longo do tempo; combine a hit rate medida com as condições atuais (Secção 16).
4. Batch APIs podem oferecer descontos para trabalho não real-time, como avaliações, geração de dados sintéticos e classificação em massa. Confirme os preços atuais e as janelas de conclusão.
5. Self-hosting pode compensar com uma utilização sustentada, mas não existe um ponto de equilíbrio universal baseado no volume de tokens. Inclua os custos de engenharia, orquestração, observabilidade, folga de capacidade e on-call, além do aluguer de GPUs.

Multiplicar os fatores ilustrativos produz uma grande redução teórica, mas os inputs não são independentes: a quantização altera o throughput, o routing altera a mistura de qualidade e o caching e o batching aplicam-se apenas ao tráfego elegível. Construa a estimativa a partir das proporções de tráfego medidas e valide-a face à fatura.

45. Planeamento de capacidade e autoscaling

O planeamento de capacidade para servir LLMs tem de considerar o custo variável dos pedidos, o trabalho de decoding de longa duração e a memória dependente da sequência. Consoante a carga de trabalho, o recurso limitante pode ser a memória KV, a largura de banda da memória, a capacidade de computação ou o interconnect.

O limite teórico de memória para pedidos concorrentes resulta do orçamento da KV cache:

$\text{max concurrent sequences} = \frac{\text{GPU memory} - \text{model weights} - \text{overhead}}{\text{per-sequence KV cache size}}$

Para os cálculos de capacidade, suponha que o runtime disponibiliza um orçamento de 40 GiB para a KV cache do Llama 3.1 70B com uma KV cache FP16. Cada sequência de 4K utiliza cerca de 1,25 GiB e cada sequência de 128K cerca de 40 GiB. Esse orçamento acomoda, portanto, no máximo cerca de 32 sequências de 4K ou uma sequência de 128K, antes de contabilizar o overhead do allocator, do runtime, da variabilidade da carga de trabalho e do SLO. É por isso que a seleção de GPU e a otimização da KV cache influenciam diretamente o plano de capacidade.

A fórmula de capacidade para dimensionar a fleet:

$\text{required GPUs} = \frac{\text{peak tokens/s} \times \text{safety-factor multiplier}}{\text{per-GPU tokens/s at target SLO}}$

Converta ambas as taxas para a mesma unidade de tempo antes de efetuar a divisão. O detalhe importante é “no SLO pretendido”. Um multiplicador de fator de segurança, como 1,3, reserva 30% de margem; escolha-o com base na variabilidade medida dos picos, nas falhas e no tempo de recuperação. O throughput máximo de tokens e o throughput em conformidade com o SLO podem diferir significativamente à medida que a concorrência aumenta. Faça o benchmark com a distribuição real dos comprimentos dos prompts e das respostas, respeitando os limiares de TTFT e TPOT necessários, em vez de utilizar um máximo teórico.

A utilização da GPU é insuficiente como único sinal de autoscaling, porque pode permanecer elevada tanto durante um processamento saudável como durante uma situação de overload. Combine-a com a profundidade da fila, a utilização da KV cache e a degradação do goodput. Ajuste os limiares a partir de testes de carga; valores como 80% de utilização da KV cache são pontos de partida, não limites universais. Estas métricas são introduzidas na Secção 43.

Scale-to-zero pode ser adequado para ambientes de desenvolvimento e staging com longos períodos de inatividade. Plataformas de inferência serverless e autoscalers baseados em Kubernetes, como o KEDA, podem eliminar capacidade ociosa, mas as poupanças e o tempo de cold start dependem do tamanho do modelo, do caching da imagem e dos pesos e da infraestrutura. Meça o tempo de arranque antes de aplicar a mesma política ao tráfego de produção sensível à latência.

Utilize o guia para escolher a próxima medição

Os conceitos interagem, mas continuam a produzir um pequeno conjunto de medições iniciais úteis. A procura da KV cache limita o tamanho do batch, juntamente com a memória dos pesos, o overhead do runtime e os comprimentos dos pedidos. Batches maiores podem aumentar a intensidade aritmética, enquanto o continuous batching aumenta o churn de alocação da KV cache e o PagedAttention reduz a fragmentação resultante.

No lado do treino, o custo ao longo do ciclo de vida pode favorecer o treino de um modelo mais pequeno com mais tokens, como ilustra o Llama 3 8B. O GRPO reduz a carga associada ao estado do critic no PPO. Na configuração testada com um modelo pequeno no DeepSeek-R1, a distillation superou o RL direto. Estas são opções a avaliar, não uma receita.

O routing, o caching, a quantização e a escolha do hardware só produzem efeitos cumulativos quando cada um é avaliado face ao mesmo objetivo de qualidade e latência. Escolha um sintoma, estabeleça essa baseline e faça com que a próxima alteração seja fácil de reverter.

Leitura adicional

Análises aprofundadas relacionadas neste blogue, organizadas por tópico:

• Guia de fine-tuning de LLM — quando fazer fine-tuning em vez de usar RAG ou prompt engineering
• Variantes de LLM open source e formatos de ficheiro — fazer corresponder variantes de modelos e formatos quantizados ao hardware
• Guia de serving do LoRAX — servir milhares de adaptadores LoRA em produção
• Escalar modelos de linguagem de grande dimensão — estratégias para várias GPUs e vários nós
• LLMs locais no macOS — configuração prática com llama.cpp e Ollama
• Ciclos de raciocínio de agentes de IA em 2026 — análise aprofundada de ReAct, ReWOO e ciclos planner-executor
• Arquitetura de memória de agentes de IA em 2026 — checkpoints, vector stores e memória documental para agentes com estado

Referências

Organizadas por área temática.

Inferência e atenção

• FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness - Dao et al., NeurIPS 2022
• FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning - Dao, 2023
• FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision - Shah et al., NeurIPS 2024
• Flash-Decoding for long-context inference - Dao et al., 2023
• Efficient Memory Management for Large Language Model Serving with PagedAttention - Kwon et al., SOSP 2023
• Orca: A Distributed Serving System for Transformer-Based Generative Models - Yu et al., OSDI 2022
• GQA: Training Generalized Multi-Query Attention - Ainslie et al., 2023
• Triton: an intermediate language and compiler for neural network computations - Tillet et al., MAPL 2019
• FlashNorm: Fast Normalization for LLMs - 2024
• Deep Kernel Fusion for Transformers - DeepFusionKernel, 2026

Decoding especulativo

• Accelerating Large Language Model Decoding with Speculative Sampling - Chen et al., 2023
• EAGLE-3: Scaling up Inference Acceleration of Large Language Models - Li et al., NeurIPS 2025
• Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads - ICML 2024

Quantização

• AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration - MLSys 2024 Best Paper
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers - Frantar et al., ICLR 2023
• Marlin: Mixed-Precision (FP16xINT4) LLM Inference Kernel - Frantar et al., 2024

Treino e fine-tuning

• LoRA: Low-Rank Adaptation of Large Language Models - Hu et al., ICLR 2022
• QLoRA: Efficient Finetuning of Quantized LLMs - Dettmers et al., NeurIPS 2023
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models - Rajbhandari et al., SC20
• ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning - Rajbhandari et al., 2021
• Self-Instruct: Aligning Language Models with Self-Generated Instructions - Wang et al., ACL 2023
• WizardLM: Empowering Large Language Models to Follow Complex Instructions - Xu et al., ICLR 2024
• Phi-4 Technical Report - Microsoft, 2024
• AI models collapse when trained on recursively generated data - Shumailov et al., Nature 2024

Alinhamento

• Direct Preference Optimization: Your Language Model is Secretly a Reward Model - Rafailov et al., NeurIPS 2023
• DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models - Introduziu o GRPO
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning - DeepSeek, 2025

Escala e arquitetura

• The Llama 3 Herd of Models - Meta, 2024
• LLaMA: Open and Efficient Foundation Language Models - Touvron et al. (Meta), 2023
• Llama 2: Open Foundation and Fine-Tuned Chat Models - Touvron et al. (Meta), 2023
• Qwen3 Technical Report - Qwen Team (Alibaba), 2025
• Training Compute-Optimal Large Language Models - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Enhanced Transformer with Rotary Position Embedding - Su et al., 2021
• YaRN: Efficient Context Window Extension of Large Language Models - Peng et al., ICLR 2024
• SGLang: Efficient Execution of Structured Language Model Programs - Zheng et al., NeurIPS 2024
• Mixtral of Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka Representation Learning - Kusupati et al., NeurIPS 2022
• pplx-embed-v1: Diffusion-Pretrained Dense and Contextual Embeddings - Perplexity AI, 2026

Arquiteturas de agentes

• ReAct: Synergizing Reasoning and Acting in Language Models - Yao et al., ICLR 2023
• ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models - Xu et al., 2023

Encaminhamento

• RouteLLM: Learning to Route LLMs with Preference Data - Ong et al., ICLR 2025

Benchmarks

• MLPerf Inference v5.0 Results - MLCommons, abril de 2025

Arquiteturas de serving

• Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve - Agrawal et al., OSDI 2024 (Chunked prefill)
• Splitwise: Efficient Generative LLM Inference Using Phase Splitting - Patel et al., ISCA 2024 (Disaggregated Serving)
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - Zhong et al., OSDI 2024 (Disaggregated Serving)

Frameworks de serving

• vLLM - motor de serving baseado em PagedAttention
• SGLang - RadixAttention e geração estruturada
• TensorRT-LLM - inferência otimizada pela NVIDIA
• llama.cpp - inferência portátil em C/C++
• DeepSpeed - biblioteca de treino distribuído da Microsoft
• Ollama - runner local de LLMs

Operações

• Agendamento eficiente de LLMs através de learning to rank - Fu et al., NeurIPS 2024 (vLLM-LTR)
• CascadeInfer: Agendamento de serving de LLMs sensível ao comprimento, com baixa latência e balanceamento de carga - Yuan et al., 2025
• A métrica goodput como medida da produtividade em ML - Google Cloud, 2024
• Otimização e tuning do vLLM - Documentação do vLLM
• Métricas do vLLM - Documentação do vLLM
• LMCache: Gestão da KV cache para serving de LLMs - offloading da KV cache
• Limites de taxa da OpenAI - Documentação da API da OpenAI
• Limites de taxa da Anthropic - Documentação da API da Anthropic