Как снижать расходы на LLM API в 2026: model routing, prompt/context caching, Batch API, output budgeting, compression, semantic cache и offload на дешёвые модели.
Стоимость LLM в продакшене почти никогда не убивается одной “серебряной пулей”. В 2026 самые большие выигрыши дают не магические промпты, а довольно скучная инженерия: правильный выбор модели, routing, prompt/context caching, batch, жёсткий output budgeting и кэширование повторяющихся ответов.
Главная разница с устаревшими гайдами в том, что рынок стал шире. Экономику теперь приходится считать не между двумя моделями, а между несколькими слоями:
premium managed models вроде GPT-5.4 или Claude Opus 4.6;
balanced models вроде GPT-5.4 mini, Claude Sonnet 4.6, Gemini 2.5 Flash;
ultra-cheap lanes вроде GPT-5.4 nano, Gemini 2.5 Flash-Lite, deepseek-chat;
отдельный reasoning layer, который часто лучше включать только по роутингу.
Оптимизация стоимости LLM похожа на экономику облака. Самый быстрый способ переплатить — запустить всё на самой дорогой модели и слать в неё слишком длинный контекст. Самый быстрый способ сэкономить — разделить запросы по сложности и перестать платить premium price за простую работу.
Не стройте дашборд так, будто у всех провайдеров есть отдельная универсальная строка reasoning tokens. У Google output price для thinking-моделей прямо включает thinking tokens; у OpenAI pricing обычно даётся как input/output rate на модель, а reasoning влияет на реальное потребление и latency. Считать нужно по фактическому usage конкретного провайдера, а не по абстрактной общей схеме.
если задача простая и массовая: GPT-5.4 nano, Gemini 2.5 Flash-Lite, deepseek-chat;
если нужен баланс: GPT-5.4 mini, Claude Sonnet 4.6, Gemini 2.5 Flash;
если reasoning дорог по latency и цене: включайте его только по роутингу;
если запрос не интерактивный: переводите в Batch API;
если контекст повторяется: сначала думайте про caching, потом уже про compression.
Без техники
Все запросы на premium-модель. Нет routing, нет cache, нет batch. 10 000 запросов в день превращаются в большой ежемесячный счёт.
С техникой
70% запросов идут на cheap lane, длинный prompt кэшируется, async-задачи уходят в batch, FAQ закрывается semantic cache. Тот же продукт может стоить в разы дешевле.
Большая часть перерасхода случается не из-за “дорогих токенов вообще”, а из-за того, что вся нагрузка льётся в слишком дорогую модель.
Практическая шкала в 2026 выглядит так:
Роль
Типичные модели
Router / classifier / guardrail
GPT-5.4 nano, Gemini 2.5 Flash-Lite, Claude Haiku 4.5
Основной workhorse
GPT-5.4 mini, Claude Sonnet 4.6, Gemini 2.5 Flash
Premium / high-stakes
GPT-5.4, Claude Opus 4.6
Cheap reasoning
deepseek-reasoner, Gemini 2.5 Flash thinking
Если приложение делает support triage, extraction, FAQ и только иногда сложный анализ, premium-модель не должна быть default.
Начинайте не с вопроса “какая модель самая умная?”, а с вопроса “какая самая дешёвая модель держит мой quality threshold на eval-наборе?”. Это почти всегда даёт больший выигрыш, чем поздняя оптимизация промптов.
Anthropic даёт явный prompt caching с двумя write-режимами:
5-minute cache write = 1.25x base input price;
1-hour cache write = 2x base input price;
cache read = 0.1x base input price.
То есть cache hit стоит 10% от обычного input. Для длинных system prompts, policy bundles, tool specs и больших документов это один из самых сильных levers.
OpenAI pricing page показывает отдельную строку cached input, причём дисконт зависит от модели. У GPT-5.4 это $0.25 против $2.50 стандартного input, у GPT-5.4 mini — $0.075 против $0.75.
Практический вывод один: если ваш префикс стабилен, economics запроса могут резко улучшиться.
Без техники
{
"title": "Плохо",
"content": "На каждый запрос заново отправляется 8K токенов системного промпта, policy и RAG-инструкций."
}
С техникой
{
"title": "Лучше",
"content": "Повторяющийся префикс выделен в cacheable слой, а в реальный runtime request попадает только пользовательский diff-контекст."
}
Старые статьи часто переоценивают input compression и недооценивают output control. Но output почти всегда дороже input, а у thinking-моделей ещё и тесно связан с reasoning / latency behavior.
Что работает:
max_output_tokens / max_tokens;
строгий output schema;
таблица, JSON или список вместо свободного эссе;
явные ограничения вроде “не больше 5 пунктов”;
разделение “short answer” и “full analysis” в разных режимах.
Плохой prompt:
«Подробно проанализируй всё, что видишь».
Хороший prompt:
«Верни 3 наиболее вероятные причины, confidence и next checks. Без длинного пересказа логов».
Если пользователи или пайплайны задают похожие вопросы, самый дешёвый LLM-вызов — тот, которого не было.
Есть два уровня:
exact cache: идентичный prompt;
semantic cache: близкий по смыслу prompt через embeddings/vector search.
Это особенно хорошо работает для:
FAQ;
классификации похожих тикетов;
RAG-answering по повторяющимся вопросам;
support/ops assistants.
Не пускайте semantic cache на high-stakes запросы без guardrails. Для поддержки или FAQ это нормально, для медицинского, юридического или финансового ответа threshold и validation должны быть намного строже.
У нас support assistant: 50K запросов в день. Сейчас всё идёт в Claude Sonnet 4.6. Есть длинный policy prompt, FAQ часто повторяются, nightly evals крутятся realtime.
Составь план снижения стоимости без заметного падения качества.
Ответ модели
Вынести длинный policy prompt в prompt caching.
FAQ закрыть semantic cache.
Классификацию и triage перевести на cheap lane.
Nightly evals и enrichment отправить в Batch API.
Оставить Sonnet 4.6 только на medium/high-complexity path.
Проверить, не переплачиваете ли вы за слишком длинный output.