# Сохранение слота llama.cpp: как проверить restore prompt cache из файла

Сохранение prompt cache слота llama.cpp нужно проверять как цикл save и restore конкретного состояния.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/llama-cpp-slot-cache-persistence/
Language: ru

Сохранение prompt cache слота llama.cpp нужно проверять как цикл save и restore конкретного состояния. Успешная запись файла не гарантирует его восстановление на другой сборке, модели или контекстной конфигурации. Зафиксируйте эти зависимости и проверьте положительный и отрицательный сценарий. Такой файл отличается от обычного попадания в prefix cache: он переносит состояние между явно выбранными этапами жизненного цикла server slot, а не просто повторно использует текущую память процесса.

## Установите границу состояния

[Server README](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/server/README.md) описывает `slot-save-path` и actions save, restore и erase. Сначала определите, какой slot сохраняется и что должно произойти после восстановления. Не считайте файл независимым от модели архивом разговора, который можно применять к любому checkpoint. Текст истории и внутреннее вычислительное состояние — разные артефакты. Для возможности пересчета сохраните исходный prompt отдельно: если restore недопустим, именно он позволяет восстановить требуемое вычисление обычным prefill, не полагаясь на совместимость бинарного состояния.

## Подготовьте воспроизводимый цикл

На изолированном экземпляре выполните фиксированный prompt, дождитесь завершения, сохраните slot и запишите сборку, model revision и context settings. Затем выполните предусмотренный тестом переход жизненного цикла и restore. Не меняйте одновременно quantization и параметры cache: иначе причина отказа будет неоднозначной. Сохраняйте имя файла и фактический результат операции. HTTP успех и ненулевой размер файла полезны, но приемка заканчивается только после проверки восстановленного состояния и корректного продолжения выбранного запроса.

## Пример отрицательных проверок

Добавьте неподходящий файл и состояние, не помещающееся в выбранный slot context. [Реализация сервера](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/server/server-context.cpp) проверяет restored tokens, размеры и полноту отдельных компонентов. Такие ветви должны давать понятный отказ, а не незаметное использование поврежденного состояния. Это схема приемки, не инструкция портить рабочий cache файл. Создавайте отдельные тестовые fixtures и сохраняйте исходную валидную копию. Если runtime возвращает возможность повторного prefill, отличайте ее от успешного restore, чтобы отчет не приписал сохраненному состоянию работу, выполненную заново.

## Учитывайте дополнительные данные

В зависимости от режима state может включать связанные checkpoints или draft составляющую. Не переносите предположение о простом текстовом случае на любой speculative или мультимодальный путь. Читайте условия выбранной версии и сохраняйте диагностические сообщения. Также ограничьте владение файлами состоянием соответствующего slot и тестового workflow, чтобы один сценарий не восстановил чужой fixture по случайно совпавшему имени. Имя файла должно идентифицировать модель и сборку через manifest, а не служить единственным источником правды о содержимом.

## Оформите стратегию восстановления

Запишите, где допустим restore и где следует пересчитать исходный prompt. При несовместимости не обещайте универсальную миграцию binary state: поддержка зависит от реализации. Сохраните функциональный результат и, если измеряете время, разделите чтение файла и дальнейший прогрев. Проверяйте поведение после обновления llama.cpp до открытия рабочего потока. Итоговый пакет включает исходный вход, state file, manifest и журнал приемки. Он позволяет отличить реальное восстановление от повторного вычисления и дает понятный fallback без попытки объявить любой файл prompt cache долговечным переносимым форматом между версиями, устройствами и произвольными моделями только потому, что операция save когда-то завершилась успешно.

## Связанные материалы

[Prefix caching: когда повторяющийся контекст помогает GPU-пулу](/ru/journal/prefix-caching/); [Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/).