O que é a janela de contexto de um modelo?

A janela de contexto é o número máximo de tokens que um modelo processa numa única chamada. Tudo disputa esse espaço: instruções do sistema, definições de ferramentas, histórico da conversa, documentos colados, a pergunta — e a resposta que ele vai gerar. Nada disso persiste depois da chamada. A cada requisição, o modelo recebe a sequência inteira de novo.

Essa última frase é o que mais confunde quem começa. A janela não é memória. Ela é o tamanho da folha que você entrega ao modelo, e a folha é reescrita do zero a cada pergunta. O que parece memória num chat é o seu código reenviando o histórico, e é ele que ocupa a maior parte da janela numa conversa longa.

Como o espaço é finito e disputado, decidir o que entra vira um problema por mérito próprio, que é do que trata a engenharia de contexto. O tamanho da unidade que está sendo contada é o token, e os tetos praticados por cada família de modelo estão em janelas de 8k a 1M.

Entrada e saída dividem o mesmo teto

O modelo não enxerga duas áreas. Ele recebe uma sequência de tokens e produz o token seguinte, depois o seguinte, cada um passando a fazer parte da sequência que ele lê para produzir o próximo. Gerar é continuar a mesma sequência.

Daí sai a consequência prática mais esquecida: o limite vale para a soma. Se a janela é de 128 mil tokens e você reserva 8 mil para a resposta, sobram 120 mil para tudo o que você manda. Pedir uma resposta longa encolhe o espaço disponível para o documento.

Vale conferir a documentação do modelo que você usa, porque isso mudou de forma. Em 2026, alguns provedores publicam um teto de saída separado — menor que o restante da janela — e nesse caso os dois limites valem ao mesmo tempo: a soma não pode passar do teto geral, e a saída não pode passar do teto próprio dela.

O detalhe que quebra sistemas em produção é o parâmetro de tokens máximos de saída. Ele costuma ser tratado como “quanto eu deixo o modelo falar” e é, na verdade, uma reserva: aquele espaço sai do orçamento antes de a chamada começar. Deixar o valor alto por precaução é reservar espaço que quase nunca é usado e que poderia estar carregando contexto.

Por que existe um limite

Três razões independentes, e todas continuam valendo mesmo com as janelas de hoje.

A atenção custa caro com o comprimento. No transformer, cada token atende a todos os anteriores, o que faz a matriz de atenção crescer com o quadrado do comprimento da sequência¹. Dobrar o contexto quadruplica esse trabalho. Técnicas de implementação melhoraram muito o uso de memória dessa etapa, mas a quantidade de computação continua crescendo do mesmo jeito.

As posições foram treinadas até certo ponto. O modelo precisa saber a ordem dos tokens, e a forma mais usada de codificar isso são as posições rotativas, que giram os vetores de consulta e chave por um ângulo proporcional à posição². Além do comprimento visto no treino, esses ângulos entram em território que o modelo nunca viu, e a qualidade cai. Um trabalho de 2023 resolveu isso comprimindo os índices de posição em vez de extrapolá-los, o que permitiu estender modelos da família LLaMA até 32.768 tokens com menos de mil passos de ajuste — e os autores argumentam que a extrapolação pura produz pontuações de atenção catastroficamente altas, que destroem o mecanismo³.

O cache de chave-valor ocupa memória. Para não recalcular tudo a cada token gerado, o servidor guarda as chaves e valores de cada token já processado. Esse cache cresce linearmente com o contexto e some com a VRAM: num modelo de 8B com atenção de consulta agrupada, ele custa cerca de 128 KB por token, o que dá algo em torno de 13 GB para 100 mil tokens de contexto — por requisição. Foi esse problema que motivou tratar o cache como memória paginada, na mesma ideia de paginação de um sistema operacional⁴.

As três se somam. É por isso que janela grande é cara mesmo quando o preço por token de entrada é baixo, e por que servir contexto longo com muitos usuários simultâneos é um problema de infraestrutura, não de configuração.

Vale notar o que mudou e o que não mudou. As janelas cresceram de 2 mil para 1 milhão de tokens em poucos anos porque as três restrições foram atacadas em frentes separadas: núcleos de atenção que evitam materializar a matriz inteira na memória, esquemas de posição que estendem sem retreinar do zero, atenção de consulta agrupada e gestão paginada para segurar o cache. Nenhuma delas eliminou a restrição de origem. Elas empurraram o ponto em que ela dói.

O que acontece quando estoura

Do lado do provedor, a resposta é simples e pouco útil: a chamada falha. Você recebe um erro dizendo que o número de tokens excede o máximo do modelo, e a requisição inteira não acontece. Não há truncamento automático, não há descarte silencioso do começo da conversa, não há aviso na chamada anterior.

Isso é o comportamento certo, e é importante entender por quê. O provedor não tem como saber o que é descartável no seu prompt. Cortar o começo apagaria a instrução que define a tarefa; cortar o fim apagaria a pergunta. Qualquer escolha automática estaria errada em algum caso, e estaria errada em silêncio.

Do lado da aplicação, existem três respostas, em ordem crescente de qualidade.

Cortar a mensagem mais antiga é a mais comum e a pior. A mensagem mais antiga costuma ser justamente a que estabelece o que está sendo feito. O agente perde a tarefa e continua trabalhando, o que produz um tipo de erro difícil de diagnosticar porque nada falhou.

Truncar na origem é barato e resolve boa parte. Resultado de ferramenta deve vir cortado por quem chama a ferramenta, com um identificador para buscar o resto. Um log de 40 mil tokens vira duas mil linhas relevantes e um caminho de arquivo.

Compactar por limiar é a resposta madura. Você define um ponto — algo como 60% da janela — e, ao cruzá-lo, resume o histórico antigo preservando decisões tomadas e pendências abertas, guardando o detalhe fora da janela para recarregar sob demanda. O detalhe de como fazer isso sem perder o que importa está em compactação de contexto.

A diferença entre as três não é de sofisticação. É de quem decide: no primeiro caso, decide o acaso.

Quanto cabe, em coisas reais

Números de ordem de grandeza, para converter a especificação em algo que dá para pensar. Todos variam com o idioma e com o tipo de conteúdo.

Uma página de texto corrido em português fica em torno de 600 a 900 tokens. Um contrato de 30 páginas, algo perto de 25 mil. Um manual de produto de 200 páginas, cerca de 160 mil — já fora de uma janela de 128 mil quando você soma o resto.

Código rende mais. Um arquivo de 500 linhas costuma passar de 6 mil tokens, porque identificadores, indentação e pontuação viram muitos tokens curtos. Um git diff de uma feature média chega fácil a 15 mil. Um package-lock.json inteiro passa de 100 mil e não deveria estar na janela nunca.

Resposta de API em JSON é o pior caso de todos: chaves repetidas em cada objeto, identificadores longos, aspas e vírgulas. Uma listagem de 200 registros com quinze campos cada pode custar 30 mil tokens para carregar informação que caberia em uma tabela de 3 mil.

O padrão que emerge dessas contas: o que estoura a janela quase nunca é o texto que alguém escreveu. É conteúdo de máquina entrando inteiro porque ninguém decidiu o contrário.

O limite anunciado não é o limite útil

Esta é a parte que a ficha técnica não conta.

Em 2024, um benchmark testou 17 modelos em 13 tarefas de contexto longo, indo além do teste de agulha no palheiro para incluir rastreamento em múltiplos saltos e agregação. Todos os 17 anunciavam janela de 32 mil tokens ou mais. Metade não sustentou desempenho aceitável já em 32 mil⁵.

O detalhe que mais importa nesse resultado: quase todos acertavam o teste simples de recuperação com precisão quase perfeita. A degradação aparece quando a tarefa exige combinar informação espalhada, que é justamente o que uma aplicação real pede. “Suporta 1M de contexto” responde uma pergunta sobre alocação de memória e nenhuma pergunta sobre a sua tarefa.

A leitura razoável é tratar a janela anunciada como um teto de alocação e descobrir empiricamente onde a sua tarefa começa a degradar. Esse número é sempre menor, muda por modelo, e é o único que serve para dimensionar o sistema.

Onde a janela engana

Contexto não é memória. Sessões longas parecem lembrar porque o histórico é reenviado. Se você reiniciar o processo sem persistir esse histórico, o modelo não sabe nada. Memória entre sessões é infraestrutura sua, não do modelo.

Tokens não são palavras. A conversão varia por idioma e por conteúdo. Texto em português costuma render mais tokens por palavra que em inglês, e código, JSON e identificadores rendem bem mais. Estimar a janela em páginas é um erro que aparece só quando o sistema já está em produção.

A janela não é o gargalo de custo mais frequente. Num agente, o mesmo histórico é reenviado a cada iteração. Se ele cresce 5 mil tokens por volta, a vigésima chamada processa 100 mil tokens de entrada — e o total processado na tarefa inteira é a soma da série, perto de 1 milhão. O teto da janela nunca foi atingido e a fatura chegou mesmo assim.

Cache de prompt muda a conta, não o limite. Reenviar o prefixo estável fica mais barato quando ele é lido de cache, mas ele continua ocupando o mesmo espaço na janela. E o cache cria um incentivo perverso: como reescrever o começo invalida o cache, existe pressão para nunca limpar o que já está lá.

A latência cresce antes do erro. Muito antes de estourar, a janela cheia já aparece como demora. O tempo até o primeiro token depende de processar toda a entrada, e ele sobe conforme o contexto cresce. Uma sessão que respondia em dois segundos na quinta mensagem e leva doze na quadragésima não tem bug: tem histórico. O sintoma é de desempenho e a causa é de orçamento de contexto, o que faz o time otimizar a coisa errada por semanas.

Como dimensionar na prática

1. Meça por categoria. Registre em cada chamada quantos tokens foram para system prompt, definições de ferramentas, histórico e documentos. A fatia dominante quase nunca é a que o time imagina.
2. Descubra o seu ponto de degradação. Rode a sua tarefa real com o contexto em 10%, 25% e 50% da janela e compare o acerto. O ponto em que a curva cai é o seu limite útil.
3. Orce a saída explicitamente. Defina o teto de tokens de resposta pelo que a tarefa precisa, não pelo máximo permitido.
4. Trunque resultado de ferramenta na origem, antes de ele entrar na janela.
5. Compacte por limiar, não por estouro. Estourar já é tarde: o usuário perdeu a sessão.
6. Coloque o crítico nas pontas. Instruções no começo, pergunta atual no fim, volume no meio.
7. Refaça a medição a cada troca de modelo. O ponto de degradação muda, e a sua configuração foi calibrada para o modelo anterior.

O passo 2 é o que separa quem dimensiona de quem chuta. Ele custa uma tarde e substitui a especificação do fornecedor por um número que vale para o seu caso.

Footnotes

1. Vaswani et al. (2017) definiram a atenção em que cada token atende a todos os outros, cujo custo cresce com o quadrado do comprimento da sequência. ↩

2. Su et al. (2021) propuseram codificar a posição girando os vetores de consulta e chave por um ângulo proporcional à posição, o esquema adotado pela maioria dos modelos abertos atuais. ↩

3. Chen et al. (2023) estenderam modelos da família LLaMA até 32.768 tokens comprimindo linearmente os índices de posição, com menos de mil passos de ajuste, e mostram que a extrapolação pura produz pontuações de atenção altas o bastante para arruinar o mecanismo. ↩

4. Kwon et al. (2023) trataram o cache de chave-valor como memória paginada para reduzir fragmentação e desperdício, que eram o que limitava o tamanho dos lotes em servidores de contexto longo. ↩

5. Hsieh et al. (2024) avaliaram 17 modelos em 13 tarefas, incluindo rastreamento em múltiplos saltos e agregação: metade dos que anunciavam ao menos 32 mil tokens não sustentou desempenho aceitável nesse comprimento. ↩