В этом материале
Сохранение prompt cache слота llama.cpp нужно проверять как цикл save и restore конкретного состояния.
Сохранение prompt cache слота llama.cpp нужно проверять как цикл save и restore конкретного состояния. Успешная запись файла не гарантирует его восстановление на другой сборке, модели или контекстной конфигурации. Зафиксируйте эти зависимости и проверьте положительный и отрицательный сценарий. Такой файл отличается от обычного попадания в prefix cache: он переносит состояние между явно выбранными этапами жизненного цикла server slot, а не просто повторно использует текущую память процесса.
Установите границу состояния
Server README описывает slot-save-path и actions save, restore и erase. Сначала определите, какой slot сохраняется и что должно произойти после восстановления. Не считайте файл независимым от модели архивом разговора, который можно применять к любому checkpoint. Текст истории и внутреннее вычислительное состояние — разные артефакты. Для возможности пересчета сохраните исходный prompt отдельно: если restore недопустим, именно он позволяет восстановить требуемое вычисление обычным prefill, не полагаясь на совместимость бинарного состояния.
Подготовьте воспроизводимый цикл
На изолированном экземпляре выполните фиксированный prompt, дождитесь завершения, сохраните slot и запишите сборку, model revision и context settings. Затем выполните предусмотренный тестом переход жизненного цикла и restore. Не меняйте одновременно quantization и параметры cache: иначе причина отказа будет неоднозначной. Сохраняйте имя файла и фактический результат операции. HTTP успех и ненулевой размер файла полезны, но приемка заканчивается только после проверки восстановленного состояния и корректного продолжения выбранного запроса.
Пример отрицательных проверок
Добавьте неподходящий файл и состояние, не помещающееся в выбранный slot context. Реализация сервера проверяет 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-пулу; Воспроизводимый стек инференса: как сохранить результат GPU-пилота.