Moonshot API — это модельный интерфейс открытой платформы Moonshot AI, то есть платформы разработчиков, стоящей за Kimi. Оплата идёт по расходу токенов, без подписки. При планировании бюджета команды чаще всего ошибаются в двух местах: продолжают вызывать уже снятую серию moonshot-v1 и смешивают вход, запись в кэш, выход и повторы в одну среднюю ставку. Ниже структура тарификации по публичной документации на октябрь 2026 года; конкретные цены — на странице цены на модели и в официальной документации.

Примечание: Moonshot и Kimi — товарные знаки соответствующих правообладателей. Статья носит технический характер и не подразумевает аффилированности или агентских отношений с правообладателями. Список моделей, длина контекста и правила тарификации могут меняться; перед закупкой сверьтесь с официальной страницей.

1. Сначала различите «актуальные» и «снятые» модели

По состоянию на октябрь 2026 года в документации платформы в качестве основных указаны kimi-k3, kimi-k2.6, kimi-k2.7-code и kimi-k2.7-code-highspeed. Старая серия moonshot-v1 выведена: moonshot-v1-8k, -32k, -128k, -auto и соответствующие визуальные preview-версии отключены 31 августа 2026 года; в тот же день отключена kimi-k2.5. Более ранние preview-версии kimi-k2, kimi-latest и другие также прекратили обслуживание.

Модель Контекст Структура биллинга Статус и примечание
kimi-k3 1 048 576 Вход, попадание в кэш, запись в кэш, выход Текущий флагман, официально рекомендуется как цель миграции
kimi-k2.6 262 144 Вход, попадание в кэш, выход Универсальная и мультимодальная, часто для чувствительных к затратам задач
kimi-k2.7-code 262 144 Вход, попадание в кэш, выход Генерация кода, вопросы по репозиторию и агенты
kimi-k2.7-code-highspeed 262 144 Вход, попадание в кэш, выход Кодовые задачи с низкой задержкой
moonshot-v1-8k/32k/128k По имени модели Старая тарификация по длине Снята с 31.08.2026

Имена моделей из старых руководств нельзя копировать напрямую. «8k» в moonshot-v1-8k — это и есть ступень контекста; сбой вызова связан не с ключом, а с тем, что модели больше нет. При миграции сначала измените имя модели, затем проверьте контекст и статьи биллинга — простой замены строки недостаточно.

2. Единица биллинга: один запрос состоит из четырёх частей

Текущий счёт обычно складывается из четырёх типов токенов: вход с промахом кэша, вход с попаданием, запись в кэш и выход. У K3 запись в кэш тарифицируется отдельно по двум TTL — 5 минут и 1 час; на странице цен серии K2 отдельной строки записи в кэш нет. Формула одного запроса:

Стоимость запроса =
  токены входа с промахом × ставка промаха
+ токены входа с попаданием × ставка попадания
+ токены записи в кэш × ставка соответствующего TTL (только K3)
+ токены выхода × ставка выхода

Официальная документация даёт полезный ориентир: в стандартном китайском тексте примерно 1,5–2 иероглифа соответствуют одному токену. Умножение числа символов на ставку занижает вход; для точного расчёта используйте оценочный интерфейс POST /v1/tokenizers/estimate-token-count или читайте usage из ответа.

В Chat Completions поля расхода — usage.prompt_tokens и usage.completion_tokens, детали кэша — в usage.prompt_tokens_details.cached_tokens и cache_write_tokens. В Messages API input_tokens не включает кэш; общий вход — сумма input_tokens, cache_read_input_tokens и cache_creation_input_tokens. Для потоковых вызовов задайте stream_options.include_usage=true.

3. Как тарифицируется кэш и почему случаются промахи

Кэш контекста работает по совпадению префикса, а не всего диалога. Любое изменение в префиксе делает содержимое после этой точки непригодным для повторного использования. Типичные разрушители префикса: вставка метки времени или случайного ID в system prompt, перестановка определений инструментов при каждом запросе, динамическая склейка фрагментов базы знаний, смена TTL. Кэш изолирован по организациям и между ними не разделяется.

Запись в кэш K3 тарифицируется при первой записи, TTL фиксирован — 5 минут или 1 час, после записи изменить его нельзя; попадание бесплатно продлевает кэш в рамках исходного TTL и не взимает плату за запись повторно. Два уровня кэша несовместимы. Если хвост префикса не образует полный блок кэша, эта часть обычно считается промахом.

Кэш — не переключатель «включил и экономлю», а работа с префиксом. Разместите system prompt, определения инструментов, фиксированные примеры и общую часть базы знаний в начале, переменные — в конце, а долю попаданий проверяйте по cached_tokens.

4. Стоимость длинного контекста: дорого обходится повторная передача

K3 поддерживает контекст 1 048 576 токенов, серия K2 — 262 144 токена. У K3 единая оплата по расходу, без старых ступеней 8k, 32k и 128k, как у moonshot-v1, поэтому старую таблицу ступеней нельзя использовать для расчёта K3.

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

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

5. Как считаются повторы и неудачные запросы

Официальные коды делят 429 на три категории: rate_limit_reached_error — достигнут предел параллелизма, RPM, TPM или TPD организации; exceeded_current_quota_error — недостаточно баланса или квоты; engine_overloaded_error — перегрузка мощности на стороне сервиса. Только проблему баланса можно решить пополнением; перегрузку пополнение не устраняет. Для 500 и 503 обычно рекомендуется повторить позже; при тайм-ауте шлюза на длинном запросе лучше перейти на потоковый режим, а не отправлять тот же запрос заново.

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

  1. Сначала классифицируйте по коду ошибки; задолженность, ошибки параметров и отказ модерации не повторяйте.
  2. Повторяйте ограниченно только 429 по лимиту, 500, 503 и сетевые обрывы.
  3. Используйте экспоненциальную задержку со случайным разбросом и соблюдайте Retry-After.
  4. Задайте верхний предел попыток и общее время, чтобы не занимать параллелизм бесконечно.
  5. Для вызовов инструментов используйте ключи идемпотентности или таблицу дедупликации, чтобы не создавать повторные заказы и сообщения.
  6. Записывайте request_id, имя модели, расход токенов и число повторов для сверки.

6. Оценка бюджета: от токенов к месячному пределу

Бюджет нужно выводить не из «сколько стоит миллион токенов», а из реальных задач. Возьмите 20–50 показательных задач, охватывающих простой, средний и сложный уровни, пропишите критерии приёмки; измерьте вход оценочным интерфейсом, прочитайте usage реальных вызовов и сравните модели по «полной стоимости одного качественного результата».

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "Извлеки этот договор в JSON: ……"}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

После оценки входа на один запрос добавьте четыре блока: историю сообщений, возвраты инструментов, долю промахов кэша и дополнительные вызовы из-за повторов. Для офлайн-пакетной обработки стоит оценить Batch API: по документации он примерно на 40% дешевле синхронных вызовов, но сейчас поддерживает только kimi-k2.7-code и kimi-k2.6; kimi-k3 пока не поддерживается.

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

7. Порядок снижения затрат и привычка сверки

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

  1. Зафиксируйте system prompt, определения инструментов и префикс базы знаний, проверяйте cached_tokens.
  2. Сокращайте передаваемый оригинал поиском и резюме, историю диалога суммируйте скользящим окном.
  3. Задайте max_completion_tokens, требуйте JSON или фиксированные поля, сокращая открытый длинный вывод.
  4. Маршрутизируйте модели по задачам: универсальные — kimi-k2.6, кодовые — версия K2.7 code, сверхдлинные материалы — K3.
  5. Длинные запросы переводите в потоковый режим, снижая повторы из-за тайм-аутов и обрывов.
  6. Офлайн-задачи отправляйте в Batch API, для реального времени оставляйте синхронный интерфейс.
  7. Ежемесячно сверяйте по проектам, моделям и сценариям, отдельно записывая долю попаданий в кэш, число повторов и среднюю длину выхода.

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

Частые вопросы

Можно ли ещё вызывать moonshot-v1-8k?

Нет. Вся серия moonshot-v1 отключена 31 августа 2026 года; официально рекомендуется миграция на kimi-k3. При миграции нужно не только сменить имя, но и заново проверить длину контекста, статьи биллинга и параметры вывода.

Почему попадание в кэш не срабатывает?

Сначала проверьте, не разрушен ли префикс меткой времени, случайным ID, динамической сортировкой или перестановкой инструментов; затем убедитесь, что интервал запросов не превысил TTL; наконец, что запись и чтение кэша идут в одной организации и на одном уровне TTL. Судите по cached_tokens, а не по ощущениям.

Длинный контекст всегда дороже?

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

Тарифицируются ли неудачные запросы?

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

Где смотреть актуальные цены?

На странице цены на модели и в официальной документации Moonshot/Kimi. Цены, список моделей и правила кэша могут меняться; не используйте старые скриншоты.

Что дальше

Создайте тестовый ключ в ZSQH AI Gateway, прогоните пакет реальных задач на kimi-k2.6 и kimi-k3, запишите вход, выход, попадания в кэш и повторы, затем выбирайте основную модель и месячный бюджет. Конкретные цены и доступные модели — на странице цены на модели.

Связанные статьи: