Servindo LLMs com contexto longo: os reais tradeoffs de memória, latência, custo e precisão

Contexto longo em modelos de linguagem deixou de ser um diferencial para se tornar um campo minado de infraestrutura. A ficha técnica diz “128K tokens” ou “1 milhão de tokens”, mas o que acontece quando dezenas de usuários mandam entradas desse tamanho ao mesmo tempo? A resposta envolve quatro tradeoffs que separam o que o modelo suporta do que o sistema entrega — e este tutorial detalha cada um deles com números reais.

O que mudou em 2026

Há dois anos, uma janela de contexto de 32K tokens era considerada generosa. Hoje, Claude Sonnet 4.6 aceita 1 milhão de tokens de entrada — cerca de 10 romances. Modelos abertos como Llama 3.1 e GPT-OSS-120B vêm com 128K tokens como padrão. Mas entre o número na ficha técnica e a realidade de produção existe uma distância que este artigo mapeia.

Prós e contras do contexto longo em produção

✅ O que você ganha

• Consultas mais ricas: um codebase inteiro, um documento jurídico completo ou meses de histórico de conversa cabem em uma única requisição
• Menos engenharia de chunking: em certos casos, elimina a necessidade de pipelines de segmentação de documentos
• Statefulness natural: sessões de agente que acumulam histórico funcionam como contexto contínuo, sem precisar de banco de dados externo para estado
• Menor latência de ida e volta: uma chamada com contexto grande é mais rápida que várias chamadas encadeadas com RAG
• Simplicidade de prototipação: colar tudo no prompt funciona para MVPs e demos — mas a conta vem depois

⚠️ O que você NÃO ganha

• Precisão garantida: modelos erram mais em contextos longos (efeito “Lost in the Middle” — a informação no meio do texto é a menos confiável)
• Custo proporcional: enviar 128K tokens custa mais que 128× enviar 1K, por causa do custo quadrático do pré-processamento (prefill)
• Latência previsível: uma requisição de 128K tokens pode segurar a GPU por segundos e atrasar todas as outras requisições na fila

Pré-requisitos: o que você precisa saber

Tradeoff 1: Memória — o KV cache devora GPUs

Para cada token que o modelo lê, ele armazena dois vetores (key e value) na memória da GPU — é o KV cache. A fórmula é simples e implacável:

KV cache = 2 × camadas × KV heads × dimensão do head × comprimento da sequência × bytes por elemento

Para um Llama 3 70B (80 camadas, 8 KV heads, head dim 128) com 128K tokens em BF16:

2 × 80 × 8 × 128 × 131.072 × 2 bytes ≈ 43 GB

43 GB de memória de GPU para o contexto de um único usuário. Uma H100 tem 80 GB no total — e os pesos do modelo já ocupam a maior parte. Com 1 milhão de tokens, o cache sozinho ultrapassa o tamanho do modelo.

O problema real está no batching. GPUs se pagam processando muitas requisições juntas. Uma única requisição de 128K ocupa 54% da memória de uma H100 (modelo 70B) — sem espaço para outras. O PagedAttention (técnica do vLLM) aloca o cache em páginas em vez de blocos contínuos, recuperando parte do desperdício, mas 128K tokens ainda precisam de 128K de memória.

Tradeoff 2: Latência — o tempo até o primeiro token explode

A atenção — operação central de todo transformer — compara cada token com todos os outros. A computação cresce com o quadrado do comprimento da entrada. Dobrar o contexto quadruplica o trabalho. Passar de 32K para 128K é 4× o comprimento e 16× a computação de atenção.

Tudo isso acontece no prefill (fase de leitura), antes da primeira palavra da resposta aparecer. É por isso que o TTFT (time to first token) vai de milissegundos em contextos curtos para vários segundos em contextos longos.

O segundo custo de latência é menos óbvio: o que sua requisição longa faz com todos os outros. Um prefill de 128K segura a GPU por segundos, e cada requisição na fila atrás dele espera. Os mais prejudicados não são os usuários de contexto longo (que já esperavam), mas os de requisições curtas que tiveram o azar de cair atrás de uma longa.

Tradeoff 3: Throughput e o teto da largura de banda

Mesmo com computação infinita, o decode (fase de geração) bate em um limite físico. Para gerar cada token de saída, a GPU precisa ler o KV cache inteiro da memória HBM. GPUs topo de linha movem ~3-4 TB/s — e esse número é fixo.

Quando o cache chega a dezenas de gigabytes, lê-lo uma vez por token gerado se torna o gargalo. A relação é quase linear: dobrar o contexto → dobrar o cache → dobrar os dados lidos por passo de decode → throughput cai pela metade.

Tradeoff 4: Precisão — e por que precisão também é um problema de velocidade

Modelos respondem perguntas sobre entradas longas de forma menos confiável. O estudo RULER mostrou que o contexto efetivo (aquele em que o modelo ainda funciona bem) é frequentemente muito menor que o anunciado. O paper “Lost in the Middle” demonstrou quedas de dois dígitos percentuais na precisão quando a informação relevante está no meio do texto.

Um estudo de 2026 da IBM Research com a TU Delft (“Accuracy Is Speed”, EuroMLSys ’26) introduziu o conceito de TTCA (Time-to-Correct-Answer): o tempo total desde a primeira tentativa até a primeira resposta correta. Um modelo rápido que erra metade das vezes pode ser pior que um modelo lento que acerta de primeira, porque os retries se acumulam.

O sistema de roteamento deles (LAAR) reduziu o TTCA médio em até 31% simplesmente escolhendo qual modelo recebe cada requisição com base no comprimento do contexto e no idioma — sem nenhuma modificação nos modelos.

O RAG ainda faz sentido com janelas de 1 milhão de tokens?

A resposta curta: sim, e mais do que nunca. Enviar o corpus inteiro em cada requisição significa pagar o custo quadrático do prefill, o TTFT de múltiplos segundos e o preço escalonado por token — mesmo quando a resposta precisava de apenas três parágrafos.

Com RAG, o modelo lê apenas a fatia relevante: prefill barato, cache pequeno, resposta rápida e operação em comprimentos onde o modelo é confiável. Contexto longo não tornou o RAG obsoleto — ele mudou quando cada abordagem vence.

Comparação de custo: três estratégias para uma sessão de agente

A 10.000 requisições por mês, enviar 128K tokens em cada uma custa ~US$ 3.840 só de entrada. O mesmo tráfego com contexto de 8K via RAG custa ~US$ 240. A arquitetura importa mais que o preço por token.

Casos de uso reais

• Análise de contratos jurídicos: um contrato de 80 páginas cabe na janela, mas revisar 50 contratos por dia exige caching de prefixo para não pagar o prefill 50 vezes
• Code review de repositórios: o codebase inteiro como contexto para um agente de revisão, com o sistema de prompt cacheado e apenas o diff novo sendo processado a cada commit
• Suporte ao cliente com base de conhecimento: 10.000 artigos de KB → RAG com 8K de contexto recuperado por consulta. Enviar tudo seria 16× mais caro e 5× mais lento
• Análise de séries temporais: meses de logs de sistema como contexto para detecção de anomalias — cache de prefixo para o schema e os logs históricos, apenas a janela recente é nova
• Tradução de documentos longos: usar chunking com contexto sobreposto em vez de enviar o documento inteiro — mantém a coerência entre chunks sem explodir o KV cache

Troubleshooting: erros comuns ao servir contexto longo

1. ❌ OOM (Out of Memory) mesmo com uma única requisição → O KV cache + pesos do modelo excedem a memória da GPU. Solução: reduzir o max_model_len no vLLM, usar tensor parallelism (2-4 GPUs) ou quantização (AWQ/FP8).
2. ❌ TTFT acima de 5 segundos para 128K tokens → Prefill sequencial está saturado. Solução: habilitar chunked prefill no vLLM/SGLang para intercalar prefill com decode, ou usar prefix caching se o prefixo for compartilhado.
3. ❌ Throughput cai 50%+ quando o contexto médio dobra → Gargalo de largura de banda de memória. Solução: medir o model FLOPs utilization (MFU) — se abaixo de 40%, o problema não é computação, é movimento de dados. Usar GPUs com HBM3e (H200, B200) ou reduzir o batch size máximo.
4. ❌ P95 e P99 de latência degradados mas média parece saudável → Requisições longas bloqueando as curtas na fila. Solução: separar filas por comprimento de contexto (short queue e long queue) ou usar preemption no programador.
5. ❌ Precisão cai quando a resposta depende de informação no meio do contexto → Efeito “Lost in the Middle”. Solução: reposicionar informações críticas no início ou fim do prompt, ou usar RAG para trazer apenas o que importa para perto das extremidades.
6. ❌ Cache de prompt expira e a conta dobra → O cache do Claude Sonnet expira em 5 minutos de inatividade. Um usuário que lê por 6 minutos e faz follow-up dispara rewrite completo. Solução: implementar heartbeat no cliente para manter o cache vivo ou migrar para um modelo com TTL de cache maior.

FAQ

P: Vale a pena usar contexto de 1M tokens se meu caso de uso não precisa disso?
R: Não. Cada token que você envia mas não usa multiplica custo, latência e consumo de memória sem benefício. Recupere apenas o que importa.

P: RAG e contexto longo são mutuamente exclusivos?
R: Não. Sistemas em produção usam ambos: RAG para selecionar o que entra no contexto, janela longa para caber uma quantidade generosa, e caching onde há repetição.

P: O que é melhor: um modelo pequeno com contexto curto + RAG ou um modelo grande com contexto longo?
R: Depende da tarefa. Para buscas de precisão (encontrar um fato específico), modelo pequeno + RAG é mais barato e rápido. Para raciocínio sobre documentos inteiros (análise jurídica), contexto longo vence — mas com caching.

P: Como saber se meu gargalo é computação ou largura de banda?
R: Calcule o MFU (Model FLOPs Utilization). Se estiver abaixo de 40% em decode, você está preso na largura de banda da memória, não na capacidade de computação. Trocar GPU por uma com mais FLOPS não vai ajudar — precisa de mais largura de banda (HBM3e).

P: Por que o preço dobra após 200K tokens no Claude Sonnet?
R: Porque os custos reais de infraestrutura não são lineares. O prefill é quadrático, o KV cache consome GPU que poderia servir outros clientes e o throughput cai. O preço reflete isso.

P: Dá para rodar Llama 3 70B com 128K de contexto em uma única GPU?
R: Só se for uma H100 80GB com quantização agressiva (AWQ 4-bit). Os 43 GB de KV cache + ~35 GB de pesos quantizados = 78 GB. Com FP16, precisa de 2 GPUs no mínimo.

O que esperar em 2027

Três tendências convergem. A primeira é de hardware: HBM3e com 8 TB/s de largura de banda (B200) alivia parcialmente o gargalo de decode, mas o custo quadrático do prefill continua. A segunda é algorítmica: atenções lineares (Mamba, RWKV) removem o custo quadrático, mas ainda perdem em tarefas que exigem recall preciso de longo alcance. A terceira é arquitetural: o padrão emergente não é “RAG ou contexto longo”, mas roteamento inteligente entre os dois, com sistemas que decidem por requisição se recuperam, cacheiam ou enviam o contexto completo.

Para times brasileiros construindo sobre LLMs, a mensagem prática é clara: meçam o TTFT e o P95 de latência com seus contextos reais, não com um benchmark sintético de requisição única. A diferença entre “suporta 128K” e “serve 128K em produção com 100 usuários simultâneos” é a diferença entre um demo e um produto.