llama.cpp Reprocessamento Massivo de Prompts com Agentes de Codificação: Depuração do Cache KV e Troca de Contexto
Um desenvolvedor no r/LocalLLaMA está enfrentando um sério problema de performance com o llama.cpp ao executar agentes de codificação de contexto longo (opencode + pi.dev) via llama-swap. Mesmo com prompts altamente semelhantes (similaridade LCP frequentemente >0,99), o sistema descarta periodicamente o cache KV e reprocessa 40k+ tokens, causando TTFT de vários minutos.
Comportamento Observado
- O contexto cresce para 50k+ tokens.
- Após várias reutilizações normais (ex.:
prompt eval time = 473 ms / 19 tokens), on_pastcai subitamente para ~4-5k. - O llama.cpp então reprocessa o prompt completo:
n_tokens = 4750 prompt eval time = 222411 ms / 44016 tokens. - O uso do cache atinge 4676 MiB, excedendo o limite configurado (2500 MiB).
Configuração Atual
llama-server --ctx-size 150000 --parallel 1 --ctx-checkpoints 32 --cache-ram 2500 --cache-reuse 256 -no-kvu --no-context-shiftCausas Suspeitas
- Invalidação do cache devido ao estouro do limite de
--cache-ram– o log mostra 4676 MiB usados vs. limite de 2500 MiB. - Mecanismo de reutilização KV ruim quando os tokens iniciais do prompt mudam (possivelmente alterações frequentes pelo opencode).
--ctx-checkpointsou--cache-reuseinsuficientes para o tamanho de contexto de 150k.
Recomendações da Comunidade
A discussão ainda tem poucas respostas, mas os primeiros passos óbvios incluem aumentar --cache-ram para corresponder ao uso típico (ex.: 5000+ MiB), ou reduzir --ctx-size para ficar abaixo do limite do cache. Verifique também se o opencode está alterando intencionalmente os prefixos do prompt; em caso afirmativo, travar o prompt do sistema ou usar um prefixo fixo pode melhorar a reutilização.
Para desenvolvedores com configurações semelhantes, compartilhem suas configurações funcionando no tópico de origem.
📖 Leia a fonte completa: r/LocalLLaMA
👀 See Also
Cinco Erros Comuns na Configuração do OpenClaw que Desperdiçam Dinheiro e Criam Riscos de Segurança
Com base na análise de mais de 50 configurações do OpenClaw, os mesmos cinco problemas aparecem repetidamente: usar o Opus como modelo padrão em vez do Sonnet para a maioria das tarefas, nunca iniciar sessões novas, instalar habilidades sem ler o código-fonte, expor o gateway à rede e adicionar um segundo agente antes de consertar o primeiro.
Como um comando /loop queimou US$ 6.000 na API Claude durante a noite
O comando /loop não monitorado de um desenvolvedor executado a cada 30 minutos no claude-opus-4-7 consumiu US$ 6.000 em uma noite devido à expiração do cache de prompt e ao crescimento do contexto — uma história de alerta para automação de agentes de IA.
Correção de Timeout do OpenClaw LLM para Carregamento de Modelo Frio
Um usuário do Reddit identificou e corrigiu um problema específico de timeout no OpenClaw, onde LLMs locais carregados a frio falhavam após cerca de 60 segundos, mesmo com timeouts gerais mais altos configurados. A solução envolve ajustar a configuração do timeout de inatividade do LLM do embedded-runner.
Oito Técnicas de Prompt que Melhoram a Qualidade da Saída do Claude
Um usuário do Reddit compartilha oito técnicas específicas de prompt que melhoraram consistentemente a qualidade da saída do Claude, incluindo comandos como "Pense em cada camada antes de responder" e "Encontre os 20% das ações que geram 80% dos resultados".