TheRouter.aiTheRouter.ai
← Все статьи

Оптимизация стоимости LLM API через smart routing: практические стратегии на 2026 год

Практический guide для инженерных команд: как снижать расходы на LLM API с помощью routing по сложности задач, fallback, prompt caching, batch-путей и бюджетных guardrails — без обещаний 'самой дешевой' модели для каждого запроса.

· TheRouter

Короткий ответ: самый безопасный способ снизить стоимость LLM API в 2026 году — не отправлять каждый request в модель с минимальной ценой за token. Лучше маршрутизировать каждый workload к самому дешевому приемлемому outcome: небольшие модели для детерминированных low-risk задач, более сильные модели там, где retry и review стоят дорого, prompt caching для повторяющихся prefix, batch API для offline jobs и fallback для надежности при rate limit или сбое provider.

Этот guide уже, чем наш cost-per-outcome routing framework. Там описана метрика. Здесь мы превращаем ее в routing plan, который можно внедрить через OpenAI-compatible gateway вроде TheRouter. Формулировка важна: routing может снижать waste, но gateway не может гарантировать самый дешевый результат для каждого prompt, provider и дня.

OpenAI-совместимость означает, что провайдер предоставляет endpoint chat-completions, чей контракт запроса и ответа достаточно близок к API OpenAI, чтобы немодифицированный вызов OpenAI SDK работал после замены трёх значений: API key, base URL, название модели. Минимальная поверхность на практике —POST /v1/chat/completions с messages, model и потоковым ответом в форме OpenAI.

Начните с четырех рычагов стоимости

Расходы на LLM обычно двигают четыре фактора:

  1. Model choice — маленькие или open-weight модели могут быть намного дешевле за token, но иногда требуют больше retry.
  2. Provider path — OpenAI, Anthropic, DashScope, SiliconFlow и Google отличаются pricing, rate limits, region и caching rules.
  3. Request shape — длинные system prompts, большие tool schemas, verbose output и повторяющийся context часто стоят дороже, чем кажется.
  4. Execution mode — realtime, cached, batch и fallback paths имеют разную экономику.

Если оптимизировать только первый пункт, получится красивая таблица и все еще дорогая production-система. Практическая цель — сопоставить все четыре рычага с workload.

Используйте routing matrix, а не один global default

Мы обычно делим traffic на четыре bucket до настройки provider.

Workload bucketПримерыГлавный cost riskRouting strategy
Simple deterministicclassification, extraction, tag cleanupпереплата за простую работуlow-cost model и короткий output
Standard assistantchat answers, support drafts, summarizationverbose output и повторный contextmid-tier models и cache-friendly prompt
Complex reasoningcode review, agent planning, legal/financial analysisretries и human reviewstronger models first; сравнение cost per accepted answer
Offline bulkevals, enrichment, document backfillsrealtime price для non-realtime работыprovider batch APIs, если supported

Это также граница против cannibalization: не повторяем абстрактный CPO-аргумент из framework post. Здесь вопрос практический: какой bucket идет в какой provider/model path и какой signal переводит его в другой bucket.

Strategy 1: routing по сложности задачи

Task-complexity routing дает высокий leverage, потому что избегает двух крайностей: все requests в frontier model или все requests в дешевую модель, которая тихо проваливает качество.

Минимальный rule set может выглядеть так:

export function chooseRoute(job: {
  task: "classify" | "summarize" | "code_review" | "agent_plan";
  inputTokens: number;
  latencyTier: "realtime" | "offline";
  qualityRisk: "low" | "medium" | "high";
}) {
  if (job.latencyTier === "offline") return "batch-mid-tier";
  if (job.qualityRisk === "high") return "premium-reasoning";
  if (job.task === "classify" && job.inputTokens < 4000) return "low-cost-fast";
  return "standard-balanced";
}

В TheRouter сохраняйте OpenAI-compatible API shape и принимайте это решение до model id, который отправляется через base_url. Корректный capability claim прост: TheRouter routes OpenAI-compatible requests through configured providers и может поддерживать provider/model routing и fallback, когда live product path это поддерживает. Не обещайте, что route всегда самый дешевый.

Strategy 2: fallback как reliability insurance

Fallback экономит деньги, когда предотвращает failed work, а не когда слепо прыгает к самой дешевой token price. Неудачный realtime request может вызвать retry, support ticket или ручной workaround. Это тоже cost.

Используйте fallback для таких случаев:

  • provider 429 или quota exhaustion;
  • временные latency spikes;
  • model-specific tool-call failures;
  • regional endpoint incidents;
  • premium model недоступна для high-risk задачи.

Безопасная fallback policy называет business goal:

{
  "primary": "premium-reasoning",
  "fallbacks": ["standard-balanced", "regional-backup"],
  "retry_budget": 1,
  "fallback_reason": ["rate_limit", "timeout", "provider_error"]
}

Детали failure modes лучше вынести в LLM API fallback routing guide и AI API rate-limit comparison. Этот post про cost strategy, а не про каждую 429-ситуацию.

Strategy 3: повторный context отправьте в caching

Prompt caching — место, где request shape встречается с routing economics. OpenAI docs говорят, что eligible requests на recent models используют prompt caching автоматически, matching делается по exact prefix, а usage показывает cached tokens; OpenAI Batch API дает 50% lower cost для async jobs с 24-hour turnaround. Anthropic docs показывают cache write/read pricing, 5-minute и 1-hour cache writes, а Message Batches API снижает usage price на 50%. DashScope docs описывают explicit context cache с 125% write / 10% hit pricing, implicit cache с 20% cached input pricing и OpenAI-compatible batch calls за 50% realtime inference price. SiliconFlow публикует per-million-token pricing, cached-input columns для ряда моделей и rate-limit metrics вроде RPM и TPM.

Implementation rule простой: stable content first.

GOOD: system policy + tool schema + repository summary + user question
BAD: user question + changing examples + system policy + tool schema

Если static prefix большой, сначала тестируйте prompt caching, потом меняйте provider. Если workload offline, проверьте provider batch path до оплаты synchronous rates.

Strategy 4: budget через stop-loss rules

Cost controls плохо работают, если они только предупреждают после неправильного invoice. Добавьте stop-loss rules в routing layer:

  • max output tokens per route;
  • max retries per route и error class;
  • daily spend budget per tenant или workspace;
  • downgrade rule для low-risk traffic после threshold;
  • human approval для high-cost batch jobs;
  • logging для route, model, provider, cached_tokens, retry_count, accepted_outcome.

Если TheRouter имеет verified billing/accounting surfaces в live product path, используйте их для сверки provider invoices с application-level cost per workflow. Если surface не implemented или не verified, формулируйте уже: логируйте route metadata и сравнивайте с provider usage exports.

Практический rollout plan

Начните с одного workflow, не со всей платформы.

  1. Выберите high-volume workflow с измеримым success criteria.
  2. Запишите seven-day baseline: token spend, retry rate, latency, human review time и accepted outputs.
  3. Разделите traffic на четыре bucket выше.
  4. Включайте одну optimization за раз: model tiering, затем caching, затем batch, затем fallback.
  5. Откатите route, если token cost упал, но rejected outputs или review time выросли.

Главная метрика — не “monthly API bill decreased”. Главная метрика — “accepted outcomes per dollar increased без поломки latency и quality”.

Provider notes на июль 2026

ProviderCost lever для первого тестаSource-backed caveat
OpenAIautomatic / explicit prompt caching; Batch APIbatch подходит для async work с 24-hour completion window
Anthropiccache TTL selection; Message Batches APIbatch requests async, часть parameters unsupported
DashScoperegion-aware Qwen pricing; context cache; OpenAI-compatible batchbatch и context-cache discounts не суммируются
SiliconFlowlow-cost open-weight routes; cached-input modelsrate limits зависят от model/account tier; free models имеют fixed limits
Google Geminicontext caching и batch где availableперед launch проверьте current region и model pricing

Production checklist

  1. Меняйте три значения, а не три SDK. Замените api_key, base_url и model в существующем клиенте OpenAI. Код запроса и ответа оставьте неизменным.
  2. Сопоставьте model ID явно. ID модели у целевого провайдера почти никогда не совпадает с OpenAI ID. Держите словарь { openai_id: target_id } вне бизнес-логики.
  3. Проверьте формат streaming. SSE-чанки должны соответствовать контракту OpenAI: data: {...} + data: [DONE]. Прогоните один streaming вызов до продакшена.
  4. Проверьте rate-limit заголовки. Некоторые провайдеры не возвращают x-ratelimit-*. Добавьте обёртку с безопасным дефолтом.
  5. Оставьте путь отката. Раскатайте замену под feature flag, гоняйте оба endpoint в shadow-режиме 24 часа, затем переключайтесь.

Перед тем как назвать cost-optimized route готовым, проверьте:

  • у каждого route есть named workload bucket;
  • у каждого fallback есть allowed error class;
  • у каждой pricing table есть retrieval date;
  • caching optimization показывает hit rate, а не только expected discount;
  • у каждого batch job есть owner, max input file size и cancellation path;
  • каждый provider/model claim подтвержден docs, code или live request evidence.

Sources

Помощь и контакты