Компактификация контекста в OpenCode на локальной модели может занимать больше десяти минут. Причина не в самой генерации саммари, а в устройстве стандартного механизма сжатия: он вырезает начало диалога вместе с системным промптом и описаниями инструментов, из-за чего кэш префилла обнуляется и модель заново обрабатывает всю беседу.
Разработчик lennartschoch опубликовал плагин opencode-cache-compact, который меняет этот порядок. Диалог остается неизменным, модель сначала пишет саммари, и только потом контекст сжимается до системного промпта, описаний инструментов и пересказа. По словам автора, на его Strix Halo операция стала занимать около 1-2 минут вместо более чем 10 минут ранее. Это первый открытый проект автора в области локальных LLM, и он просит обратную связь о полезности решения.
Ниже разобрано, как работает кэш префилла, почему стандартный компактинг его ломает, что именно делает плагин, откуда берется выигрыш в скорости и какие ограничения у подхода остаются непроверенными.
Что такое компактификация контекста в OpenCode и почему она тормозит на локальных моделях
OpenCode работает как агентная среда для LLM: системный промпт, описания инструментов и история вызовов лежат в одном растущем контексте. Чем дольше сессия, тем больше токенов прогоняется через модель на каждом шаге. Чтобы контекст не рос бесконечно, OpenCode периодически выполняет компактификацию: просит модель сжать историю и подменяет старую часть диалога кратким пересказом.
Стандартный механизм устроен так, что он вырезает блок токенов из начала беседы, включая системный промпт и описания инструментов (описание плагина на r/LocalLLaMA). Для хостинговых моделей это приемлемо: провайдер сам управляет кэшем, а повторная обработка промпта не так заметна по времени. На локальном железе логика другая, и разница проявляется в минутах.
Как работает кэш префилла и почему он важен для локального инференса
Префилл - это этап, на котором модель обрабатывает входной контекст перед выдачей первого токена ответа. На каждый токен промпта строятся промежуточные представления, и при длинном контексте именно они занимают основную часть времени. Генерация ответа при этом может занимать секунды, тогда как обработка промпта из десятков тысяч токенов на домашней системе растягивается на минуты. Как соотносятся ускорение префилла и реально измеренные результаты на локальных моделях, подробно разобрано в материале про KV-кэш и ускорение prefill на Qwen.
Кэш префилла снимает часть этой нагрузки. Если следующий запрос начинается с того же набора токенов, что и предыдущий, рантайм берет уже посчитанные представления из кэша и обрабатывает только новый хвост диалога. Работает это по принципу самого длинного общего префикса: совпадать должно начало, а не середина или конец. Поменяли первый токен промпта - весь кэш невалиден, даже если остальные 50 тысяч токенов остались на месте.
Цену такого механизма хорошо показывает кейс с перестановкой промпта: когда вопрос с фиксированными вариантами ответа поставили перед контекстом, медианная задержка локального Qwen3.6-35B-A3B снизилась с 400 до 80 мс именно за счет более стабильного префикса. Механика разобрана в статье про порядок промпта и кэширование префикса.
Почему стандартный компактинг ломает кэш
Цепочка выглядит так:
- Стандартная компактификация удаляет начало диалога вместе с системным промптом и описаниями инструментов.
- Первый токен нового запроса перестает совпадать с тем, что лежит в кэше.
- Кэш префилла инвалидируется целиком, а не частично.
- Модель заново префиллит весь оставшийся диалог, чтобы затем сгенерировать саммари.
Отсюда и берется время операции больше десяти минут: дорогая часть - не генерация пересказа, а повторная обработка беседы, которая до этого лежала в кэше. Автор плагина формулирует это прямо: для хостинговых моделей вырезание начала диалога нормально, а на локальной модели оно означает префилл всей беседы заново.
Как плагин opencode-cache-compact меняет механизм сжатия
Плагин меняет порядок действий: начало диалога не трогается до того момента, когда саммари уже готово.
Пошагово: сохранение диалога, генерация саммари, перестройка контекста
- Диалог сохраняется как есть. Плагин не вырезает системный промпт и описания инструментов перед сжатием, поэтому префикс запроса совпадает с префиксом предыдущих шагов сессии.
- Модель пишет саммари. Запрос уходит к той же модели с уже закэшированным префиксом, и на этот этап тратятся только токены нового задания плюс генерация пересказа.
- Контекст перестраивается. После получения саммари история заменяется: остаются системный промпт, описания инструментов и текст пересказа, а промежуточные сообщения удаляются.
Такой порядок сохраняет кэш ровно там, где он нужен. К моменту перестройки самая дорогая операция уже позади, и обнуление кэша стоит только одного префилла нового, короткого контекста. Автор описывает это так: плагин держит беседу неизменной, просит модель написать саммари, а затем преобразует диалог, оставляя только системный промпт, инструменты и сам пересказ (сообщение автора).
Почему это ускоряет операцию: роль кэша префилла
Ускорение объясняется переиспользованием кэша, а не более быстрой генерацией и не более умным алгоритмом сжатия. Там, где раньше требовался префилл всей беседы, теперь берутся готовые представления из кэша, и модель обрабатывает только новый текст задания.
По словам автора, поскольку весь диалог остается в кэше, операция занимает около 1-2 минут на его Strix Halo, тогда как раньше уходило больше 10 минут (описание проекта). Это замеры одного человека на одном устройстве, независимых проверок нет.
Насколько это быстрее на практике: цифры и условия
Доступны только две цифры: около 1-2 минут против более чем 10 минут. Все остальное - рамки, в которых такой результат имеет смысл.
Что означает Strix Halo в контексте теста
Strix Halo - аппаратная платформа, на которой автор измерял время компактификации. Это единственная известная конфигурация с опубликованным замером. Переносить цифру 1-2 минуты на свою систему напрямую нельзя: время префилла зависит от модели, квантизации, длины контекста и пропускной способности памяти, а не только от плагина.
От чего зависит ускорение на других конфигурациях
- Наличие кэша префилла в рантайме. Если бэкенд не переиспользует посчитанный префикс, экономить нечего.
- Стоимость префилла на конкретной модели. Чем длиннее контекст и чем медленнее обработка промпта, тем заметнее разница между повторным префиллом и работой из кэша.
- Длина диалога до сжатия. На коротких сессиях разница будет в пределах погрешности, потому что префиллить почти нечего.
- Объем памяти и скорость подсистемы памяти. Кэш префилла хранится в VRAM или системной памяти, и при нехватке места часть представлений придется пересчитывать.
То, как разные патчи и настройки рантайма влияют на скорость обработки промпта, видно на примере экспериментов с MoE-инференсом в llama.cpp: часть изменений дала прирост, часть - регрессии. Для плагина это означает простую вещь: эффект нужно мерить у себя, а не переносить с чужой машины.
Ограничения и риски подхода
Чего мы пока не знаем
- Как плагин ведет себя на очень длинных диалогах, где саммари становится объемным.
- Как меняется качество пересказа по сравнению со стандартным механизмом сжатия.
- Есть ли накладные расходы на перестройку контекста после генерации саммари и насколько они заметны.
- Как решение сочетается с разными моделями и рантаймами, помимо конфигурации автора.
Ответов на эти вопросы в описании проекта нет. Подход меняет поведение стандартной компактификации, поэтому теоретически возможны эффекты на качество саммари или на дальнейшую работу агента, но это гипотеза, а не подтвержденный факт.
Кому подход может не подойти
- Вы работаете только с хостинговыми моделями: проблема повторного префилла там стоит иначе, и выигрыш может быть незаметным.
- Ваш рантайм не переиспользует кэш префилла: ускорять нечего.
- Вы не используете OpenCode: плагин написан под эту среду и напрямую не переносится.
- Вам нужна предсказуемость: это первый открытый проект автора в области локальных LLM, зрелость решения сообщество пока не проверило.
Как попробовать opencode-cache-compact и что проверить
Проект открытый, автор - lennartschoch, код опубликован на GitHub. Автор отдельно просит обратную связь о полезности решения, так что рассказ о своих результатах уместен.
Мини-чек-лист для самостоятельной проверки
- Возьмите типичный для вас сценарий в OpenCode и зафиксируйте время компактификации без плагина. Лучше на трех похожих диалогах, а не на одном.
- Установите плагин по инструкции из репозитория.
- Повторите тот же сценарий с сопоставимым объемом контекста и той же моделью.
- Сравните время операции, а не только факт ее успешного завершения.
- Проверьте качество итогового саммари: не потерялись ли детали, которые агенту нужны дальше.
- Понаблюдайте за работой агента после перестройки контекста: сохраняются ли роли, инструменты и текущая задача.
Для чистоты сравнения держите одинаковый контекст, модель и настройки семплинга. Единичный замер ничего не доказывает: разброс времени префилла может быть заметным сам по себе.
Что это говорит о кэшировании префилла в локальных LLM
Кейс opencode-cache-compact показывает общий принцип: на локальных моделях любая операция, меняющая начало контекста, рискует обнулить кэш префилла и превратить дешевое действие в дорогое. Компактификация - только один пример. Тот же эффект дают перестановка системного промпта, смена порядка сообщений, добавление или удаление инструмента в начале сессии.
Практический вывод простой: при работе с локальными моделями стоит строить пайплайн так, чтобы префикс оставался стабильным до конца дорогой операции. Это не универсальное решение и не замена грамотной настройке инференса, а способ убрать лишнюю работу там, где она не нужна. Кэширование префилла заслуживает отдельного внимания при выборе рантайма и модели: от него напрямую зависит, насколько комфортно длинная сессия пойдет на вашем железе.