Kimi K3 Context Caching: оценка затрат в 2026

Официальная документация Kimi указывает, что kimi-k3 поддерживает контекст до 1 000 000 токенов, а входные токены с попаданием в кэш тарифицируются отдельно от обычного входа. (описание Kimi API и контекстного окна) Это не означает автоматическую экономию: если вы часто меняете начало запроса, редко повторяете контекст или запускаете много неудачных повторов, счёт может не уменьшиться.

План на эту неделю: сначала выгрузите логи Kimi K3 API, отдельно посчитайте повторяемый префикс, cache hit, промахи, вывод и повторы. Затем проведите короткий контрольный тест с неизменным системным сообщением. Только после этого выбирайте оптимизацию подсказок, разделение контекста или расширение среды запуска.

Эта статья для трёх групп:

• разработчиков кодовых Agent, которые отправляют большой системный промпт при каждом запросе;
• команд, работающих с фиксированными документами, правилами кода и базой знаний;
• руководителей AI SaaS, которым нужно разделить Token Cost модели, повторные запросы и постоянные расходы на сервер.

Последнее обновление: 3 августа 2026 года. Механизм и расчётная логика сверены с официальной страницей тарифов Kimi API, справкой по устранению проблем и описанием ограничений API. Актуальные тарифные поля проверяйте непосредственно в консоли перед расчётом бюджета.

1. Сначала определите, что именно должно повторяться

Kimi K3 Context Caching полезен не потому, что запрос длинный. Он полезен, когда несколько запросов используют один и тот же начальный контекст.

В типичном запросе Agent есть четыре слоя:

1. стабильная роль и правила ответа;
2. описание доступных инструментов;
3. фиксированная документация или кодовые соглашения;
4. сообщение пользователя, результаты инструментов и история текущей задачи.

Первые три слоя могут образовать повторяемый префикс. Последний слой обычно меняется. Поэтому длинная сессия сама по себе не гарантирует экономию.

Официальная справка указывает, что Kimi API автоматически пытается кэшировать повторяющийся начальный контекст. Отдельный cache ID, TTL или дополнительный параметр не требуется. При этом изменение префикса может снизить вероятность попадания в кэш. (официальная справка о Context Caching)

Нужно ли вручную включать кэширование контекста?

Нет, отдельное включение не требуется. Но автоматический механизм не освобождает вас от проектирования запросов. Вы должны сохранять одинаковыми порядок сообщений, текст системных правил, описания инструментов и неизменную часть документов. Если каждый запрос получает новый идентификатор версии, случайный блок времени или динамическую инструкцию в начале, повторное использование становится менее предсказуемым.

Практическая схема:

[стабильный system prompt]
[стабильные tool definitions]
[стабильные правила проекта]
[версия документа]
[текущий вопрос пользователя]
[новые результаты инструментов]

Динамические поля лучше помещать после стабильной части. Не вставляйте текущую дату, случайный идентификатор задачи или индивидуальные права пользователя в начало общего префикса, если они не должны влиять на весь контекст.

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

2. Проверьте фиксированные документы и правила кода

Вопросно-ответная система часто выглядит выгодным кандидатом для кэширования: инструкция одна, документы одни, вопросы разные. На практике экономия зависит от того, как именно вы собираете контекст.

Документная база

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

• обновление одного фрагмента может изменить общий префикс;
• другая сортировка разделов нарушает последовательность;
• разные пользователи могут получать разные права доступа и набор документов.

Поэтому храните документы в детерминированном порядке. Добавляйте явную версию набора. Не смешивайте в общей части пользовательский вопрос и персональные разрешения.

Файлы, загруженные через API, сами по себе не дают оснований считать последующий контекст бесплатным. При обращении к содержимому оно преобразуется во входные токены и участвует в расчёте использования. Поэтому после загрузки файла всё равно нужно контролировать фактически переданные токены и поля usage. (официальные правила тарификации Kimi API)

Кодовые стандарты

Для кодового Agent стабильными кандидатами являются:

• правила форматирования;
• описание архитектуры проекта;
• соглашения по тестам;
• структура репозитория;
• справочник инструментов;
• неизменные инструкции по безопасности.

Слабый вариант — добавлять в начало полный список изменённых файлов, текущую ветку и временные диагностические данные. Такой префикс будет различаться почти в каждом цикле.

Какие входные токены могут попасть в кэш?

В первую очередь — повторяемые начальные токены: системные инструкции, описания инструментов и стабильные справочные материалы. Текущий вопрос, новый результат поиска, свежий вывод терминала и изменённое сообщение пользователя относятся к динамической части. Официальная формулировка говорит именно о повторяющемся initial context, а не о любой похожей строке внутри запроса.

Нельзя делать вывод о cache hit только по тому, что в двух запросах встречается один и тот же документ. Для проверки сравнивайте последовательность сообщений, порядок блоков, версии шаблонов и фактические поля usage.

3. Разделите длинную сессию на повторное начало и новые раунды

Длинный диалог часто ошибочно считают идеальным сценарием для кэширования. В действительности каждая новая итерация добавляет сообщения, ответы инструментов и промежуточные решения.

Расходы нужно считать по четырём потокам:

• входные токены, попавшие в кэш;
• входные токены без попадания в кэш;
• выходные токены;
• дополнительные запросы из-за ошибок, тайм-аутов и повторов.

Базовая формула для одного запроса:

Стоимость запроса =
  cached_input_tokens × ставка cache hit
+ uncached_input_tokens × ставка cache miss
+ output_tokens × ставка output

Для задачи:

Стоимость успешной задачи =
  сумма стоимости всех запросов
+ стоимость повторов
+ стоимость дополнительных вызовов инструментов

Сами ставки не следует зашивать в статью или код навсегда. Kimi указывает, что API тарифицирует входные и выходные токены отдельно, а кэшированная часть входа имеет отдельную ставку. Подробные значения нужно брать из актуальной таблицы модели. (официальная страница тарифов и правил биллинга)

При расчёте сохраните хотя бы следующие поля:

• request_id;
• модель;
• время запроса;
• общее число входных токенов;
• cache hit и cache miss, если они возвращаются в ответе или доступны в биллинге;
• выходные токены;
• HTTP-статус;
• число повторов;
• результат задачи.

Считайте отдельно запросы и успешно завершённые задачи. Один результат пользователя может потребовать несколько вызовов API, поэтому средняя цена запроса почти всегда ниже реальной цены готового результата.

Становится ли длинная задача автоматически дешевле?

Нет. Длинный контекст может снизить среднюю цену входной части только при стабильном повторяемом начале. Новые сообщения, результаты инструментов и длинный вывод продолжают создавать расходы. Кроме того, большой запрос может увеличить время ответа и вероятность тайм-аута. Для Kimi K3 предел контекста до 1 000 000 токенов — это техническая вместимость, а не обещание низкой стоимости. (официальное описание модели Kimi K3)

4. Сравните четыре сценария до изменения архитектуры

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

Оценка здесь означает не процент экономии, а пригодность сценария для эксперимента. Не смешивайте cache hit rate с task success rate. Первый показывает, какая часть входного контекста обслуживается по льготной схеме. Второй показывает, завершилась ли задача полезным результатом.

Если из десяти запросов девять попали в кэш, но только шесть завершились без повтора, это не означает «экономия 90 %». Для бизнеса важнее стоимость шести успешных задач, включая неудачные вызовы и повторные действия.

5. Разделите общую часть и данные арендатора

В многопользовательском AI SaaS нельзя создавать единый кэш из данных разных клиентов.

Безопасная структура состоит из трёх уровней:

1. общий системный слой — правила ответа и формат результата;
2. изолированный слой арендатора — права, документы и настройки конкретной организации;
3. динамический слой задачи — вопрос, история и результаты инструментов.

Общий слой можно повторять между пользователями, если он действительно одинаков. Данные арендатора должны оставаться изолированными. Нельзя жертвовать границами доступа ради большего количества повторяемых токенов.

С точки зрения затрат это означает, что вы не должны умножать весь контекст на число пользователей. Сначала оцените:

общий префикс;
арендаторский префикс;
динамический ввод;
вывод;
повторы.

Затем вычислите стоимость каждого слоя отдельно. Если индивидуальная часть занимает большую долю запроса, оптимизация общего system prompt даст ограниченный эффект.

Работает ли кэш после изменения подсказки?

Изменение начала запроса может снизить попадание в кэш. Даже небольшая правка формулировки, новый блок безопасности или перемещённое описание инструмента могут создать другую последовательность токенов. Поэтому выпускайте шаблоны с версией и сравнивайте затраты до и после изменения.

Полезно вести журнал изменений:

версия шаблона;
дата выпуска;
изменённый блок;
средний input;
cached input;
output;
повторы;
стоимость успешной задачи.

Если после изменения подсказки доля кэшированного ввода выросла, но количество неудачных ответов увеличилось, итоговое решение нельзя считать удачным. Для Agent важен результат задачи, а не только статистика совпадения префикса.

6. Учтите повторы и циклы инструментов

Кэш не компенсирует бесконтрольное выполнение Agent.

Клиент или SDK могут автоматически повторять запросы. В справке Kimi указано, что некоторые ошибки по умолчанию повторяются два раза, то есть один исходный вызов может превратиться всего в три запроса. Это влияет на фактическое число обращений и использование лимитов. (официальная справка о повторах и лимитах)

Дополнительные причины роста счёта:

• повторное выполнение одного и того же инструмента;
• тайм-аут локального клиента при завершённом серверном запросе;
• повторная отправка всей истории после ошибки парсинга;
• запуск нескольких подагентов на одну задачу;
• слишком большой max_completion_tokens;
• повтор генерации после ответа, который не прошёл проверку.

Отсутствие результата в интерфейсе не доказывает отсутствие серверного вызова. Проверяйте HTTP-статус, request_id, usage, автоматические повторы и биллинг.

Для циклов инструментов задайте предохранители:

максимум попыток на один инструмент;
максимум общего времени задачи;
остановка при одинаковом tool name и arguments;
отдельный журнал каждого вызова;
ручное подтверждение рискованных операций.

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

Учитывайте и лимиты API. Kimi разделяет ограничения по параллельности, RPM, TPM и TPD. Поэтому большой контекст может влиять не только на Token Cost, но и на пропускную способность очереди. (официальные ограничения Kimi API)

7. Постройте расчёт из реальных логов

Начните не с процента экономии, а с таблицы наблюдений.

Зафиксируйте контрольный период, например рабочий день или неделю. Период должен содержать обычную нагрузку, а не только удачный демонстрационный тест.

Расчётная доля повторяемого входа:

Доля повторяемого входа =
  сумма cached_input_tokens
  / сумма всех input_tokens

Расчётная стоимость успешной задачи:

Стоимость успешной задачи =
  общая сумма биллинга
  / число успешно завершённых задач

Если биллинг не предоставляет cache hit и cache miss отдельно, не восстанавливайте эти значения по общей сумме. Используйте только доступные поля и помечайте результат как неполный. Нельзя выдавать расчётную долю за подтверждённую скидку.

Минимальный набор проверки:

1. выберите один тип задачи;
2. зафиксируйте версию системного шаблона;
3. исключите ручные запросы из выборки;
4. соберите все request_id;
5. сопоставьте статусы и повторы;
6. разделите успешные и неуспешные задачи;
7. сравните стоимость до и после изменения.

Как оценить экономию по журналам API?

Сначала сложите кэшированные входные токены за период. Затем отдельно сложите некэшированные входные токены, вывод и расходы на повторы. Подставьте актуальные ставки из консоли Kimi. После этого сравните фактическую стоимость с контрольным расчётом, в котором весь вход считается некэшированным.

Расчётная разница =
  стоимость контрольной схемы
  − фактическая стоимость

Это ещё не чистая прибыль. Из результата нужно вычесть время разработки, тестирование, поддержку версий шаблонов и стоимость дополнительного мониторинга.

8. Примените пятишаговый тест перед оптимизацией

Шаг 1. Зафиксируйте шаблон.
Сохраните неизменную версию system prompt, tool definitions и документов. Уберите случайные поля из начала.

Шаг 2. Разделите контекст.
Отметьте общие правила, данные арендатора, текущий вопрос и результаты инструментов.

Шаг 3. Создайте контрольную группу.
Отправьте несколько запросов без изменения стабильной части. Не меняйте модель, формат и параметры во время теста.

Шаг 4. Сопоставьте биллинг.
Для каждого вызова запишите request_id, usage, статус и факт повтора. Сравните данные с консолью.

Шаг 5. Посчитайте успешную задачу.
Сведите не только входные токены, но и выход, ошибки, инструментальные циклы и время работы Agent.

После этого выберите действие:

• если повторяемая часть большая, а успешные задачи стабильны — оптимизируйте структуру префикса;
• если общая часть мала, а основную долю создают индивидуальные документы — не ожидайте заметного эффекта от одного system prompt;
• если счёт растёт из-за повторов — сначала исправьте retry и tool loop;
• если затраты приемлемы, а изменение шаблона повышает риск ошибок — оставьте текущую схему;
• если Token Cost снижается, но сервер постоянно работает без нагрузки, пересчитайте общую стоимость среды.

9. Решите, что выгоднее: подсказка, модель или среда

После анализа логов у вас есть три направления.

Оптимизировать подсказку

Выбирайте этот путь, когда:

• одна и та же база инструкций используется многими задачами;
• префикс редко меняется;
• большая часть расходов приходится на вход;
• качество не ухудшается после разделения контекста.

Не удаляйте из system prompt критичные правила только ради уменьшения размера. Потеря корректности может привести к дополнительным повторам и ручной обработке.

Сохранить текущую схему

Это разумно, когда:

• запросы короткие или сильно персонализированы;
• кэш редко используется;
• основную стоимость создаёт вывод;
• Agent выполняет мало повторяющихся задач;
• измеримая экономия меньше времени на сопровождение шаблонов.

Изменить модель или архитектуру

Рассматривайте этот вариант, если оптимизация входа не меняет стоимость успешной задачи. Параметры рассуждения, объём вывода, количество инструментов и число подагентов могут влиять на итоговый счёт сильнее, чем повторяемый system prompt.

Увеличение вычислительной среды имеет смысл, если вы упираетесь в очередь, задержки, лимиты или постоянную работу Agent. Но сначала проверьте, не создаются ли лишние запросы клиентскими повторами. Разделяйте проблемы API, клиента и фонового процесса.

В качестве оценки используйте пять переменных:

Q — запросов за период;
R — доля повторяемого входа;
H — доля фактических cache hit;
O — объём вывода;
F — доля неудачных и повторных вызовов.

Ваш бюджет должен учитывать не только Q × R, но и O, F, время поддержки, очередь и стоимость постоянно работающего узла.

Что делать сейчас

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

Отдельно оцените инфраструктуру. Локальный ноутбук или случайная виртуальная машина часто имеют три слабых места: нестабильное сетевое подключение, отсутствие постоянного фонового процесса и ручное обслуживание при росте очереди. Для Agent это означает потерю состояния, задержки после перезапуска и дополнительные вызовы API. Кэш снижает часть Token Cost, но не устраняет эти операционные расходы.

Если вам нужен постоянный Mac-узел для тестирования Agent, очереди, интеграций и фоновых задач, можно рассмотреть аренду Mac для длительного запуска. У VPSSpark также есть отдельная информация о компании и формате обслуживания на странице об аренде Mac-инфраструктуры. Если требования связаны с конкретным регионом или режимом работы, перед запуском уточните детали через контактную форму VPSSpark.

Такой вариант не универсален. При кратком эксперименте дешевле оставить локальный запуск. При постоянной тяжёлой нагрузке нужно сравнивать аренду, собственное оборудование и другой облачный узел по полной стоимости. Но когда текущая среда теряет соединения, не умеет стабильно держать Agent и требует ручного контроля, аренда Mac у VPSSpark может оказаться практичнее, чем бесконечно оптимизировать только цену входного токена.