Большое число попаданий в кэш (cache hit) не означает бесплатный запрос, а промахи (cache miss) не доказывают поломку. Для проверки расходов DeepSeek нужны три числа: закэшированные входные токены, остальные входные токены и выходные токены. Токены — единицы текста для учёта объёма. Их общего количества недостаточно для расчёта цены.
Нулевые попадания при похожих запросах не раскрывают внутреннюю архитектуру сервиса. Сначала сравните фактический вход и показатели usage, вместо настройки предполагаемого «липкого сервера».
Что действительно кэшируется
Текущая документация описывает автоматически включённый кэш префикса, то есть начальной части запроса. Попадание требует полного совпадения с уже сохранённым блоком префикса, а не просто похожего текста.
В официальном примере запросы A+B и A+C сначала помогают системе выделить общее A. Использовать этот сохранённый префикс может следующий запрос A+D. Поэтому правило «второй запрос обязан попасть в кэш» неверно.
Практическая настройка: держите постоянные инструкции и повторяемый документ в начале, а переменный вопрос ближе к концу. Не добавляйте перед общим текстом меняющуюся метку времени (timestamp) или случайный идентификатор без необходимости.
Сравнивайте фактически отправленные сообщения, а не шаблон до обработки библиотекой.
Что записывать в журнал
- usage.prompt_cache_hit_tokens: входные токены, попавшие в кэш.
- usage.prompt_cache_miss_tokens: входные токены без попадания.
- Выходные токены, имя модели, время запроса и endpoint, то есть адрес API.
Для стоимости умножьте каждую категорию на её ставку за миллион токенов, сложите результаты и разделите на миллион. Не прибавляйте hit второй раз к уже полному входу.
Официальная таблица цен различает cache hit, cache miss, выход, а также пиковое и непиковое время. Ставки посредника могут отличаться: сначала выясните, кому именно платит интеграция.
Почему попадания не гарантированы
Кэш работает по принципу best effort: сервис старается использовать его, но не гарантирует попадание для каждого запроса. Создание занимает секунды, неиспользуемые записи обычно очищаются через часы или дни.
При устойчивой аномалии сохраняйте идентификаторы запросов и обезличенный минимальный пример, а не объявляйте причиной балансировщик по одному заголовку.
Проверено 10 ноября 2026 года. Собственные замеры скорости или экономии не проводились.
Последнее редактирование: