Кэширование промптов в Kimi K3

Кэш срабатывает автоматически: первый вызов всегда по полной цене

Кэш не нужно включать — параметров для этого нет: он срабатывает, когда начало запроса (префикс) в точности повторяет один из предыдущих. Сколько токенов пришло из кэша, видно в поле usage.prompt_tokens_details.cached_tokens.

Мы сгенерировали совершенно новые случайные префиксы, которые никогда прежде не отправлялись в Moonshot, — значит, кэша для них существовать не могло (первый такой вызов ниже называем «холодным», повторный — «тёплым») — и отправили каждый префикс дважды:

// first call, fresh 12,504-token prefix
"usage": {
  "prompt_tokens": 12504,
  "completion_tokens": 32
  // no cached_tokens field at all
}

// second call, byte-identical prefix, ~2s later
"usage": {
  "prompt_tokens": 12504,
  "completion_tokens": 32,
  "prompt_tokens_details": {"cached_tokens": 12288}   // 96 blocks of 256
}

На всех протестированных префиксах, от 1,3 тыс. до 29 тыс. токенов, холодный вызов кэшировал ровно ноль. Частичного зачёта при первом контакте не бывает. Скидка существует только со второго запроса — а значит, нагрузка, в которой префикс никогда не повторяется, не выиграет ничего, какими бы большими ни были её промпты.

Размер блока — 256 токенов

Попадания в кэш начисляются не по токенам. В девяти тестах cached_tokens каждый раз возвращался строго кратным 256, оставляя вне кэша остаток до 255 токенов:

Хвост вне кэша никогда не дотягивает до одного блока

Токены вне кэша на каждом тёплом префиксе · девять префиксов, 1,3–29 тыс. · замерено 2026-07-16

Практический вывод: кэширование окупается пропорционально размеру префикса. У префикса в 300 токенов — максимум один кэшируемый блок и до 255 токенов некэшируемого хвоста: большая часть промпта по полной цене. У префикса в 50 тыс. — почти 200 блоков, и хвост превращается в погрешность округления. Не тратьте силы на выбивание попаданий в кэш на маленьких промптах.

prompt_cache_key не дал ничего измеримого

В документации API Moonshot есть параметр prompt_cache_key: он описан как средство сессионного кэширования и «рекомендован» для многоходовых диалогов. Читается как тот самый рычаг, за который положено дёргать. Это не так — по крайней мере для повторного использования префикса.

Мы провели чистый тест: совершенно новый префикс, первый вызов уже с явным prompt_cache_key, затем второй такой же вызов. Результат оказался неотличим от варианта без ключа:

Тот же промах на холодном вызове, то же попадание на тёплом. Автоматическое кэширование префикса уже сделало всю работу. Для нагрузок с повторяющимся префиксом этот параметр не нужен — а если вы добавили его в расчёте на скидку, то скидка пришла не отсюда.

Экономит деньги, а не время

Вот это нас удивило. Интуиция подсказывает: попадание в кэш пропускает часть работы, значит, должно быть быстрее. Но при сравнении холодных и тёплых вызовов на одном и том же префиксе астрономическое время не показало устойчивого улучшения:

Разброс от прогона к прогону на этих размерах перекрывает любой эффект кэша — и не забывайте: K3 в любом случае тратит секунды на рассуждения при каждом вызове, и именно они доминируют в общем времени. Относитесь к кэшированию промптов как к оптимизации счёта, а не задержки. Если нужна скорость — смотрите наши замеры задержки.

Сколько тёплый префикс остаётся тёплым

Прогретый префикс всё ещё возвращал те же 12 032 токена из кэша спустя 210 секунд — без деградации на пробах через 30, 90 и 210 секунд.

Это нижняя граница, а не TTL — на этой отметке мы перестали пробовать. Moonshot не документирует ни TTL, ни минимальную длину префикса, ни то, берётся ли доплата за запись в кэш, поэтому выдумывать числа мы не будем. Что можно сказать уверенно: префикс, повторно использованный в течение нескольких минут, остаётся тёплым — а это покрывает самый важный сценарий, цикл агента.

Как стабильно получать цену из кэша

• Стабильные байты — вперёд. Системный промпт, определения инструментов, длинные документы — в начало; меняющаяся реплика пользователя — в конец. Кэш сопоставляет префикс: одна ранняя правка обесценивает всё, что идёт после неё.
• Не пускайте дрейф в префикс. Метка времени, ID запроса, пересериализованный JSON с переставленными ключами — любое из этого меняет байты и молча скидывает вас на $3.00 за 1 млн. Это самый частый способ потерять скидку и не заметить.
• Пакуйте запросы под один префикс. Двадцати вопросам об одном документе нужен один тёплый префикс и двадцать коротких хвостов.
• Не выстраивайте кэширование под маленькие промпты. До ~256 токенов кэшировать нечего; до ~1 тыс. хвост — большая часть вашего счёта.
• Смиритесь с холодным вызовом. Первый запрос каждого холодного периода идёт по полной цене. Заложите его в бюджет вместо попыток спроектировать его исчезновение.
• Следите за cached_tokens в проде. Это единственный способ убедиться, что процент попаданий такой, каким вы его считаете. Если поля нет — это был промах.

Сколько стоит эта разница

Агент с фиксированным префиксом в 50 000 токенов, обслуживающий 200 запросов в день, — 10 млн входных токенов ежедневно:

Арифметика по официальным тарифам от 2026-07-16, только вход. Дешёвая строка идеализирована: холодные вызовы тарифицируются по полной цене, а хвост не кэшируется никогда. Выход в любом случае стоит $15.00/1M, и токены рассуждений на такой нагрузке могут превысить весь ваш счёт за вход. Это потолок и пол, а не смета.