Простые прайсы провайдеров ИИ — реальные счета за инференс выше в разы из-за
Обычно стоимость запроса к языковой модели прикидывают очень просто: открывают прайс, смотрят на стоимость входа и выхода за миллион токенов, умножают на ожидаемые объёмы и закрывают таблицу. Потом приходит реальный счёт, и он отличается от первоначальной прикидки в разы. Иногда сумма оказывается меньше, если кто-то незаметно для себя попадал в кэш, но чаще бюджеты трещат по швам от скрытых факторов ценообразования. Разработчики и владельцы продуктов обнаруживают, что юнит-экономика запросов кардинально расходится с базовыми прайсами провайдеров.
Как отмечает автор разбора, все базовые тарифы и условия опираются на официальную документацию OpenAI, Anthropic и Google. Провайдеры берут деньги за токены, а не за запросы или символы, поэтому стоимость вызова складывается из нескольких слагаемых с собственными ценниками. В эту структуру входят некэшированный вход, прочитанный из кэша вход, записанный в кэш вход, видимый ответ модели, а также скрытые от глаз пользователя рассуждения.
Выход почти всегда обходится дороже входа. В текущих прайсах трёх крупных провайдеров разница у большинства моделей составляет от четырех до восьми раз, поэтому длинный ответ гарантированно стоит дороже длинного вопроса. Рассуждения сидят в выходных токенах, то есть в самом дорогом слагаемом, а кэш умножает на маленький коэффициент самое большое слагаемое входа лишь при условии точного совпадения префикса до последнего токена. При этом множитель r обычно составляет 0,1 или меньше у части новых моделей, показывая, во сколько раз дешевле обходится чтение из кэша. В то же время множитель w равен 1,25 у пятиминутного кэша Anthropic и у моделей OpenAI с платной записью. У часового кэша Anthropic этот коэффициент равен 2.
Давайте разберем реальную механику на производственном примере. Представьте типичный корпоративный пайплайн для анализа длинных документов: система отправляет контекст объемом 100 000 токенов (из которых 80 000 успешно подхватываются из кэша) и запрашивает у модели развернутый отчет с рассуждениями на 2 000 токенов на выходе. Если провайдер использует базовый множитель записи $w = 1.25$ для новых кэшируемых блоков и коэффициент чтения $r = 0.1$, то затраты на запись недостающих 20 000 токенов и чтение 80 000 токенов из кэша начинают доминировать над простым линейным умножением. Более того, при масштабировании такого запроса до 10 000 вызовов в сутки любая микроошибка в учете префикса приводит к тому, что кэш сбрасывается, и система вместо дешевого чтения начинает оплачивать полную стоимость каждого токена по максимальному тарифу входа. На практике это превращает прогнозируемые ежемесячные затраты на инференс в нестабильную статью расходов, где одна неудачная сессия с частым обновлением контекста способна полностью сжечь дневной бюджет.
Подводные камни API и правила чтения кэша
Все объемы токенов фиксируются в ответе API в объекте usage, но провайдеры называют поля по-своему и считают их по разным правилам. Самая коварная разница обнаруживается именно во входе. У OpenAI и Gemini общий вход уже содержит кэшированные токены, и чтобы получить ту часть, за которую вы платите полную цену, кэш надо вычесть. У Anthropic всё наоборот: input_tokens представляет собой только хвост после последней точки кэширования. Если написать универсальный обработчик и попытаться вычесть кэш из входа Anthropic при наличии долгого контекста, в ответе получится отрицательное число.
У OpenAI и Anthropic рассуждения уже включены в выходные токены, а у Gemini их надо прибавлять отдельно.
С выходом модели ведут себя похожим образом, но в зеркальном отражении. У OpenAI и Anthropic рассуждения уже включены в выходные токены, а у Gemini токен рассуждений нужно прибавлять к выходным токенам отдельно. Если забыть про эту архитектурную особенность, модель от Google в отчетах будет выглядеть заметно дешевле, чем на чем есть на самом деле.
Рост токенизации и ступенчатые тарифы
Дополнительным сюрпризом для разработчиков становится изменение внутренних алгоритмов самих провайдеров. Вдобавок у некоторых провайдеров тариф устроен ступенчато: если общий объём входа вместе с кэшированной частью превышает установленный порог, все цены в формуле автоматически меняются на повышенные. Это создает дополнительные риски для разработчиков, которые пытаются оптимизировать расходы за счет укрупнения контекста, но в итоге попадают в более дорогой ценовой сегмент.
На наш взгляд, подобная непрозрачность в расчетах — это не случайный баг документации, а осознанная архитектурная ловушка для бизнеса. Пока компании выстраивают долгосрочные продуктовые стратегии вокруг LLM, провайдеры перекладывают на их плечи всю волатильность инференса, превращая масштабирование в русскую рулетку с бюджетом.
Источник: Хабр ML