2026-03-13 · Atualizado 2026-07-15

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

LLM Guia de Engenharia: 45 Conceitos para Inferência, Treino, Arquitetura e Operações

Os sistemas de produção LLM recorrem simultaneamente ao hardware GPU, à engenharia de sistemas e à teoria ML. Os mesmos conceitos fundamentais são aplicados quer estejamos a ajustar o TTFT para um chatbot, quer a configurar o DeepSpeed ZeRO para uma execução fine-tuning. Este guia reúne-os num único local.

TL;DR: Esta referência abrange 45 conceitos em oito partes, desde hardware e inferência até treino, deploy e operações. Cada entrada define o conceito, explica o seu impacto prático, apresenta valores quando estes ajudam a esclarecer a escala, e faz ligações para secções relacionadas. Os dados citados cobrem o período de 2024 até ao início de 2026.

Este guia pressupõe conhecimentos básicos de ML (retropropagação, descida de gradiente, softmax) e alguma noção sobre sistemas (hierarquias de memória, conceitos fundamentais de rede).

[!NOTE] Uma nota sobre o escopo

Trata‑se de uma referência extensa, e não de um tutorial linear. Utilize a tabela abaixo para aceder à parte que corresponde à sua decisão atual.

Como utilizar este guia como um hub

Esta página foi concebida de forma intencionalmente abrangente. Utilize-a como um mapa geral e, assim que a decisão se tornar mais concreta, aceda aos artigos mais detalhados.

O caminho que oferece o maior retorno costuma ser o seguinte: compreender o gargalo, selecionar a pilha tecnológica mais simples capaz de expô-lo, benchmark com a carga de trabalho real, e só então adicionar complexidade nos pontos em que os dados o justificam.

Parte I — Fundamentos de hardware

Os conceitos aqui apresentados — intensidade aritmética, a hierarquia de memória GPU e os termos relacionados com o hardware — aparecem em todos os outros pontos deste guia.

1. Limitações de memória versus limitações de processamento e o modelo roofline

O ponto de partida para avaliar o desempenho de LLM é a intensidade aritmética: para cada byte de dados que o GPU carrega da memória, quantos cálculos úteis ele realiza? Essa relação determina se uma operação é limitada por computação (aguardando o processador) ou limitada por memória (aguardando que os dados sejam carregados).

Cada GPU possui um limiar de “intensidade crítica” em que a sua capacidade de processamento equilibra exatamente a sua largura de banda de memória. No caso de um NVIDIA H100 (Folha de Dados, 2023):

$\frac{989 \text{ TFLOPS}}{3,35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

As duas fases da inferência de LLM situam‑se em lados opostos a este limiar:

• A decodificação é limitada pela memória. Gerar tokens um a um implica carregar a matriz de pesos de vários gigabytes da memória para multiplicá‑la por cada novo token. Numa análise simplificada de 16 bits e lote único, a operação tem cerca de 1 FLOP/byte, o que representa quase 300 vezes menos que o limite máximo do H100. Essa diferença explica por que a decodificação não consegue atingir a taxa de processamento máxima neste regime.
• Prefill é limitado pelo poder de processamento. Ao processar o prompt de entrada, os pesos são carregados uma única vez, mas são multiplicados por centenas ou milhares de tokens ao mesmo tempo. A intensidade de processamento supera amplamente 295, saturando assim as unidades de cálculo.

Para acelerar a decodificação, é necessário trabalhar na largura de banda da memória: reduzir os pesos com quantização, reduzir o overhead de memória KV com GQA e PagedAttention, e aumentar a intensidade com agrupamento em lotes. Para acelerar o prefill, é necessário focar na computação bruta: realizar operações de GPUs e FP8 de forma mais rápida.

2. Hierarquia de memória GPU

Um GPU possui quatro camadas de memória dispostas em forma de pirâmide: uma memória principal grande, mas lenta (HBM), localizada na base, e registos pequenos, mas extremamente rápidos, no topo. O movimento de dados para cima e para baixo nesta pirâmide representa o principal gargalo de desempenho. O ponto mais crítico encontra‑se entre HBM e a SRAM, onde esta última é aproximadamente 10 vezes mais rápida.

Do mais rápido ao mais lento num H100:

1. Registos — a memória mais rápida, ligada diretamente aos threads de processamento. É aqui que as operações matemáticas são efetivamente executadas; os dados têm de ser carregados aqui para que os Tensor Cores possam utilizá‑los.
2. SRAM (Memória Compartilhada) — a memória de trabalho com uma velocidade aproximada de 33 TB/s.
3. Cache L2 — uma camada intermédia (50 MB) com uma taxa de transferência em torno de 12 TB/s. Funciona como um buffer, de modo que, quando vários SMs precisam dos mesmos pesos, não é necessário que todos eles os obtenham de HBM.
4. HBM3 — a memória principal de 80 GB que armazena os pesos do modelo e KV cache, com uma velocidade de ~3,35 TB/s.

FlashAttention, a fusão de kernels e PagedAttention reduzem todos eles o tráfego entre estas camadas. Eles permitem que os dados permaneçam mais tempo na SRAM rápida, evitando transferências repetidas para HBM.

3. Glossário de hardware GPU

Os termos abaixo aparecem ao longo de todo o resto do guia.

HBM (Memória de Alta Largura de Banda) — Células DRAM empilhadas e interligadas por vias através do silício (TSVs), instaladas diretamente no pacote ao lado da célula GPU. Gerações: HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s), HBM3e (H200/B200, 4,8–8 TB/s). A razão pela qual isso é importante para LLMs: a fase de decodificação é limitada pela largura de banda da memória, pelo que a largura de banda de HBM determina diretamente o TPOT.

GDDR (Graphics DDR) — Memória gráfica tradicional (GDDR6, GDDR6X) utilizada em GPUs de consumo (RTX 4090, L40S). Possui largura de banda inferior à de HBM, mas é mais económica por GB. O GDDR6X em RTX 4090 Consegue entregar cerca de 1 TB/s, em comparação com os 3,35 TB/s do HBM3 da H100.

SM (Streaming Multiprocessor) — O bloco de computação básico dos NVIDIA GPUs. Cada SM dispõe de CUDA núcleos, Tensor Cores, memória partilhada (SRAM) e um agendador de warps. H100 possui 132 SMs; A100 possui 108.

Tensor Cores — Unidades especializadas em multiplicação e acumulação de matrizes localizadas dentro de cada SM. Elas aceleram as operações de matmulp de precisão mista (FP16, BF16, FP8, INT8), que são fundamentais nos cálculos dos modelos transformer. Os Tensor Cores do H100 oferecem 989 TFLOPS em TF32 em comparação com cerca de 67 TFLOPS obtidos apenas com as CUDA núcleos.

CUDA Cores — Unidades de ponto flutuante e inteiro de uso geral. Estas são responsáveis por operações elemento a elemento, funções de ativação e tarefas que não envolvem matmul. Os Tensor Cores assumem o trabalho mais intensivo relacionado ao LLMs; as cores CUDA cuidam de todo o resto.

Warp — Um grupo de 32 threads que executam em sincronia num SM. A menor unidade de agendamento na NVIDIA GPUs. Especialização em warping Atribui deformações distintas a tarefas diferentes (carregamento de dados versus computação) para fins de pipelineização.

NVLink — Interconexão de alta velocidade entre GPU e GPU dentro de um nó. NVLink 4.0 (H100) oferece 900 GB/s em modo bidirecional; o NVLink 5.0 (B200) atinge 1,8 TB/s. É essencial para o paralelismo de tensores, onde GPUs precisa trocar ativações em cada camada.

InfiniBand — Estrutura de rede de alta velocidade para comunicação entre nós GPU. NVIDIA ConnectX-7 Fornece 400 Gb/s por porta. É utilizado para obter pipeline de paralelismo e para treino distribuído entre vários nodos.

RDMA (Acesso Direto à Memória Remota) — Permite que um GPU leia/escreva na memória de outro equipamento sem a intervenção do CPU, minimizando o tempo de latência. GPUDirect RDMA Permite transferências diretas de GPU para GPU entre nós. É utilizado em serving desagregados para transferências de KV cache.

NVMe (Non-Volatile Memory Express) — Interface de SSD de alta velocidade utilizada para o descarregamento de KV cache ZeRO-Infinity O descarregamento de parâmetros quando a memória GPU/CPU é insuficiente. As velocidades de leitura sequencial variam entre 5–7 GB/s por unidade (PCIe Gen 4), sendo que as unidades mais recentes da geração 5 atingem valores entre 10–14 GB/s.

TFLOPS / PFLOPS — Operações de ponto flutuante em tera/peta por segundo. 1 TFLOPS = 10¹² FLOPS. É a unidade padrão utilizada para medir a taxa de processamento de GPU. O H100 oferece 989 TFLOPS no modo TF32; o FlashAttention-3 atinge aproximadamente 1,2 PFLOPS em FP8.

Parte II — Fundamentos de inferência

A inferência é a parte do sistema que os utilizadores realmente percebem. A latência, o KV cache, o modelo de execução em duas fases, a atenção e a quantização entre eles determinam quão rápido, quão económico e com que fiabilidade é possível fornecer os serviços.

4. Latência: TTFT, TPOT e percentis

Tempo até ao Primeiro Token (TTFT) é o atraso desde a submissão do pedido até ao primeiro token de saída. Este valor é determinado pela fase prefill: o modelo tem de processar todo o prompt antes de gerar qualquer conteúdo, pelo que períodos mais longos de prompts tendem a aumentar o TTFT. Os objetivos a atingir variam consoante o produto; MLPerf Inference v5.0 Utiliza um limite P99 TTFT de $\leq$ 450 ms no seu cenário interativo com o Llama 2 70B.

Tempo por Token de Saída (TPOT) é o intervalo médio entre tokens consecutivos a partir do primeiro. Este valor está relacionado com a fase de decodificação, na qual cada passo é limitado pela largura de banda da memória:

$\text{TPOT} = \frac{\text{Latência E2E} - \text{TTFT}}{\text{Tokens de Saída} - 1}$

A velocidade média de leitura silenciosa em inglês para adultos é de aproximadamente 238 palavras por minuto em textos de não ficção.Brysbaert, 2019). Os alvos de streaming devem continuar a ser definidos a partir de testes de produto; o MLPerf utiliza um limite P99 TPOT de $\leq$ 40 ms para o seu cenário interativo.

Latência P50 vs P99 é importante porque a mediana oculta as extremidades da distribuição. Um sistema com um bom valor de P50 mas um P99 ruim pode apresentar problemas de agrupamento de operações, preempção, filas ou desequilíbrio no volume de trabalho; são necessários registos detalhados para os distinguir.

5. Rendimento: tokens por segundo e o compromisso entre latência e velocidade

O throughput é medido em tokens de saída por segundo nas solicitações concorrentes. O número de solicitações por segundo, por si só, não é suficiente para avaliar o desempenho, uma vez que uma resposta com 10 tokens e outra com 1.000 tokens implicam custos muito diferentes. Os valores publicados para benchmark variam consoante o modelo, a precisão, o hardware, prompt e os comprimentos da saída, bem como a concorrência e os SLO. Compare vLLM, SGLang, e TensorRT-LLM utilizando um único harness em vez de combinar os seus resultados principais.

O compromisso: em baixa concorrência, cada pedido apresenta uma latência elevada, mas o GPU fica subutilizado. O aumento do tamanho dos lotes eleva a taxa de transferência de dados de forma quase linear até que a capacidade de processamento seja esgotada, momento em que a latência sobe drasticamente. Goodput, que representa a fração de pedidos que cumprem os objetivos definidos nos SLO, é a métrica que relaciona a taxa bruta de transferência com a satisfação real dos utilizadores.

6. KV cache: o gargalo por trás da maioria dos outros gargalos

Durante a geração autoregressiva, cada novo token leva em consideração todos os tokens anteriores. O KV cache armazena as projeções de Chave e Valor de cada token em cada camada, de modo a evitar a recálculo de ordem $O(n^2)$. Sem ele, gerar o token $n$ exigiria a execução novamente do modelo para todos os $n-1$ tokens anteriores.

O KV cache costuma ser a principal fonte de pressão na memória, uma vez que aumenta de forma linear com o comprimento da sequência, o tamanho do lote 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$ = tamanho do lote

Exemplos concretos com FP16 e tamanho de lote 1: o Llama 3 8B, com 8.192 tokens, utiliza aproximadamente 1,0 GB de KV cache; com 128K tokens, a necessidade sobe para 16 GB. Já o Llama 3 70B, ao processar 128K tokens, requer cerca de 40 GB para uma única sequência, o que corresponde a metade da capacidade de VRAM de um hardware H100. Em tamanhos de lote de produção, KV cache supera facilmente a memória destinada ao peso do modelo. Implementações ingênuas desperdiçam de 60 a 80% da memória KV alocada devido à fragmentação, o que representa um problema significativo. PagedAttention foi desenvolvido para resolver.

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

7. Prefill vs decode: duas fases, dois gargalos

A prefill fase processa o prompt em paralelo e preenche o KV cache. Devido às suas grandes multiplicações matriciais, o seu tempo de execução é limitado por operações computacionais intensivas, pelo que o prefill determina em grande parte o tempo até ao primeiro token (TTFT). A fase de decodificação gera um token de cada vez. Em cada passo, são lidos os pesos do modelo e o KV cache a partir de HBM, Tornar a descompressão limitada pela largura de banda da memória o principal fator que determina o tempo por token de saída (TPOT).

Chunked prefill divide o prompt em blocos de tamanho fixo (por exemplo, 512 tokens), em vez de processá-lo na totalidade de uma só vez. Um prefill muito longo deixa de bloquear os pedidos de decodificação em curso, as tarefas limitadas por recursos computacionais e de memória passam a ser agendadas em conjunto no mesmo GPU, e as operações vLLM benchmarks apresentam um ganho de 50% no rendimento.Agrawal et al., 2024). O custo é ligeiramente superior no TTFT para o novo pedido.

Disagregação de serving separa os prefill e realiza a sua decodificação em pools GPU distintos, permitindo que cada pool trate um gargalo diferente. Splitwise e DistServe descreva o padrão. Os pools transferem dados do cache KV através de uma interconexão rápida, como RDMA, Assim, o custo de comunicação passa a fazer parte do design.

8. GQA e MQA: reduzir o tamanho do KV cache

Padrão Atenção Multicabeça (AMC) cada cabeça de consulta recebe a sua própria cabeça K e V. Atenção Multi-Consulta (MQA) partilha uma única cabeça KV entre todas as cabeças de consulta, o que representa uma redução extremamente significativa. Atenção de Consulta Agrupada (GQA) Trata‑se de um compromisso prático: grupos de cabeças de consulta partilham uma única cabeça KV.

O Llama 3 70B utiliza 64 cabeças de consulta, mas apenas 8 cabeças KV, o que representa uma redução de 8x KV cache em comparação com a mesma arquitetura que possui uma cabeça KV por cada cabeça de consulta. Já o Llama 3.1 405B emprega 128 cabeças de consulta e 8 cabeças KV, resultando numa redução de 16x segundo o mesmo cálculo.Meta, 2024). Ainslie e colaboradores relatam que a qualidade de GQA obtida nos modelos testados é próxima da do MHA, ao mesmo tempo que se aproxima da velocidade de MQA. Um KV cache menor permite lidar com lotes maiores, mas o ganho real em latência e taxa de transferência continua a depender do kernel e do tipo de carga de trabalho.

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

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

AWQ (Activation-Aware Weight Quantization) identifica os <1% de pesos mais relevantes analisando as magnitudes das ativações e aplica um escalonamento por canal para protegê‑los. Para isso, são necessários apenas 128–1.024 tokens de calibração, e este método conquistou o prémio de Melhor Artigo no MLSys 2024. GPTQ Utiliza informações do Hessian de segunda ordem para a quantização por camadas e requer mais dados de calibração. bitsandbytes (A biblioteca de Tim Dettmers) realiza a quantização durante o carregamento do modelo, sem necessidade de uma etapa de pré-processamento separada; o seu formato NF4 permite a utilização de QLoRA fine-tuning. O FP8 em hardware da classe Hopper reduz a memória necessária para armazenar os pesos em comparação com FP16/BF16, mas a qualidade e a velocidade continuam a depender do modelo, da calibração e do kernel.

O kernel serving pode ser tão importante quanto o algoritmo de quantização. Na comparação discutida em Secção 10, Os mesmos pesos quantizados apresentam uma diferença de 2,6x no throughput entre os diferentes kernels.

Parte III — Otimizações de inferência

Esta secção aborda as técnicas de software que permitem transformar um sistema de inferência funcional num sistema mais rápido. Cada uma delas visa um gargalo específico: FlashAttention tira partido da disparidade entre SRAM e HBM, PagedAttention elimina a fragmentação de KV cache, enquanto o agrupamento contínuo mantém o GPU sempre ocupado.

10. Kerneles CUDA e fusão de kerneles

Um CUDA kernel é uma função desenvolvida para o GPU que é executada em paralelo através de milhares de threads. Quando o CPU faz uma chamada a um kernel, o GPU distribui o trabalho entre eles. SMs: Cada SM executa várias sequências de processamento (“warps”) compostas por 32 threads, sendo que cada thread lida com uma parte específica dos dados. Toda operação na inferência realizada com LLM, desde a multiplicação matricial até à amostragem de tokens, é, em última análise, um lançamento de kernel. Uma única passagem forward num modelo de 70B desencadeia centenas a milhares de lançamentos de kernel, e a diferença entre um kernel simples e um otimizado pode determinar se o sistema cumpre os seus objetivos de desempenho em termos de latência.

As principais categorias de kernel em LLM serving:

• Núcleos GEMM para multiplicação de matrizes, que dominam tanto os cálculos de prefill como os de decodificação.
• Núcleos de atenção como FlashAttention, que dividem os cálculos em blocos para permanecerem dentro SRAM em vez de se espalharem para HBM.
• Núcleos fundidos que combinam várias operações (como adição + normalização por camada ou projeção QKV) num único lançamento, de modo a evitar as viagens de ida e volta intermediárias HBM.
• Núcleos de amostragem que convertem logits em IDs de token através de amostragem top-k, top-p ou por temperatura.

A qualidade do kernel costuma ser mais importante do que o algoritmo de quantização. Os mesmos pesos INT4-quantizados são fornecidos através de Marlin Um núcleo otimizado para FP16xINT4 atingiu 712 tokens/s, contra 276 tokens/s do GPTQ convencional, o que representa uma diferença de 2,6 vezes no rendimento, fruto exclusivamente de uma melhor utilização dos GPU. O Marlin consegue isso graças à recuperação assíncrona de memória e a filas de memória compartilhada que mantêm os Tensor Cores alimentados, em vez de esperar por HBM. Triton Reduz a barreira para a criação de kernels personalizados ao permitir a programação com GPU através de Python, em vez de utilizar o C++ puro CUDA, o que torna a otimização a nível de kernel acessível a engenheiros ML e não apenas a especialistas GPU. A maioria das otimizações abordadas mais adiante nesta secção (FlashAttention, kernels fundidos, PagedAttention) consiste, no essencial, ou em kernels melhorados ou em formas mais inteligentes de orquestrar a execução de kernels.

A fusão de kernels combina operações sequenciais num único kernel GPU, evitando escritas intermediárias de HBM. As fusões mais comuns incluem a projeção QKV, atenção mais softmax, e adição mais RMSNorm.FlashNorm), e ativação SwiGLU (DeepFusionKernel). Triton torna estes kernels acessíveis através de Python. Os ganhos exatos em termos de número de execuções e utilização dependem do grafo do modelo, do compilador, GPU, e de serving framework, pelo que é necessário realizar um perfilamento da pilha implementada em vez de confiar num percentual universal.

11. FlashAttention: atenção em mosaico para alojamento em SRAM

Atenção padrão materializa toda a matriz de atenção $N \times N$ em HBM, o que consome $O(N^2)$ de memória e gera um elevado tráfego de memória. A ideia por detrás de FlashAttention é evitar totalmente a materialização desta matriz. Ela divide as matrizes Q, K e V em blocos que cabem dentro SRAM, Calcula a atenção parcial dentro de cada tile e funde os resultados através de um softmax online (registando de forma incremental o valor máximo e a soma acumulados ao longo dos blocos). A memória utilizada passa de $O(N^2)$ para $O(N)$, e as leituras de HBM diminuem numa ordem de grandeza.

Cada versão aborda o gargalo na geração do seu GPU:

• FlashAttention v1 (O A100, de 2022) demonstrou que a abordagem baseada em mosaico combinada com softmax online funciona eficazmente. Obtém-se um aumento de velocidade de 2 a 4 vezes em relação à atenção padrão, mas a utilização fica apenas entre 25% e 40% GPU, devido ao agendamento dos kernels que deixa muitos SMs ociosos. FlashAttention v2 (O A100 de 2023) reformulou o modelo de paralelismo de modo a distribuí-lo pela dimensão da sequência, em vez de focar nos lotes e nas cabeças de processamento. Ele alcançou uma utilização de 50–73% no A100, sendo aproximadamente 2 vezes mais rápido que a versão v1.
• FlashAttention v3 (H100 Hopper, 2024) incluiu uma especialização de “warps” (warps separados para movimentação de dados e para operações matemáticas), bem como um pipeline GEMM-softmax, com o objetivo de sobrepor as cargas de memória às operações de cálculo. É possível atingir uma utilização de 75–85% no H100 e até ~1,2 PFLOPS em FP8. Destaque no NeurIPS 2024. FlashAttention v4 (B200 Blackwell, 2026) aborda um novo gargalo: no Blackwell, a taxa de transferência dos núcleos tensoriais aumenta de forma tão rápida que as operações que não envolvem matmul (exponenciais de softmax, redimensionamento) passam a ser o fator limitante. O software FA4 emula as funções exponenciais através de aproximações polinomiais nas unidades FMA, utiliza redimensionamento condicional para diminuir o overhead e armazena os resultados intermediários na memória dedicada a tensors do Blackwell (TMEM), em vez de nos registos. O resultado é 1.605 TFLOPS/s no B200 em BF16, o que representa 1,3 vezes mais velocidade em comparação com a cuDNN 9.13 e 2,7 vezes mais velocidade em relação ao Triton.

Cada geração enfrentou um limite de hardware diferente, e cada versão de FlashAttention foi redesenhada desde o núcleo até resolver esse problema.

12. FlashDecoding: paralelização do gargalo de decodificação

O padrão FlashAttention mantém o GPU ocupado ao distribuir o trabalho entre o tamanho do lote e o comprimento da consulta. Durante a decodificação, o modelo gera exatamente 1 token de cada vez (comprimento da consulta = 1). Se o tamanho do lote multiplicado pelo número de cabeças de atenção for inferior ao total de unidades SM do GPU (108 num A100), a maior parte dos GPU permanece inativa, enquanto apenas algumas unidades processam 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. Ele divide o KV cache em blocos menores e distribui-os por todos os processadores GPU que, de outra forma, estariam ociosos, para que sejam avaliados em paralelo; em seguida, funde os resultados parciais obtidos através de uma redução por log-sum-exp.

O resultado é uma aceleração de 8 vezes na velocidade de decodificação end-to-end em sequências longas (contexto de 64K), com um tempo de decodificação por token praticamente constante. Gerar o token 60.000 continua quase tão rápido quanto gerar o token 100.

13. Agrupamento contínuo versus agrupamento estático

Agrupamento estático aguarda que todas as sequências de um lote sejam processadas antes de iniciar a seguinte, fazendo com que sequências curtas percam ciclos GPU em espera após atingirem o fim da sequência. O agrupamento contínuo (introduzido pelo Artigo Orca, (O OSDI 2022) funciona com uma granularidade ao nível de iteração: em cada passo de decodificação, as sequências concluídas são removidas e novas são inseridas.

No OPT-13B da Anyscale benchmark, o agrupamento estático otimizado alcançou um desempenho 4 vezes superior ao da abordagem básica não otimizada, enquanto o agrupamento contínuo atingiu um valor 8 vezes maior; adicionalmente, com o uso de vLLM em conjunto com PagedAttention no contexto de agrupamento contínuo, o desempenho chegou a 23 vezes superior (Anyscale, 2023). O agrupamento contínuo também aumenta a pressão sobre a alocação de KV, e é por isso que costuma ser combinado com gestão de memória paginada.

14. PagedAttention: memória virtual para KV cache

o PagedAttention de vLLM Aplica a concepção de memória virtual do SO à gestão de KV cache. O KV cache é dividido em blocos de tamanho fixo (geralmente 16 tokens); esses blocos são alocados conforme necessário, à medida que novos tokens são gerados. As posições lógicas (sequenciais) correspondem a locais de memória física (dispersos) através de tabelas de blocos. Várias solicitações que partilham um prefixo comum (system prompts, busca por feixe) podem apontar para os mesmos blocos físicos.

Os sistemas anteriores desperdiçavam 60–80% da memória KV cache devido à fragmentação e à pré-alocação. As soluções PagedAttention reduzem esse valor para <4%, o que permite um aumento do débito de 2–4 vezes mantendo a mesma latência, e até 24 vezes em comparação com o HuggingFace Transformers.vLLM Blogue, 2023).

15. Decodificação especulativa: vários tokens por passo forward

Um pequeno modelo de esboço gera $K$ tokens candidatos e, em seguida, o grande modelo alvo verifica todos esses $K$ tokens numa única passagem forward. Os tokens corretos são aceites; o primeiro incorreto é rejeitado. A qualidade da saída é matematicamente idêntica à do modelo alvo utilizado isoladamente, pelo que se trata de um aceleramento sem perdas.

Funciona porque a decodificação de LLM é limitada pela largura de banda da memória: verificar $K$ tokens custa aproximadamente o mesmo que gerar 1, uma vez que ambos carregam todos os pesos do modelo uma única vez. Os ganhos de velocidade típicos situam‑se entre 1,5x e 3x, com métodos como EAGLE-3 atingindo até 6,5x. As variantes incluem Medusa (cabeças de previsão adicionais, sem modelo separado), decodificação por consulta prompt (correspondência de n-gramas com a entrada, sem restrições) e EAGLE (extrapolação a nível de características).

Em tamanhos de lote elevados, o trabalho adicional de elaboração e verificação pode anular os benefícios obtidos; um relatório de avaliação citado indica uma desaceleração de 1,4 a 1,8 vezes nesse cenário. A decodificação especulativa revela-se a abordagem mais promissora quando o lote serving é suficientemente pequeno e a taxa de aceitação das versões preliminares é alta.

16. Armazenamento em cache de prefixos e reutilização de KV cache

Em vez de descartar o KV cache quando uma solicitação é concluída, o cacheamento por prefixo mantém-o disponível para reutilização em novas solicitações que partilham os mesmos tokens de prefixo. Isso reduz a necessidade de prefill redundantes para system prompts, exemplos de few-shot, o contexto RAG e o histórico de conversação em várias turnos.

Armazenamento automático em cache de prefixos de vLLM Bloqueia os dados em pares chave-valor através de hashes e recorre a uma tabela de hashes global para efetuar consultas. RadixAttention da SGLang mantém uma árvore de radix com tensores KV em cache, com granularidade ao nível dos tokens. Ambos dependem da presença repetida de prefixos idênticos entre tokens, pelo que é necessário reportar a taxa de acerto juntamente com a latência ou a taxa de transferência de dados.

17. Transmissão em tempo real na prática

Transmissão em fluxo contínuo envia os tokens para o cliente à medida que são gerados, em vez de esperar pela resposta completa. Muitos serving frameworks disponibilizam-no através de Server-Sent Events: o cliente estabelece uma ligação HTTP de longa duração, e o servidor envia cada token ou lote de tokens conforme eles são produzidos data: evento. O TTFT determina o momento em que o utilizador vê pela primeira vez a saída; o TPOT ajuda a definir o quão fluida essa experiência parece. Defina o valor-alvo através de testes do produto e do modelo de interação escolhido.

No lado do cliente, o streaming obriga à tomada de decisões relativas ao buffer. A renderização token a token pode causar tremores visuais, especialmente com blocos de markdown ou código que necessitam de um contexto composto por vários tokens para serem formatados corretamente. Os padrões mais comuns são o buffering a nível de palavra (acumular tokens até encontrar um limite de espaço em branco), o buffering a nível de linha (aguardar uma nova linha antes de renderizar) e o buffering adaptativo (renderizar imediatamente o texto prosaico e armazenar temporariamente os dados dos blocos de código). O stream_options: {"include_usage": true} O parâmetro em APIs compatível com a OpenAI devolve as contagens de tokens no evento SSE final, o que permite um acompanhamento preciso dos custos nas respostas transmitidas em fluxo.

Processamento em blocos prefill É isso que permite que o streaming mantenha o desempenho sob carga elevada. Sem ele, um único prefill prolongado pode causar atrasos na entrega de tokens para todos os outros utilizadores em simultâneo.

Parte IV — Arquitetura do modelo

Como são construídos os LLMs: o bloco transformer, a tokenização, o tratamento de contexto e as variantes arquitetónicas que se tornaram padrão. Todos estes elementos constituem a base tanto para a inferência como para o treino.

18. Elementos essenciais da arquitetura Transformer

Um transformador moderno dedicado apenas à decodificação (GPT, Llama) é uma pilha de camadas idênticas, cada uma contendo dois sub-blocos: atenção e feed-forward. Cada sub-bloco é envolvido por uma conexão residual e por um processo de normalização. Os componentes principais:

Atenção Multi-Cabeça — o mecanismo que permite a cada token analisar todos os outros tokens para determinar o que é relevante. A entrada é projetada em três matrizes: Consultas (o que estou à procura?), Chaves (o que conteno?) e Valores (que informações carrego?). Os scores de atenção são então calculados da seguinte forma:

$\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. A divisão por $\sqrt{d_k}$ impede que os produtos escalares aumentem excessivamente (o que levaria o softmax a regiões com gradientes nulos). O softmax converte as pontuações em probabilidades, e a multiplicação por $V$ gera uma combinação ponderada dos vetores de valor. Executar este processo em várias “cabeças” em paralelo permite que o modelo trate diferentes relações ao mesmo tempo (uma cabeça para a sintaxe, outra para a coreferência, e assim por diante).

Rede Feed-Forward (FFN) — uma vez que a atenção determinou quais tokens são relevantes, a FFN decide o que fazer com essa informação. As versões modernas de LLMs utilizam SwiGLU em vez da FFN ReLU com duas matrizes originais:

$\text{SwiGLU}(x) = \text{Swish}(xW_1) \otimes xW_2$

O SwiGLU utiliza três matrizes de pesos em vez de duas, bem como uma ativação Swish suave em substituição da ReLU. É utilizado por famílias de modelos como Llama, Mistral, Qwen e Gemma. O FFN representa normalmente cerca de dois terços dos parâmetros totais do modelo, embora a proporção exata dependa da arquitetura.

Conexões Residuais — cada sub-bloco adiciona a sua saída de volta à sua entrada: $\text{Saída} = \text{Entrada} + \text{Subcamada}(\text{Entrada})$. Sem esta conexão de salto, os gradientes desaparecem aquando da retropropagação através de 80–128 camadas. As conexões residuais criam um caminho que permite que as informações e os gradientes fluam diretamente das camadas iniciais para as camadas finais.

RMSNorm — é comum nas famílias modernas de LLM. O LayerNorm normaliza ao reposicionar o valor no centro (subtraindo a média) e ao reescalar (dividindo pela desvio padrão). RMSNorm Ignora a subtração da média e realiza apenas um novo escalonamento; o artigo correspondente relata acelerações de 7–64% nos modelos testados, sem qualquer perda de desempenho nesses experimentos. A aplicação do método Pre-norm, que normaliza os dados antes da atenção ou do FFN, também é bastante utilizada, pois contribui para melhorar a estabilidade dos gradientes.

Estimativa do número de parâmetros para um modelo apenas de decodificação:

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

Onde $V$ representa 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 entrada embedding; o termo $12 \times d^2$ aproxima os pesos de atenção e dos FFN em cada camada. Para o Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$), a estimativa é de aproximadamente $0.53B + 6.44B = 6.97B$ parâmetros. O valor total publicado de 8.03B é superior porque a aproximação omite detalhes arquitetónicos, como a largura exata dos FFN e a projeção de saída separada.

19. Por que as arquiteturas apenas com decodificador dominam

O original Transformer (2017) contava tanto com um codificador como com um decodificador. Desde então, o campo dividiu‑se em três famílias arquitetónicas, sendo que uma delas passou a ser a escolha padrão para modelos gerativos AI.

Os modelos só com encoder (BERT, RoBERTa) utilizam atenção bidirecional: cada token presta atenção a todos os outros tokens em ambas as direções. Isso gera representações ricas para tarefas de compreensão (classificação, NER, similaridade semântica), mas não permite a geração de texto de forma autoregressiva. Os modelos só com encoder continuam a dominar como estrutura fundamental para embedding modelos, rerankers, e classificadores leves (por exemplo, os roteadores baseados em BERT) RouteLLM).

Os modelos encoder-decoder (T5, BART, o Transformer original) separam a fase de compreensão da fase de geração. O encoder processa toda a entrada com atenção bidirecional e, em seguida, o decoder gera a saída de forma autoregressiva, ao mesmo tempo que consulta as representações do encoder através de cross-attention. Isso oferece uma vantagem natural para tarefas de sequência para sequência, como a tradução, nas quais a entrada e a saída são sequências fundamentalmente distintas. O T5, desenvolvido pelo Google, demonstrou que qualquer tarefa de NLP pode ser formulada como texto para texto, e os modelos encoder-decoder continuam a ser utilizados em alguns sistemas especializados (como o Whisper para reconhecimento de fala e o FLAN-T5 para execução de instruções).

Modelos só de decodificador (GPT, Llama, Mistral, Gemini) utilizam atenção causal (unidirecional): cada token presta atenção apenas aos tokens anteriores. Eles estruturam tudo como previsão do token seguinte: a “entrada” é o início da sequência, e a “saída” é a sua continuação. Quatro razões pelas quais esta arquitetura se tornou dominante:

1. KV cache de eficiência. O KV cache dos tokens anteriores permanece válido à medida que novos tokens são gerados, pelo que nunca é necessário descartá-lo ou recalcá-lo. Os modelos encoder-decoder têm de manter dois caches de atenção separados (autoatenção e atenção cruzada sobre a saída do encoder), o que aumenta o consumo de memória e a complexidade arquitetónica.

2. Simplicidade no treino. O objetivo do treino consiste simplesmente na previsão do próximo token a partir de texto bruto. Não são necessários dados de entrada/saída emparelhados (como nos modelos de tradução) nem reconstrução de tokens mascarados (como no BERT). É possível treinar com praticamente qualquer tipo de texto proveniente da Internet, livros ou código, sem necessidade de pré-processamento especial, o que representa uma vantagem significativa ao escalar os dados para trilhões de tokens.

3. Simplicidade arquitetónica. Um único módulo trata de tudo: o mesmo bloco transformer, repetido $L$ vezes. Não existem camadas de atenção cruzada entre codificador e decodificador, nem uma pilha separada de codificadores. Isto torna as estratégias de paralelismo mais diretas (Secção 33), e reduz a superfície de engenharia necessária para a otimização. FlashAttention, a quantização e a decodificação especulativa precisam apenas de ser aplicadas a um único padrão de atenção.

4. Aprendizagem in-context. Os modelos apenas de decodificador são naturalmente adequados para a aprendizagem com poucos exemplos, uma vez que os exemplos, as instruções e a consulta são todos meros tokens na mesma sequência. O modelo não distingue entre “entrada” e “saída”; ele prevê o próximo token com base em tudo o que precede. O GPT-3 foi o primeiro a demonstrar isto em larga escala, o que tornou os modelos apenas de decodificador uma opção ideal para o papel de assistente multiusos.

20. Mistura de especialistas

MoE substitui a FFN densa em cada camada do transformador por vários FFNs especializados mais pequenos, juntamente com um roteador de gating de baixo consumo. O roteador calcula uma pontuação para cada especialista (geralmente um softmax sobre projeções lineares aprendidas) e seleciona os $k$ melhores especialistas por token. Apenas os especialistas ativados são processados, permitindo que um modelo tenha uma capacidade total enorme sem que o custo por token seja elevado. Trata-se de computação condicional esparsa: os parâmetros totais determinam o que o modelo pode representar, enquanto os parâmetros ativos definem o _custo* para o seu funcionamento.

O especialista partilhado no DeepSeek-V3 é ativado para cada token. Ele fornece uma representação de base sobre a qual os especialistas direcionados podem criar especializações adicionais.

O treino de MoE apresenta três problemas recorrentes: desequilíbrio de carga, colapso dos especialistas e custo de comunicação elevado para paralelismo especializado. Os modelos tradicionais MoE adicionam uma perda auxiliar para penalizar o encaminhamento desequilibrado, mas essa perda pode concorrer com o objetivo principal. DeepSeek-V3 Em vez disso, são utilizados termos de viés fora do processo de retropropagação: o sistema reduz a pontuação dos especialistas sobrecarregados e aumenta a pontuação daqueles subutilizados. O artigo demonstra um melhor equilíbrio no encaminhamento das tarefas, sem a necessidade de fazer compromissos relacionados com perdas auxiliares na sua arquitetura.

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

LLMs não consegue visualizar o texto. Eles percebem apenas sequências de IDs de tokens inteiros. Um tokenizador divide o texto bruto em tokens (partes subpalavras) e atribui um ID a cada um deles. A escolha do tokenizador influencia a qualidade do modelo, a velocidade de inferência e a equidade multilíngue.

Codificação de Par de Bytes (BPE) Trata‑se do algoritmo mais comum. Ele funde de forma iterativa os pares adjacentes mais frequentes no corpus de treino. Um exemplo simplificado:

1. Comece com o vocabulário a nível de caractere: [l, o, w, e, r, _]
2. O par mais frequente é (l, o) → fundir em lo → vocabulário: [l, o, w, e, r, _, lo]
3. O par seguinte mais frequente é (lo, w) → fundir com low → o vocabulário é adicionado low
4. Continue até que o vocabulário atinja o tamanho desejado (por exemplo, 128K tokens)

Palavras comuns como “the” tornam‑se tokens únicos, enquanto palavras raras como “defenestration” são divididas em partes sub‑palavra. ["def", "en", "est", "ration"]O compromisso reside no tamanho do vocabulário em contrapartida com o comprimento da sequência.

Três implementações de tokenizador cobrem a maioria dos cenários de produção:

• SentencePiece trata a entrada como um fluxo de bytes bruto, sem qualquer pré-processamento específico de linguagem (sem pré-tokenização por espaços ou pontuação), o que o torna agnóstico a línguas e é particularmente importante para escritas não latinas. Suporta tanto BPE como unigramas. É utilizado por Llama 1/2, T5 e Mistral. tiktoken Trata‑se do tokenizador da OpenAI baseado em Rust que utiliza processamento ao nível de bytes BPE. O seu núcleo em Rust compilado é 3–6 vezes mais rápido do que as alternativas baseadas em Python. O Llama 3 passou a utilizar o algoritmo do tiktoken em vez do SentencePiece.
• Hugging Face Tokenizadores É uma biblioteca amplamente utilizada baseada em Rust que suporta BPE, WordPiece e Unigram.

Os tamanhos dos vocabulários têm vindo a aumentar de forma constante, o que tem implicações significativas para a eficiência:

Fertilidade (tokens por palavra) mede a eficiência de compressão. Quanto menor, melhor: menos tokens significam sequências mais curtas, custo reduzido e mais conteúdo que cabe na janela de contexto. Em inglês, o valor costuma ficar entre ~1,0 e 1,3 tokens/palavra, mas escritas não latinas (chinês, japonês, coreano, árabe) podem apresentar valores 2 a 4 vezes maiores quando utilizam vocabulários centrados em inglês. O mesmo conteúdo exige de 2 a 4 vezes mais tokens para usuários que não falam inglês, o que representa um problema persistente de equidade que vocabulários maiores e mais equilibrados só conseguem resolver parcialmente.

22. Janelas de contexto e codificações posicionais

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

Existe um problema fundamental aqui: o mecanismo de atenção trata a sua entrada como um conjunto, e não como uma sequência. Ele não possui uma noção embutida de ordem das palavras. Sem informações posicionais, frases como “the cat sat on the mat” e “the mat sat on the cat” gerariam representações idênticas. As codificações posicionais introduzem essa ordem, permitindo que o modelo saiba onde cada token se encontra.

Três abordagens comuns são:

• RoPE (A posição rotativa Embeddings) codifica a posição de cada token rotando os seus vetores de consulta e chave por um ângulo proporcional a essa posição. Os tokens que estão próximos uns dos outros sofrem rotações semelhantes, fazendo com que o seu produto escalar (escore de atenção) permaneça elevado. Já os tokens distantes entre si apresentam rotações muito diferentes, o que permite codificar a distância relativa. O RoPE é o padrão em quase todos os LLMs modernos abertos (Llama, Mistral, Qwen), uma vez que lida bem com as posições relativas e é computacionalmente eficiente.

• ALiBi (Atenção com Viéses Lineares) ignora as modificações realizadas por embedding e aplica uma penalização diretamente nas pontuações de atenção: quanto maior for a distância entre dois tokens, maior será o viés negativo aplicado. Não existem parâmetros a serem aprendidos, nem cálculos adicionais necessários. Este método permite alguma extrapolação para além do comprimento do treino, mas sua performance degrada-se significativamente quando o contexto utilizado é 2 vezes ou mais extenso que o usado durante o treinamento.

• YaRN (Uma outra extensão RoPE) permite que um modelo RoPE funcione para além do seu contexto de treino. Este método agrupa as dimensões de frequência em três categorias e aplica escalonamentos diferentes a cada uma delas. O artigo demonstra que são necessários 10 vezes menos fine-tuning tokens e 2,5 vezes menos passos de treino em comparação com a versão de base que utiliza interpolação por posição.

Parte V — Treino e alinhamento

O treino é o processo através do qual as capacidades dos modelos são desenvolvidas. Esta secção aborda o pré-treino, técnicas eficientes de fine-tuning (LoRA, precisão mista), leis de escala e métodos de alinhamento.

23. Pré-treino, fine-tuning, e alinhamento

Pré-treino consiste em previsão autossupervisionada do próximo token num corpus de grande dimensão. O seu consumo computacional abrange vários ordens de grandeza; Llama 3 405B, Por exemplo, foram utilizados $3,8 \times 10^{25}$ FLOPs. O aprendizagem supervisionada fine-tuning (SFT) adapta o modelo pré-treinado a dados rotulados específicos para uma determinada tarefa. O RLHF / RLAIF utiliza dados de preferência para moldar o comportamento: um RLHF pipeline convencional recolhe comparações, treina um modelo de recompensa e, em seguida, otimiza a política. O RLAIF substitui alguns julgamentos humanos por feedback gerado por AI.

O cálculo depende do tamanho do modelo, do comprimento da sequência, do volume de dados, do otimizador e do método utilizado. O PPO também armazena mais estado do modelo do que o SFT, uma vez que uma configuração típica inclui modelos de política, referência, recompensa e crítico. Abordei na íntegra o processo de tomada de decisão fine-tuning com base em framework. LLM Fine-Tuning Guia.

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

LoRA Congela os pesos pré-treinados e injeta matrizes de baixo rank treináveis $A$ ($r \times k$) e $B$ ($d \times r$), de modo que o peso atualizado seja $W_0 + BA$. O artigo LoRA conseguiu reduzir o modelo GPT-3 175B para aproximadamente 18 milhões de parâmetros treináveis na sua arquitetura proposta. O rank é um parâmetro de ajuste e não uma regra relacionada com a complexidade da tarefa; deve ser selecionado através de análises de qualidade e de consumo de memória. Os adaptadores LoRA podem ser integrados nos pesos base após o treino, evitando assim a necessidade de um caminho separado para eles durante a inferência.

QLoRA Carrega o modelo base com quantização de 4 bits no formato NF4, ao mesmo tempo que treina adaptadores LoRA em BF16. O formato NormalFloat4 distribui mais níveis de quantização perto de zero, onde a densidade dos pesos é mais elevada. O artigo realizou um ajuste fino num modelo de 65B em apenas uma unidade de GPU de 48 GB e reportou resultados próximos aos obtidos com as versões de 16 bits. Os seus compromissos entre runtime e consumo de memória são específicos da stack testada.

25. Treino de precisão mista

Cada formato de ponto flutuante aloca os seus bits em três campos: sinal (sempre 1 bit), exponente (que define a gama dinâmica) e mantissa (que determina a precisão). Um maior número de bits no exponente permite uma gama mais ampla de valores representáveis; um maior número de bits na mantissa permite distinções mais finas entre valores próximos. Os formatos inteiros não possuem exponente algum e representam apenas números inteiros uniformemente espaçados dentro de uma gama fixa.

BF16 possui o mesmo intervalo que FP32, uma vez que o intervalo é determinado pelo campo de expoente, e BF16 mantém todos os 8 bits de expoente de FP32. Em troca, são sacrificados os bits da mantissa (7 contra 23), o que permite reduzir a memória em 2 vezes, evitando ao mesmo tempo os problemas de sobrecarga e subcarga que afetam o treinamento de FP16. FP16 dispõe apenas de 5 bits de expoente, o que limita o seu intervalo a aproximadamente 65K. Os gradientes costumam exceder esse valor, e é por isso que o treinamento de FP16 requer escalação da perda: multiplica-se a perda por uma constante elevada antes da retropropagação e, em seguida, dividem‑se os gradientes. BF16 torna a escalação da perda desnecessária.

Os formatos inteiros são pouco utilizados na aritmética principal de treino, uma vez que a retropropagação exige uma ampla gama dinâmica. Eles são frequentemente empregues na inferência, onde os pesos congelados podem ser mapeados para escalas calibradas. A quantização de pesos INT4 reduz o tamanho de um modelo de 7B de aproximadamente 14 GB para 3,5 GB, sem contar com os custos adicionais de runtime; por isso, é essencial avaliar a qualidade do modelo e do método escolhidos.

FP8 de treino em H100 através de Motor Transformer Utiliza o E4M3 quando a precisão é crítica e o E5M2 quando se exige um intervalo de valores mais amplo. A NVIDIA relata tempos de execução até 75% mais rápidos, segundo testes realizados com uma configuração de 175 bilhões de parâmetros. DeepSeek-V3 Foi utilizado FP8 de precisão mista, e foi reportado um custo computacional equivalente a aproximadamente 5,6 milhões de dólares para a sua fase final de treino, sem incluir despesas com I&D e infraestrutura.

26. Checkpointing de gradiente

Cada camada da passagem forward gera uma saída intermédia denominada ativação:

$\text{Entrada} \rightarrow [\text{Camada 1}] \rightarrow \text{ativação}_1 \rightarrow [\text{Camada 2}] \rightarrow \text{ativação}_2 \rightarrow [\text{Camada 3}] \rightarrow \text{Saída}$

Normalmente, todas as ativações têm de permanecer na memória, uma vez que a retropropagação as necessita para calcular os gradientes. No caso de um transformador profundo, as ativações armazenadas podem consumir mais memória do que os próprios pesos do modelo.

O gradient checkpointing troca recursos de processamento por memória, descartando a maior parte dessas ativações e recalculando-as dinamicamente durante a retropropagação. A estratégia padrão (Chen et al., 2016) Divide uma rede com $n$ camadas em $\sqrt{n}$ segmentos uniformemente espaçados e guarda apenas a ativação de borda de cada segmento. Essas bordas salvas correspondem aos “checkpoints.” Todas as ativações intermédias dentro de um segmento são descartadas imediatamente.

Quando a passagem retrograda atinge uma camada dentro de um segmento, as suas ativações são recalculadas a partir do checkpoint mais próximo. Isto reduz a memória de ativação de $O(n)$ para $O(\sqrt{n})$, o que representa uma redução de 60–70% na prática, ao custo de aproximadamente mais uma passagem forward (~20–33% mais recursos computacionais). O FlashAttention aplica o mesmo princípio no âmbito da atenção, evitando a criação da matriz de atenção completa. É possível ativá‑lo na HuggingFace com gradient_checkpointing=True.

27. Fases ZeRO do DeepSpeed

No paralelismo de dados padrão, cada GPU armazena uma cópia completa dos pesos do modelo, dos gradientes e dos estados do otimizador. No caso do Adam, cada parâmetro consome 2 bytes para o peso FP16, 4 bytes para o peso mestre FP32, 4 bytes para o momento, 4 bytes para a variância e 2 bytes para o gradiente, totalizando 16 bytes por parâmetro. Um modelo com 7,5 bilhões de parâmetros requer aproximadamente 120 GB por GPU, e cada GPU armazena exatamente os mesmos dados. Em 64 GPUs, isso resulta em 64 cópias idênticas de 120 GB cada, o que representa um grande desperdício.

DeepSpeed ZeRO (Otimizador de Zero Redundância) elimina esta duplicação ao fragmentar estes componentes por GPUs em vez de os replicar:

• Fase 1 — otimização da partição dos estados do otimizador. Cada GPU armazena apenas 1/N dos estados do otimizador (momento e variância do Adam, 8 bytes/pараметro). Quando um GPU precisa atualizar um peso, ele atualiza apenas a sua fatia e transmite o resultado. A memória diminui de ~120 GB para ~31 GB por GPU.
• Fase 2 — partição também dos gradientes. Os gradientes (2 bytes/pараметro) já não são reduzidos integralmente para cada GPU. Cada GPU recebe apenas a fatia do gradiente de que necessita através do algoritmo reduce-scatter. A memória fica em ~16 GB por GPU.
• Fase 3 — partição também dos pesos do modelo. Cada GPU contém apenas 1/N dos pesos de FP16. Antes de cada passo forward ou backward de uma camada, o GPU executa uma operação all-gather para reconstruir temporariamente os pesos completos da camada a partir de todos os outros GPUs, realiza os cálculos e descarta esses pesos reunidos. A memória diminui para ~1,9 GB por GPU.

O compromisso reside na comunicação entre os elementos. A Fase 1 introduz um overhead mínimo, a Fase 2 substitui o algoritmo all-reduce por reduce-scatter (com custo semelhante), mas a Fase 3 exige chamadas all-gather antes de cada camada, tanto nas passagens forward como backward, resultando num volume de comunicação aproximadamente 1,5 vezes maior em comparação com o paralelismo de dados padrão.

ZeRO-Infinity Estende a Fase 3 ao transferir estados particionados para a RAM de CPU e até mesmo para SSDs NVMe, o que torna possível o treino de modelos com triliões de parâmetros em clusters GPU limitados. O custo disso é uma redução significativa na velocidade (o NVMe é cerca de 500 vezes mais lento que HBM), pelo que o ZeRO-Infinity é a solução a utilizar quando o modelo realmente não cabe na memória GPU + CPU.

28. FSDP: particionamento nativo de PyTorch

Paralelismo de Dados Totalmente Fragmentado (FSDP) Trata‑se da resposta integrada de PyTorch ao DeepSpeed ZeRO-3. Ela fragmenta parâmetros, gradientes e estados do otimizador em GPUs, seguindo a mesma lógica fundamental. A mecânica para cada camada consiste num ciclo simples:

1. All-gather todos os parâmetros de todos os GPUs (reconstruindo temporariamente a camada completa).
2. Compute a passagem forward ou backward para essa camada.
3. Liberte imediatamente os parâmetros reunidos. Cada GPU mantém apenas o seu próprio fragmento.
4. Reduce-scatter os gradientes de modo que cada GPU receba apenas a sua fatia de gradiente atribuída.

Como FSDP é nativo de PyTorch, ele integra-se diretamente com as ferramentas de depuração, os perfisadores e outros recursos de PyTorch. torch.compile. O desempenho em relação ao DeepSpeed ZeRO-3 depende da política de envolvente, da topologia de comunicação, das definições de offload e do tamanho do modelo; portanto, é necessário compará-los no mesmo cluster.

FSDP2 (2024–2025) representa uma reescrita que melhora torch.compile integração para uma melhor fusão de kernels, acrescenta suporte à formação FP8 através de TorchAO, e simplifica o API. Tanto o FSDP como o DeepSpeed são acessíveis através de HuggingFace Accelerate, o que permite alternar entre eles com uma única alteração de configuração.

29. Leis de escala e a armadilha da Chinchila

Escalonamento Chinchilla (DeepMind, 2022) identificou uma alocação computacional otimizada, próxima de 20 tokens de treino por parâmetro, dentro das premissas estabelecidas. Esse objetivo não leva em conta o custo associado às etapas posteriores de serving. Se um modelo mais pequeno, treinado com mais dados, atingir a qualidade desejada, pode ser menos dispendioso ao longo de um ciclo de inferência de grande volume.

A solução consiste em sobretreinar modelos mais pequenos com muito mais dados. A evolução é notável:

Para um modelo utilizado em grande escala, investir mais recursos de computação em treinamento num modelo menor pode reduzir os custos ao longo do seu ciclo de vida. O Llama 3 8B ilustra esta estratégia, mas o facto de ela ser eficaz depende da qualidade exigida e do volume previsto de inferências. “Chinchilla-optimal” refere-se à eficiência na utilização de recursos de computação para treinamento, o que é um objetivo distinto dos custos ao longo do ciclo de vida.

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

Alinhamento direciona um modelo pré-treinado em direção a instruções, preferências e políticas de segurança desejadas. Por si só, ele não garante a veracidade nem um comportamento seguro. Os métodos apresentados abaixo realizam um compromisso entre complexidade de implementação, requisitos de dados, capacidade de exploração e estabilidade do treino.

O clássico RLHF pipeline: SFT → recolher pares de preferências humanas → treinar um modelo de recompensa com base nesses pares → ajustar a política com PPO (Proximal Policy Optimization). O PPO mantém 4 cópias do modelo na memória ao mesmo tempo (política, modelo de referência, modelo crítico/valor e modelo de recompensa), é sensível a hiperparâmetros e está sujeito a reward hacking, situação em que o modelo explora peculiaridades do modelo de recompensa (como respostas longas e com tom de confiança excessiva) em vez de melhorar verdadeiramente a qualidade.

DPO (Otimização de Preferência Direta) ignora o modelo de recompensa aprendido e o ciclo de RL em tempo real, otimizando diretamente uma perda com base em pares de preferências. Isso simplifica o processo de treino pipeline. O DPO padrão é offline: ele é treinado com base num dataset fixo e não explora novas respostas durante o ciclo de atualização. A relevância dessa limitação depende da tarefa e da cobertura dos dados.

GRPO (Group Relative Policy Optimization, DeepSeek) remove o crítico aprendido por PPO ao gerar múltiplas conclusões para cada prompt e utilizar recompensas relativas ao grupo como referência. Isto reduz a carga no estado do modelo em comparação com uma configuração típica de PPO. Diferentemente de DPO, GRPO funciona dentro da política: o modelo gera respostas novas durante o treino. DeepSeek-R1 Combina GRPO com RLVR (aprendizagem por reforço a partir de recompensas verificáveis), recorrendo a verificações como respostas matemáticas, compilação de código e testes unitários. Estas recompensas são mais fáceis de auditar do que um valor de preferência aprendido, mas testes incompletos e objetivos substitutos ainda podem ser explorados.

31. Destilação: compressão do conhecimento entre modelos

A destilação de conhecimento transfere as capacidades de um modelo “professor” de grande porte para um modelo “aluno” mais pequeno. A destilação baseada em logítos treina o aluno para que reproduza a distribuição de saídas do professor. Já a destilação baseada em dados faz com que o professor gere exemplos nos quais o aluno é posteriormente ajustado. Os métodos baseados em dados são frequentemente utilizados para LLMs, uma vez que podem ser aplicados em diferentes arquiteturas e com professores que utilizam exclusivamente API, mas o seu valor fica limitado pela qualidade do professor, pela cobertura dos dados, pelos processos de filtragem e pelo custo de geração.

DeepSeek-R1 Foram gerados 800.000 exemplos de raciocínio e utilizados para refinar os modelos Qwen2.5 e Llama 3, reduzindo o número de parâmetros de 1,5 mil milhões para 70 mil milhões. Na avaliação apresentada no artigo:

• DeepSeek-R1-Distill-Qwen-32B atinge 72,6% no AIME 2024 e 94,3% no MATH-500, valores superiores aos resultados reportados pelo OpenAI para o modelo o1-mini no mesmo estudo.
• DeepSeek-R1-Distill-Qwen-7B obtém 55,5% no AIME 2024, número também superior ao resultado obtido com o modelo QwQ-32B-Preview, que é menor em dimensões.

Nos experimentos com modelos pequenos do DeepSeek-R1, a destilação apresentou desempenho superior ao método direto GRPO nos modelos de base testados. Esse resultado apoia a utilização da destilação nesta configuração; no entanto, ele não estabelece uma classificação universal entre a destilação e o RL.

32. Geração de dados sintéticos

LLMOs dados de treino gerados são utilizados em vários padrões recorrentes:

• Autoinstrução Inicializa‑se a partir 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 Alpaca O projeto utilizou 52.000 exemplos provenientes de 175 fontes de dados e registou um custo de geração de aproximadamente 600 dólares; a sua comparação com o GPT-3.5 constituiu uma avaliação limitada do projeto, e não uma equivalência completa.
• Evol-Instruct (WizardLM) utiliza instruções existentes e evolui-as de forma iterativa ao longo dos eixos de complexidade (adicionando restrições, aprofundando o raciocínio e tornando os problemas mais concretos), de modo a gerar exemplos de treino cada vez mais difíceis.
• Microsoft’s Phi-4 (14B) utilizou dados sintéticos na maior parte do pré-treinamento, incluindo processos de geração, avaliação crítica, auto-revisão e inversão de instruções. O seu relatório técnico compara o desempenho obtido em áreas como STEM e programação com modelos maiores no âmbito dos benchmarks selecionados.

O risco relevante aqui é o colapso do modelo: quando os modelos são treinados recursivamente com dados sintéticos de gerações anteriores, as extremidades da distribuição original desaparecem progressivamente. O modelo sobrestima os padrões comuns e perde as variações raras, mas importantes.Shumailov et al., 2024). Um estudo independente realizado pela Ahrefs classificou 74,2% das páginas web recém-criadas na sua amostra de 900.000 páginas como contendo texto gerado por AI; trata-se de um resultado obtido através de um classificador fornecido pelo próprio serviço, e não de um levantamento abrangente da internet. A mitigação desses problemas começa com a combinação de dados sintéticos e reais, a aplicação de filtros e o rastreamento da origem dos dados, de modo a permitir a medição do material gerado de forma recursiva.

Parte VI — Escalabilidade e implementação

Escalar de um GPU para um cluster implica dividir o trabalho entre vários dispositivos. Esta secção aborda estratégias de paralelismo, serving frameworks, seleção de GPU e roteamento.

33. Quatro formas de paralelismo

Paralelismo de Tensores (TP) divide as matrizes de pesos individuais entre GPUs e geralmente comunica-se após cada camada. Links rápidos dentro do mesmo nó, como o NVLink, tornam esta abordagem extremamente prática dentro de um único nó. Aumentar o número de fragmentos reduz a memória e o poder de processamento por dispositivo, mas eleva a carga de comunicação; portanto, deve‑se escolher o grau de paralelismo com base numa latência benchmark adequada.

Pipeline Paralelismo (PP) divide as camadas sequencialmente entre GPUs, transferindo as ativações de uma fase para outra. O seu padrão de comunicação pode funcionar entre nós, mas os pipeline “bubbles” e os tempos desiguais entre as fases reduzem a utilização efetiva. As implementações em larga escala costumam combinar o TP dentro de um único nó com o PP entre vários nós.

Paralelismo de Dados (PD) replica o modelo serving de modo que cada réplica trate pedidos independentes, sem necessidade de comunicação entre réplicas para cada solicitação. Este método é eficiente quando o modelo cabe nos recursos disponíveis e o tráfego pode ser equilibrado. Durante o treinamento, o PD é frequentemente combinado com ZeRO ou FSDP para dividir o estado do modelo em partes.

Paralelismo Especializado (PE) distribui MoE especialistas por todo o GPUs através de comunicação tipo “todos-com-todos” para o encaminhamento de tokens. O seu desempenho depende do equilíbrio de tokens, da localização dos especialistas e da topologia das interconexões; o tráfego de tipo “todos-com-todos” pode tornar‑se o principal gargalo.

Uma heurística de paralelismo inicial:

• O modelo cabe em um único GPU: comece com réplicas independentes e meça a escala do DP.
• O modelo cabe dentro de um único nó: teste o TP no interior do nó e, caso haja necessidade devido ao tráfego, replique o grupo.
• O modelo abrange vários nós: teste uma combinação de TP e PP considerando as especificações de interconexão e os limites de latência.
• Mistura de especialistas: adicione EP somente quando a disposição dos especialistas o exigir.

34. Comparação entre Serving e frameworks

vLLM Disponibiliza alocação de KV por páginas, agrupamento contínuo, um API compatível com a OpenAI, bem como vários modos de paralelismo. As especificações de modelo e hardware suportadas mudam frequentemente, pelo que é necessário verificar o modelo alvo contra a matriz de compatibilidade atual.

SGLang Combina o RadixAttention para reutilização de prefixos, um agendador personalizado e geração estruturada. Os ganhos de taxa de processamento reportados dependem do tipo de carga de trabalho e das configurações utilizadas; compare-o com vLLM e TensorRT-LLM utilizando os mesmos prompts, resultados, hardware e SLOs.

TensorRT-LLM Permite atingir uma baixa latência por solicitação graças à fusão de grafos CUDA e à otimização do kernel, contando com suporte nativo para FP8/FP4. Os valores divulgados são específicos para cada tipo de hardware e modelo, pelo que deve compará‑los com os outros frameworks num mesmo harness. O custo disso é uma curva de aprendizagem mais acentuada e uma superfície de implementação específica da NVIDIA.

TGI Integra-se com o ecossistema Hugging Face e suporta vários backends de hardware. Verifique o estado atual de manutenção e de funcionalidades do repositório antes de o selecionar para uma nova implementação.

Ollama Destaca um fluxo de trabalho simples com modelos locais. Utilize-o para facilitar o desenvolvimento; benchmark outra pilha serving quando for essencial lidar com alta concorrência ou um controlo explícito de SLOs.

llama.cpp Trata-se de uma implementação portátil em C/C++ runtime que funciona com arquiteturas ARM, x86, Metal, CUDA, ROCm e Vulkan. O GGUF permite a utilização de vários níveis de quantização. O desempenho varia significativamente consoante o modelo, o nível de quantização, o contexto e as condições de backend; por isso, utilize a ferramenta local benchmark correspondente à máquina alvo.

35. Seleção GPU para inferência

A tabela apresenta um registo atualizado, de março de 2026, dos preços de hardware e serviços em nuvem. As etiquetas de precisão referem-se às capacidades oferecidas pelos fornecedores, sendo que os preços podem variar consoante o provedor, a região, o período de compromisso e a disponibilidade; verifique esses valores antes de efetuar a compra.

A seleção deve ser feita primeiro com base na compatibilidade de memória e, em seguida, no rendimento medido face ao objetivo de latência. A capacidade de 141 GB do H200 pode simplificar a implementação de alguns modelos de grande dimensão, enquanto o B200 oferece suporte para FP4, 192 GB de HBM3e e uma geração mais recente de NVLink. Os GPUs baseados em GDDR, de menor tamanho, podem ser mais económicos para modelos quantizados, desde que os seus limites de memória e interconexão sejam compatíveis com a carga de trabalho.

O suporte à quantização nativa do hardware exerce uma influência significativa no desempenho. AWQ e GPTQ (com pesos de INT4) podem ser executados de forma eficiente em qualquer arquitetura através da desquantização para registos FP16, mas a verdadeira aceleração nativa por meio de Tensor Cores depende da geração do hardware. Os modelos Hopper (H100/H200) e Ada (L40S/4090) aceleram nativamente FP8, enquanto o Blackwell (B200) inclui Tensor Cores FP4 nativos que permitem ganhos significativos de largura de banda. Todos os GPUs listados suportam operações matriciais INT8.

A descompressão de LLM costuma ser limitada pela largura de banda da memória; portanto, para cargas de trabalho de serving, a capacidade e a largura de banda de HBM podem ser mais importantes do que o valor máximo de TFLOPS. Compare GPUs mantendo constantes o modelo, a precisão, a distribuição dos lotes, o comprimento do contexto e o objetivo de latência.

36. Cascata e encaminhamento de modelos

O encaminhamento de modelos seleciona qual LLM irá tratar cada consulta, com base na complexidade ou capacidade previstas. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) relata uma redução de custos de 85% na sua infraestrutura MT-Bench, mantendo simultaneamente 95% da qualidade de referência do GPT-4. A eficácia da utilização de rotadores depende dos preços atuais, da composição do tráfego, dos erros nos roteadores e do nível mínimo de qualidade exigido.

Os roteadores vão desde classificadores leves até avaliadores baseados em LLM. A variante em cascata consiste num processo sequencial: uma consulta começa com um modelo menos recursos-intensivo e é escalada para um modelo mais potente sempre que uma função de pontuação rejeita a resposta obtida. FrugalGPT Os relatórios indicam uma redução de custos de até 98% ou um aumento na precisão de até 4% no conjunto de modelos avaliados. Uma implementação em produção exige critérios de escalonamento bem definidos e monitorização contínua das consultas que o modelo económico processa de forma incorreta.

Parte VII — Aplicações

Padrões a nível de aplicação que transformam as capacidades brutas dos modelos em sistemas úteis. A recuperação de Embeddings confere poder às respostas, o RAG baseia as respostas em conhecimento externo, os agentes orquestram fluxos de trabalho multietapas e o prompt engineering une tudo isso de forma coerente.

37. Embedding modelos vs modelos gerativos

Os Embedding codificam texto em vetores de dimensão fixa que capturam o significado semântico. Diferentemente dos modelos gerativos de decodificação que produzem sequências de tokens, eles geram um único vetor denso (com 768–4.096 dimensões) para todo o conjunto de entrada. A maioria dos embedding utiliza transformadores com apenas encoder (atenção bidirecional) em vez de decodificadores. O encoder processa todos os tokens de entrada simultaneamente e cria uma representação contextualizada para cada um deles. Em seguida, uma camada de pooling agrega essas representações individuais num único vetor, geralmente por meio de mean pooling (média de todos os embeddings do token) ou CLS pooling (utilizando a saída de um token especial de classificação). Por fim, o modelo é ajustado por meio de aprendizagem contrastiva: textos semanticamente semelhantes são aproximados no espaço vetorial, enquanto textos diferentes são afastados.

Modelos embedding selecionados e as suas pontuações reportadas (2025–2026):

A tabela combina relatórios de modelo com versões de benchmark, pelo que representa uma lista restrita e não uma classificação estrita. Alguns sistemas mais recentes de embedding recorrem a estruturas base de decodificador com atenção bidirecional e mecanismos de agrupamento de informação. Outros geram embeddings de precisão inferior ou multimodal. Avalie o idioma, a modalidade, a tarefa, a dimensão e o custo de serving necessários num único conjunto de recuperação de dados.

Aprendizagem de Representações Matryoshka (MRL, Kusupati et al., NeurIPS 2022) Torna as dimensões embedding flexíveis. Batizada em homenagem às bonecas russas matryoshka, a estrutura MRL organiza um embedding de modo a fazer com que as suas primeiras $m$ dimensões sejam tão informativas quanto um modelo $m$-dimensional treinado de forma independente. Durante o treino, em vez de calcular uma única perda para todo o embedding, a MRL calcula várias perdas em paralelo em dimensões espaçadas logicamente (64, 128, 256, 512, 1024, 2048, 3072). A perda agregada faz com que as dimensões iniciais transmitam informações semânticas gerais, enquanto as dimensões posteriores adicionam detalhes mais precisos.

Após o treino, um MRL embedding pode ser truncado para uma dimensão de prefixo suportada. A OpenAI relata que o modelo text-embedding-3-large com 256 dimensões supera o modelo text-embedding-ada-002 com 1.536 dimensões na comparação MTEB mencionada por eles. Isso resulta numa redução de 6 vezes no armazenamento de vetores brutos; a latência das buscas e os custos do banco de dados também dependem do índice, dos metadados, dos mecanismos de filtragem e do hardware utilizado.

O modelo embedding é um componente importante num RAG pipeline, juntamente com a análise sintática, o particionamento de dados, a busca, reranking, e a geração. Se não forem recuperadas evidências relevantes, um gerador mais potente não conseguirá recuperá-las de forma fiável.

38. Arquitetura RAG em produção

A Geração Aprimorada por Recuperação fornece um LLM com documentos recuperados no momento da consulta. Ela pode disponibilizar evidências atuais ou privadas que não constam nos pesos do modelo, mas a recuperação não garante que a resposta utilize essas evidências de forma correta. Um sistema RAG em produção é um pipeline multifásico cujas fases exigem avaliações separadas.

A ingestão pipeline é realizada offline. Os documentos brutos (PDF, HTML, Markdown, bases de dados) são primeiro analisados para converterem‑se em texto limpo, o que é mais complexo do que parece: a mera análise de PDFs já pode resultar na perda de tabelas, cabeçalhos e formatação. Em seguida, o texto é dividido em blocos, os quais são integrados e indexados de forma independente.

O processamento em blocos afeta tanto a recuperação e o recall quanto o contexto disponível para o gerador. Os tamanhos ideais dependem da estrutura do documento, da granularidade da consulta, dos limites do embedding e dos limites de reranker. As abordagens mais comuns são o processamento em blocos de tamanho fixo com sobreposição, a divisão recursiva ao longo das fronteiras do documento e o processamento em blocos semântico com base na similaridade definida por embedding. É recomendável compará-las através de etiquetas de relevância a nível de página ou seção, em vez de adotar universalmente um único intervalo de tokens.

Cada fragmento é então incorporado com um modelo semelhante aos existentes. Secção 37 e armazenado numa base de dados vetorial (Pinecone, Weaviate, Qdrant, pgvector, entre outros).

A recuperação pipeline é executada no momento da consulta. Comece com uma linha de base mensurável e, em seguida, adicione etapas sempre que a análise de erros indicar que elas resolvem falhas reais:**

• Pesquisa híbrida combina a recuperação vetorial densa com métodos de recuperação esparsos, como o BM25, sendo frequentemente fundidos através da Reciprocal Rank Fusion (RRF). A pesquisa densa lida com paráfrases semânticas; a pesquisa esparsa identifica identificadores exatos, códigos de erro e acrónimos. Os fornecedores benchmarks relatam melhorias em relação a soluções baseadas apenas em vetores, mas o seu tamanho depende do corpus e das etiquetas de relevância.
• Reranking faz passar os candidatos recuperados por um modelo que avalia simultaneamente a consulta e o documento. Isso pode melhorar a relevância em nível detalhado, mas à custa de mais uma chamada ao modelo. O número de candidatos, o número mantido e o tempo de latência devem ser ajustados em conjunto. Abordei na íntegra o processo multiestágio de pipeline em Construir uma pilha de classificação de busca moderna.
• A transformação da consulta reescreve a pergunta do utilizador antes da recuperação de informação, com o objetivo de melhorar a taxa de recuperação. O HyDE (Documento Hipotético Embeddings) utiliza o LLM para gerar uma resposta hipotética, que é posteriormente incorporada e utilizada no processo de recuperação. A expansão multiconsulta gera várias formulações da mesma questão. O prompting de retrocesso consiste em fazer primeiro uma pergunta mais geral, de modo a obter um contexto mais abrangente.

Os modos de falha mais comuns:

• Falha de recuperação — o documento correto existe, mas não é recuperado. Teste a segmentação em blocos, a transformação das consultas, a busca híbrida e o filtragem de metadados perante este cenário de falha.
• Envenenamento de contexto — blocos recuperados irrelevantes induzem em erro o LLM. Teste o reranking, os filtros de contexto e conjuntos menores a serem mantidos.
• Perda no meio — o LLM ignora o contexto relevante localizado no meio de um prompt extenso.Liu et al., 2024 Verificou‑se que os modelos dão maior atenção ao início e ao fim da janela de contexto.

GraphRAG (Microsoft, 2024) melhora a recuperação vetorial através da utilização de um grafo de entidades e relações extraído. Este método destina‑se a perguntas em escala de corpus e com grande número de relações, que a recuperação por blocos simples pode não conseguir identificar. O custo associado é o trabalho adicional de extração, indexação, armazenamento e avaliação.

Os guias destinados a profissionais da área publicam intervalos de latência para embedding, busca, reranking e geração, mas esses valores variam consoante a região, o corpus, o hardware e o modelo utilizado. É necessário medir cada fase nos rastreios e avaliar as alterações na qualidade antes de aceitar o aumento da latência.

39. Arquiteturas de agente e chamada a ferramentas

Os LLM utilizam modelos para selecionar e sequenciar tool calls ao longo de um estado em constante evolução. Existem três padrões de orquestração úteis:

• ReAct — intercala a seleção de ações com as observações. Pode adaptar‑se após cada tool result, mas um histórico cada vez mais extenso aumenta os custos em termos de tokens e latência. ReWOO — planeia tool calls com placeholders, executa tarefas independentes em paralelo e, em seguida, realiza a síntese. O artigo correspondente relata uma poupança de tokens face a ReAct, mas o plano fixo requer um caminho de recuperação explícito quando uma ferramenta falha.
• Planner-executor — separa o planeamento da execução e permite a adição de uma política de replaneamento após uma falha. Embora permita a especialização do modelo, introduz um estado de orquestração e mais uma fronteira de decisão.

Function calling é um mecanismo comum para a invocação de ferramentas. Os APIs permitem expor as definições das ferramentas e devolver argumentos estruturados, reduzindo assim a necessidade de analisar texto em formato livre. Argumentos válidos segundo o esquema ainda podem selecionar a ferramenta errada ou conter valores inválidos. A execução paralela function calling pode diminuir o número de idas e voltas quando as operações são independentes.

Structured output e constrained decoding impõem um esquema ao restringir os tokens disponíveis em cada passo de geração. Motores como xgrammar, É utilizado em vLLM e no SGLang, podendo eliminar numerosas falhas de sintaxe e de análise com um baixo custo operacional nas configurações suportadas. No entanto, não garantem que os valores ou decisões extraídos estejam corretos. Raciocínio Guiado por Esquema (SGR) utiliza a ordem dos campos e a estrutura do esquema para permitir a inspeção do estado intermédio antes da tomada de decisão final. Os seus três padrões são Cascade (etapas sequenciais), Routing (tipos de união como comutadores semânticos) e Cycle (listas delimitadas).

A qualidade da seleção de ferramentas, a latência de ponta a ponta e o custo por token tendem geralmente a piorar à medida que o conjunto de ferramentas e a profundidade das ações aumentam. É necessário medir essas curvas com base nas descrições reais das ferramentas e na distribuição de falhas. Frameworks como LangGraph É possível tornar os caminhos de estado e de recuperação explícitos, mas isso não elimina o ônus associado à avaliação.

40. Prompt engineering para produção

A geração em produção constitui um problema de avaliação: altera-se uma parte do prompt ou do contexto e, em seguida, mede‑se a qualidade da tarefa e os modos de falha. As técnicas apresentadas a seguir são pontos de partida comuns, mas não representam uma ordem universal.

Exemplos de few-shot são frequentemente eficazes para controlar o formato da saída. Comece com 3–5 exemplos que abranjam entradas vazias, consultas ambíguas e respostas multifacetadas, e depois avalie o resultado num conjunto reservado. Os exemplos devem refletir a distribuição real das entradas, e não apenas os cenários mais simples. Mais exemplos consomem contexto e não garantem melhorias adicionais.

Chain-of-thought (CoT) – o prompting consiste em solicitar a um modelo que exponha o seu raciocínio intermédio antes de dar uma resposta. Kojima e colaboradores relataram ganhos com o sufixo “Vamos pensar passo a passo” nas tarefas de raciocínio que testaram, mas o efeito varia consoante o modelo, e os métodos mais recentes de raciocínio APIs podem não revelar rastros ocultos. Em ambientes de produção, prefira uma decomposição da tarefa que permita inspeção ou uma justificação concisa sempre que isso for útil para o avaliador. Autoconsistência (Wang et al., 2023) Testa vários caminhos de raciocínio e agrega as respostas, sacrificando um custo adicional de inferência em troca de maior robustez em tarefas adequadas.

Structured output com esquemas JSON explícitos (Secção 39) elimina muitas falhas de análise sintática. Constrained decoding Motores como o xgrammar podem impor a gramática suportada durante a geração; no entanto, a precisão factual e a validade semântica ainda exigem avaliação, e as funcionalidades de esquema não suportadas podem continuar a necessitar de tratamento especial.

Prompt chaining divide uma tarefa em fases específicas, como, por exemplo, classificar a intenção → recuperar o contexto → gerar a resposta → validar a saída. Este método permite identificar falhas de forma mais precisa, utilizar modelos diferentes em cada fase e disponibilizar estados intermediários que possam ser armazenados em cache. No entanto, também introduz interfaces adicionais e aumenta a latência, pelo que deve ser comparado com um cenário de chamada única.

Temperatura altera a distribuição de amostragem. Valores baixos constituem um ponto de partida razoável para tarefas de classificação ou extração; valores mais elevados podem aumentar a diversidade na geração de ideias. O comportamento exato varia consoante o modelo APIs e interage com top_p, top_ke as predefinições do fornecedor; por isso, deve-se percorrer as configurações suportadas da tarefa em vez de copiar apenas um intervalo.

Separação entre mensagem do sistema e mensagem do utilizador mantém a política persistente distinta do conteúdo específico de cada pedido. Os modelos de chat e o ajuste de instruções atribuem prioridades diferentes a estas funções, mas não transformam uma mensagem do sistema numa fronteira de aplicação de regras. Coloque o comportamento estável na mensagem do sistema, guarde os dados não fidedignos no conteúdo do utilizador ou da ferramenta, e aplique restrições rigorosas, como a remoção de PII, também fora do modelo.

Context engineering expande o trabalho de prompt para a montagem de documentos recuperados, tool results, histórico de conversas e exemplos. Liu e colaboradores detetaram um efeito de “perda no meio” nos modelos de contexto longo que testaram; portanto, a posição deve fazer parte da avaliação, em vez de ser considerada irrelevante. Abordei o fluxo de trabalho mais abrangente em Context Engineering para Agentes AI.

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

Esta secção aborda o limitação de taxa, os modos de falha, a monitorização, a otimização de custos e o planeamento de capacidade em condições de tráfego real.

41. Limitação de taxa para solicitações com custo variável

A limitação de taxa tradicional por pedidos por segundo pressupõe um custo aproximadamente igual por pedido. LLMs quebra esse pressuposto. Uma classificação com 10 tokens prompt e uma análise de documento com 100K tokens acedem ao mesmo ponto de extremidade API, mas o seu custo difere em quatro ordens de grandeza. A limitação por RPS ou permite que os pedidos mais dispendiosos passem sem ser verificados ou priva indevidamente os pedidos mais baratos de recursos.

Os sistemas de produção necessitam de limitação de taxa baseada em tokens em várias dimensões. OpenAI documenta os limites de solicitações e tokens por nível de utilização. Anthropic Separa os limites de token de entrada e token de saída. As cotas exatas e os algoritmos podem sofrer alterações, pelo que a documentação do fornecedor deve ser considerada a fonte de verdade; o objetivo arquitetónico é orçamentar as solicitações e os tokens de forma independente.

O padrão de implementação prática consiste numa hierarquia de limites multidimensional (utilizador → aplicação → organização → global), com níveis de prioridade para acesso premium. A nível das solicitações, a técnica relevante é a reserva de orçamento de tokens: estimar o número total de tokens (entrada + max_tokens) no momento da admissão, é feita uma dedução no “bucket”, sendo posteriormente ajustado o valor conforme o uso real após a conclusão do pedido. Isso impede que um aumento súbito de pedidos de geração demorada esgote a capacidade antes mesmo de começarem a gerar resultados.

Em implementações auto-hospedadas, o equivalente é a largura de banda provisionada: reservar capacidade dedicada de GPU para as taxas de tokens desejadas. Em implementações de vLLM, isso significa configurar um controle de admissão baseado nos slots de decodificação ativos e na pressão de KV cache, em vez de considerar apenas o número de solicitações. As Secção 5 Explica-se que tanto o throughput como a admissão requerem limites sensíveis a tokens.

42. Modos de falha a considerar no projeto

LLM serving permitem identificar modos de falha associados a comprimentos variáveis de sequência, à memória KV e a processos de decodificação de longa duração. É essencial projetar e realizar testes de carga nas medidas de proteção antes que o tráfego em produção passe a depender delas.

Out-of-Memory (OOM) é uma falha bastante comum. Um modelo de 70B FP16 requer aproximadamente 140 GB apenas para os seus pesos, e KV cache, no caso de uma única sequência com contexto de 128K, pode acrescentar mais cerca de 40 GB, segundo as premissas estabelecidas. Secção 6. A diferença entre “caber na memória” e “OOM sob carga” é menor do que parece, pois um lote de solicitações com contexto extenso pode consumir mais memória KV do que o esperado. A prevenção combina uma reserva de memória bem dimensionada com quantização e alocação de KV por páginas. Para cargas de trabalho com alta pressão sobre a memória KV, LMCache Pode descarregar os dados KV para a memória ou disco de CPU; utilize os resultados publicados por ele como ponto de partida e benchmark a hierarquia de memória local.

Preempção ocorre quando a pressão exercida por KV cache obriga o agendador a expulsar ou a recalcular tarefas em execução. A estratégia exata a ser adotada depende da versão e das configurações de serving. Do ponto de vista do utilizador, o sintoma manifesta-se como uma maior latência de ponta a ponta, sem que haja um erro evidente na aplicação. É recomendável monitorizar os valores de preempção e associá-los ao consumo de memória KV, à profundidade da fila de espera e ao comprimento dos pedidos recebidos.

A latência de saída pode aumentar drasticamente quando preenchimentos em grande escala atrasam o processo de decodificação. Dividir os dados em prefill (Secção 7) E o agendamento sensível ao comprimento ajuda a mitigar essa interferência. Os trabalhos “Learning-to-Rank” e “CascadeInfer” relatam ganhos significativos em relação às suas linhas de base, mas o resultado exato depende da distribuição do comprimento das solicitações e da configuração do agendador.

Falhas em cascata podem surgir quando solicitações lentas aumentam a fila de espera, os clientes a montante expiram o tempo de espera e as tentativas de repetição adicionam ainda mais carga. As medidas de proteção incluem controlo de admissão, limites de concorrência por utilizador, limites de saída, orçamentos de tentativa e disjuntores de circuito no gateway. A desagregação de prefill e a utilização de pools de decodificação podem ser úteis quando os testes de carga revelam interferências faseadas persistentes.

43. Monitorização de sistemas LLM

O LLM difere do API tradicional em vários aspetos fundamentais. Cada solicitação tem um custo variável, apresenta duas fases distintas com gargalos diferentes, e exige uma quantidade de memória que depende tanto do comprimento da entrada quanto do comprimento da geração. Métricas padrão como a latência da solicitação e a taxa de erros não capturam a maior parte dos fatores relevantes.

Goodput representa o número de solicitações por segundo que cumprem todos os limiares SLO definidos, como TTFT, TPOT e latência total. Trata‑se de uma métrica combinada útil, pois o throughput bruto pode parecer saudável mesmo quando os SLO de latência não são atingidos: um sistema que processa 100 solicitações por segundo, mas falha nos seus limiares em 40% delas, apresenta um goodput de 60. Otimizar para goodput permite manter visível a distribuição de desempenho, em vez de reportar apenas a média.

vLLM expõe um endpoint Prometheus em /metrics Com solicitações em execução e em espera, utilize distribuições de comprimento de geração e estatísticas de cache de prefixos, como o KV cache. Os nomes das métricas podem variar entre versões, portanto, vincule os painéis à versão efetivamente implementada. Uma stack típica utiliza o Prometheus para coleta de métricas, o Grafana para visualização, bem como rastreios compatíveis com OpenTelemetry em toda a aplicação e nos componentes serving.

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

• Aumentos acentuados no número de preempções — as solicitações estão a ser expulsas e reiniciadas; os utilizadores sofrem um duplicação silenciosa da latência.
• A utilização de KV cache a aproximar‑se da região de preempção testada — é necessário adicionar capacidade ou reduzir a carga antes que ocorra uma cascata de expulsões.
• A profundidade da fila permanece consistentemente acima do limite de lote testado — o controle de admissão deve começar a rejeitar ou a dar menor prioridade às solicitações.
• O TTFT a aumentar enquanto o TPOT se mantém estável — esta divergência indica, em primeiro lugar, problemas de filas, controle de admissão, rede ou pressão de prefill, e não uma melhoria no débito de decodificação. Utilize rastreios e métricas de fila para distinguir entre estas causas.

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

Como um registo datado, os preços de março de 2026 API variavam em ordens de grandeza entre os diferentes níveis de modelos. Os valores exatos mudam com rapidez, pelo que deve utilizar a calculadora atual do fornecedor para tomar uma decisão de compra. O ponto importante a reter é que a escolha do modelo e o comprimento da saída podem influenciar significativamente o custo, mesmo antes das otimizações na infraestrutura.

No snapshot de março de 2026 utilizado para esta secção, os tokens de saída custam várias vezes mais do que os tokens de entrada para as camadas de modelo citadas. Essa assimetria reflete o trabalho de decodificação sequencial descrito em Secção 7. Nessas estruturas de preços, reduzir a saída desnecessária pode ser mais eficaz do que diminuir o mesmo número de tokens de entrada.

Várias abordagens podem ser empilhadas, mas apenas após se avaliar quais delas se aplicam à carga de trabalho:

1. Quantização de FP16 para INT4 reduz a memória necessária para os pesos em 75%. Se isso diminui a fatura depende da velocidade do kernel, do tamanho do lote e da utilização do hardware (Secção 9).
2. Encaminhamento de modelos envia o tráfego qualificado para modelos mais económicos. A Estudo de caso do fornecedor Maxim AI Foi relatada uma redução na fatura mensal de 42.000 USD para 29.000 USD; reproduza o gate de qualidade antes de utilizar a sua quota de encaminhamento.Secção 36).
3. Prompt caching reduz o trabalho associado a prefixos repetidos. Os descontos oferecidos pelos fornecedores e as regras de rate limiting mudam ao longo do tempo; portanto, é necessário combinar a taxa de acerto medida com os termos atuais.Secção 16).
4. O processamento em lote APIs permite descontos em tarefas que não são em tempo real, como avaliações, geração de dados sintéticos e classificação em massa. Verifique os preços atuais e os prazos de conclusão.
5. A autohosting pode ser vantajosa quando há uma utilização contínua, mas não existe um ponto de equilíbrio universal em termos de volume de tokens. Além do aluguer de GPU, devem ser considerados os custos de engenharia, orquestração, observabilidade, margem de capacidade e suporte técnico 24/7.

A multiplicação dos fatores ilustrativos resulta numa redução teórica significativa, mas as variáveis de entrada não são independentes: a quantização afeta a taxa de transferência, o encaminhamento altera a composição da qualidade, e o armazenamento em cache e o agrupamento de pedidos só se aplicam ao tráfego elegível. Construa a estimativa com base nas quotas de tráfego medidas e valide-a em comparação com a fatura.

A Relatório de fornecedor de 2024 da TrueFoundry Os atributos que mais influenciam o custo de implementação nos seus exemplos referem‑se à engenharia associada a ML e não ao processamento computacional. Deve tratar esse valor como um prompt que inclui mão de obra e operações no cálculo do modelo, e não como uma taxa universal.

45. Planeamento de capacidade e autoscaling

O planeamento de capacidade para LLM serving deve ter em conta o custo variável das solicitações, os processos de decodificação de longa duração e a memória dependente da sequência. Conforme a carga de trabalho, o recurso limitante pode ser a memória KV, a largura de banda da memória, o poder de processamento ou as ligações entre componentes.

O limite estrito para solicitações concorrentes é o orçamento de memória KV cache, e não os FLOPS:

$\text{máximo de sequências concorrentes} = \frac{\text{memória GPU} - \text{pesos do modelo} - \text{despesas operacionais}}{\text{tamanho por sequência KV cache}}$

Num exemplo simplificado do Llama 3 70B INT4, cerca de 35 GB de pesos num dispositivo H100 com 80 GB disponíveis deixam aproximadamente 40 GB após reservar espaço para despesas adicionais. Com contexto de 4K, assumindo 160 MB por sequência, o limite teórico situa‑se perto de 250 sequências; com contexto de 128K, a mesma conta resulta em cerca de cinco sequências. A capacidade real é ainda menor quando se leva em conta o comportamento do alocador, os buffers runtime, as variações no comprimento das solicitações e os padrões de desempenho em termos de latência. É por isso que seleção GPU e otimização KV cache impulsionar diretamente o plano de capacidade.

A fórmula de capacidade para o dimensionamento da frota:

$\text{Necessário GPUs} = \frac{\text{tokens de pico/minuto} \times \text{margem de segurança medida}}{\text{throughput por GPU no SLO alvo}}$

O aspecto crucial é o cumprimento do SLO alvo. O throughput máximo de tokens e o throughput compatível com o SLO podem divergir significativamente à medida que a concorrência aumenta. Benchmark, tendo em conta a distribuição real de prompt e do comprimento das saídas nos limiares exigidos de TTFT e TPOT, em vez de se recorrer a um valor máximo teórico.

A utilização de GPU é insuficiente como único sinal de autoescala, pois pode permanecer elevada tanto durante um processamento normal como em situações de sobrecarga. É necessário combiná-la com a profundidade da fila, a utilização de KV cache e a degradação de goodput. Os limiares devem ser ajustados com base em testes de carga; valores como 80% de utilização do KV servem apenas como pontos de partida, e não como limites universais. Estas métricas são introduzidas em Secção 43.

A estratégia de escala para zero permite adaptar-se a ambientes de desenvolvimento e de staging com longos períodos de inatividade. Plataformas de inferência serverless e mecanismos de autoescala baseados em Kubernetes, como o KEDA, conseguem eliminar a capacidade ociosa, mas as economias obtidas e o tempo de arranque em condições de “cold start” dependem do tamanho do modelo, do armazenamento em cache de imagens e pesos, bem como da infraestrutura utilizada. É necessário medir o tempo de arranque antes de aplicar a mesma política ao tráfego de produção, que é sensível à latência.

O sistema interconectado

Estes 45 conceitos não constituem uma coleção desorganizada. Eles formam um sistema interligado. O tamanho de KV cache determina o tamanho dos lotes, o tamanho dos lotes influencia a intensidade aritmética, a intensidade aritmética controla se a fase de decodificação é limitada pela memória, o que por sua vez afeta o TPOT, e o TPOT define a taxa de transferência. GQA faz com que KV cache diminua, o que permite a utilização de lotes maiores, aumentando assim a intensidade aritmética e melhorando a utilização de GPU. FlashAttention tira partido da diferença de largura de banda entre a SRAM e HBM. A agrupação contínua de operações resolve o problema da baixa utilização dos recursos de processamento, mas gera fragmentação de memória, problema que é resolvido por PagedAttention. A divisão em blocos de prefill permite agendar de forma coordenada tarefas dependentes de processamento e tarefas dependentes de memória; o modelo roofline explica por que essa complementaridade funciona.

No que diz respeito ao treino, o custo ao longo do ciclo de vida pode favorecer a formação de um modelo mais pequeno com um maior número de tokens, como ilustra o Llama 3 8B. GRPO reduz a carga associada ao estado do crítico em PPO. Na configuração de modelo pequeno testada no DeepSeek-R1, a destilação apresentou desempenhos superiores aos métodos de RL direto. Trata‑se de opções de projeto a serem avaliadas, e não de uma única receita de treino.

O padrão operacional é mais estável do que qualquer curva de preços: o encaminhamento, o armazenamento em cache, a quantização e o hardware com capacidade adequada só se tornam eficazes quando cada um deles é avaliado com base no mesmo objetivo de qualidade e latência.

Princípios fundamentais

1. LLM a inferência possui duas fases distintas. Nos regimes comuns de serving, o prefill privilegia o processamento, enquanto a decodificação depende da largura de banda da memória; a forma do trabalho pode deslocar esse limite.
2. O KV cache costuma ser uma restrição fundamental. O seu tamanho influencia a capacidade de processamento em lote e a pressão sobre a memória. Técnicas como GQA, alocação paginada e quantização KV visam abordar diferentes aspectos dessa restrição.
3. A hierarquia de memória GPU explica muitas das otimizações aplicadas. Estratégias como FlashAttention e fusão de kernels reduzem os custosos movimentos de dados, em vez de alterar a função do modelo.
4. O processamento contínuo em lotes e PagedAttention funcionam em sinergia. Uma comparação publicada demonstrou um aumento de 23 vezes no rendimento em relação ao método básico; avalie os benefícios na sua pilha de serving.
5. O estado ótimo para Chinchilla não é necessariamente o ótimo para inferência. Por exemplo, o Llama 3 8B foi treinado com aproximadamente 1.875 tokens por parâmetro, a fim de obter maior capacidade de processamento durante o treino em troca de uma inferência mais económica.
6. Técnicas como GRPO e destilação modificaram as ferramentas utilizadas para alinhamento. O DeepSeek-R1 apresentou resultados mais sólidos com modelos pequenos após aplicação de destilação, em comparação com os experimentos diretos baseados em RL.
7. A otimização de custos só se torna eficaz em tráfego qualificado. A quantização de modelos, o roteamento, o armazenamento em cache e o processamento em lotes APIs exigem medições separadas de cobertura e qualidade antes que os seus ganhos possam ser potenciados.
8. Serving hardware deve corresponder ao gargalo de desempenho. Cargas de trabalho com muita atividade de decodificação costumam se beneficiar de capacidade e largura de banda HBM; já cargas de trabalho intensivas em prefill colocam maior ênfase no processamento computacional.

Leitura adicional

Artigos aprofundados relacionados deste blogue, organizados por tópico:

• LLM Fine-Tuning Guia — quando aplicar ajuste fino vs. RAG vs. prompt engineering
• Variantes e Formatos de Ficheiro de Código Aberto LLM — correspondência entre variantes de modelo e formatos quantizados e o hardware Guia LoRAX Serving — serving milhares de adaptadores LoRA em produção
• Escalar modelos de linguagem de grande porte — estratégias multi-GPU e multi-nó Localizar LLMs no macOS — configuração prática com llama.cpp e Ollama AI Laços de Raciocínio de Agente em 2026 — Análise aprofundada de ReAct, ReWOO e os ciclos planeador-executor
• AI Arquitetura de Memória de Agente em 2026 — checkpoints, armazenamentos vetoriais e memória de documentos para agentes com estado

Referências

Organizado por área temática; os números de seção estão entre parênteses, quando aplicável.

Inferência e atenção

• FlashAttention: Atenção Exata Rápida e Eficiente em Termos de Memória, com Consciência de E/S - Dao et al., NeurIPS 2022 FlashAttention-2: Atenção mais rápida graças a um melhor paralelismo e à divisão do trabalho - Dao, 2023
• FlashAttention-3: Atenção Rápida e Precisa com Assincronia e Baixa Precisão - Shah et al., NeurIPS 2024 Decodificação Rápida para inferência em contexto longo - Dao et al., 2023
• Gestão Eficiente de Memória para Modelos de Língua Grande Serving com PagedAttention - Kwon et al., SOSP 2023
• Orca: Um sistema distribuído Serving para modelos generativos baseados em Transformer - Yu et al., OSDI 2022
• GQA: Treino de Atenção Multi-Consulta Generalizada - Ainslie et al., 2023
• Triton: uma linguagem intermédia e compilador para cálculos em redes neurais - Tillet et al., MAPL 2019
• FlashNorm: Normalização rápida para LLMs - 2024
• Fusão Profunda de Kernel para Transformers - DeepFusionKernel, 2026

Decodificação especulativa

• EAGLE-3: Escalonamento da Aceleração de Inferência em Modelos de Língua Grande - Li et al., NeurIPS 2025 Medusa: Aceleração Simples de LLM Inferência Framework com Várias Cabeças de Decodificação - ICML 2024

Quantização

• AWQ: Quantização de Peso Sensível à Ativação para LLM Compressão e Aceleração - Melhor Artigo do MLSys 2024 GPTQ: Quantização Pós-Treino Precisa para Transformers Pré-treinados Gerativos - Frantar et al., ICLR 2023
• Marlin: Precisão Mista (FP16xINT4) LLM Núcleo de Inferência - Frantar et al., 2024

Treino e fine-tuning

• LoRA: Adaptação de Baixo Rank de Modelos de Língua Grande - Hu et al., ICLR 2022 QLoRA: Ajuste fino eficiente de LLMs quantizado - Dettmers et al., NeurIPS 2023
• ZeRO: Otimizações de Memória para o Treino de Modelos com Bilhões de Parâmetros - Rajbhandari et al., SC20 ZeRO-Infinity: Quebrando a barreira de memória GPU para aprendizagem profunda em escala extremamente elevada - Rajbhandari et al., 2021
• Self-Instruct: Alinhar Modelos de Língua com Instruções Autogeradas - Wang et al., ACL 2023
• WizardLM: Capacitar modelos de linguagem de grande escala para seguir instruções complexas - Xu et al., ICLR 2024 Relatório Técnico Phi-4 - Microsoft, 2024 AI Os modelos entram em colapso quando treinados com dados gerados recursivamente. - Shumailov et al., Nature 2024

Alinhamento

• Otimização de Preferência Direta: O seu modelo de linguagem é, na verdade, um modelo de recompensa - Rafailov et al., NeurIPS 2023 DeepSeekMath: Além dos Limites do Raciocínio Matemático em Modelos de Língua Abertos - Foi introduzido o GRPO
• DeepSeek-R1: Estímulo da capacidade de raciocínio em LLMs por meio de Aprendizagem por Reforço - DeepSeek, 2025

Escalabilidade e arquitetura

• O rebanho de modelos Llama 3 - Meta, 2024 LLaMA: Modelos de Linguagem Fundamentais Abertos e Eficientes - Touvron et al. (Meta), 2023
• Llama 2: Modelos de chat de código aberto da Open Foundation e adaptados por fine-tuning - Touvron et al. (Meta), 2023 Relatório Técnico Qwen3 - Qwen Team (Alibaba), 2025 Treino de modelos de linguagem grandes otimizados para recursos computacionais - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Transformador aprimorado com posicionamento rotativo Embedding - Su et al., 2021 YaRN: Extensão Eficiente da Janela de Contexto em Modelos de Língua Grande - Peng et al., ICLR 2024 SGLang: Execução eficiente de programas de modelos de linguagem estruturada - Zheng et al., NeurIPS 2024
• Mixtral de Especialistas - Jiang et al. (Mistral AI), 2024

Embeddings

• Aprendizagem de Representações Matryoshka - Kusupati et al., NeurIPS 2022 pplx-embed-v1: Denso e Contextual Pré-treinado por Difusão Embeddings - Perplexidade AI, 2026

Arquiteturas de agente

• ReAct: Sinergizar o raciocínio e a ação em modelos de linguagem - Yao et al., ICLR 2023
• ReWOO: Desacoplamento do Raciocínio das Observações para Modelos de Linguagem Aumentados Eficientes - Xu et al., 2023

Roteamento

• RouteLLM: Aprendizagem para Roteamento de LLMs com Dados de Preferência - Ong et al., ICLR 2025

Benchmarks

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

Arquiteturas Serving

• SARATHI: Inferência eficiente de LLM através da utilização de decodificações “piggyback” com preenchimentos em blocos. - Agrawal et al., 2023 (Processamento em blocos Prefill) Splitwise: Inferência Generativa LLM Eficiente através da Divisão de Fases - Patel et al., ISCA 2024 (Desagregação de Serving)
• DistServe: Desagregação de Prefill e decodificação para modelos de linguagem grande otimizados para Goodput Serving - Zhong et al., OSDI 2024 (Disagregado Serving)

Serving frameworks

• vLLM - Motor 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 - Executador local LLM

Operações

• Agendamento eficiente LLM através do Aprendizado por Classificação - Fu et al., NeurIPS 2024 (vLLM-LTR) CascadeInfer: Baixa latência e balanceamento de carga LLM Serving através de agendamento sensível ao comprimento dos dados - 2024
• a métrica Goodput como indicador da produtividade ML - Google Cloud, 2024 vLLM Otimização e Ajuste - vLLM Documentação vLLM Métricas - vLLM Documentação
• LMCache: Gestão de KV Cache para LLM Serving - KV cache transferência de carga Limites de taxa da OpenAI - Documentação da OpenAI API Limites de taxa da Anthropic - Documentação da Anthropic API