Сравнение тарифов LLM: как честно посчитать итоговую цену

Почему цены трудно сравнить

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

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

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

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

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

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

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

Какие единицы встречаются в прайсах

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

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

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

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

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

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

Как собрать таблицу пересчёта

Таблица работает только тогда, когда у всех строк одна и та же база. Для текстовых моделей удобнее всего сводить всё к цене за 1 млн токенов. Если провайдер продаёт не токены, а вызовы, держите рядом вторую базу - цену за 1000 запросов. Потом переведите вызовы в токены по своим средним объёмам и сравните строки без путаницы.

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

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

Дальше подставьте свои числа. Не берите рекламный пример вроде "200 входных и 50 выходных токенов", если у вас в поддержке средний ответ в три раза длиннее. Лучше выгрузить 3-7 дней логов и посчитать среднее, медиану и 90-й перцентиль по входу и выходу. Тогда сразу видно, где дешёвый вход потом добирает цену на длинном ответе.

Полезно держать два режима расчёта:

• обычный день - средняя длина запроса, нормальная доля кэша, мало повторов;
• пик - длиннее диалоги, больше параллельных вызовов, выше доля ретраев.

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

Строки с округлением помечайте сразу. Один провайдер считает фактические токены, другой округляет до 1000 токенов, третий берёт минимум за запрос. На коротких сообщениях разница заметна. Если пользователь прислал 120 токенов, а биллинг считает как 1000, цена на бумаге и цена в конце месяца будут совсем разными.

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

Как посчитать итоговую цену шаг за шагом

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

1. Соберите выборку из запросов одного типа. Не смешивайте чат поддержки, поиск по базе знаний и длинную генерацию документов. У каждого сценария свой объём входа, свой объём выхода и свой расход.
2. Для этой выборки замерьте среднее число входных токенов, среднее число выходных токенов и долю ответов, которые пришли из кэша. Если провайдер считает cached input отдельно, это сразу меняет итог.
3. Возьмите ставки каждого провайдера и умножьте их на ваши объёмы. Считайте отдельно вход, выход и кэш, а не одной строкой. Именно цена выходных токенов часто превращает дешёвый тариф в дорогой.
4. Добавьте потери, которые обычно забывают: повторные запросы после ошибок, тайм-ауты с перезапуском, ответы длиннее нормы и служебные вызовы для классификации или модерации. В продакшене это часть счёта, а не шум.
5. Переведите результат в понятный масштаб: цену 100 запросов, цену дня и цену месяца. Так проще увидеть, где разница в несколько десятых цента на одном вызове превращается в заметную строку расходов.

Если хотите совсем простую формулу, она выглядит так: итог = вход * ставка входа + выход * ставка выхода + кэш * ставка кэша + медиа + стоимость повторов.

Пример: чат поддержки банка

В чате поддержки банка пользователь часто пишет очень коротко: "Почему карта не проходит?" или "Как поднять лимит?". Но бот редко отвечает так же коротко. Он должен учесть правила безопасности, добавить шаги для клиента и дать аккуратную формулировку без лишних обещаний.

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

Допустим, один диалог выглядит так:

Для честного сравнения сначала приводим единицы к одной базе, например к цене за 1 млн токенов. Тогда видно не рекламную цифру, а реальную стоимость в рабочем сценарии.

Расчёт здесь простой. У провайдера A вход стоит дёшево: 450 входных токенов обходятся всего в $0.00009. Но 900 выходных токенов стоят уже $0.0027, и именно они съедают бюджет.

У провайдера B ситуация обратная. Вход дороже - $0.00027 на диалог, зато длинный ответ стоит всего $0.00108. На одном разговоре разница кажется маленькой, но на потоке она быстро растёт.

Для банка это обычная история. Поддержка не живёт одним диалогом. Если бот обрабатывает 10 000 обращений в месяц, вариант B даёт экономию $14.40 только на этом одном сценарии. Если добавить ещё споры по платежам, перевыпуск карт и вопросы по лимитам, разрыв станет заметнее.

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

Где дешёвая цена на вход скрывает дорогой итог

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

Хороший пример - сводки, отчёты и длинные ответы для поддержки. Если модель получает 3000 входных токенов, а возвращает 6000, дешёвый вход уже мало что решает. Провайдер с ценой 0,1 за вход и 1,2 за выход легко окажется дороже, чем тот, у кого вход стоит 0,3, а выход - 0,5.

То же происходит с RAG-агентами. На бумаге запрос кажется коротким, но в каждый вызов система добавляет большой контекст: выдержки из базы знаний, историю диалога и служебные инструкции. Пользователь пишет 30 слов, а биллинг считает 12 000 или 20 000 входных токенов. Если таких запросов тысячи в день, разница в ставке на вход уже не кажется мелочью.

Где расход растёт незаметно

Чаще всего бюджет раздувают не сами цены, а форма тарификации.

• Повторный вызов после тайм-аута или ошибки почти удваивает расход, если система снова отправляет тот же контекст.
• Округление до крупных блоков съедает выгоду от низкой ставки. Запрос на 1100 токенов могут посчитать как 2000 или как минимальный пакет.
• Мультимодальные запросы ломают расчёт, если смотреть только на текст. Картинки, аудио и видео часто тарифицируются отдельно.
• Длинная история чата медленно накапливает вход, даже когда ответы остаются короткими.

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

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

Поэтому полезнее смотреть не на цену одной единицы, а на стоимость готового действия: ответа в чате, сводки разговора или проверки документа. Тогда сравнение получается честным.

Ошибки в сравнении тарифов

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

Представьте два варианта. У первого вход стоит 0,05 за 1 тыс. токенов, выход - 0,40. У второго вход стоит 0,12, выход - 0,18. На запросе с 300 входными и 900 выходными токенами первый вариант даст 0,375, а второй - 0,198. На витрине дешевле выглядел первый, а в счёте он почти вдвое дороже.

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

Ещё часто забывают про служебные токены. В расчёт должны входить системный промпт, история диалога, JSON-схемы, tool calls, разметка и токены, которые попали или не попали в кэш. На длинных сессиях это уже заметная сумма. Системный промпт на 700 токенов при 15-20 сообщениях легко съедает бюджет, если у провайдера слабый caching или он работает только для части запроса.

Ещё одна ошибка - не считать цену отказов и повторов. Модель может вернуть пустой ответ, сломать JSON, уйти в refusal или ответить так, что приложение отправит повторный вызов. Даже 5-10% повторов меняют итог сильнее, чем разница в прайсе на пару центов.

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

Быстрая проверка перед выбором

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

Нормальная таблица сводит всех провайдеров к одной единице. В ней есть цена за 1 млн входных токенов, цена за 1 млн выходных токенов, условия по кэшу, лимиты и расходы на повторы. Иначе один поставщик кажется дешёвым только потому, что пишет цену за 1K, другой - за 1M, а третий прячет дорогой вывод внизу прайса.

Проверьте пять вещей:

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

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

Цифры для 100, 1000 и 10 000 вызовов быстро показывают, где разница перестаёт быть мелочью. На сотне запросов два провайдера могут отличаться совсем немного. На десяти тысячах тот же разрыв уже превращается в заметную строку расходов.

Лимиты и повторы тоже меняют итог. Если провайдер часто упирается в rate limit, приложение отправляет запрос ещё раз, а стоимость токенов растёт без пользы. То же и с кэшем: тариф с хорошей долей повторного использования промпта иногда выходит дешевле, даже если базовая ставка у него чуть выше.

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

Что сделать дальше

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

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

Зафиксируйте порог замены модели

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

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

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

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

Если вы сравниваете модели через AI Router, такой тест удобнее прогонять на одинаковых SDK и промптах: достаточно сменить base_url на api.airouter.kz и считать один и тот же сценарий у разных провайдеров. Для казахстанских B2B-команд там ещё можно учесть ежемесячный инвойсинг в тенге и требования к хранению данных внутри страны без отдельной обвязки вокруг каждого провайдера.