Зачем маршрутизировать LLM-запросы

Обучающий материал: от проблемы к работающему решению. Каждая глава строится на предыдущей. В конце: сквозной пример и чек-лист, с которым можно начинать строить.

Проблема: одна модель на все запросы

Представь: ты запустил AI-продукт. Чат-бот для customer support, или coding assistant, или аналитический инструмент. У тебя 10,000 запросов в день.

Перед тобой выбор: какую модель использовать?

Это ложная дилемма. На практике ~70% запросов в большинстве продуктов простые: фактические вопросы, повторяющиеся сценарии, короткие уточнения. И только ~30% действительно требуют мощной модели.

Идея routing: не человек выбирает модель, а система автоматически направляет каждый запрос к оптимальной модели, исходя из его сложности и типа.

Как работает routing (30 секунд)

Весь механизм сводится к четырем шагам:

1. Классифицировать входящий запрос: какая сложность (simple / medium / complex)? какой тип (factual / reasoning / creative / code)?
2. Маршрутизировать: по конфигу (YAML-файл) определить, какая модель обрабатывает эту комбинацию сложности и типа
3. Подстраховать: если выбранная модель недоступна (timeout, rate limit, outage), автоматически переключить на fallback
4. Измерить: логировать каждый запрос: какая модель использована, сколько токенов, стоимость, латентность, качество

Дальше мы разберем каждый шаг. Начнем с экономики: нужно понимать, между чем мы выбираем.

Глава 1: Экономика моделей

Прежде чем строить router, нужно понимать: какие модели существуют, сколько стоят, и где разница в качестве оправдывает разницу в цене.

Ландшафт моделей (начало 2026)

У каждого провайдера есть линейка от дорогих и мощных до дешевых и быстрых. Это не случайность: именно этот спектр делает routing возможным.

Цены: input / output за 1M токенов.

Где разница в качестве критична, а где нет

Это центральный вопрос routing. Не "какая модель лучше?", а "на каких задачах дешевая модель выдает результат, неотличимый от дорогой?"

Данные LMSYS Chatbot Arena (крупнейший crowdsourced бенчмарк, где реальные пользователи вслепую сравнивают ответы двух моделей) подтверждают: на factual Q&A и extraction mid-tier модели набирают Elo-рейтинг, статистически неотличимый от flagship. Разрыв проявляется на hard prompts, coding и reasoning.

Как считать стоимость запроса

LLM API тарифицируют по токенам. Формула простая:

Cost = (input_tokens x input_price / 1M) + (output_tokens x output_price / 1M)

Но есть нюанс: output-токены в 3-5x дороже input. Причина техническая: генерация output требует последовательных вычислений, а input обрабатывается параллельно.

Типичные размеры запросов

Prompt caching и batch API: дополнительная экономия

Помимо routing, есть два механизма снижения стоимости, которые стакаются с ним:

Prompt caching

Если ваш system prompt или контекст повторяется между запросами (а он почти всегда повторяется), провайдер может кэшировать его и брать за повторное чтение в 10x меньше.

Batch API

Если запросы не нужно обрабатывать real-time (eval, аналитика, bulk processing), batch API дает 50% скидку у всех трех провайдеров. Комбинация batch + caching может дать до 95% экономии на input-токенах.

Глава 2: Как классифицировать запросы

Routing работает, только если мы можем понять, какой запрос перед нами: простой или сложный, фактический или творческий. Это задача классификации.

Есть три подхода, от простого к сложному. Каждый следующий точнее, но дороже и медленнее. Смысл в том, чтобы выбрать подход, соответствующий стадии продукта.

Подход 1: Rule-based (правила)

Самый простой: набор if/else правил на основе наблюдаемых свойств запроса.

def classify(prompt: str) -> str:
    tokens = prompt.split()

    # Длина как прокси сложности
    if len(tokens) < 15:
        complexity = "simple"
    elif len(tokens) < 80:
        complexity = "medium"
    else:
        complexity = "complex"

    # Ключевые слова для категории
    code_signals = ["code", "function", "debug", "error", "```"]
    if any(s in prompt.lower() for s in code_signals):
        category = "code"
    elif any(s in prompt.lower() for s in ["explain", "compare", "analyze", "why"]):
        category = "reasoning"
    else:
        category = "factual"

    return complexity, category

Когда хватит: MVP, первая неделя разработки, узкий домен с предсказуемыми запросами, или как первый слой в гибридном подходе.

Подход 2: Embedding-based (по похожести)

Идея: если у тебя есть примеры запросов каждой категории, можно находить ближайшую категорию для нового запроса по семантической близости.

Как это работает

1. Готовишь примеры: 20-50 запросов на категорию с правильными метками. "Какой курс доллара?" → simple/factual. "Проанализируй динамику за 3 года" → complex/reasoning.
2. Эмбеддишь: каждый пример превращается в числовой вектор через sentence-transformer модель (например, all-MiniLM-L6-v2: бесплатная, работает локально).
3. При запросе: входящий промпт эмбеддится, считается cosine similarity со всеми примерами, запрос назначается категории ближайших (kNN).

Готовая реализация: Semantic Router (MIT, open-source). Снижает latency классификации с ~5000ms (LLM) до ~100ms.

Когда использовать: production-система с известными категориями запросов. Когда уже собрал достаточно данных, чтобы набрать по 20+ примеров на категорию.

Подход 3: LLM-as-classifier

Используем саму LLM (дешевую и быструю) для классификации запроса. По сути, задаем LLM вопрос: "какой это тип запроса?"

Zero-shot (без примеров)

System: Classify the user query.
Complexity: simple | medium | complex
Category: factual | reasoning | creative | code
Return only JSON: {"complexity": "...", "category": "..."}

User: {query}

Промпт короткий, latency минимальная (200-500ms на Haiku). Хорошо работает, когда категории интуитивно понятные. Accuracy: 70-85%.

Few-shot (с примерами)

Добавляем 3-10 примеров на категорию прямо в промпт. Accuracy растет до 80-92%, но промпт становится длиннее, а значит каждая классификация дороже.

Как выбрать подход: decision framework

Глава 3: Routing-паттерны

Классификация определила, что запрос: medium/reasoning. Теперь нужно решить, какой модели его отправить. Это решение определяется routing-паттерном.

Базовый routing: конфиг-маппинг

Простейший вариант: YAML-файл, который маппит комбинации сложности и типа на конкретные модели.

routing:
  simple:
    factual: haiku-4.5
    reasoning: haiku-4.5
    creative: sonnet-4.6
    code: haiku-4.5

  medium:
    factual: sonnet-4.6
    reasoning: sonnet-4.6
    creative: sonnet-4.6
    code: sonnet-4.6

  complex:
    factual: sonnet-4.6
    reasoning: opus-4.6
    creative: opus-4.6
    code: opus-4.6

Это работает и покрывает 80% потребностей. PM может менять конфиг без деплоя. Но есть паттерны, которые дают больше.

Cascade routing: попробуй дешевую, эскалируй если нужно

Идея: не выбирать модель заранее, а сначала отправить запрос дешевой модели. Если ее ответ "достаточно хорош", возвращаем его. Если нет, эскалируем на дорогую.

Как оценивать "достаточно хорош"

• Logprobs: если API возвращает вероятности токенов, низкая средняя вероятность = модель не уверена. Хорошо для factual, хуже для creative.
• LLM-as-judge: маленькая модель оценивает ответ большой. Надежнее, но добавляет вызов.
• Self-reported confidence: попросить модель оценить себя (1-10). Ненадежно для слабых моделей.
• Heuristics: длина ответа, наличие "I'm not sure", структура.

ETH Zurich paper (2024) доказывает: комбинация routing + cascading в единый фреймворк теоретически оптимальна по сравнению с каждой стратегией по отдельности.

Confidence-based routing: страховка от ошибок классификатора

Улучшение базового routing: классификатор выдает не только метку, но и confidence score. Routing учитывает оба:

• Confidence высокий (>0.85) → отправляем модели по конфигу
• Confidence низкий (<0.5) → safety net: отправляем на более мощную модель, чем по конфигу
• Confidence средний → зависит от cost tolerance

Это простое улучшение, которое значительно снижает under-routing (сложные запросы на дешевую модель). Имплементируется за час поверх базового routing.

RouteLLM и другие решения

RouteLLM (open-source, LMSYS)

Фреймворк от команды Chatbot Arena. GitHub, paper.

Отличие от нашего подхода: RouteLLM обучен на 80K+ реальных human preference comparisons из Arena. Не классифицирует запрос, а напрямую предсказывает, какой модели пользователь предпочтет ответ.

Лучший результат: Matrix Factorization роутер достигает 95% качества GPT-4, отправляя на GPT-4 только 14% запросов. Остальные 86% идут на дешевую модель. Это 85% снижение cost на MT-Bench.

Ограничение: роутит между ровно двумя моделями (strong vs weak). Для multi-model routing (3+ модели) нужна кастомизация.

Коммерческие решения

Как выбрать паттерн: decision framework

Глава 4: Надежность

Routing добавляет зависимость от нескольких провайдеров. Каждый из них может упасть, затормозить, или вернуть ошибку. Если не подстраховаться, routing принесет больше проблем, чем решит.

Три слоя защиты, от мелкого к крупному:

Слой 1: Fallback chains

Для каждой модели определяешь, кто подхватывает при отказе:

# routing config
complex:
  primary: claude-opus-4.6
  fallback:
    - gpt-5.4           # same-tier: другой провайдер
    - claude-sonnet-4.6  # downgrade: слабее, но работает
  timeout_ms: 30000

simple:
  primary: claude-haiku-4.5
  fallback:
    - gpt-4.1-nano
  timeout_ms: 5000

Четыре уровня деградации (в порядке приоритета):

1. Same-tier: Opus → GPT-5.4. Другой провайдер, аналогичное качество.
2. Downgrade: Opus → Sonnet. Слабее, но ответ будет.
3. Cached: если был похожий запрос недавно, вернуть кэшированный ответ.
4. Graceful failure: понятное сообщение пользователю, не stack trace.

Слой 2: Circuit breaker

Проблема: если провайдер лёг на 10 минут, fallback chain будет каждый раз ждать timeout primary-модели (30 секунд) прежде чем переключиться. 10,000 запросов x 30 сек ожидания = пользователи уходят.

Circuit breaker решает это. Паттерн из электротехники: когда downstream-сервис нездоров, "выбиваем автомат" и перестаем к нему обращаться.

Три состояния

class CircuitBreaker:
    def __init__(self, provider, threshold=5, timeout=30):
        self.provider = provider
        self.state = "closed"
        self.failures = 0
        self.threshold = threshold
        self.timeout = timeout
        self.opened_at = None

    def call(self, prompt):
        if self.state == "open":
            if time.time() - self.opened_at > self.timeout:
                self.state = "half_open"
            else:
                raise CircuitOpen(self.provider)

        try:
            result = self.provider.complete(prompt)
            if self.state == "half_open":
                self.state = "closed"
                self.failures = 0
            return result
        except (Timeout, RateLimit, ServerError) as e:
            self.failures += 1
            self.opened_at = time.time()
            if self.failures >= self.threshold:
                self.state = "open"
            raise

Готовые библиотеки: PyBreaker, circuitbreaker.

Слой 3: Retry с backoff и timeout management

Порядок действий при ошибке:

1. Retry с exponential backoff (1s, 2s, 4s). Тот же провайдер, max 2-3 попытки. Только для transient errors.
2. Fallback на другой провайдер: та же модель через другой endpoint (Anthropic → AWS Bedrock).
3. Fallback на другую модель: Opus → Sonnet → Haiku.
4. Circuit breaker: если провайдер стабильно падает, отключаем его на cooldown.

Timeout по классам моделей

Streaming + heartbeat: при streaming, если нет новых токенов 5+ секунд, считай ответ "зависшим" и переключайся. Это ловит partial failures, которые обычный timeout пропускает.

# Полная цепочка обработки ошибок
Request -> Primary (timeout T)
  -> Retry x2 с backoff (если transient error)
    -> Same model, другой провайдер (timeout T/2)
      -> Fallback model (timeout T)
        -> Graceful error + cached response if available

Глава 5: Измерение и observability

Routing внедрен, fallback работает. Но без observability ты не знаешь: экономит ли routing? Где классификатор ошибается? Деградирует ли качество?

Без данных невозможно итерировать. А итерация: это то, что отличает "поставил routing" от "routing приносит результат".

Какие метрики трекать и зачем

Не все метрики одинаково важны. Вот приоритеты:

Tier 1: бизнес-метрики (показываешь на review)

Tier 2: операционные (смотришь каждый день)

Tier 3: аналитические (смотришь раз в неделю)

Как оценивать качество в production

Три подхода (используй все три):

1. Heuristic checks (100% трафика): ответ не пустой? JSON парсится? Код компилируется? Нет отказа? Дешево, ловит грубые проблемы.
2. LLM-as-judge (5-10% sample): дешевая модель оценивает ответы по rubric (helpfulness, relevance, accuracy). Score 0-1. Alignment с human judgment: до 85%.
3. User feedback: thumbs up/down. Implicit: retry = плохо, copy = хорошо. Самые ценные данные, но мало и biased.

Готовые инструменты

Прежде чем строить свое, стоит знать, что уже существует:

Своя observability: что логировать

SQLite-схема, адаптированная для multi-model router:

CREATE TABLE requests (
    id TEXT PRIMARY KEY,
    timestamp_utc TEXT NOT NULL,

    -- Что пришло
    prompt TEXT NOT NULL,
    prompt_tokens INTEGER,

    -- Как классифицировали
    complexity TEXT,                -- simple/medium/complex
    category TEXT,                  -- factual/reasoning/creative/code
    classifier_strategy TEXT,       -- rules/embeddings/llm_classifier
    classifier_confidence REAL,     -- 0.0-1.0

    -- Куда отправили
    target_model TEXT NOT NULL,
    fallback_used BOOLEAN DEFAULT 0,
    fallback_model TEXT,

    -- Что получили
    response TEXT,
    output_tokens INTEGER,
    status TEXT DEFAULT 'success',  -- success/error/timeout/fallback
    error_type TEXT,

    -- Перформанс
    classification_latency_ms INTEGER,
    llm_latency_ms INTEGER,
    total_latency_ms INTEGER,

    -- Деньги
    input_cost REAL,
    output_cost REAL,
    total_cost REAL,

    -- Качество (заполняется асинхронно)
    quality_score REAL,
    user_feedback INTEGER           -- -1/0/1
);

Ключевые views дашборда

1. KPI cards (top): total requests, total cost, cost savings %, avg latency, error rate
2. Cost breakdown by model (stacked bar, daily): видишь, куда уходят деньги
3. Model distribution (pie/donut): % запросов на каждую модель. Drift = проблема.
4. Latency p50/p95 (line, per model): деградация видна сразу
5. Routing efficiency (comparison): actual cost vs single-model baseline
6. Request log (table): searchable, filterable, click to expand

Сквозной пример: от проблемы до результата

Соберем все вместе. Один сценарий, который проходит через каждую главу.

Шаг 1: Анализ запросов

Берем выборку из 500 запросов за последнюю неделю. Размечаем вручную (или с помощью LLM + spot-check):

Вывод: 45% запросов (простые, фактические) не требуют Sonnet. Еще 35% (medium) можно попробовать на дешевой модели с confidence-based escalation.

Шаг 2: Routing config

routing:
  simple:
    factual: claude-haiku-4.5    # $1/$5
    reasoning: claude-haiku-4.5
    creative: claude-sonnet-4.6
    code: claude-haiku-4.5

  medium:
    factual: claude-sonnet-4.6   # $3/$15
    reasoning: claude-sonnet-4.6
    creative: claude-sonnet-4.6
    code: claude-sonnet-4.6

  complex:
    factual: claude-sonnet-4.6
    reasoning: claude-opus-4.6   # $5/$25
    creative: claude-opus-4.6
    code: claude-opus-4.6

fallback:
  claude-opus-4.6: [gpt-5.4, claude-sonnet-4.6]
  claude-sonnet-4.6: [gpt-4.1, claude-haiku-4.5]
  claude-haiku-4.5: [gpt-4.1-nano]

Шаг 3: Классификация

MVP: rule-based (длина + keywords). Accuracy ~70%. Через неделю, когда наберется 200+ размеченных запросов: embedding-based через Semantic Router. Accuracy ~85%.

Шаг 4: Считаем экономику

Средний запрос: 2,000 input + 800 output tokens.

И это без prompt caching (ещё -20-30% на input) и без batch API. С ними реалистично дойти до 60%+ экономии.

Шаг 5: Что на дашборде

Через неделю работы router показывает на дашборде:

• Model distribution: Haiku 45%, Sonnet 40%, Opus 15%. Совпадает с ожиданием.
• Cost savings: 44% vs all-Sonnet baseline.
• Quality (LLM-judge, 10% sample): 0.87 routed vs 0.89 all-Sonnet. Delta 2.2%. Приемлемо.
• Fallback rate: 0.3%. Здоровая система.
• Classifier confidence: 82% запросов с confidence >0.8. 6% с confidence <0.5 (зона для улучшения).

Action item: 6% запросов с low confidence. Посмотреть, что это за запросы, добавить примеры в embedding set, пересчитать accuracy.

Итог: что ты теперь знаешь и что делать дальше

Карта знаний

Чек-лист: порядок действий

Ресурсы для углубления

Papers

• RouteLLM: Learning to Route LLMs (LMSYS, 2024). Главный paper по теме. Четыре реализации роутера, 85% cost reduction.
• Unified Cascade-Routing (ETH Zurich, 2024). Доказательство оптимальности гибрида cascade + routing.
• "Doing More with Less" (Feb 2025). Наиболее полный survey по LLM routing.
• ZeroRouter (Jan 2025). Model-agnostic routing без model-specific данных.

Open-source инструменты

• RouteLLM: framework для learned routing (LMSYS)
• Semantic Router: embedding-based routing (MIT)
• BEST-Route: adaptive model + sample selection (Microsoft)
• PyBreaker: circuit breaker для Python
• Langfuse: open-source LLM observability
• Helicone: LLM proxy с observability

Коммерческие платформы

• Martian: routing через mechanistic interpretability
• Unify.ai: LLM optimization + dynamic benchmarks
• Not Diamond: routing + prompt adaptation

Бенчмарки и цены

• LMSYS Chatbot Arena: crowdsourced model ranking
• Artificial Analysis: LLM Leaderboard
• Pricing: Anthropic | OpenAI | Google

Guides

• Portkey: Retries, Fallbacks, Circuit Breakers
• LogRocket: LLM Routing in Production
• AWS: Multi-LLM Routing Strategies