Цена по часам суток: третий вендор за месяц

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

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

Одинаково у всех, кто её вводит.

Окна задаются по часам. Обычно два-три интервала в будни, выходные целиком по низкой ставке.

Часовой пояс вендорский. Это ключевая деталь: окно, объявленное как «с 9 до 12», означает 9–12 там, а не у вас.

Разница кратная. Обычно вдвое между пиком и непиком.

Скидка отсчитывается от поднятой базы. В первом случае, который мы разбирали, «ночная скидка вдвое» сопровождалась ростом базовой ставки — и половина новой цены оказалась выше прежней полной. Это стоит проверять отдельно от радости по поводу скидки — подробный разбор первого случая.

Почему это распространяется

Причина инфраструктурная, и она объясняет, почему схема будет появляться и дальше.

Мощности под инференс покупаются под пик. Ночью они простаивают, днём их не хватает. Разница между пиком и спадом у глобального сервиса кратная, и всё это время самая дорогая часть капитала либо перегружена, либо стоит без дела.

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

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

Что ломается в учёте

Три вещи, которые перестают работать.

Константа ставки в коде. Самое очевидное. Ставку приходится превращать в функцию от времени.

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

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

Практический минимум для тех, кто пишет учёт расходов:

1. Храните время запроса, а не только стоимость. Иначе разобраться в счёте потом будет нечем.
2. Держите таблицу окон в конфигурации. Вендор их поменяет, и это должна быть правка конфига, а не релиз — что ещё стоит вынести из кода.
3. Логируйте, в какое окно попал запрос. Без этого не видно, какая доля расхода приходится на дорогое время.
4. Считайте по пиковой ставке в прогнозах. Тогда экономия будет запасом, а не условием выживания.

Кому это выгодно

Разделение резкое.

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

Проигрывает всё интерактивное. Чат, помощник в интерфейсе, агент, отвечающий на действие человека. Такие сценарии работают тогда, когда работают люди, — то есть ровно в часы пик.

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

Что делать с длинными запросами

Деталь, которую вендоры обычно не документируют.

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

Это первое, что стоит уточнить в поддержке, прежде чем строить на почасовой схеме экономику. И второе — не запускать длинные пакеты впритык к границе окна.

Как это связано с другими схемами

Почасовой тариф редко приходит один. Рядом обычно живут ещё три множителя, которые перемножаются:

Порог по длине контекста — за ним дорожает весь запрос целиком, а не превышение.

Режим обработки — отложенный дешевле, ускоренный дороже, разброс до четырёх раз.

Кэш — вход из кэша бывает вдесятеро дешевле обычного.

Почасовой тариф и три соседних множителя в одной таблице:

Вместе это означает, что «цена за миллион токенов» в прайсе — середина широкого диапазона, а не цена вашего запроса. Подробный разбор множителей — Batch, Flex и Fast и пороги по контексту.

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

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

Почасового тарифа у нас нет. Ставка одна и не зависит ни от времени суток, ни от дня недели. Расход считается умножением объёма на ставку, и посчитать его можно заранее.

Порогов по длине контекста тоже нет. Запрос на 300 тысяч токенов идёт по той же ставке, что и короткий.

Кэша нет. У каждой текстовой позиции в выдаче поле prompt_cache со статусом unsupported.

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

Что делать, если вы на таком тарифе

Пять действий, по убыванию отдачи.

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

Перенесите терпящее в дешёвое окно. Очередь с отложенным запуском — несколько десятков строк кода, а экономия кратная.

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

Заведите отдельный ключ под пакетную нагрузку. Тогда видно, какая доля расхода приходится на дешёвое время, и понятно, окупается ли перенос — как разводить ключи.

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

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

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

Не называем вендоров и конкретные окна. Схемы и часы меняются; смотрите документацию того, с кем работаете.

Не проверяли тарификацию запросов, пересекающих границу окна. В доступных публикациях этого нет.

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

Цифры каталога — на дату. Состояние на 7 сентября 2026 года.

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

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

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

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

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

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

И главное техническое следствие: стоимость запроса перестала быть его свойством. Храните время запроса вместе со стоимостью — без этого разобраться в счёте задним числом будет нечем.

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