Как выровнять счета Qwen3.8-Max, Kimi K3 и DeepSeek V4

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

Самое быстрое решение: не сравнивайте тарифы напрямую. Для Qwen3.8-Max, Kimi K3 и DeepSeek V4 приведите расходы к стоимости одной задачи, которая прошла одинаковую проверку качества, отдельно учитывая вход, кэш, вывод, ошибки, повторные вызовы и инструменты.

Эта статья предназначена независимым разработчикам, которые собирают единую таблицу по пробным счетам. Она также полезна техническим руководителям, отвечающим за API-бюджет, и командам AI Agent, где повторные попытки и вызовы инструментов часто меняют итоговую сумму.

Последнее обновление: 8 августа 2026 года. Правила и доступность моделей сверены по официальным страницам документации и тарифов; перед закупкой необходимо повторно проверить модельный идентификатор, цену и дату действия скидок.

Почему тарифная строка не равна стоимости задачи

Проблема возникает из-за смешения трёх разных уровней расчёта:

1. Платёжный уровень — сумма подписки, пополнения или пакета.
2. Уровень потребления — Credits, входные Token, выходные Token, попадание в кэш.
3. Бизнес-уровень — число задач, которые действительно прошли проверку и не потребовали дополнительной работы.

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

Для DeepSeek официальная документация прямо разделяет входные Token с попаданием в кэш, входные Token без попадания в кэш и выходные Token. На проверенной странице для deepseek-v4-flash указаны цены 0,0028 доллара за миллион кэшированных входных Token, 0,14 доллара за миллион входных Token без кэша и 0,28 доллара за миллион выходных Token; для deepseek-v4-pro — 0,003625, 0,435 и 0,87 доллара соответственно. Это только коэффициенты формулы, а не стоимость завершённой задачи. (api-docs.deepseek.com)

У Kimi официальный API работает по модели оплаты за фактическое потребление, а подписка Kimi Membership и API-биллинг относятся к разным продуктам. Поэтому Credits или лимиты интерфейсного тарифа нельзя автоматически считать эквивалентом API-Token. (kimi.com)

С Qwen3.8-Max нужна дополнительная осторожность: в официальной таблице Alibaba Cloud, которую мы проверили 8 августа 2026 года, присутствуют другие идентификаторы серии Qwen Max, включая qwen3.7-max и версии с датой, но это не является подтверждением цены именно для Qwen3.8-Max. Если в кабинете используется такое название, в расчёте нужно сохранить фактический model_id, регион, режим и дату тарифа, а не подставлять цену похожей модели. (alibabacloud.com)

Единый знаменатель: одна успешно завершённая задача

Базовая формула должна выглядеть так:

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

В общий расход входят:

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

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

Таблица 1. Какие показатели можно сравнивать

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

Первая проверка: разделите модель, тариф и продукт

Перед расчётом создайте отдельные строки для каждого сочетания:

поставщик → модельный идентификатор → регион → режим → тарифная версия → период действия

Не объединяйте в одну строку:

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

Официальная таблица Alibaba Cloud показывает, что у моделей Qwen могут использоваться ступени цены по длине входа, разные регионы и отдельные пометки для временных скидок и кэширования. Поэтому строка «Qwen Max — столько-то за миллион Token» без региона и диапазона контекста недостаточна для бюджета. (alibabacloud.com)

Для Qwen3.8-Max Credits нельзя переводить в стоимость миллиона Token, если официальный источник не публикует такую связь. Допустим только расчёт вида:

стоимость одного Credits =
фактическая сумма оплаты / фактически приобретённое число Credits

Но затем Credits всё равно нужно разделить на число успешных задач:

стоимость успешной задачи =
израсходованные Credits / успешно завершённые задачи

Можно ли перевести Credits Qwen3.8-Max в цену миллиона Token? Только если официальная документация одновременно указывает коэффициент Credits к Token, условия его действия и модельный идентификатор. Если такого правила нет, перевод будет предположением. Для закупки безопаснее вести две независимые метрики: «стоимость успешной задачи в Credits» и «стоимость успешной задачи в валюте».

Таблица 2. Рабочая схема для трёх моделей

Для Kimi K3 официальная документация указывает контекст до 1 миллиона Token, автоматическое кэширование и поддержку Tool Calls. Это означает, что при сравнении длинных задач нужно фиксировать не только объём входа, но и состояние кэша и количество инструментальных вызовов. (platform.kimi.ai)

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

Длинный контекст создаёт три разных режима расходов:

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

Для корректного теста одной задачи недостаточно. Возьмите одинаковый документ и проведите три серии:

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

В журнале сохраните:

task_id
model_id
input_tokens
cached_input_tokens
uncached_input_tokens
output_tokens
cache_status
latency
success

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

DeepSeek V4 официально заявляет контекст до 1 миллиона Token, поддерживает кэшированный и некэшированный вход, а также Tool Calls. При этом сама документация предупреждает о возможном повышении цен в будущем, поэтому опубликованный тариф нужно хранить вместе с датой проверки. (api-docs.deepseek.com)

Как сопоставить кэширование Kimi K3 и DeepSeek V4? Не по проценту скидки и не по рекламной формулировке. Сначала разделите одинаковый набор входных Token на hit и miss, затем умножьте каждую группу на её официальную цену и добавьте выход. Только после этого сравнивайте стоимость успешной задачи с одинаковой долей повторно используемого контекста.

Кэш полезен прежде всего для:

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

Он менее предсказуем для:

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

Программный агент: считайте всю цепочку, а не последний ответ

В программном агенте одна пользовательская задача может включать:

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

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

Записывайте каждую попытку с указанием причины:

attempt_id
parent_task_id
tool_name
tool_cost
request_tokens
cached_tokens
output_tokens
error_code
retry_reason
final_status

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

Почему стоимость API программного агента выше оценки по прайс-листу? Потому что цена в таблице обычно рассчитана на один запрос, а агент оплачивает полный путь до результата: дополнительные сообщения, tool calls, исправление ошибок, продолжение после тайм-аута и иногда повторную передачу почти всего контекста.

У DeepSeek V4 для Flash и Pro заявлены разные лимиты параллельности — 2 500 и 500 соответственно. Превышение лимита может привести к HTTP 429, а затем — к повторным попыткам со стороны вашего оркестратора. Поэтому ограничение пропускной способности является не только операционной характеристикой, но и потенциальной статьёй расходов. (api-docs.deepseek.com)

Вторая проверка: используйте одинаковую приёмку

До запуска теста запишите критерии успешного результата. Пример для кодового агента:

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

Для документов критерии будут другими, но принцип тот же. Если критерии меняются после получения счёта, сравнение теряет смысл.

Таблица 3. Что считать одной задачей

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

Пошаговая нормализация счёта

Шаг 1. Зафиксируйте исходные правила

Сохраните снимок официальной страницы модели и тарифа, дату, валюту, регион и модельный идентификатор. Для Qwen отдельно запишите, является ли строка предварительной, временной или регулярной. Для Kimi разделите API и подписочные продукты. Для DeepSeek сохраните режим Flash или Pro и правило кэширования.

Шаг 2. Подготовьте одинаковый набор задач

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

Шаг 3. Подключите журнал usage

Не ограничивайтесь данными, которые видны в пользовательском интерфейсе. Сохраняйте ответ API, поля Token Usage, состояние кэша, код ошибки, время ожидания и сведения о повторном вызове. Если интерфейс отдаёт только Credits, не создавайте искусственные Token-поля — оставьте их пустыми и считайте Credits отдельно.

Шаг 4. Разделите расходы по типам

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

Шаг 5. Определите статус задачи

Используйте значения success, failed, manual_fix, timeout, rate_limited. В знаменатель включайте только success. Статус manual_fix не должен превращаться в успешный результат, даже если исправление заняло несколько минут.

Шаг 6. Рассчитайте стоимость цепочки

Для Token-биллинга используйте:

расход =
вход без кэша × цена miss
+ вход с кэшем × цена hit
+ вывод × цена output
+ инструменты

Для Credits используйте фактическое списание, не пытаясь подменить его Token-оценкой.

Шаг 7. Сравните сценарии, а не только модели

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

Условия выбора без искусственного общего рейтинга

Используйте следующие ветвления:

• Если у команды много повторяющегося контекста, есть подтверждённые данные о cache hit и одинаковый формат истории — выбирайте модель с минимальной стоимостью кэшированной части после проверки успешности задач. Если состояние кэша не видно, вернитесь к расчёту по холодному старту.
• Если основная нагрузка — одноразовые запросы, сравнивайте вход без кэша и выход. Не включайте потенциальную скидку за повторное использование.
• Если используется Qwen3.8-Max с Credits, выбирайте его только после того, как стоимость Credits на успешную задачу стабильна на нескольких циклах. Если нет официального коэффициента к Token, не переводите Credits в общую таблицу Token.
• Если команда запускает программного агента, выбирайте не самый дешёвый одиночный вызов, а маршрут с меньшим расходом на успешное завершение и меньшей долей повторов.
• Если ответы часто превышают плановый объём, сначала ограничьте вывод и проверьте качество. Если сокращение вывода ухудшает приёмку, сравнивайте модели по полной стоимости ответа, а не по входной цене.
• Если тариф меняется или модель переходит из предварительной версии в регулярную, заморозьте старый период и начните новую серию. Смешивание двух тарифных режимов делает месячный прогноз непроверяемым.
• Если данных пока мало, параллельно прогоните одинаковую выборку через все три API. Не публикуйте общий рейтинг после нескольких удачных запросов.

От пробного счёта к закупке и развёртыванию

Для низкочастотного тестирования важнее утилизация пакета: сколько Credits или оплаченного лимита действительно превращается в успешные задачи. Для стабильного потока важнее эффективная стоимость задачи, ошибки и предсказуемость тарифа. Для длинного контекста главным фактором становится доля повторно используемого ввода. Для AI Agent критичны ретраи, тайм-ауты, лимиты параллельности и внешние инструменты.

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

В этом месте полезно отдельно оценить стоимость лимитов Qwen3.8-Max Preview, но не переносить выводы той статьи в текущую таблицу без повторной проверки действующего модельного идентификатора. Для команд, которые рассматривают локальный запуск, пригодится также материал об инструментах для локального запуска Qwen3.8 27B: это уже другой класс затрат и другой набор ограничений.

Текущий API-подход удобен для быстрого старта, но у него есть реальные недостатки: расходы растут незаметно из-за ретраев, тарифы и модельные идентификаторы могут меняться, а длинные цепочки зависят от лимитов и доступности внешнего сервиса. В отдельных задачах аренда Mac через JexMac даёт более управляемую среду для проверки Agent, локальных инструментов и сценариев самохостинга: не нужно сразу покупать оборудование, а конфигурацию можно оценить до перехода к постоянной эксплуатации. Это не заменяет API для кратких нерегулярных запросов, но становится разумнее, когда стоимость повторных вызовов, требования к непрерывности или контроль данных уже важнее минимальной цены одного Token.

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