Почему routing layer для оптимизации AI-затрат может сломать продукт: реальный кейс и архитектурные паттерны

Когда экономия превращается в катастрофу

Все гениальное просто. Routing layer — прослойка, которая решает, какую модель ИИ запустить для каждого запроса. Дешевую для простых задач, дорогую для сложных. Звучит как идеальная экономия? На бумаге — да. На практике — вы получаете каскадный отказ, который убивает пользовательский опыт и превращает ваш продукт в тыкву.

Я пережил этот ад в стартапе, который обслуживал 4 миллиона активных пользователей и обрабатывал 200 000 запросов в день. Мы гордились своей умной маршрутизацией между GPT-5, Claude Opus 4 и дешевым кастомным Mixtral-инстансом. Экономили до 40% бюджета на inference. А потом все рухнуло — не в день релиза, а спустя полгода, когда продукт был уже на пике. Вот как мы вляпались и что из этого вынесли.

1 Иллюзия умного классификатора

Routing layer (или AI Router) — это обычно легковесная модель-классификатор, которая по промпту решает, куда направить запрос. Мы обернули это в NestJS сервис с очередями (подробнее про такой подход — в статье Прокачай свой AI-бэкенд: пишем LLM-роутер на NestJS). В тестах классификатор показывал 95% accuracy. Но accuracy — это ловушка. Когда 5% самых дорогих и сложных запросов улетают на дешевую модель, пользователи получают чушь. И эти 5% превращаются в 15% негативных отзывов и 25% оттока.

Мы попали в Pareto trap: попытка сэкономить последние 10% затрат заставила нас положить на алтарь надежности. Классификатор сам стал SPOF (single point of failure). Он падал под пиковой нагрузкой, и весь трафик шел в fallback — на самую дорогую модель. В деньгах это было катастрофой, но фатальным оказалось то, что роутер начал отваливаться по таймаутам, и мы теряли запросы.

Анатомия треша: что пошло не так

Вот типичная архитектура, которую мы видели в сотне статей и которую скопировали:

• Запрос от клиента → API Gateway → Routing layer (классификатор) → одна из моделей
• Routing layer — отдельный микросервис на Python с FastAPI, который загружает маленький BERT-подобный классификатор
• Кэширование результатов классификации (по хешу промпта)
• Фоллбэк: если роутер недоступен, отправляем на самую мощную модель (GPT-5)

На старте все работает. Но когда у вас 2000 RPS, а классификатор требует 50 мс на каждый промпт (без кэша), латентность удваивается. Кэш помогает только для повторяющихся запросов, а их у нас было 30%. Остальные 70% — уникальные, каждый раз классифицируются заново. В итоге при пике мы получали 500 ошибок от роутера, потому что он не справлялся с очередью.

Фоллбэк на GPT-5 — это был suicide pill. Сначала мы думали: ну ок, раз в час слетает, но клиенты не замечают. Но когда роутер начал отваливаться на 5-10 минут, счет за LLM вырос в 4 раза. А потом пришел DevOps и сказал: либо вы решаете проблему, либо мы отключаем premium-модель.

Архитектурные паттерны, которые нас спасли

После двух недель крови и код-ревью мы перешли на другой подход. Расскажу три паттерна, которые в итоге стабилизировали систему.

2 Контекстно-зависимая маршрутизация (Context-Aware Routing)

Вместо того чтобы классифицировать каждый запрос изолированно, мы начали учитывать историю сессии пользователя. Если пользователь уже задавал сложные вопросы, вероятность того, что новый запрос тоже сложный, резко возрастает. Алгоритм:

• Ведите профиль сессии: средняя длина промпта, количество витков диалога, тема (определяется быстрым классификатором один раз)
• Для “умных” пользователей — сразу на мощную модель, без повторной классификации
• Для новых — используйте lightweight-модель (например, Llama 4 Scout), но с порогом уверенности: если модель сама оценивает свою уверенность < 0.7, то запрос уходит на реклассификацию

Этот паттерн описан в статье AI Router для мобильного приложения: как не разориться на моделях и не потерять качество. Мы реализовали его, и нагрузка на классификатор упала на 40%, а точность маршрутизации выросла.

3 Двухуровневая архитектура с быстрым путём

Классический anti-pattern — один роутер для всего. Мы разбили на два уровня:

• L1 (молниеносный): простые эвристики + маленькая модель (типа DistilBERT) — работает за 5-10 мс. Направляет запрос либо на дешевую модель, либо в L2.
• L2 (точный): более тяжелая модель-классификатор (например, Gemini 2 Flash в режиме классификации) — запускается только для сомнительных случаев.

L1 занимается routing layer в изначальном понимании, но L2 — это контроллер качества. Если L1 ошибся (судя по метрикам downstream), запрос автоматически реклассифицируется и переотправляется. Так мы снизили ошибки классификации с 5% до 0.7% без увеличения latency для 80% запросов.

4 Паттерн Adaptive-K на уровне маршрутизации

Вдохновившись техникой Adaptive-K Routing для MoE-моделей (см. гайд по Adaptive-K), мы применили идею динамического выбора K экспертов к routing layer. Вместо бинарного выбора (дешевая/дорогая модель) мы выстроили пул из 4-5 моделей разного размера и стоимости. Роутер назначает каждой запросу score-вектор и запускает top-K моделей, результаты агрегируются голосованием или выбирается наиболее уверенный. Это увеличило cost на 15% по сравнению с простым бинарным выбором, но устранило catastrophic failures — при ошибке одной модели другая может исправить.

Pareto trap и парадокс Джевонса

Routing layer — это классический пример Pareto trap. Вы гоняетесь за последними 10-20% экономии и создаете хрупкую систему. А когда внезапно растет трафик (пользователи полюбили ваш продукт), routing layer становится бутылочным горлышком. Вы начинаете его хардкодить, добавлять исключения, и через полгода он превращается в Big Ball of Mud.

Более того, срабатывает парадокс Джевонса в AI-версии: экономия на моделях стимулирует пользователей генерировать больше запросов, и общее потребление ресурсов (а значит, и затраты) растет. Мы заметили: после внедрения роутинга среднее количество запросов на пользователя выросло на 30%, а bill — на 10% (да, мы тратили меньше на один запрос, но их стало больше). Про этот эффект детально написано в Парадокс Джевонса в AI: как оптимизация моделей ведет к дефициту железа.

Как не наступить на те же грабли: checklist

На основе своего опыта и последних трендов 2026 года (сейчас мы уже используем GPT-6, Claude Opus 5, Gemini 2 Ultra, Llama 4 и кастомные Mixtral-кластеры) я составил чек-лист для тех, кто хочет внедрить routing layer без экзистенциальных кризисов:

1. Всегда имейте два роутера: основной и shadow (теневой). Shadow роутер работает параллельно, но его решения не используются — только логируются. По логам вы выявляете drift классификатора и переобучаете его на свежих данных.
2. Не кластеризуйте роутер как монолит. Используйте distributed routing: каждый инстанс обработки запроса имеет свой локальный классификатор (можно синхронизировать через etcd или Redis). Это защищает от каскадных отказов.
3. Fallback — никогда на самую дорогую модель! Лучше используйте очередь с дропом запросов (rate limiting) или простой rule-based роутер (по длине промпта и ключевым словам). Да, он будет менее точным, но зато предсказуемым.
4. Мониторьте не только latency и cost, но и пользовательские метрики: NPS, retention, количество переотправок. Резкое падение NPS — первый признак того, что роутер начал ошибаться.
5. Обновляйте классификатор каждую неделю. Мы обучали его на реальном трафике (собранные пары промпт-идеальная модель). Без этого accuracy падает с 95% до 80% за месяц из-за дрифта пользовательского поведения.

Кстати, про подготовку инфраструктуры под такие нагрузки — обязательна AI-Ready инфраструктура. Без быстрых сетей и low-latency storage routing layer будет тормозить сам себя.

И последнее. Если вы пишете routing layer для IoT-решений (а такие задачи тоже бывают — Когда IoT встречает AI), то latency становится критическим. Там наш двухуровневый паттерн сработал идеально, но пришлось отказаться от тяжелого классификатора в пользу эвристик.

Подписаться на канал