Как снизить расходы на LLM: пять множителей в счёте
Вопрос «как снизить расходы на LLM» обычно сводят к выбору модели подешевле. На деле счёт складывается не из одной цифры: кроме модели на него влияют ещё пять настроек, и каждая меняет сумму в разы. Второго августа я разбирался, почему у одной и той же модели в наших расчётах и на её странице стоят разные цены, – и в итоге сел мерить каждую настройку отдельно.
Все цифры – из собственного прогона 4 августа 2026 года: семь замеров, 460 запросов, оплата по фактическому списанию. Тарифы живут неделями, поэтому у каждой суммы стоит дата.
Почему одна и та же модель стоит по-разному
Потому что «модель» и «маршрут до модели» – это разные вещи. Одну и ту же модель раздают несколько компаний, и у каждой свой тариф.
У GPT-5.6 Luna на 4 августа было шесть маршрутов. Самый дешёвый – экономкласс у самого OpenAI, $0,05 за миллион входных токенов. Считают здесь не символы и не слова, а токены – куски текста примерно по три-четыре буквы; миллион токенов это около семисот страниц. Самый дорогой – Azure в европейском регионе, $1,10. Между ними двадцать два раза. Модель одна, но разворачивают её у всех по-своему – вплоть до точности вычислений, к этому вернёмся ниже. Одинаков в запросе только идентификатор модели.
У моделей с открытыми весами маршрутов больше, потому что их разворачивает у себя кто угодно. У DeepSeek V4 Flash на ту же дату – 21 маршрут, у GLM-5.2 – 34. Список живой: между 2 и 4 августа у GLM появился новый дешёвый провайдер, и разброс цен по модели просел с восьмикратного до четырёхкратного.
Цифра стоимости из чужой статьи, из презентации подрядчика или из прошлогоднего расчёта не значит ничего, пока рядом не стоит дата и не назван провайдер.
Пять множителей, из которых складывается счёт
Вот они по порядку, с эффектом, который мы измерили или посчитали по тарифам:
| Множитель | Что это | Во сколько раз меняет счёт |
|---|---|---|
| Провайдер | чей сервер отдаёт ответ | 11 у Luna в одном классе (22, если считать вместе с классом), 4,6 у GLM-5.2 на 4 августа |
| Класс обслуживания | приоритет запроса в очереди | 2 между экономом и стандартом, 4 между экономом и приоритетом |
| Кэш промпта | переиспользование неизменной части запроса | 3,9 в замере, 3,6 в расчёте ниже – разная доля попадания |
| Длина контекста | сколько текста вы возите в каждом запросе | 5,5 при сжатии втрое, из них 2 – переход через тарифный порог |
| Режим рассуждений | «думает» ли модель перед ответом | до 3,9 на моделях, где он управляется |
Множители перемножаются. И ни один не требует менять модель.
Провайдер: совет, который повторяют все, и который ничего не даёт
Самая частая рекомендация из обучающих видео – включить режим «всегда самый дешёвый провайдер». Мы проверили: экономии он не даёт.
DeepSeek V4 Flash, четыре конфигурации по двадцать запросов. Без единой настройки средняя цена вызова составила $0,0000298. С включённым режимом «самый дешёвый» – $0,0000312, то есть на пять процентов дороже. Разница в пределах шума.
Причина в том, что маршрутизация и без настроек склоняется к дешёвому: сначала отсеиваются провайдеры, у которых только что были сбои, а между остальными запросы распределяются с сильным перевесом в пользу низкой цены – так это описано в документации сервиса. Настройка «самый дешёвый» этот механизм выключает: вы получаете самый дешёвый сервер вместе с его сегодняшней доступностью. То есть первый же совет из тех, что обычно дают на вопрос «как снизить расходы на LLM», в нашем замере не сработал.
Где настройки провайдера действительно нужны – там, где важна стабильность, а не цена. У клиентов с большим объёмом мы закрепляем конкретного провайдера и запрещаем автоматическое переключение: пусть лучше запрос упадёт и уйдёт в повтор, чем незаметно уедет на другой сервер, где та же модель развёрнута с меньшей точностью и отвечает иначе.
Это не паранойя. Исследовательская группа, которая прогоняет эксперименты через тот же сервис, опубликовала разбор о том, как незакреплённый провайдер обесценивает результаты: у одной популярной модели самый дорогой маршрут отдавал её в пониженной точности, а более дешёвый – в полной. Цена точность не отслеживает.
Класс обслуживания: вдвое дешевле за фоновые задачи
Класс обслуживания – это приоритет вашего запроса в очереди. Их три: экономный, стандартный и приоритетный. Модель во всех трёх случаях одна и та же, меняется только то, как быстро до неё дойдёт очередь. Экономкласс стоит вдвое дешевле стандарта, приоритетный – вдвое дороже.
Я взял Luna и прогнал сорок раундов по три одновременных запроса, по одному на каждый класс. Результат оказался против ожиданий: на коротких ответах экономкласс не медленнее стандарта. Половина ответов приходила быстрее 3,68 секунды против 3,79 у стандарта, а самые долгие – 6,35 против 6,48. Ни одного отказа из ста двадцати запросов. При этом он ровно вдвое дешевле.
Под нагрузкой разница нашлась, но не в скорости, а в стабильности. Я запустил три залпа по двенадцать длинных генераций. У стандартного класса пачка занимала 18,6, 18,5 и 18,3 секунды – как по часам. У экономкласса 17,4, потом 37,8, потом 15,8: один залп из трёх растянулся вдвое, потому что одна генерация задержалась.
Экономкласс вдвое дешевле и не медленнее в среднем, но менее предсказуем в худшем случае.
Всё, что ждёт живой человек, остаётся в стандартном классе. Всё, что работает фоном – поиск по базе, аудит документов, ночная обработка, генерация контента впрок, – уходит в экономкласс. У нас так работают фоновые проверки: они не критичны по сроку, но критичны по качеству модели, и половина тарифа там достаётся бесплатно.
Страховка на такой схеме – повторные попытки. Схема классическая: нарастающие таймауты, пауза между попытками, повторяем, пока не придёт конкретная ошибка. На наших фоновых задачах полное окно повторов ни разу не превысило двух часов, обычно всё заканчивается сильно раньше. В самом замере оно не понадобилось: ни один запрос в экономклассе не упал. Если у задачи есть жёсткий срок – двадцать минут, тридцать, – окно ужимается, а последняя попытка уходит в стандартный класс по полной цене.
Неудачная попытка в экономклассе не тарифицируется – об этом прямо сказано в документации OpenAI, там же рекомендованы увеличенные таймауты и повтор с эскалацией. Вы платите только за успешный ответ, поэтому повторы не съедают экономию.
Ретраи здесь не перестраховка, а обязательная часть схемы. За весь наш прогон экономкласс не отказал ни разу, но это один день и один аккаунт. На форуме разработчиков OpenAI лежат два разбора, где всё было иначе: у одной команды экономкласс изо дня в день возвращал ошибку сервера – проблема ушла, только когда параметр убрали совсем; у другого разработчика параметр молча игнорировался из-за настройки уровня проекта, которая перебивает то, что отправлено в запросе. На части моделей экономкласса просто нет, и запрос честно падает с ошибкой.
Вывод для проекта простой: экономию считать по факту и держать в коде путь отхода в стандартный класс.
Кэш промпта: самый недооценённый рычаг
Кэш снижает цену, не трогая ни модель, ни провайдера, ни качество ответа. Провайдер запоминает обсчитанное начало запроса и в следующий раз не считает его заново.
В нашем замере системный промпт на 3355 токенов и восемь одинаковых запросов подряд дали такую картину: первые два вызова стоили полную цену, а с третьего в кэш попали 3200 токенов из 3355, и вызов подешевел в 3,9 раза.
Про кэш важно понимать вот что.
Устроен он по-разному у разных провайдеров. У OpenAI, DeepSeek и ещё нескольких он включается автоматически. У Anthropic, Google и Qwen нужную часть промпта нужно размечать вручную, без разметки кэша не будет вовсе. Скидка на чтение тоже разная: от девяноста процентов до пятидесяти. Сводная таблица по провайдерам обновляется вместе с тарифами, свой вариант лучше сверять по ней.
Срок жизни у кэша ограничен. У свежих моделей OpenAI – от получаса, у Anthropic по умолчанию пять минут с возможностью продлить до часа за более дорогую запись. Каждое обращение к кэшу бесплатно продлевает срок, поэтому при живом потоке запросов он держится сам.
Ломает кэш не рост диалога, а изменение его начала. Новое сообщение дописывается в хвост и ничего не портит. А вот текущая дата или идентификатор запроса, вставленные в системную инструкцию, меняют начало каждую минуту – и кэш не срабатывает никогда. Это самая частая причина, по которой кэш «не работает»: постоянная часть промпта должна быть в начале и не меняться, переменная – в конце.
Порог, о котором не написано в прайс-листе
У многих моделей тариф меняется, когда запрос становится длинным. В прайс-листе указана цена до порога.
У GPT-5.6 Luna порог наступает на 272 тысячах входных токенов: дальше входные токены дорожают вдвое, выходные в полтора раза. Это много, и на обычных задачах такое не встречается.
А вот у Qwen3.7 Flash порогов два, и первый срабатывает на 32 тысячах токенов. Базовая цена $0,03 за миллион превращается в $0,10, то есть модель дорожает втрое. Тридцать две тысячи токенов – это не экзотика, это обычный рабочий промпт агента с историей диалога и парой документов.
Длину контекста надо резать намеренно. Сжимать историю переписки, вытаскивать из документов нужные факты вместо того, чтобы возить их целиком, обрезать хвосты диалога. Экономия здесь двойная – и на объёме, и на том, что запрос не переходит в дорогой тариф. В нашем расчёте сжатие контекста втрое дало снижение счёта в пять с половиной раз.
Режим рассуждений: множитель, которым не все умеют управлять
Пятый множитель – рассуждения. Модель «думает» перед ответом, эти размышления пользователь не видит, но оплачивает: они тарифицируются как обычный вывод.
Управляется это параметром effort с тремя уровнями. Мы прогнали через них три недорогие модели с одинаковыми задачами, и разброс получился разный.
У gpt-oss-120b доля рассуждений в оплаченном выводе выросла с 8 процентов на низком уровне до 74 на высоком. Счёт за один и тот же набор задач – с $0,000266 до $0,001036, то есть в 3,9 раза. Время ответа – с 17,6 до 58,8 секунды. Одна строчка в запросе.
А две другие модели команду фактически проигнорировали. У Nemotron-3-Nano доля рассуждений на трёх уровнях – 33, 32 и 37 процентов. У Nex-N2-Mini – 69, 69 и 73: эта тратит на размышления две трети вывода даже там, где её просят думать поменьше.
Отсюда два практических следствия. Первое: effort – это просьба, и выполнят её не все, так что долю рассуждений надо мерить на своей модели, а не предполагать. Второе: выключить рассуждения можно не везде. У части эндпоинтов это запрещено на уровне тарифа, и попытка отключить возвращает ошибку – мы такое видели у Gemini.
В расчёт ниже этот множитель не входит: он измерен на другой модели и на других задачах, и перемножать его с тарифами Luna было бы подтасовкой. Считайте его отдельно и на своей модели.
Сколько это в деньгах
Возьмём бота на двести обращений в день – шесть тысяч вызовов в месяц. Модель одна и та же, ответы те же самые, меняются только настройки. Ставки взяты из тарифов на 4 августа 2026 года.
| Как настроено | За вызов | В месяц |
|---|---|---|
| Перепродавец, длинный контекст, без кэша | $0,6798 | $4 078,80 |
| Тот же перепродавец, контекст сжат | $0,1232 | $739,20 |
| Свой вендор, стандартный класс, длинный контекст | $0,0618 | $370,80 |
| Свой вендор, стандартный класс, контекст сжат | $0,0112 | $67,20 |
| Экономкласс, контекст сжат | $0,0056 | $33,60 |
| Экономкласс, сжатый контекст, кэш | $0,00155 | $9,30 |
Четыре тысячи долларов в месяц против девяти. 439 – это отношение крайних строк таблицы; складывается оно из четырёх шагов: уход с перепродавца к вендору даёт 11, сжатие контекста 5,5, экономкласс 2, кэш 3,6. Округлённые множители в точности 439 не дают, но порядок именно такой. Ни один из четырёх не про то, чтобы взять модель попроще.
Это расчёт по тарифам, а не прогон обеих конфигураций живьём. Ставки настоящие, из открытого справочника цен на конкретную дату, но один запрос в самой дорогой конфигурации стоил бы 68 центов, и такой прогон мы не делали.
Где экономить не нужно
Есть границы, за которыми экономия оборачивается убытком.
Первая – пользовательские сценарии. Тридцать семь секунд ожидания из нашего замера обычный клиентский диалог не переживёт, а редкий медленный ответ заранее не предскажешь. Всё, что видит клиент, живёт в стандартном классе.
Вторая – качество там, где оно стоит денег. Мы регулярно прогоняем модели через свои задачи на русском языке, и разрыв в качестве между дешёвой и дорогой моделью бывает как ничтожным, так и решающим – зависит от задачи. В прогоне 2 августа дорогая модель уступила дешёвой и в цене диалога в сорок шесть раз, и в баллах. Как выбирать модель под конкретную задачу, я подробно разбирал в отдельной статье про выбор LLM для проекта: там данные по восьми моделям на двух реальных сценариях.
Третья – экономия вслепую. Мы попробовали потребовать от провайдеров повышенную точность вычислений «на всякий случай»: цена вызова выросла на 60%, а задержка втрое. При этом на нашем наборе проверок более дешёвая конфигурация не показала себя хуже. Настройка, поставленная из общих соображений, может как сэкономить, так и добавить к счёту – заранее не скажешь.
Как снизить расходы на LLM: что проверить в своём проекте
Короткий чек-лист для разового аудита. Пункты идут в том порядке, в котором их разумно проходить: сначала измерения, потом настройки, потом проверка результата.
- Включите учёт по факту. Считайте по реально списанным деньгам. На нашем прогоне 2 августа у GLM-5.2 фактическое списание вышло на 108% выше расчёта по прайсу: маршрутизатор увёл запрос к другому провайдеру.
- Записывайте, кто обработал каждый запрос. Провайдер и класс обслуживания приходят в ответе API. Без этого журнала невозможно объяснить, почему на прошлой неделе всё работало иначе.
- Откройте полный список провайдеров своей модели. Не одну цену из общего справочника, а все маршруты: разница между первым и последним доходит до двадцати двух раз. Заодно узнаете, есть ли у вашей модели выбор вообще — у части моделей маршрут ровно один.
- Найдите тарифный порог по длине контекста. Проверьте, не ходят ли ваши запросы за него. У кого-то порог на 272 тысячах токенов, у кого-то на 32 тысячах — то есть на обычном рабочем промпте.
- Сожмите контекст осознанно. Историю переписки резать, из документов вытаскивать нужные факты вместо того, чтобы возить их целиком. Экономия двойная: и на объёме, и на том, что запрос не переходит в дорогой тариф.
- Разделите промпт на постоянную и переменную части. Постоянную — в начало, переменную — в конец. Это включает кэш. Проверьте, что в начале нет текущей даты и идентификатора запроса: они убивают кэш каждым вызовом.
- Вынесите фоновые задачи в экономкласс. С нарастающими паузами между повторами и переходом в стандартный класс по сроку. Всё, чего ждёт живой человек, остаётся в стандартном классе.
- Поставьте потолок цены и предел на длину ответа. Первый не даст запросу уехать к дорогому провайдеру, второй — модели уйти в рассуждения на тридцать тысяч токенов и вернуть пустоту.
- Замерьте долю рассуждений на своей модели. Она приходит в ответе отдельным полем. Если модель тратит на размышления больше половины оплаченного вывода, это ваш главный расход, а не провайдер.
- Проверьте качество на своей задаче. Точность, с которой развёрнута модель, ценой не определяется: у одной популярной модели самый дорогой маршрут отдавал её в урезанном виде, а маршрут подешевле — в полном.
Первые два пункта не требуют инженера вообще, и начинать стоит с них: пока расходы не измеряются, оптимизировать нечего.
Результаты наших прогонов мы публикуем открыто: живой лидерборд моделей обновляется из базы по мере новых замеров – там видно и балл, и фактическую цену вызова на наших задачах. Разборы по горячим следам, с цифрами и до того, как они превратятся в статью, я выкладываю в Telegram-канале «ИИ для бизнеса».