llama.cpp Массовая повторная обработка запросов с помощью кодовых агентов: отладка KV-кэша и обмена контекстом

Разработчик на r/LocalLLaMA столкнулся с серьезной проблемой производительности llama.cpp при запуске длинноконтекстных кодирующих агентов (opencode + pi.dev) через llama-swap. Даже при очень похожих промптах (сходство LCP часто >0.99) система периодически сбрасывает кэш KV и перерабатывает 40k+ токенов, что приводит к TTFT в несколько минут.

Наблюдаемое поведение

• Контекст вырастает до 50k+ токенов.
• После нескольких обычных повторных использований (например, prompt eval time = 473 ms / 19 tokens) значение n_past внезапно падает до ~4-5k.
• llama.cpp затем перерабатывает полный промпт: n_tokens = 4750 prompt eval time = 222411 ms / 44016 tokens.
• Использование кэша достигает 4676 МиБ, превышая установленный лимит (2500 МиБ).

Текущая конфигурация

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

Предполагаемые причины

• Инвалидация кэша из-за переполнения лимита --cache-ram – лог показывает 4676 МиБ использования против лимита 2500 МиБ.
• Плохой механизм повторного использования KV при изменении начальных токенов промпта (возможно, частые изменения в opencode).
• Недостаточные значения --ctx-checkpoints или --cache-reuse для размера контекста 150k.

Рекомендации сообщества

В обсуждении пока мало ответов, но очевидные первые шаги: увеличить --cache-ram до уровня типичного использования (например, 5000+ МиБ) или уменьшить --ctx-size, чтобы оставаться в пределах лимита кэша. Также стоит проверить, не изменяет ли opencode намеренно префиксы промптов; если да, фиксация системного промпта или использование фиксированного префикса может улучшить повторное использование.

Разработчикам, использующим подобные конфигурации, предлагается делиться своими рабочими настройками в исходном обсуждении.