Оптимизация стоимости LLM: как снизить расходы на ИИ без потери качества

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

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

Из чего на самом деле складывается стоимость LLM?

В счёте может быть одна строка «токены», но стоимость ИИ состоит из нескольких разных статей. Оптимизация без понимания того, какая из них самая крупная, обычно оказывается вложением не туда.

Входные токены: системная инструкция, описания инструментов, фрагменты документов, найденные через RAG, история диалога и вопрос пользователя. В большинстве продакшен-систем это самая большая статья, потому что один и тот же длинный контекст отправляется заново с каждым запросом.
Выходные токены: текст, который генерирует модель. Их цена за единицу обычно выше, чем у входных. Эту статью раздувают излишне длинные ответы, форматы с требованием пояснений и токены рассуждений.
Повторы и ошибки: второй и третий вызовы из-за невалидного JSON, тайм-аутов или ответов, не прошедших проверку. Они незаметны, но накапливаются.
Циклы агентов: агент, вызывающий инструменты, может сделать десять и более обращений к модели ради одного запроса пользователя. Контекст растёт на каждом шаге, поэтому стоимость растёт быстрее, чем число шагов.
Эмбеддинги и поиск: преобразование документов в векторы, векторная база данных и модели переранжирования (reranking).
Хостинг и эксплуатация: если вы запускаете модели сами, это GPU, масштабирование, мониторинг и дежурства.
Ручная проверка: время команды на исправление ответов с низкой уверенностью. Реальная стоимость модели, которая выглядит дешёвой на бумаге, часто скрывается именно здесь.

Почему стоимость нужно считать за успешную задачу, а не за вызов?

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

Пример расчёта (условные цифры): в задаче классификации документов модель A стоит 1 единицу за вызов, модель B стоит 4 единицы. Модель A правильно решает 70 процентов задач, оставшиеся 30 процентов исправляет эксперт, чьё время стоит 10 единиц. Модель B правильно решает 97 процентов задач. Средняя стоимость одной задачи для A составляет 1 + 0,30 × 10 = 4 единицы, для B получается 4 + 0,03 × 10 = 4,3 единицы. Модель, которая на бумаге дешевле в четыре раза, обходится почти так же за задачу и оставляет команде гораздо больше исправлений. Чем дороже ошибка, тем сильнее баланс смещается в пользу более дорогой модели.

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

Как кэширование снижает стоимость LLM?

Кэширование означает просто не платить дважды за одну и ту же работу. Существует три его вида, и у каждого свой риск.

Кэширование промпта (prefix caching)

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

Кэш точных ответов

В задачах, где один и тот же вход должен давать один и тот же ответ (генерация описания товара, перевод неизменного текста, однократное резюме документа), хранение самого ответа означает, что модель вообще не вызывается. Ключ должен объединять хэш входных данных, название модели, версию промпта и параметры, чтобы при изменении промпта старые ответы автоматически становились недействительными.

Семантический кэш

Семантический кэш сопоставляет вопросы, которые не совпадают дословно, но близки по смыслу, с помощью сходства эмбеддингов и возвращает прежний ответ. Он может дать большую экономию там, где одни и те же вопросы задают разными словами, например в боте поддержки, но это самый рискованный вид кэша. «Могу ли я отменить заказ?» и «Я не могу отменить заказ» выглядят похоже, но требуют разных ответов. Ответы с персональными данными могут попасть к другому пользователю, а это серьёзная проблема с точки зрения законодательства о персональных данных. Используйте семантический кэш только для ответов с общей информацией, со строгим порогом сходства, для записей без пользовательских данных и с ограниченным сроком жизни. Порог подбирайте по тестовому набору реальных пар вопросов, а не наугад.

Как работают маршрутизация моделей и каскадные вызовы?

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

Маршрутизация (routing): запрос сразу отправляется нужной модели в зависимости от его типа. Это можно сделать простым набором правил (тип задачи, длина входа, уровень клиента) или небольшой моделью-классификатором. Начинать с правил дёшево, и ошибки в них легко найти.
Каскад (cascade): запрос сначала идёт к небольшой модели. Если ответ проходит проверку (валидация схемы, бизнес-правило, оценка уверенности, вторая быстрая проверка), он используется; если нет, запрос передаётся большой модели. Большинство простых задач завершается на дешёвом уровне, а сложные всё равно получают правильный ответ.

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

Что дают бюджет токенов и сокращение контекста?

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

Слишком много фрагментов в RAG: отправка 20 фрагментов документов «на всякий случай» увеличивает и стоимость, и риск опереться на неверный фрагмент. Отбор нескольких самых релевантных фрагментов с помощью переранжирования обычно и дешевле, и точнее.
Неограниченная история диалога: в длинных диалогах стоит резюмировать старые сообщения или хранить только последние несколько реплик и важные постоянные факты.
Неиспользуемые описания инструментов: вместо описаний 40 инструментов в каждом запросе агенту стоит передавать только подмножество, относящееся к типу задачи.
Неконтролируемый вывод: задайте максимальную длину ответа, запрашивайте структурированный вывод (JSON-схему) и используйте удлиняющие ответ инструкции вроде «объясни по шагам» только там, где они действительно нужны.
Лимит шагов агента: у каждой задачи агента должен быть бюджет шагов и токенов. При его превышении агент останавливается и передаёт задачу человеку; агент, застрявший в цикле, может за ночь израсходовать месячный бюджет.

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

Когда имеет смысл пакетная обработка?

Кандидатом на пакетную (batch) обработку подходит любая задача, ответа на которую пользователь не ждёт: ночная классификация документов, обогащение каталога товаров, разметка исторических записей, повторное построение эмбеддингов, прогоны оценки качества. Большинство крупных провайдеров предлагают интерфейс со скидкой для пакетных запросов, если вы готовы получить результат в течение нескольких часов. Важно, чтобы процесс действительно мог ждать: если пользователь ждёт на экране, пакетная обработка не подходит. В пакетных задачах также нужно повторно ставить в очередь неудачные записи и проверять результаты.

Когда модели с открытыми весами на своих серверах обходятся дешевле?

За последний год модели с открытыми весами заметно усилились. С выходом Qwen 3.8 модель класса Max впервые стала доступна с открытыми весами, а такие модели, как Kimi K3, в ряде задач приблизились к закрытым. Поэтому вопрос «API или свои серверы?» стал настоящим вопросом стоимости.

Две модели затрат принципиально различаются. В API стоимость переменная: вы платите за то, что используете, и ничего не платите, когда не используете. На своих серверах стоимость в основном фиксированная: GPU-сервер, время инженеров на его поддержку, мониторинг и резервирование оплачиваются независимо от наличия трафика. Поэтому собственный хостинг становится дешевле только при высоком и стабильном объёме.

Пример расчёта (условные цифры): сравним инсталляцию с фиксированной месячной стоимостью 100 единиц (включая GPU, эксплуатацию и мониторинг) с API, который берёт 2 единицы за миллион токенов. Точка безубыточности составляет 50 миллионов токенов в месяц. Ниже неё дешевле API; выше, пока хватает мощности сервера, выгоднее собственная инсталляция. В реальном расчёте учитывайте и среднюю загрузку сервера: стоимость GPU, простаивающего ночью, ложится на дневные запросы.

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

Как отслеживать стоимость LLM?

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

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

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

Чек-лист оптимизации стоимости LLM

Считаете ли вы стоимость за успешную задачу, а не за вызов?
Логируется ли каждый вызов с функцией, клиентом, моделью и версией промпта?
Есть ли у вас тестовый набор, который измеряет точность и прогоняется при каждом изменении?
Стоит ли постоянный контекст (системная инструкция, описания инструментов) в начале, чтобы работал кэш промпта?
Используется ли кэш точных ответов для повторяющихся входных данных?
Если есть семантический кэш, исключены ли из него ответы с персональными данными?
Направляются ли простые задачи небольшой модели или решаются каскадом?
Ограничены ли число фрагментов в RAG и история диалога?
Заданы ли максимальная длина ответа и структурированный вывод?
Есть ли у агентов бюджет шагов и токенов?
Выполняются ли задачи, которые могут подождать, через пакетный интерфейс?
Сравнили ли вы API и модели с открытыми весами для вашего объёма по актуальным ценам?
Настроены ли оповещения о дневном бюджете и аномалиях?

Как Detartech подходит к стоимости ИИ?

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

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

Часто задаваемые вопросы

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

Снижает ли расходы переход на более дешёвую модель? Не всегда. Если дешёвая модель чаще ошибается, повторы и ручные исправления могут увеличить стоимость успешной задачи. Решение нужно принимать, сравнив точность и полную стоимость задачи для обеих моделей на одном тестовом наборе.

Влияет ли кэширование промпта на качество? Нет. Кэширование промпта избавляет модель от повторной обработки того же контекста и не меняет содержание ответа. Чтобы оно работало, неизменное содержимое должно стоять в начале контекста, а изменяемое в конце.

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

Как отслеживать расходы на ИИ по клиентам? Логировать каждый вызов модели вместе с идентификатором клиента или арендатора. Эти записи показывают, сколько расходов создаёт каждый клиент и покрывает ли их ваше ценообразование; квоты и оповещения строятся на тех же данных.