Смерть монолитной LLM: почему выигрывает не тот, кто покупает флагман, а тот, кто строит сплит-роутинг

Продажа монолитного «суперинтеллекта» по премиальной цене за токен исчерпала себя как маржинальный B2B-бизнес. К середине 2026 года качество базовых языковых моделей выравнялось, а ценовые войны и развитие open-source экосистемы обесценили стоимость чистого генеративного токена.

Реальная добавочная стоимость и юнит-экономика коммерческих ИИ-продуктов переместились в инфраструктурный слой — динамические роутеры, которые каскадируют до 80% входящих запросов на малый кремний и лишь 20% эскалируют на дорогой фронтир.

Для современного enterprise-сегмента выбор «одной лучшей модели» превратился в устаревшую инженерную ошибку. В борьбе за юнит-экономику выигрывает не тот, кто переплачивает за флагманские API, а тот, кто относится к LLM как к взаимозаменяемому сырью и строит сложную архитектуру маршрутизации.

Маркетинг вендоров продолжает транслировать нарратив о бескомпромиссном лидерстве и борьбе за доли процентов в синтетических тестах. Однако прикладные замеры и опыт эксплуатации B2B-продуктов показывают, что разрыв между закрытыми флагманами и компактными или открытыми решениями сократился до погрешности в подавляющем большинстве повседневных enterprise-задач.

В прикладных сценариях — таких как извлечение данных, парсинг JSON, классификация обращений или генерация ответов по базе знаний в RAG-системах — компактные и средние модели показывают точность на уровне 93–97% относительно топовых закрытых API.

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

При отправке 100% клиентских запросов в монолитный флагманский API компания переплачивает десятикратно ради единиц процентов точности на редких краевых случаях. Данные публичных лидебордов и прикладных исследований зафиксировали плато: прирост показателей на 1–2% в бенчмарках больше не конвертируется в измеримый бизнес-эффект, из-за чего enterprise-заказчики перестали строить продуктовую стратегию вокруг обновления линейки одной конкретной LLM.

Монолитный выбор единственной модели для всех задач enterprise-системы стал неэффективен. Главные причины этого сдвига кроются в жесткой математике цен на вычисления и трансформирующейся экономике токенов.

За последние 18 месяцев стоимость обработки одного миллиона токенов на рынке упала в десятки раз. Причиной стал не только агрессивный демпинг со стороны технологических гигантов, но и архитектурные сдвиги — повсеместное внедрение Mixture-of-Experts с разреженной активацией и оптимизация инференса на уровне специализированных ускорителей.

Смещение стратегий отчетливо прослеживается на примере компании Meta, которая превратила открытые семейства Llama в инфраструктурный стандарт. Маржинальность провайдеров базовых моделей сгорает под давлением колоссальных капитальных затрат (CAPEX) на GPU-кластеры и обучение следующих поколений.

Разработчики закрытых API рискуют превратиться в операторов «тупой трубы», перепродающих вычислительные мощности с минимальной наценкой, пока основная норма прибыли уходит инфраструктурным оркестраторам.

Разница в стоимости вызовов между классами моделей достигает десятков раз. Любая попытка задействовать флагманские модели для выполнения простейшего парсинга или форматирования текста генерирует отрицательную юнит-экономику при масштабировании.

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

Сплит-роутинг (Split Routing) — это архитектурный паттерн, в котором входящий промпт проходит через предварительный слой оценки и направляется к наиболее дешевой модели с достаточным уровнем точности. Вся обработка строится не вокруг единого API, а вокруг сквозного оркестратора.

Входящий запрос первым делом попадает на классификатор интентов и сложности (Intent & Complexity Classifier). Это может быть легкий эвристический модуль на векторных эмбеддингах или малая ML-модель. За доли миллисекунд классификатор рассчитывает скор сложности и выбирает маршрут. В 80% случаев запрос уходит на Light Tier — компактную коммерческую или открытую модель, выполняющую парсинг, RAG-форматирование или базовую классификацию.

Если же классификатор определяет высокую сложность, или если легкая модель возвращает ошибку структурирования (провал валидации JSON), происходит эскалация на Frontier Tier (дорогой закрытый API). На каждом этапе системные инструкции приводятся к формату целевого движка через промпт-адаптеры.

Практика использования каскадных фреймворков (таких как RouteLLM) доказала: обученный на специализированных датасетах роутер-классификатор позволяет сохранить до 98% точности монолитного флагмана, сокращая общие операционные расходы на 70% и более.

Теоретические схемы каскадирования подкрепляются математическими расчетами совокупной стоимости владения для реальных коммерческих объемов трафика.

Для оценки финансовой эффективности рассмотрим юнит-экономику B2B SaaS-сервиса с объемом 10 000 000 запросов в месяц. Средние параметры запроса: 800 входных токенов (Input) и 200 выходных токенов (Output). Суммарный ежемесячный объем трафика составляет 8 миллиардов входных и 2 миллиарда выходных токенов.

В Сценарии А (Монолит) весь входящий поток направляется напрямую во фронтирный закрытый API:

• Затраты на Input: 8 000 * $2.50 = $20 000.
• Затраты на Output: 2 000 * $10.00 = $20 000.
• Совокупные расходы: $40 000 в месяц.

В Сценарии Б (Сплит-роутинг 80/20) 80% трафика обрабатывается малым классом моделей, а 20% эскалируется на фронтир:

• Затраты на Light Tier (80% объема): (6 400 * $0.15) + (1 600 * $0.60) = $960 + $960 = $1 920.
• Затраты на Frontier Tier (20% объема): (1 600 * $2.50) + (400 * $10.00) = $4 000 + $4 000 = $8 000.
• Затраты на инфраструктуру роутера (хостинг классификатора и система трейсинга): ~$500.
• Совокупные расходы: $10 420 в месяц.

Переход на сплит-роутинг обеспечивает экономию в 73.95% ($29 580 в месяц или $354 960 в год) при сохранении итоговой точности системы на уровне 96% от показателей монолитного флагмана.

Однако прямая финансовая выгода сопровождается архитектурными издержками, которые необходимо учитывать при проектировании.

Внедрение мультимодельной оркестрации создаёт технические компромиссы, требующие системного инженерного контроля. Переход от простой линейной схемы вызова API к каскадной всегда сопряжен с усложнением инфраструктуры.

Во-первых, опрос классификатора неизбежно создаёт оверхед по времени. Однако легкий классификатор отрабатывает за доли миллисекунд, а перенаправление 80% запросов на компактные модели снижает медианную задержку (p50 Latency) всей системы в 2–3 раза за счет высокой скорости генерации малых нейросетей.

Во-вторых, возникает проблема дрейфа промптов (Prompt Drift), когда инструкция под Claude дает сбои на Llama или GPT mini. Это компенсируется отказом от свободных текстов в пользу жестких схем с автоматической типацией (BAML, Pydantic).

В-третьих, усложняется отладка (Debugging Complexity), что требует сквозного трейсинга через Trace ID на каждом шаге каскада.

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

Процесс миграции с монолитного API на гибридную архитектуру маршрутизации требует последовательного выполнения инженерных шагов. Командам рекомендуется придерживаться следующего алгоритма:

• Провести аудит трафика: Собрать выборку из 1000–5000 реальных промптов и разметить их по классам сложности (извлечение данных, RAG, простой Q&A, сложный рефакторинг).
• Изолировать прямые вызовы API: Внедрить единый шлюз оркестрации (на базе LiteLLM, OpenRouter или собственного прокси-сервера), чтобы код приложения перестал напрямую зависеть от SDK конкретного вендора.
• Развернуть классификатор: Начать с базовых эвристик (длина контекста, регулярные выражения, тип интента), постепенно переходя на эмбеддинговые или ML-роутеры.
• Настроить каскадный Fallback: Задать автоматический сброс запроса на фронтирную модель в случае сетевых ошибок (5xx API), превышения таймаута или провала автоматической валидации ответа.
• Стандартизировать форматы ответа: Перевести обработку структурированных данных на схемы с жесткой типацией и автоматической повторной генерацией при ошибках парсинга.

Выполнение этих шагов позволяет снизить операционные расходы уже на первых этапах миграции. Постепенная отладка классификатора и фоллбэков дает возможность безопасно перевести систему в продакшен без риска для качества клиентского сервиса.

Языковая модель перестала быть продуктом — она стала сырьевым ресурсом. Борьба за верхние строчки в публичных бенчмарках осталась маркетинговым инструментом вендоров.

В реальном enterprise-секторе преимущество и маржинальность формируются на уровне оркестрации: в умении строить гибкие каскады, минимизировать стоимость успешного выполнения задачи (Cost-per-Successful-Task) и сохранять полную независимость от отдельных провайдеров.

Для тех, кто предпочитает графики вместо букв — вся суть статьи на одной картинке:

Выпустили аудиоверсию этого материала. Внутри — подробный разговор о том, как устроена архитектура сплит-роутинга, почему выбор «одной лучшей модели» стал инженерной ошибкой и как бороться с дрейфом промптов при каскадировании запросов между Light и Frontier сетками.

Слушайте нас на своих любимых подкаст-платформах.

• 👉 Слушать на Mave
• 👉 Слушать на Яндекс Музыке
• 👉 Слушать в Звуке
• 👉 Слушать на Pocket Casts