Измеренный ответ сразу: когда кеш промпта llama.cpp делает своё дело, второй вопрос по тому же документу возвращается почти мгновенно, а первый оплачивает весь префилл. Если кеш выключен или ваш пайплайн его ломает, эту цену платит каждый вопрос. Цифры и единственное условие, которое кешу нужно, — ниже.
Каждый, кто вставлял длинный файл в локальный ассистент, знает этот ритм. Первый ответ ползёт целую вечность. Все следующие приходят едва ли не раньше, чем вы дописали вопрос. Форумы объясняют это взмахом руки в сторону кеширования и на том останавливаются. Мы измерили реальный разрыв на одной коробке: рантайм запинен, три повторных прогона, сырые записи опубликованы.
Что мерили
Один Beelink GTR9 Pro с Ryzen AI Max+ 395 и 128 ГБ unified-памяти, llama.cpp server на бэкенде Vulkan, сборка запинена по digest образа. Модель — Qwen3.6-35B-A3B Q4_K_M, запинена по хэшу артефакта. Ворклоад — замороженная документная сессия: загрузить английский документ, задать вопрос, затем задать второй по тому же документу. Два размера документа, 8k и 32k токенов. Reasoning выключен. Единственный переключатель под исследованием — серверный кеш промпта.
Сколько реально экономит кеш промпта?
Первый вопрос к 32k-документу стоит 33940мсrepeated. Это счёт за префилл: модель читает весь документ, прежде чем сказать хоть слово, и никакой кеш на свете не поможет документу, который она видит впервые.
Второй вопрос по тому же документу, когда кеш промпта делает своё дело, стоит 860мсrepeated. Документ уже переварен; сервер обрабатывает только то, что изменилось.
Теперь контрольная ячейка. Тот же второй вопрос с выключенным кешем: 33728мсrepeated. Полный префилл, оплаченный заново, за документ, который сервер только что прочитал. Именно в этой конфигурации тихо живёт удивительно много локальных установок.
На меньшем 8k-документе второй вопрос с кешем возвращается за 660мсrepeated — кешированный путь почти не замечает размера документа. Некешированный растёт вместе с ним.
Когда кеш промпта llama.cpp вообще срабатывает?
Кеш сопоставляет по префиксу, байт в байт, в пределах живой серверной сессии. Всё, что трогает байты перед вашим новым вопросом, выбрасывает экономию: системный промпт со вшитым текущим временем, RAG-пайплайн, который между ходами переранжирует и перетасовывает найденные фрагменты, прокси, переписывающий историю, перезапуск сервера. Документ обязан приходить идентичным, на том же месте, каждый ход.
Поэтому жалобы «у меня и следующие вопросы медленные» — обычно не про железо. С коробкой всё в порядке. Что-то посередине переписывает префикс, и каждый вопрос платит цену первого.
Что это меняет на практике
Для персонального документного ассистента на железе этого класса рабочая схема такая: заплатить за заполнение один раз, дальше сидеть в сессии и спрашивать всё, что накопилось. Больно делает другая схема — скакать между документами или любой пайплайн, пересобирающий контекст на каждый запрос. Прежде чем покупать железо побыстрее ради медленных follow-up-вопросов, посмотрите, что ваш стек делает с префиксом. Лечение может оказаться бесплатным.
Чего это НЕ говорит
- Здесь ничего нет о качестве ответов. Сессионный ворклоад гейтит формат, язык и повторы; понимание он не оценивает.
- Одна модель, один квант, один бэкенд, одна коробка. Переносится форма разрыва; точные цифры — нет.
- Это поведение llama.cpp server. Другие рантаймы кешируют иначе, и здесь мы их не меряли.
Матрица бок о бок — на странице сравнения, вердикт по протестированной конфигурации — на карточке doc-session. У каждой цифры выше есть постоянная страница со скоупом, ограничениями и сырыми прогонами: реестр клеймов.