Qwen local perde contexto antes do limite: isole KV cache, backend e GPU

Você configurou um Qwen local para 128K de contexto, mas ele pode falhar perto de 72K, ficar lento demais ou concluir a resposta ignorando instruções do início. Quase nunca existe um único ajuste milagroso: quantização dos pesos, KV cache, backend de inferência e distribuição no hardware formam juntos o limite real.

Este guia oferece um diagnóstico repetível. Primeiro você separa capacidade, velocidade e memória efetiva; depois muda uma variável por vez para decidir se deve trocar o KV cache, testar outro backend, rebalancear várias GPUs ou reduzir a janela usada em produção.

Resposta direta: o contexto configurado é um teto, não uma garantia

Selecionar 128K apenas pede ao backend que se prepare para uma entrada desse tamanho. A configuração só é viável enquanto esta conta fecha:

pesos do modelo + KV cache + área de trabalho do runtime + margem de segurança ≤ memória realmente utilizável pelo backend

Os pesos costumam ocupar uma parcela grande e quase fixa ao carregar o modelo. O KV cache cresce com o número de tokens mantidos, enquanto buffers temporários variam conforme backend, batch e kernels. Mesmo quando tudo cabe, latência e recuperação de informações distantes podem deixar de ser aceitáveis antes do limite físico.

Por isso, você precisa responder a três perguntas distintas: cabe, termina em tempo útil e ainda usa corretamente o começo do contexto? O valor máximo mostrado na interface não responde sozinho a nenhuma delas.

Identifique o sintoma antes de trocar a pilha inteira

“Não chega a 128K” pode significar falhas diferentes. Classifique seu caso primeiro para não otimizar o componente errado.

Sintoma	Direção mais provável	Primeira verificação
OOM ao carregar ou reservar contexto longo	Pesos e KV cache disputam memória, ou uma GPU não consegue reservar sua parte	Registre pico e memória livre de cada GPU
O backend falha quase sempre no mesmo número de tokens	Formato do KV cache, implementação do backend ou limite de alocação	Mantenha modelo e hardware; troque apenas cache ou backend
A entrada é aceita, mas prefill ou geração ficam impraticáveis	Largura de banda, tráfego entre GPUs, kernels ou comprimento excessivo	Meça processamento do prompt e geração separadamente
A resposta termina, mas esquece restrições iniciais	Qualidade do contexto efetivo, não apenas capacidade bruta	Espalhe fatos de controle por todo o prompt
O mesmo teste às vezes passa e às vezes falha	Pouca folga, carga concorrente ou runtime instável	Remova outras cargas e repita três vezes

Se tudo cabe, mas fica lento demais, reduzir o KV cache não é automaticamente a melhor solução. Se cabe, mas o começo é esquecido, adicionar VRAM também pode não resolver.

O que um relato de 72K para 128K mostra — e o que não mostra

Em um relato de configuração de 23 de setembro de 2026, Nigel Hungerford-Symes descreveu Qwen3.8-27B (Unsloth UD-Q5_K_M) em uma RTX 5060 Ti de 16GB mais uma RTX 3070 de 8GB. A pilha de 128K informada usava beellama.cpp + kvarn5 KV + MTP n=2, com cerca de 36 tok/s em contexto curto e 18 tok/s em 126K; a configuração anterior com llama.cpp principal e KV q8_0 parava, segundo o autor, perto de 72K.

O relato é útil porque mostra que o limite utilizável de uma máquina específica pode mudar com a pilha de inferência. Ele não isola a causa: backend, esquema de KV cache e outros parâmetros mudaram juntos. Portanto, não prova que um único formato produziu todo o ganho nem que as mesmas velocidades valem para outro equipamento.

Use-o como pista de diagnóstico. Se seu limite reaparece na mesma faixa, inclua KV cache e backend no comparativo em vez de olhar apenas para o arquivo do modelo.

Crie uma linha de base antes de mexer na configuração de 72K

Salve uma linha de base reproduzível antes de alterar qualquer coisa. Caso contrário, mesmo que a nova pilha funcione, você não saberá qual mudança foi relevante.

Área	O que registrar
Modelo	Nome completo, arquivo exato, quantização dos pesos, tamanho
Backend	Nome, versão ou commit, forma de inicialização
Contexto	Janela solicitada, tokens reais de entrada, reserva para saída
KV cache	Tipo ou esquema, localização em GPU ou RAM, compressão
Hardware	Modelo e VRAM de cada GPU, RAM, topologia PCIe
Distribuição	Divisão entre GPUs, offload, travessias entre dispositivos
Runtime	Batch, concorrência, amostragem, saída máxima
Resultado	Sucesso ou erro, mensagem exata, pico de VRAM/RAM, prefill e geração

Não trate uma GPU de 16GB e outra de 8GB como um bloco simples de 24GB. O backend decide onde ficam pesos, cache e buffers; uma placa pode lotar primeiro, e o tráfego entre dispositivos pode dominar o custo em contexto longo.

Teste quatro variáveis separadamente

1. A quantização dos pesos muda a ocupação fixa

A quantização do modelo altera principalmente a memória necessária para carregar os pesos. Um arquivo menor pode abrir espaço para o KV cache, mas não garante uma janela maior e pode mudar qualidade ou velocidade.

Para verificar se os pesos estão espremendo o cache, mantenha backend, tipo de KV e prompt. Troque apenas a quantização dos pesos e registre quanta memória foi liberada e se o ponto de falha mudou.

2. O tipo de KV cache muda o custo por token

O KV cache guarda estados reutilizados na geração dos próximos tokens. Para um modelo e uma representação fixos, seu consumo tende a crescer aproximadamente com os tokens retidos, o que o torna a alavanca mais direta para contexto longo.

Compare três resultados em conjunto: pico de memória, maior entrada estável e precisão de recuperação. “Coube 128K” não é uma vitória útil se a exatidão cair ou o backend ficar instável.

3. O backend decide como tudo é implementado

Backends podem diferir no layout do cache, alocação, distribuição multi-GPU e kernels. O mesmo valor de contexto e o mesmo arquivo não precisam produzir a mesma curva de memória nem a mesma velocidade.

Se o backend candidato exige outro formato de KV, descreva o resultado como “esta pilha passou”. Não atribua tudo a um só formato. Para isolar o backend, faça outro A/B com configurações aceitas pelos dois sempre que possível.

4. A distribuição no hardware decide qual recurso falha primeiro

O erro comum em multi-GPU é observar apenas a VRAM total. A execução pode falhar porque uma placa não consegue uma alocação grande, o cache se concentra em um dispositivo, falta folga para a área de trabalho ou a troca via PCIe destrói o desempenho.

Acompanhe cada GPU. Se uma estiver quase cheia e outra tiver folga, rebalanceie a distribuição antes de sacrificar a qualidade do modelo.

Execute uma escada de aceitação de contexto longo

Não pule de um prompt curto diretamente para 128K. Uma escada fixa mostra se a falha surge de repente ou se a configuração perde utilidade aos poucos.

Um começo prático é 8K → 32K → 64K → 72K → 96K → 126K. O ponto de 126K fica perto de 128K e reserva espaço explícito para a saída; aumente essa reserva se você precisa de respostas longas.

Prepare um conjunto controlado de prompts

1. Conte tokens com o tokenizer realmente usado pelo modelo; não estime por caracteres nem tamanho do arquivo.
2. Insira “fatos canário” diferentes perto de 10%, 20% e assim por diante até 90%, como ORBIT-17 = copper.
3. Coloque uma restrição de código no início, outra no meio e outra no fim; peça que a resposta repita as restrições e aplique uma pequena alteração.
4. Mantenha ordem do conteúdo, amostragem e orçamento de saída iguais em todos os comprimentos.
5. Remova outras cargas e repita três vezes cada comprimento crítico.

Os canários medem recuperação, não toda a capacidade de programação. Na aceitação final, acrescente código, logs ou documentação semelhantes ao seu trabalho diário.

Registre sempre as mesmas métricas

Métrica	Pergunta respondida
Tokens reais de entrada	O backend aceitou o comprimento desejado?
Resultado da alocação e erro exato	Onde capacidade ou compatibilidade falharam?
Pico por GPU e pico de RAM	Qual dispositivo virou gargalo?
Tempo ou taxa de processamento do prompt	O prefill longo ainda é aceitável?
Velocidade de geração	A interação após o prompt longo é prática?
Canários recuperados	O modelo usa informações distantes?
Restrições de código cumpridas	A janela longa ajuda na tarefa real?

Defina o critério de aprovação antes do teste. Um exemplo: três conclusões seguidas no comprimento-alvo, nenhum erro de memória ou backend, pelo menos 9 de 10 canários corretos e tempo dentro do limite do seu fluxo. 9/10 é apenas um exemplo; o importante é não baixar o padrão depois de ver um 128K que apenas inicia.

Escolha o próximo passo conforme o resultado

OOM aparece sempre no mesmo comprimento

Descubra qual dispositivo lota primeiro. Se o crescimento do cache consome a folga, compare primeiro um esquema de menor ocupação. Se os pesos já deixam pouco espaço ao carregar, teste uma quantização menor. Mude uma coisa por execução e veja se o limite se desloca como previsto.

O backend novo chega a 128K e o antigo para em 72K

Trate a nova pilha como candidata, repita três vezes e complete o teste de recuperação. Se backend e cache mudaram juntos, a conclusão defensável é que a pilha funciona, não que uma causa única foi isolada.

128K termina, mas o desempenho é inaceitável

Esse é um limite operacional, não uma falha de capacidade. Use uma janela menor por padrão e ative contexto extremo só em tarefas específicas, ou compare modelo menor, outro backend e melhor distribuição. “Consegue rodar” e “vale usar todo dia” são decisões diferentes.

128K termina, mas perde informações do início

Trate como problema de qualidade do contexto efetivo. Rode o mesmo prompt em 64K, 72K e 96K para montar uma curva de recuperação. Se comprimentos menores forem claramente mais confiáveis, fixe o limite de produção onde a qualidade passa, não onde a memória cabe. Recuperação, divisão em blocos ou resumo prévio também reduzem material irrelevante em repositórios enormes.

Otimize uma janela verificada, não o maior número do menu

Se 72K cobre seus repositórios e logs habituais, não troque ao mesmo tempo quantização, KV cache, backend e divisão de GPU apenas para exibir 128K. Preserve a base estável e exija que cada mudança prove ganho de capacidade, velocidade ou recuperação.

Se você realmente precisa de mais de 100K de entrada, defina primeiro a escada e os critérios de aceitação, depois compare combinações de cache e backend. A conclusão útil é específica: “este modelo, backend, cache e hardware passaram em 126K três vezes com nossa velocidade e recuperação mínimas”, e não apenas “a configuração aceita 128K”.