Стоимость вывода — это свойство рабочей нагрузки: модель и регион, некешированные и кэшированные входные данные, сгенерированные токены и токены рассуждений, инструменты, повторные попытки, параллелизм, хранение и человеческий обзор имеют значение. Начинайте с фактических затрат и трассировок, а не с отраслевых заявлений об экономии.
Текущие цены и правила кэширования часто меняются. Перепроверяйте официальные страницы цен OpenAI, цен Anthropic и цен Gemini перед использованием любой модели расчета стоимости.
В статье — техники, цифры и дисциплина продакшена. Исходим из того, что базовую маршрутизацию моделей вы уже сделали (это разобрано в другой статье); идём глубже.
Структура затрат
Эта статья предполагает, что базовая маршрутизация моделей уже настроена; она описана в материале «Оркестрация нескольких моделей». Здесь мы рассматриваем следующий уровень оптимизации.
Затраты на LLM складываются из:
- Токены ввода. Данные, которые вы отправляете модели. Включают системный промпт, контекст и запрос пользователя.
- Токены вывода. Данные, возвращаемые моделью. Соотношение цен за ввод и вывод варьируется в зависимости от провайдера, модели, режима пакетной обработки и состояния кэша.
- Заряды за рассуждения или скрытые вычисления. Отчетность провайдеров и порядок выставления счетов различаются; используйте поля фактического потребления и текущий прайс-лист, а не предполагайте равенство с видимым выводом.
- Определения инструментов и их использование. Схемы могут добавлять токены ввода, тогда как размещенные инструменты или внешние сервисы могут иметь отдельные тарифы.
- Повторные попытки и неудачные запросы. Некоторые неудавшиеся или прерванные вызовы могут учитываться в потреблении; классифицируйте точки сбоев на основе данных биллинга провайдера и трассировки.
Оптимизация работает на каждом уровне.
Техника 1: кэширование промптов
Кэширование может существенно снизить затраты, если запросы имеют общий допустимый префикс и рабочая нагрузка обеспечивает высокую долю попаданий.
Изучите актуальную документацию провайдера по кэшированию: минимальный размер префикса, тарифы на запись и чтение, время жизни данных, ограничения маршрутизации и возможности мониторинга.
В общем случае повторяющийся допустимый префикс может использоваться повторно в течение окна, определяемого провайдером. Точная семантика не является переносимой между разными провайдерами.
Практическая реализация:
Стройте промпты так, чтобы статический контент шёл первым, а динамический — последним:
[CACHED: 10K tokens]
- Системный промпт
- Описания инструментов
- Статический профиль пользователя
- Фрагменты базы знаний, которые вряд ли меняются на каждый вызов
[NOT CACHED: 1K tokens]
- История разговора (меняется на каждом ходу)
- Текущий запрос пользователя
Допустимость префикса и порядок его тарификации зависят от выбранной модели и провайдера.
Формула экономии:
daily cost = calls × (uncached input × input rate + cache writes × write rate + cache reads × read rate + output × output rate + tool charges)
Заполните её фактическими количествами оплаченных токенов и текущим прайс-листом. Сравнивайте эквивалентные временные интервалы и учитывайте промахи кэша.
Дисциплина реализации:
- Определите статические и динамические части промптов.
- Размещайте статическое первым.
- Используйте маркеры кэша там, где провайдер их поддерживает (Anthropic), для явного контроля.
- Проверяйте попадания в кэш — ваша система наблюдаемости должна показывать долю попаданий в кэш. Если она низкая — структура промпта неправильная.
Приоритизируйте кэширование только после того, как анализ трассировки покажет, что повторяющиеся допустимые входные данные являются основной статьей затрат.
Техника 2: маршрутизация моделей
Подробно разобрана в другом месте. Кратко: разные запросы — разным моделям по сложности.
Сформируйте размеченный набор данных для оценки маршрутизации, сравните модели-кандидаты по качеству и стоимости, а также предусмотрите резервный вариант для неопределенных или неудачных случаев. Итоговый состав маршрутизации специфичен для конкретной рабочей нагрузки.
Техника 3: контроль длины вывода
Токены результата могут быть основной статьей затрат. Подтвердите это в данных потребления перед оптимизацией длины ответа.
Стратегии:
Явные инструкции по длине.
Ответьте не более чем в 100 словах.
Модели могут по-прежнему нарушать инструкцию о длине текста. Обеспечьте соблюдение лимита и оцените его эффект, сообщая об измеренном изменении количества токенов и качества, а не обещая значительной экономии.
Структурированный вывод.
Если требуемый ответ представляет собой короткие структурированные данные, строгая схема может сократить избыточный текст. Она не устраняет невалидный результат, значения полей сверх допустимого размера, повторные попытки или риск усечения; проверяйте каждый результат.
Лимит токенов результата у провайдера.
Установите лимит вывода текущего API, исходя из измеренных потребностей задачи, и оставьте запас для корректного завершения. Названия параметров и их семантика различаются в зависимости от API и модели; слишком маленький лимит может привести к усечению структурированного результата и вызвать дополнительные вызовы.
Ограничения формата.
«Только списком» или «одним абзацем» дают более короткий вывод, чем свободная форма.
Списки вместо прозы.
Маркированные списки могут сократить связный текст для некоторых ответов. Измеряйте количество токенов; подробный маркированный список может быть длиннее лаконичного абзаца.
Без преамбулы.
«Пропускайте вводные фразы. Сразу к ответу». Модели часто начинают с «Отличный вопрос…» или «Давайте объясню…» — впустую потраченные токены.
Пример измерения:
Для рабочего процесса суммаризации сравните стандартный и ограниченный результаты на одних и тех же документах. Укажите оплаченные выходные токены, полноту фактической информации, читаемость, частоту последующих запросов пользователей и любые случаи усечения. Меньшее количество токенов не является экономией, если пользователям требуется дополнительный вызов.
Техника 4: сэмплирование вывода и ранний останов
В некоторых сценариях вам нужен не полный вывод LLM, а решение или классификация.
Logprobs для классификации.
# Use only a model and API operation whose current documentation supports
# log probabilities; support varies by model and endpoint.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
Это побуждает совместимую модель выдать краткую метку. Убедитесь, что выбранный API поддерживает логарифмические вероятности (log probabilities), что метки однозначно отображаются в токены и что качество классификации соответствует целевым показателям.
Ограниченные метки или логит-смещение (logit bias).
Для выводов из известного набора предпочтительно использовать документированное ограничение перечисления (enum) или схемы, если оно доступно. Логит-смещение влияет на выбор токенов, но зависит от токенизатора и модели.
response = openai.chat.completions.create(
model=COMPATIBLE_MODEL,
messages=[...],
# If used, build logit_bias from every tokenization variant you intend
# to accept; do not assume a class label is exactly one token.
logit_bias=VALIDATED_TOKEN_BIAS,
max_tokens=1,
)
Логит-смещение влияет на выбор токенов; оно не гарантирует валидность класса и не доказывает надежность классификации. Проверяйте результат и отклоняйте неожиданные данные.
Техника 5: пакетная обработка
Когда обрабатываете много объектов — обрабатывайте их пакетами.
Асинхронная пакетная обработка на уровне API.
Некоторые провайдеры поддерживают асинхронные или пакетные продукты, иногда с другими ценами, окнами завершения, лимитами и условиями обработки данных.
- OpenAI и Anthropic документируют свои асинхронные пакетные продукты. Проверьте текущую скидку, окно завершения, лимиты и условия обработки данных на их официальных страницах с ценами и информацией о пакетной обработке.
Если фоновая работа не требует интерактивного ответа, сравните текущее пакетное ценообразование и поведение завершения с синхронным путем.
Пакетирование внутри промпта.
Обрабатывайте несколько объектов в одном вызове LLM, где это возможно.
Вместо:
[10 отдельных вызовов, каждый классифицирует один тикет]
Делайте:
[1 вызов, классифицирует 10 тикетов в одном промпте]
Одиночный вызов содержит больше входных элементов, но может использовать один набор фиксированных накладных расходов на промпт. Это может уменьшить общее количество токенов в некоторых рабочих нагрузках; разделители, более длинные результаты, повторные попытки и сбои на уровне пакета могут свести эту экономию на нет.
Предупреждение: пакетная обработка может изменить качество, порядок следования, обрезку и изоляцию сбоев. Подбирайте размеры пакетов на репрезентативных входных данных, а не используйте универсальный диапазон.
Техника 6: меньшие модели на узкие задачи
Помимо стандартной маршрутизации — задумайтесь, действительно ли задаче нужна большая модель.
Классификация: оцените модель более низкого уровня на размеченных примерах, включая редкие классы и сценарии отказа от выдачи ответа, по сравнению с текущей производственной моделью. Используйте актуальные цены провайдера для сравнения затрат.
Извлечение данных: сравните компактные, средние, детерминированные и гибридные извлекатели по точности на уровне полей, обработке исключений, задержкам и стоимости. Передавайте сложные случаи на доработку согласно проверенным правилам.
Перевод: оцените специализированные системы перевода и уровни LLM на реальных языковых парах, терминологии, форматировании, требованиях к безопасности и необходимости ручной проверки. Не делайте выводов о покрытии на основе агрегированных бенчмарков.
Эмбеддинги: используйте модели, заточенные под эмбеддинги, а не универсальные LLM.
Паттерн: определите свои «простые, узкие» нагрузки. Направляйте их в самую маленькую модель, которая делает работу приемлемо. Берегите флагман для сложной работы, требующей суждения.
Техника 7: дообученные маленькие модели
Для очень высокообъёмных узких задач — дообучите маленькую модель.
Для высоконагруженной задачи классификации сравните модель с промптами, дообученную модель, детерминированные правила и гибридный подход. Учитывайте затраты на обучающие и оценочные данные, обслуживание, простой мощности, мониторинг, переобучение и инженерные расходы. Дообучение экономически оправдано только в том случае, если измеренная кривая «качество/стоимость» это подтверждает.
Это разобрано в статье о дообучении. Принцип: когда сходятся масштаб и узость, дообучение — рычаг по затратам.
Тот же принцип применим к дообучению: когда масштаб и узость задачи совпадают, оно может стать рычагом снижения затрат. Подробнее см. «Дообучение в 2026 году».
Техника 8: предварительная фильтрация
Для многошаговых процессов на LLM дешёвая фильтрация ловит очевидные случаи до дорогой обработки.
Пример: классификация обращений в поддержку плюс ответ.
Дешёвая предварительная фильтрация:
- «Это реальный вопрос в поддержку или спам/мусор?» (классификация в один токен на маленькой модели).
- «Это известный вопрос из FAQ?» (поиск по эмбеддингам; дёшево).
До дорогой генерации ответа доходят только запросы, прошедшие фильтр.
Измерьте долю трафика, который префильтр может обработать с требуемой точностью. Ложные срабатывания могут блокировать корректные запросы, поэтому экономия затрат должна оцениваться в совокупности с качеством и влиянием на эскалацию.
Техника 9: кэширование сверх кэширования промптов
Помимо кэширования промптов на стороне провайдера — кэширование на уровне приложения:
Кэширование ответов. Для утвержденного диапазона и полного набора входных данных, влияющих на ответ, используйте предыдущий ответ, если его свежесть и семантика остаются корректными. Недетерминизм означает, что это решение продукта, а не тождественный закон.
import hashlib
import json
def stable_sha256(value):
payload = json.dumps(value, sort_keys=True, separators=(",", ":"))
return "llm:" + hashlib.sha256(payload.encode("utf-8")).hexdigest()
def cached_call(scope, prompt_version, prompt, model, params, ttl=3600):
# Canonicalize all response-affecting inputs and include tenant/user scope
# where a shared answer is not explicitly safe. Use a stable cryptographic
# digest rather than the process-randomized built-in hash().
cache_key = stable_sha256({
"scope": scope,
"prompt_version": prompt_version,
"prompt": prompt,
"model": model,
"params": params,
})
cached = redis.get(cache_key)
if cached:
return json.loads(cached.decode("utf-8"))
response = call_llm(prompt, model, params)
redis.set(cache_key, json.dumps(response), ex=ttl)
return response
Для подходящих достаточно детерминированных запросов это позволяет избежать повторных вызовов после попадания в кэш. Определите свежесть и инвалидацию, изолируйте области действия, предотвращайте эффект «каш-стампед» (cache stampede) и не кэшируйте конфиденциальные или персонализированные выходные данные без одобрения.
Кэширование эмбеддингов. Вычисленные эмбеддинги кэшируются.
Кэширование результатов извлечения. Результаты поиска по запросу кэшируются на короткие промежутки.
Кэширование результатов инструментов. Результаты вызова инструментов кэшируются, если данные под ними меняются нечасто.
Уровни кэширования складываются. На каждом слое вы экономите вызовы.
Техника 10: Спекулятивное выполнение (компромисс по задержке, а не экономия затрат)
Для чувствительных к задержке процессов, где можно предсказать следующие шаги, — вызывайте заранее, спекулятивно.
Пример: агент поддержки. Вы знаете, что после того, как клиент описал проблему, следующий шаг обычно — «резюмировать обращение». Запустите это резюмирование параллельно с показом подтверждения пользователю.
Если предсказание верное — ответ готов к моменту, когда он нужен. Если нет — вы потратили один вызов впустую.
Этот подход намеренно расходует вычислительные ресурсы, которые могут быть отброшены, поэтому затраты могут увеличиться. Используйте его только тогда, когда измеренная польза для задержки оправдывает потери, а отмена и побочные эффекты контролируются, и спекулятивный запрос не может раскрыть или изменить данные без соответствующих прав.
Техника 11: Сравнение провайдеров
Провайдеры различаются по цене, возможностям, регионам, квотам, условиям использования данных, надежности и реализации моделей. Сравнивайте кандидатов с эквивалентным качеством в рамках одинаковой нагрузки и условий контракта.
Модели с открытым исходным кодом на управляемых платформах вывода.
Сравнивайте цены текущих провайдеров только после того, как кандидат пройдет оценку на той же рабочей нагрузке. Аналогичный размер параметров или маркетинговый уровень не гарантируют эквивалентного качества.
Та же модель у разных провайдеров.
Некоторые модели с открытым исходным кодом предлагаются несколькими провайдерами. Проводите бенчмаркинг точной ревизии, квантизации, конфигурации обслуживания и поведения API; одно и то же название модели не гарантирует идентичного результата или производительности.
Самостоятельный хостинг в масштабе.
Собственный хостинг может стать дешевле при определенной утилизации рабочей нагрузки. Учитывайте часы использования GPU моделью, реплики, простои и пиковую мощность, сеть, мониторинг, обновления, безопасность, реагирование на инциденты и ответственность инженерной команды.
Маршрутизация между несколькими провайдерами добавляет сложность интеграции, оценки, безопасности, закупок, мониторинга и отказов. Применяйте её только тогда, когда измеренная устойчивость или экономическая выгода превышают затраты на поддержку.
Техника 12: ускорение инференса
Для собственного хостинга — оптимизация самого слоя инференса.
vLLM, TGI, SGLang. Серверы вывода с различным покрытием моделей и путями оптимизации. Проводите бенчмаркинг поддерживаемых версий на целевом оборудовании.
Квантование. Снижение точности может уменьшить потребление памяти или повысить пропускную способность, при этом влияние на качество зависит от задачи и метода. Проводите бенчмаркинг конкретного артефакта и конфигурации обслуживания.
Flash Attention, paged attention. Архитектурные оптимизации, включённые в современных серверах.
Непрерывная пакетная обработка. Серверы, которые объединяют запросы на лету в пакеты ради лучшей загрузки GPU.
Для команд, которые хостятся сами в масштабе, это важно. Для команд на API этим занимается провайдер.
Техника 13: потоковая передача
Потоковая передача не уменьшает число токенов, но улучшает UX, а это влияет на восприятие экономической эффективности.
При длинном выводе пользователи видят, как контент появляется сразу. Они могут читать по ходу генерации. Ощущается заметно быстрее, чем ожидание полного ответа.
Для агентов передавайте утвержденные события прогресса или сводки статуса. Не раскрывайте приватные рассуждения, секреты, не проверенные аргументы инструментов или данные других арендаторов в качестве «промежуточных шагов».
Реализация: если выбранное API и модель поддерживают потоковую передачу, протестируйте её для пользовательских сценариев. Потоковая передача изменяет воспринимаемую задержку, но не обязательно общую стоимость или время завершения задачи.
Техника 14: бюджетные ограждения
Сверх оптимизации — вводите жёсткие бюджеты, чтобы предотвратить неконтролируемый рост затрат.
Бюджет на запрос. Максимум токенов на запрос. Превышение — стоп.
Бюджет на пользователя. Дневной или месячный потолок стоимости на пользователя. Ограничение скорости на подходе к нему.
Бюджет по функциям. У каждой функции есть выделенный бюджет и протестированный механизм реагирования при превышении порога, специфичного для рабочей нагрузки.
Глобальный бюджет. Общий дневной/месячный лимит. На подходе к нему — приостановка некритичной работы.
Эти меры не доказывают экономию. Они ограничивают или перенаправляют расходы и могут также снизить доступность, поэтому протестируйте поведение оповещений, ограничения скорости, понижения качества, очередей и разрыва цепи для критически важных и некритических рабочих нагрузок.
Шаблон эксперимента по снижению затрат
Не представляйте комплексные данные как результат для клиента. Для одного производственного рабочего процесса зафиксируйте базовый период выставления счетов и применяйте одно изменение за раз:
Изменения:
-
Кэширование промптов. Зафиксируйте подходящие префиксные токены, частоту попаданий в кэш, записи и чтения кэша, задержку и оплаченную стоимость.
-
Маршрутизация моделей. Зафиксируйте распределение маршрутов, качество по каждому маршруту, резервные варианты, задержку и стоимость.
-
Контроль длины вывода. Фиксируйте длину вывода, качество завершения, повторные запросы пользователя и затраты.
-
Предварительная фильтрация. Фиксируйте точность, полноту, количество эскалаций, отфильтрованные корректные запросы и предотвращённые вызовы.
-
Кэширование ответов для FAQ. Фиксируйте правила семантического эквивалента, актуальность данных, условия инвалидации, частоту попаданий в кэш и качество ответа.
Отчитывайтесь о валовой и чистой экономии, результатах оценки, затраченном инженерном времени, новых операционных затратах и интервалах неопределённости там, где это подтверждается данными и методологией. Не утверждайте неизменность качества, если дизайн оценки не позволяет выявить значимые регрессии.
Распространённые ошибки
Шаблоны сбоев для проверки в ваших собственных трассировках:
Ошибка 1: отсутствие учёта затрат. У команды нет видимости, сколько стоит каждая функция, пользователь, вызов. Без измерения оптимизация невозможна.
Ошибка 2: оптимизация не того. Потратили недели на снижение входных токенов на 5%, когда выходные занимали 80% счёта. Сначала измеряйте; потом оптимизируйте крупнейшие статьи.
Ошибка 3: регрессии качества. Урезание затрат выкатили без мониторинга качества. Сэкономили деньги, потеряли пользователей. Всегда сочетайте работу над затратами с наборами оценочных тестов.
Ошибка 4: чрезмерная маршрутизация. Агрессивная маршрутизация в маленькие модели на задачи, которые они на деле не тянут. Мнимая экономия.
Ошибка 5: загрязнение кэша. Кэш забивается редкими запросами. Большинство записей используются один раз. Доминируют промахи. Нужна другая стратегия кэширования.
Ошибка 6: Пропуск пакетной оценки. Реальная обработка применяется к задачам, которые могли бы перенести текущее окно пакетной обработки и ограничения провайдера.
Ошибка 7: переусложнение. Строят сложную оптимизацию поверх функций, которые всё равно нерентабельны. Иногда правильный ответ — «закрыть функцию».
Ошибка 8: нет бюджетных ограждений. Один баг вызывает неконтролируемый рост. Катастрофа вместо лёгкого неудобства.
Дисциплина эксплуатации
Рекомендуемые практики эксплуатации:
- Рассматривайте затраты как метрику, а не как второстепенную задачу.
- Назначьте ответственного за затраты в рамках инженерных и финансовых обязанностей.
- Проводите обзор затрат с частотой, соответствующей волатильности расходов и бизнес-рискам.
- Сортируйте всплески затрат по определённым порогам и руководствам по действиям (runbooks).
- Устанавливайте бюджеты на каждую функцию; настраивайте оповещения о превышении порогов.
- Делайте компромиссы явными (затраты против качества против задержки).
Пробелы в контроле, на которые следует обратить внимание:
- Отсутствие назначенного ответственного за затраты.
- Выявление счетов только после того, как окно принятия решений уже прошло.
- Оповещения без назначенного ответственного или руководства по действиям.
- Отсутствие утверждённого бюджета или прогнозного коридора.
- Пропуск обсуждения компромиссов; оптимизация одного параметра за раз.
Это управленческие решения, которые следует проверять через записи об ответственности, посещаемость обзоров, реакцию на оповещения и завершённые действия по затратам, а не утверждение о культуре команды.
Дрейф цен и возможностей
Пара слов о более широком тренде.
Цены провайдеров, возможности моделей, пакетные продукты, правила кэширования и комиссии за хостинг инструментов меняются по расписанию поставщика. Данная статья не устанавливает универсальной исторической тенденции или прогноза.
Повторно запускайте модель оценки затрат и качества после существенных изменений цен, моделей, контрактов или рабочей нагрузки. Не предполагайте, что в настоящее время нерентабельный рабочий процесс станет рентабельным, или что будущие снижения базовых цен спасут неэффективный дизайн.
Иллюстративная двенадцатинедельная последовательность оптимизации затрат
Для команды, начинающей с позиции «у нас есть функция ИИ, затраты выше ожидаемых», приведенная ниже последовательность служит примером планирования. Измените продолжительность и условия остановки в соответствии с рабочей нагрузкой, доказательствами и операционными возможностями.
Недели 1-2: измеряем.
- Инструментуем стоимость каждого вызова.
- Строим дашборды по функциям и пользователям.
- Определяем крупнейшие статьи затрат.
Недели 3–4: Быстрые победы.
- Пробуйте кэширование промптов только там, где трассировка показывает повторяющиеся подходящие префиксы и текущие правила поставщика соответствуют требованиям.
- Переструктурируйте самые дорогие подходящие промпты, затем измерьте частоту попаданий в кэш, задержку, качество и оплаченную стоимость.
- Устанавливайте текущий лимит результата для каждого API только там, где это подтверждается измеренными потребностями задачи; тестируйте усечение и повторные попытки.
- Настройте оповещения о бюджете.
Недели 5-6: маршрутизация.
- Определяем простые задачи, которые идут на флагман.
- Строим маршрутизатор для 3-5 самых вызываемых эндпоинтов.
- Тестируем на регрессии качества.
Недели 7-8: вывод и кэширование.
- Ограничиваем длину вывода там, где он не виден пользователю.
- Добавляем кэш ответов на уровне приложения для распространённых запросов.
- Добавляем предварительные фильтры для самых высокообъёмных процессов.
Недели 9-10: продвинутое.
- Batch API для работы не в реальном времени.
- Оцениваем альтернативных провайдеров.
- Кэш эмбеддингов, кэш извлечения.
Недели 11-12: закалка.
- Бюджетные ограждения на каждой функции.
- Дашборды затрат в регулярном обзоре команды.
- Документация паттернов для будущих функций.
В конце цикла улучшений опубликуйте измеренное изменение затрат и доказательства качества. График не гарантирует определенный процент экономии.
Сначала измерьте, потом складывайте экономию
Затраты на LLM часто можно снизить, но процент и влияние на качество зависят от конкретной рабочей нагрузки. Кандидаты в техники включают кэширование, маршрутизацию, контроль результата, пакетную обработку, предварительную фильтрацию, кэширование ответов, выбор модели и ограничения бюджета.
Вносите изменения последовательно, чтобы их эффекты оставались атрибутируемыми; взаимодействия могут складываться, перекрываться или компенсировать друг друга.
Используйте чистый вклад после учета затрат на результат, инструменты, участие человека в контуре, инфраструктуру, обслуживание и поддержку, чтобы решить, является ли функция экономически устойчивой.
Сначала измеряйте. Оптимизируйте крупнейшие статьи. Поддерживайте мониторинг качества. Встройте дисциплину по затратам в регулярную работу команды.
Результат: ИИ-функции, которые масштабируются экономически, а не только технически. Именно это делает ИИ устойчивой частью продукта, а не разовым заголовком при запуске.
