Оптимизация стоимости LLM в 2026

Как снижать расходы на 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 конкретного провайдера, а не по абстрактной общей схеме.

Короткая версия

Самые сильные рычаги экономии в 2026:

  1. Model selection и routing: не слать всё в GPT-5.4 или Opus 4.6.
  2. Prompt/context caching: кэшировать длинный системный промпт, policy, RAG-context, документы.
  3. Batch API: переносить асинхронные задачи в batch со скидкой.
  4. Output budgeting: резать лишний output, а не только input.
  5. Compression и context hygiene: не слать мусор в контекст.
  6. Response cache: не вызывать LLM повторно на одинаковые или почти одинаковые вопросы.
  7. Cheap lane / local offload: простые задачи отдавать дешёвым API-моделям или SLM.

Где обычно лежат деньги

Где обычно сгорает бюджет LLM-приложения
Слишком дорогая модель по умолчанию35%
Лишние input tokens25%
Лишние output tokens20%
Повторные одинаковые запросы12%
Неправильный reasoning routing8%

Ключевые managed-цены на 20 марта 2026

МодельInputOutputCached / Cache hitЧто важно
GPT-5.4$2.50$15.00$0.25 cached inputСильный premium default, но плохой cost baseline
GPT-5.4 mini$0.75$4.50$0.075 cached inputПрактичный OpenAI workhorse
GPT-5.4 nano$0.20$1.25$0.02 cached inputДешёвый high-volume router / classifier
Claude Sonnet 4.6$3.00$15.00$0.30 cache hitСильный balanced layer у Anthropic
Claude Haiku 4.5$1.00$5.00$0.10 cache hitДешёвый Anthropic lane
Gemini 2.5 Flash$0.30$2.50$0.03 context cachingOutput включает thinking tokens
Gemini 2.5 Flash-Lite$0.10$0.40$0.01 context cachingОдин из лучших ultra-cheap lanes
deepseek-chat / deepseek-reasoner$0.28 miss$0.42$0.028 hitСамый дешёвый managed слой в этой группе

Быстрые правила

  • если задача простая и массовая: 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. Тот же продукт может стоить в разы дешевле.

1. Самый мощный рычаг: не держите одну модель default для всего

Большая часть перерасхода случается не из-за “дорогих токенов вообще”, а из-за того, что вся нагрузка льётся в слишком дорогую модель.

Практическая шкала в 2026 выглядит так:

РольТипичные модели
Router / classifier / guardrailGPT-5.4 nano, Gemini 2.5 Flash-Lite, Claude Haiku 4.5
Основной workhorseGPT-5.4 mini, Claude Sonnet 4.6, Gemini 2.5 Flash
Premium / high-stakesGPT-5.4, Claude Opus 4.6
Cheap reasoningdeepseek-reasoner, Gemini 2.5 Flash thinking

Если приложение делает support triage, extraction, FAQ и только иногда сложный анализ, premium-модель не должна быть default.

Начинайте не с вопроса “какая модель самая умная?”, а с вопроса “какая самая дешёвая модель держит мой quality threshold на eval-наборе?”. Это почти всегда даёт больший выигрыш, чем поздняя оптимизация промптов.

2. Prompt caching и context caching

Кэширование повторяющегося контекста в 2026 стало одним из самых недооценённых способов экономии.

Anthropic

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.

Google Gemini

У Gemini есть context caching с отдельной ценой за cached tokens и отдельной storage fee. Например:

  • Gemini 2.5 Flash: $0.03 за cached text/image/video input при стандартном input $0.30;
  • Gemini 2.5 Flash-Lite: $0.01 при стандартном input $0.10.

Паттерн тот же: длинный повторяющийся контекст не должен повторно тарифицироваться как обычный input на каждом запросе.

OpenAI

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-контекст." }

3. Batch API: самый простой способ получить скидку без деградации качества

И OpenAI, и Anthropic, и Google на batch-режимах дают существенную скидку для асинхронных задач.

  • Anthropic прямо пишет о 50% discount on both input and output tokens.
  • Google для Gemini 2.5 Flash даёт batch-price $0.15 / $1.25 вместо $0.30 / $2.50.
  • OpenAI pricing для Batch API также заявляет 50% экономии на async workload.

Batch нужен там, где ответ не требуется прямо сейчас:

  • nightly evals;
  • массовая классификация тикетов;
  • enrichment / tagging;
  • офлайн-суммаризация;
  • large-scale content generation;
  • периодические отчёты.

Плюсы

  • Обычно даёт самый чистый и предсказуемый дисконт
  • Не требует менять сам prompt или модельное качество
  • Хорошо подходит для evals, ETL и enrichment pipelines

Минусы

  • Не подходит для интерактивных пользовательских запросов
  • Нужен отдельный orchestration layer
  • Ошибки batch-job надо разбирать отдельно от realtime трафика

4. Output budgeting важнее, чем многие думают

Старые статьи часто переоценивают 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. Без длинного пересказа логов».

5. Compression и context hygiene

Не каждый длинный prompt нужно сжимать моделью. Часто достаточно нормальной инженерной гигиены:

  • убрать дубли;
  • сократить few-shot до 1-2 реально нужных примеров;
  • не слать лишние поля из RAG;
  • выносить policy/instructions в cacheable prefix;
  • summarization-before-reasoning для длинных документов.

LLMLingua и похожие компрессоры полезны, когда:

  • контекст стабильно больше 5K-10K токенов;
  • вы не можете радикально переписать prompt;
  • стоимость input реально стала bottleneck.

Но в большинстве production-систем сначала выгоднее сделать retrieval hygiene, а уже потом автоматическое prompt compression.

6. Response cache и semantic cache

Если пользователи или пайплайны задают похожие вопросы, самый дешёвый LLM-вызов — тот, которого не было.

Есть два уровня:

  • exact cache: идентичный prompt;
  • semantic cache: близкий по смыслу prompt через embeddings/vector search.

Это особенно хорошо работает для:

  • FAQ;
  • классификации похожих тикетов;
  • RAG-answering по повторяющимся вопросам;
  • support/ops assistants.
Не пускайте semantic cache на high-stakes запросы без guardrails. Для поддержки или FAQ это нормально, для медицинского, юридического или финансового ответа threshold и validation должны быть намного строже.

7. Reasoning routing: не включайте deep thinking везде

Одна из самых дорогих ошибок в 2026 — отправлять весь трафик в reasoning mode “на всякий случай”.

Хороший практический подход:

  • обычные extraction, rewrite, translation, FAQ — на cheap/general model;
  • code review, planning, root-cause analysis, policy-heavy decisions — на reasoning-capable layer;
  • high-stakes reasoning — только там, где цена ошибки выше цены токенов.

Это особенно важно потому, что accounting у reasoning-провайдеров разный:

  • у Gemini output price прямо включает thinking tokens;
  • у OpenAI reasoning не продаётся как отдельный универсальный line item на pricing page;
  • у DeepSeek дешёвый reasoning API может быть хорошим default, но тоже не должен быть обязательным для каждого запроса.

8. Простой порядок внедрения

Плюсы

  • Самый большой выигрыш обычно даёт model routing, а не косметическая правка промпта
  • Caching и batch дают очень чистую, измеримую экономию
  • Gemini Flash/Flash-Lite и DeepSeek делают дешёвый managed lane реально конкурентным
  • Output budgeting часто даёт быстрый win без падения качества

Минусы

  • Неправильный routing может ухудшить качество сильнее, чем сэкономить
  • Semantic cache требует аккуратного quality threshold
  • Reasoning-cost accounting отличается между провайдерами
  • Автоматическая compression не чинит плохой retrieval и плохую архитектуру prompt-а

Production-паттерны

Калькулятор стоимости

from dataclasses import dataclass

@dataclass
class ModelPricing:
    name: str
    input_per_1m: float
    output_per_1m: float
    cached_input_per_1m: float = 0.0

MODELS = {
    "gpt-5.4": ModelPricing("GPT-5.4", 2.50, 15.00, 0.25),
    "gpt-5.4-mini": ModelPricing("GPT-5.4 mini", 0.75, 4.50, 0.075),
    "gpt-5.4-nano": ModelPricing("GPT-5.4 nano", 0.20, 1.25, 0.02),
    "claude-sonnet-4.6": ModelPricing("Claude Sonnet 4.6", 3.00, 15.00, 0.30),
    "claude-haiku-4.5": ModelPricing("Claude Haiku 4.5", 1.00, 5.00, 0.10),
    "gemini-2.5-flash": ModelPricing("Gemini 2.5 Flash", 0.30, 2.50, 0.03),
    "gemini-2.5-flash-lite": ModelPricing("Gemini 2.5 Flash-Lite", 0.10, 0.40, 0.01),
    "deepseek-chat": ModelPricing("DeepSeek Chat", 0.28, 0.42, 0.028),
}

def calculate_cost(model: str, input_tokens: int, output_tokens: int, cached_tokens: int = 0) -> float:
    pricing = MODELS[model]
    regular_tokens = max(input_tokens - cached_tokens, 0)
    return (
        (regular_tokens / 1_000_000) * pricing.input_per_1m
        + (cached_tokens / 1_000_000) * pricing.cached_input_per_1m
        + (output_tokens / 1_000_000) * pricing.output_per_1m
    )

Anthropic prompt caching

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = """Ты ассистент поддержки.
Правила ответа:
- отвечай кратко
- не выдумывай политику
- при нехватке данных эскалируй оператору
"""

response = client.messages.create(
    model="YOUR_CURRENT_CLAUDE_MODEL_ID",
    max_tokens=512,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "Как вернуть товар?"}],
)

Простая routing-логика

def pick_model(task_type: str, risk_level: str) -> str:
    if task_type in {"faq", "classification", "simple_extraction"}:
        return "gpt-5.4-nano"
    if task_type in {"summary", "rewrite", "normal_rag"} and risk_level != "high":
        return "gpt-5.4-mini"
    if task_type in {"root_cause_analysis", "architecture_review", "policy_decision"}:
        return "gpt-5.4"
    return "gemini-2.5-flash"

Semantic cache

def maybe_use_cache(similarity: float, risk_level: str) -> bool:
    if risk_level == "high":
        return similarity >= 0.995
    return similarity >= 0.95

Практический шаблон аудита

ПромптCost audit
У нас support assistant: 50K запросов в день. Сейчас всё идёт в Claude Sonnet 4.6. Есть длинный policy prompt, FAQ часто повторяются, nightly evals крутятся realtime.

Составь план снижения стоимости без заметного падения качества.
Ответ модели
  1. Вынести длинный policy prompt в prompt caching.
  2. FAQ закрыть semantic cache.
  3. Классификацию и triage перевести на cheap lane.
  4. Nightly evals и enrichment отправить в Batch API.
  5. Оставить Sonnet 4.6 только на medium/high-complexity path.
  6. Проверить, не переплачиваете ли вы за слишком длинный output.

Проверьте себя

Проверьте себя

1. Какой рычаг чаще всего даёт самый большой выигрыш по стоимости?

2. Когда Batch API особенно уместен?

3. Почему нельзя строить cost dashboard по одной общей строке `reasoning tokens`?