llama.cpp Reprocesamiento Masivo de Prompts con Agentes de Codificación: Depuración de Caché KV e Intercambio de Contexto

Un desarrollador en r/LocalLLaMA se encuentra con un grave problema de rendimiento con llama.cpp al ejecutar agentes de codificación de contexto largo (opencode + pi.dev) a través de llama-swap. Incluso con prompts muy similares (similitud LCP a menudo >0,99), el sistema descarta periódicamente la caché KV y reprocesa más de 40k tokens, lo que provoca un TTFT de varios minutos.

Comportamiento observado

• El contexto crece hasta 50k+ tokens.
• Después de varios reúsos normales (por ejemplo, prompt eval time = 473 ms / 19 tokens), n_past cae repentinamente a ~4-5k.
• llama.cpp entonces reprocesa el prompt completo: n_tokens = 4750 prompt eval time = 222411 ms / 44016 tokens.
• El uso de caché alcanza 4676 MiB, superando el límite configurado (2500 MiB).

Configuración actual

llama-server --ctx-size 150000 --parallel 1 --ctx-checkpoints 32 --cache-ram 2500 --cache-reuse 256 -no-kvu --no-context-shift

Causas sospechadas

• Invalidación de caché por desbordamiento del límite --cache-ram – el registro muestra 4676 MiB usados frente al límite de 2500 MiB.
• Mecanismo de reúso de KV defectuoso cuando los tokens iniciales del prompt cambian (posiblemente alteraciones frecuentes por opencode).
• --ctx-checkpoints o --cache-reuse insuficientes para el tamaño de contexto de 150k.

Recomendaciones de la comunidad

El hilo tiene pocas respuestas hasta ahora, pero los primeros pasos obvios incluyen aumentar --cache-ram para igualar el uso típico (por ejemplo, 5000+ MiB), o reducir --ctx-size para mantenerse por debajo del límite de caché. También verificar si opencode está mutando intencionalmente los prefijos de prompt; de ser así, bloquear el prompt del sistema o usar un prefijo fijo podría mejorar el reúso.

Para desarrolladores que ejecuten configuraciones similares, compartan sus configuraciones funcionales en el hilo de origen.