Batch, Flex и Fast: цена запроса гуляет вчетверо

Одна и та же работа у одного и того же вендора может стоить в четыре раза по-разному — и решает это не модель, а режим обработки. По документации GPT-6 Astra режимы Batch и Flex тарифицируются в половину стандартной ставки, а Fast mode — вдвое дороже. Между нижней и верхней точкой ровно четыре раза за идентичный запрос. Сверху накладывается порог в 272 тысячи входных токенов, за которым вход дорожает вдвое для всего запроса целиком, — и тогда разрыв по входной части доходит до восьмикратного. Разбираем все три множителя, считаем в рублях и говорим честно, чего из этого нет у нас.

Три множителя, которые перемножаются

Все три опубликованы вендором, все три применяются к одному и тому же запросу.

Режим обработки. Batch и Flex — половина стандартной ставки. Standard — единица. Fast — двойная. Разброс четырёхкратный.

Порог длины. Запрос с входом свыше 272 000 токенов считается по удвоенным ставкам входа (и кэша), а выход — по полуторной. Причём для всего запроса целиком, а не для превышения.

Кэш. Вход из кэша у Astra стоит $1 против $10 обычного — вдесятеро дешевле. Запись в кэш, наоборот, дороже обычного входа в 1,25 раза.

Перемножаются они честно: медленный пакетный запрос на коротком контексте и срочный запрос на длинном — это разные ценовые вселенные при одинаковом тексте.

Сколько это в деньгах

Считаем на Astra по курсу ЦБ 86,5857 ₽ за доллар на 5 сентября 2026 года. Стандартная ставка входа $10, выхода $50.

Теперь добавим порог. Запрос с входом больше 272 000 токенов в режиме Fast считается по удвоенной ставке от Fast: $40 за миллион входа, то есть 3 463 ₽. Против $5 у Flex под порогом — разрыв восьмикратный за одну и ту же работу.

И третий рычаг: если тот же вход попадает в кэш, стандартная ставка падает до $1 — 86,59 ₽ за миллион. Между кэшированным Flex и некэшированным Fast за порогом разница уже двузначная.

Кому подходит Batch

Признаки задачи, которая реально выигрывает.

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

Результат не нужен пользователю сейчас. Никто не сидит и не ждёт ответа.

Задачи однотипные. Тогда их удобно собрать в пакет и разобрать результат разом.

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

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

Чем Fast оправдан

Логика обратная и она реже осознаётся.

Двойная цена за скорость окупается там, где ожидание стоит дороже токенов. Живой оператор, ждущий подсказку. Пользователь в форме, который уйдёт, не дождавшись. Конвейер, где задержка одного шага останавливает остальные.

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

Важно, что Fast не ускоряет генерацию как таковую: он про приоритет обработки. Из чего вообще складывается задержка и что чинится бесплатно — разбирали отдельно.

Порог 272 000: главная ловушка

Механизм, на котором переплачивают чаще всего.

Дорожает весь запрос, а не превышение. Запрос на 272 001 токен стоит вдвое дороже запроса на 271 999 — не на доли процента, соответствующие приросту объёма, а ровно вдвое.

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

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

Кэш: самый недооценённый множитель

Отдельно, потому что он работает в другую сторону.

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

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

Подробно про механику и про то, как собирать промпт под кэш, — кэш промптов: как экономит и почему есть не везде.

Как посчитать свой случай

Порядок на полчаса, который даёт ответ вместо ощущений.

1. Разделите нагрузку на срочную и терпящую. Обычно вторая часть больше, чем кажется.
2. Посчитайте объём каждой в токенах — как считать.
3. Прикиньте, где вы относительно порога 272 000. Если рядом — это первое, что надо чинить, до всякого выбора режима.
4. Оцените долю неизменного начала запроса. Она определяет, есть ли смысл в кэше.
5. Умножьте на множители режимов и сравните варианты.
6. Добавьте стоимость сложности. Пакетная обработка — это отдельный код, очередь и разбор результатов. Если экономия меньше недели работы разработчика в год, она не окупится.

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

Как устроено у нас

Скажем прямо, включая невыгодное.

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

Fast-режима тоже нет — и переплаты за него, соответственно, тоже.

Порогов по длине контекста нет. Запрос на 300 тысяч токенов считается по той же ставке, что и на 3 тысячи. Это упрощает расчёт и снимает целый класс ошибок в бюджете.

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

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

Чего мы не утверждаем

Не описываем, как включаются режимы. Форма запроса у вендора своя и меняется; смотрите документацию.

Не обещаем сроков обработки в Batch. Вендор их гарантирует по-своему, и это отдельный параметр планирования.

Не переносим множители на другие модели и вендоров. Цифры взяты со страницы GPT-6 Astra в документации разработчика на 5 сентября 2026 года.

Не сравниваем качество моделей. Своих замеров мы не делали.

Что нужно, чтобы посчитать свой профиль

Посмотреть наши ставки можно без регистрации: GET /v1/models открыт без ключа, там же видно, что порогов по длине контекста нет, а prompt_cache помечен как неподдерживаемый. Это ровно те три поля, которые нужны, чтобы сравнить нашу схему с вендорской на ваших числах.

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, платные текстовые модели доступны сразу на приветственном бонусе.

Что держать в голове

Цена одного и того же запроса у вендора гуляет вчетверо только из-за режима обработки, а вместе с порогом 272 000 — восьмикратно по входу. Ставка за миллион в прайсе — это середина диапазона, а не цена вашего запроса.

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

Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте и в llms.txt. Сравнить со своей нагрузкой: keydealer.ru/login.