К середине 2026 года самая частая архитектурная ошибка ИИ, которую мы видим в продакшене, — переплата за инференс. Команды выкатывают LLM-функции, видят, что они работают, а потом получают пятизначные ежемесячные счета, которые растут вместе с использованием. Часть функций становится убыточной. Часть компаний режет функции, которые были бы жизнеспособны при лучшей дисциплине по затратам.
Большинство счетов за LLM заметно больше, чем нужно. Экономия приходит не от одной волшебной техники, а от набора оптимизаций, каждая из которых по отдельности умеренна.
В статье — техники, цифры и дисциплина продакшена. Исходим из того, что базовую маршрутизацию моделей вы уже сделали (это разобрано в другой статье); идём глубже.
Структура затрат
Затраты на LLM складываются из:
- Входные токены. То, что вы отправляете в модель. Включают системный промпт, контекст, пользовательский запрос.
- Выходные токены. То, что модель возвращает. Обычно в 4-6 раз дороже входных (Anthropic 5x, OpenAI ~6x по текущим прайс-листам — см. справочник моделей и цен, проверено 2026-07-07).
- Токены рассуждений. У рассуждающих моделей — внутренние токены «размышления». Часто такие же дорогие, как выходные.
- Вызовы инструментов. При использовании вызова инструментов каждое описание инструмента — это входные токены.
- Повторные попытки. Неудавшиеся вызовы тоже стоят денег.
Оптимизация работает на каждом уровне.
Техника 1: кэширование промптов
Самый большой рычаг. Большинство современных провайдеров кэшируют повторяющиеся префиксы входа — за первый раз вы платите полную цену, а за последующие вызовы с тем же префиксом значительно меньше.
Цены (типично):
- Anthropic: кэшированный вход ~10% от обычной цены.
- OpenAI: автоматически при совпадении префиксов, ~50% от обычной (зависит от модели).
- Google: явно задаваемый кэшируемый контент, варьируется.
Как это работает: первый вызов модели с конкретным префиксом входа — по обычной цене. Последующие вызовы в окне кэша (обычно 5-60 минут, зависит от провайдера) переиспользуют кэшированное представление.
Практическая реализация:
Стройте промпты так, чтобы статический контент шёл первым, а динамический — последним:
[CACHED: 10K tokens]
- Системный промпт
- Описания инструментов
- Статический профиль пользователя
- Фрагменты базы знаний, которые вряд ли меняются на каждый вызов
[NOT CACHED: 1K tokens]
- История разговора (меняется на каждом ходу)
- Текущий запрос пользователя
Первые 10K токенов кэшируются после первого вызова. Последующие вызовы платят за них ~10% и полную цену за 1K.
Пример экономии:
Без кэширования:
- 11K входных токенов × €3/миллион = €0.033 за вызов.
- 100K вызовов/день = €3,300/день.
С кэшированием (90% входа кэшировано):
- 1K по полной цене + 10K кэшированных по 10%:
- 1K × €3/миллион + 10K × €0.30/миллион = €0.003 + €0.003 = €0.006 за вызов.
- 100K вызовов/день = €600/день.
Экономия 82%. Реальные цифры, реальные системы.
Дисциплина реализации:
- Определите статические и динамические части промптов.
- Размещайте статическое первым.
- Используйте маркеры кэша там, где провайдер их поддерживает (Anthropic), для явного контроля.
- Проверяйте попадания в кэш — ваша система наблюдаемости должна показывать долю попаданий в кэш. Если она низкая — структура промпта неправильная.
Это оптимизация с самым высоким ROI. Внедрите её прежде всего остального.
Техника 2: маршрутизация моделей
Подробно разобрана в другом месте. Кратко: разные запросы — разным моделям по сложности.
- 60% запросов — маленьким моделям.
- 30% — среднему классу.
- 10% — флагману.
Типичная экономия: 60-80% против использования флагмана на всё.
В сочетании с кэшированием — экономия 90%+ против наивного базового уровня.
Техника 3: контроль длины вывода
Выходные токены доминируют в стоимости для большинства сценариев. Они обычно в 4-6 раз дороже входных; их определяют модель и промпт; и они часто длиннее, чем нужно.
Стратегии:
Явные инструкции по длине.
Ответьте не более чем в 100 словах.
Модели следуют этому вполне сносно. Значимо режут стоимость вывода.
Структурированный вывод.
Когда видимый пользователю ответ — короткие структурированные данные (JSON с конкретными полями), вывод ограничен. Нет риска ненужного многословия.
Параметр max_tokens.
Задайте его. Не оставляйте значение по умолчанию. Если 200 токенов достаточно — поставьте max в 250 (небольшой буфер). Модель не сможет выйти за предел.
Ограничения формата.
«Только списком» или «одним абзацем» дают более короткий вывод, чем свободная форма.
Списки вместо прозы.
Списки обычно вдвое короче прозы, передающей ту же информацию.
Без преамбулы.
«Пропускайте вводные фразы. Сразу к ответу». Модели часто начинают с «Отличный вопрос…» или «Давайте объясню…» — впустую потраченные токены.
Пример экономии:
Процесс суммирования. Вывод по умолчанию: 500 токенов. С ограничением: 200 токенов.
- 500 токенов × €10/миллион = €0.005 за вызов.
- 200 токенов × €10/миллион = €0.002 за вызов.
Экономия 60% на выводе. Менее впечатляюще, чем 90% у кэширования, но по самой большой статье расходов.
Техника 4: сэмплирование вывода и ранний останов
В некоторых сценариях вам нужен не полный вывод LLM, а решение или классификация.
Logprobs для классификации.
# Use a small NON-reasoning model here: reasoning-family models
# (GPT-5.x thinking tiers and similar) reject logprobs/logit_bias.
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
Вы просите модель выдать один токен (категорию). Стоимость — один проход по входу плюс 1 выходной токен. Быстрее, дешевле и часто не хуже длинных ответов.
Logit bias.
Для вывода из известного множества — смещайте логиты в сторону допустимых вариантов.
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_bias keys are token IDs (as strings), not words.
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[...],
logit_bias=bias,
max_tokens=1,
)
Направляет модель на нужный тип вывода. Дёшево и надёжно для классификации.
Техника 5: пакетная обработка
Когда обрабатываете много объектов — обрабатывайте их пакетами.
Асинхронная пакетная обработка на уровне API.
Большинство провайдеров поддерживают асинхронные или пакетные API (batch), которые обрабатывают несколько запросов по сниженной цене.
- OpenAI Batch API: -50%, SLA 24 часа.
- Anthropic Message Batches: -50%, SLA 24 часа.
Если у вас есть отложенная работа, которой не нужен ответ в реальном времени, — прогоняйте её через Batch API. Вдвое дешевле.
Пакетирование внутри промпта.
Обрабатывайте несколько объектов в одном вызове LLM, где это возможно.
Вместо:
[10 отдельных вызовов, каждый классифицирует один тикет]
Делайте:
[1 вызов, классифицирует 10 тикетов в одном промпте]
У единого вызова больше входа (10 объектов), но лишь один комплект фиксированных накладных расходов (системный промпт, описания инструментов). Суммарно токенов меньше, чем у 10 отдельных вызовов.
Оговорка: при слишком большом числе объектов на промпт качество может падать. Найдите оптимум для своего сценария. Обычно 5-20 объектов в промпте — нормально.
Техника 6: меньшие модели на узкие задачи
Помимо стандартной маршрутизации — задумайтесь, действительно ли задаче нужна большая модель.
Классификация: модель младшего уровня часто не хуже флагмана для простой классификации. По текущим прайс-листам (проверено 2026-07-07): Claude Haiku 4.5 за $1/$5 на миллион токенов против Claude Opus 4.8 за $5/$25 — ровно 5x экономии; младший уровень OpenAI против GPT-5.5 — похожий множитель.
Извлечение: модели среднего класса справляются со структурированным извлечением. Берегите флагман для случаев, где они не справляются.
Перевод: специализированные модели перевода или мелкие LLM справляются с большинством случаев.
Эмбеддинги: используйте модели, заточенные под эмбеддинги, а не универсальные LLM.
Паттерн: определите свои «простые, узкие» нагрузки. Направляйте их в самую маленькую модель, которая делает работу приемлемо. Берегите флагман для сложной работы, требующей суждения.
Техника 7: дообученные маленькие модели
Для очень высокообъёмных узких задач — дообучите маленькую модель.
Пример: 100K запросов классификации в день.
- GPT-5 без модификаций: €30/день в затратах на API.
- Дообученная 8B модель на выделенном инференсе: €5-10/день на инференс плюс единоразовая стоимость дообучения.
При достаточном объёме дообученные маленькие модели быстро окупаются. Расчёт зависит от вашего объёма.
Это разобрано в статье о дообучении. Принцип: когда сходятся масштаб и узость, дообучение — рычаг по затратам.
Техника 8: предварительная фильтрация
Для многошаговых процессов на LLM дешёвая фильтрация ловит очевидные случаи до дорогой обработки.
Пример: классификация обращений в поддержку плюс ответ.
Дешёвая предварительная фильтрация:
- «Это реальный вопрос в поддержку или спам/мусор?» (классификация в один токен на маленькой модели).
- «Это известный вопрос из FAQ?» (поиск по эмбеддингам; дёшево).
До дорогой генерации ответа доходят только запросы, прошедшие фильтр.
Экономия: если 30% входящих запросов — мусор или покрыты FAQ, это минус 30% ваших дорогих вызовов.
Предварительный фильтр дёшев (€0.0001 за вызов) по сравнению с генерацией ответа (€0.05 за вызов). Лёгкий ROI.
Техника 9: кэширование сверх кэширования промптов
Помимо кэширования промптов на стороне провайдера — кэширование на уровне приложения:
Кэширование ответов. Тот же запрос, тот же контекст, тот же ответ. Кэшируем и возвращаем без вызова модели.
def cached_call(prompt, model, ttl=3600):
cache_key = hash(prompt + model)
cached = redis.get(cache_key)
if cached:
return cached
response = call_llm(prompt, model)
redis.set(cache_key, response, ttl=ttl)
return response
Для идемпотентных запросов это полностью устраняет дублирующие вызовы.
Кэширование эмбеддингов. Вычисленные эмбеддинги кэшируются.
Кэширование результатов извлечения. Результаты поиска по запросу кэшируются на короткие промежутки.
Кэширование результатов инструментов. Результаты вызова инструментов кэшируются, если данные под ними меняются нечасто.
Уровни кэширования складываются. На каждом слое вы экономите вызовы.
Техника 10: спекулятивное выполнение
Для чувствительных к задержке процессов, где можно предсказать следующие шаги, — вызывайте заранее, спекулятивно.
Пример: агент поддержки. Вы знаете, что после того, как клиент описал проблему, следующий шаг обычно — «резюмировать обращение». Запустите это резюмирование параллельно с показом подтверждения пользователю.
Если предсказание верное — ответ готов к моменту, когда он нужен. Если нет — вы потратили один вызов впустую.
Это скорее оптимизация задержки, чем затрат, но для некоторых процессов она заметно улучшает UX.
Техника 11: арбитраж провайдеров
Разные провайдеры берут по-разному за похожие модели. Пользуйтесь этим.
Открытые модели у дешёвых провайдеров инференса.
Llama 3.3 70B на Together AI: $0.88/M входных и выходных (прайс-лист, проверено 2026-07-07). Закрытый класс, с которым она конкурирует, Claude Sonnet 5: $3/M входных, $15/M выходных (вводная цена $2/$10 до 2026-08-31).
Для задач, где открытой 70B достаточно, это ~3.4x на входе и ~17x на выходе — считайте 3-17x в зависимости от вашего соотношения входа и выхода.
Та же модель у разных провайдеров.
Некоторые открытые модели размещаются у нескольких провайдеров с разной ценой. Сравнивайте предложения.
Самостоятельный хостинг в масштабе.
При достаточном объёме (скажем, €10K+/месяц на конкретной модели) самостоятельный хостинг становится дешевле вызовов API. Требует операционных мощностей.
Арбитраж провайдеров требует сложности. Мультипровайдерная маршрутизация с запасным вариантом. Тесты качества под вариант каждого провайдера. В масштабе — оправданно.
Техника 12: ускорение инференса
Для собственного хостинга — оптимизация самого слоя инференса.
vLLM, TGI, SGLang. Оптимизированные серверы инференса. 2-10x пропускной способности против наивных реализаций.
Квантизация. Запуск моделей в меньшей точности (4-bit, 8-bit). 2-4x пропускной способности, лёгкая потеря качества.
Flash Attention, paged attention. Архитектурные оптимизации, включённые в современных серверах.
Непрерывная пакетная обработка. Серверы, которые объединяют запросы на лету в пакеты ради лучшей загрузки GPU.
Для команд, которые хостятся сами в масштабе, это важно. Для команд на API этим занимается провайдер.
Техника 13: потоковая передача
Потоковая передача не уменьшает число токенов, но улучшает UX, а это влияет на восприятие экономической эффективности.
При длинном выводе пользователи видят, как контент появляется сразу. Они могут читать по ходу генерации. Ощущается заметно быстрее, чем ожидание полного ответа.
Для агентов потоковый вывод промежуточных шагов даёт пользователю видимость прогресса.
Реализация: каждое современное API поддерживает потоковую передачу. Используйте её в пользовательских сценариях.
Техника 14: бюджетные ограждения
Сверх оптимизации — вводите жёсткие бюджеты, чтобы предотвратить неконтролируемый рост затрат.
Бюджет на запрос. Максимум токенов на запрос. Превышение — стоп.
Бюджет на пользователя. Дневной или месячный потолок стоимости на пользователя. Ограничение скорости на подходе к нему.
Бюджет на функцию. У каждой функции свой бюджет. Автоотключение при 10x от среднесуточного.
Глобальный бюджет. Общий дневной/месячный лимит. На подходе к нему — приостановка некритичной работы.
Напрямую денег это не экономит, но предотвращает катастрофы. Один баг или атака без ограждений могут быстро раздуть счёт.
Проработанный пример: реальное снижение затрат
Команда с ИИ-поддержкой в продакшене имела счёт €12,000/месяц. Шесть месяцев спустя, с применёнными техниками, — €1,800/месяц, снижение на 85%.
Изменения:
-
Кэширование промптов. Промпты перестроены под максимизацию статического префикса. ~70% входа теперь кэшируется. Экономия ~30%.
-
Маршрутизация моделей. Классификация и сортировка тикетов переведены с Claude Sonnet на Claude Haiku. Экономия ~15%.
-
Контроль длины вывода. Ответы ограничены 250 словами против прежних 800-1500. Экономия ~25%.
-
Предварительная фильтрация. Дешёвая классификация ловит тикеты, покрытые FAQ, и они выдаются из кэша. ~20% тикетов исключено из дорогого процесса. Экономия ~10%.
-
Кэширование ответов для FAQ. Идентичные вопросы возвращают кэшированные ответы. Экономия ~5%.
Перечисленные проценты — доля каждой техники в итоговом снижении: в сумме они дают те самые ~85%, и каждая измерялась относительно счёта, оставшегося после предыдущего изменения; это не независимые множители, которые можно применить к вашему собственному счёту.
Качество: по каждой замеренной метрике (удовлетворённость клиента, корректность ответа, доля решённых обращений) качество не изменилось или чуть улучшилось.
Операционные затраты: ~80 инженерных часов за 3 месяца. ROI: окупилось за 2 недели.
Распространённые ошибки
Несколько паттернов, которые мы видим:
Ошибка 1: отсутствие учёта затрат. У команды нет видимости, сколько стоит каждая функция, пользователь, вызов. Без измерения оптимизация невозможна.
Ошибка 2: оптимизация не того. Потратили недели на снижение входных токенов на 5%, когда выходные занимали 80% счёта. Сначала измеряйте; потом оптимизируйте крупнейшие статьи.
Ошибка 3: регрессии качества. Урезание затрат выкатили без мониторинга качества. Сэкономили деньги, потеряли пользователей. Всегда сочетайте работу над затратами с наборами оценочных тестов.
Ошибка 4: чрезмерная маршрутизация. Агрессивная маршрутизация в маленькие модели на задачи, которые они на деле не тянут. Мнимая экономия.
Ошибка 5: загрязнение кэша. Кэш забивается редкими запросами. Большинство записей используются один раз. Доминируют промахи. Нужна другая стратегия кэширования.
Ошибка 6: игнорирование Batch API. Реальное время там, где хватило бы пакетной обработки. Скидка в 50% лежала на столе.
Ошибка 7: переусложнение. Строят сложную оптимизацию поверх функций, которые всё равно нерентабельны. Иногда правильный ответ — «закрыть функцию».
Ошибка 8: нет бюджетных ограждений. Один баг вызывает неконтролируемый рост. Катастрофа вместо лёгкого неудобства.
Культурная часть
Дисциплина по затратам отчасти культурна. Команды, у которых получается:
- Относятся к стоимости как к метрике, а не как к чему-то второстепенному.
- Имеют ответственного (часто на стыке инженерии и финансов).
- Смотрят затраты в недельных метриках.
- Расследуют скачки сразу.
- Ставят бюджеты по функциям; настраивают оповещения при пробое порогов.
- Делают компромиссы явно (стоимость / качество / задержка).
Команды, у которых не получается:
- Относятся к стоимости как к чужой проблеме.
- Обнаруживают счёт в конце месяца.
- Реагируют на скачки постфактум.
- Не имеют понятия о бюджете.
- Пропускают разговор о компромиссах; оптимизируют по одной оси за раз.
Культурное изменение труднее технического. Но именно оно делает технические изменения устойчивыми.
Траектория цен
Пара слов о более широком тренде.
Стоимость единицы возможностей круто падала год к году — в основном потому, что меньшие модели догоняют вчерашние флагманы, а не потому, что прайс-листы флагманов рушатся. Относитесь к любой цифре «цена через год» как к модельному допущению и перепроверяйте справочник моделей и цен, прежде чем её цитировать.
Это значит:
- Некоторые оптимизации со временем значат меньше (абсолютная цена и так падает).
- Часть нагрузок, нерентабельных сейчас, станут рентабельными.
- Стройте на длинную дистанцию: чистая архитектура важнее, чем выжимание каждого цента сейчас.
При этом: даже с падающими ценами оптимизация важна. Неэффективные системы транжирят деньги при любой цене. И конкурентное преимущество часто достаётся командам с эффективными операциями при меньшей стоимости.
90-дневный план оптимизации затрат
Для команды, которая начинает с «у нас есть ИИ-функция, а затраты выше ожидаемых»:
Недели 1-2: измеряем.
- Инструментуем стоимость каждого вызова.
- Строим дашборды по функциям и пользователям.
- Определяем крупнейшие статьи затрат.
Недели 3-4: быстрые победы.
- Включаем кэширование промптов там, где оно поддерживается.
- Перестраиваем 3 самых частых промпта под максимум доли попаданий в кэш.
- Ставим max_tokens на всех вызовах.
- Внедряем бюджетные оповещения.
Недели 5-6: маршрутизация.
- Определяем простые задачи, которые идут на флагман.
- Строим маршрутизатор для 3-5 самых вызываемых эндпоинтов.
- Тестируем на регрессии качества.
Недели 7-8: вывод и кэширование.
- Ограничиваем длину вывода там, где он не виден пользователю.
- Добавляем кэш ответов на уровне приложения для распространённых запросов.
- Добавляем предварительные фильтры для самых высокообъёмных процессов.
Недели 9-10: продвинутое.
- Batch API для работы не в реальном времени.
- Оцениваем альтернативных провайдеров.
- Кэш эмбеддингов, кэш извлечения.
Недели 11-12: закалка.
- Бюджетные ограждения на каждой функции.
- Дашборды затрат в регулярном обзоре команды.
- Документация паттернов для будущих функций.
К концу 90 дней: снижение затрат на 50-80% реалистично. Качество под мониторингом. Дисциплина внедрена.
Сначала измерьте, потом складывайте экономию
Стоимость LLM поддаётся снижению — обычно на 60-90% — без потери качества. Техники хорошо известны: кэширование, маршрутизация, контроль вывода, пакетная обработка, предварительная фильтрация, кэширование ответов, выбор модели, бюджетные ограждения.
По отдельности каждая экономит умеренно. Вместе они складываются в колоссальную экономию.
Команды, которые делают это правильно, превращают убыточные ИИ-функции в прибыльные. Команды, которые не делают, в итоге вынуждены резать функции, которые могли бы быть жизнеспособны.
Сначала измеряйте. Оптимизируйте крупнейшие статьи. Поддерживайте мониторинг качества. Встройте дисциплину по затратам в регулярную работу команды.
Результат: ИИ-функции, которые масштабируются экономически, а не только технически. Именно это делает ИИ устойчивой частью продукта, а не разовым заголовком при запуске.
