Каскад LLM: когда малая модель снижает TCO, а когда нет

Короткий вывод

Каскад из малой и большой LLM может заметно снизить стоимость инференса, но только если компания считает не долю запросов, отправленных в дешёвую модель, а стоимость принятого результата с учётом повторных вызовов, проверки и ошибок. Для малого и среднего бизнеса самый безопасный старт — не обученный «умный роутер», а правила риска, малая модель в теневом режиме и явный порог передачи сильной модели.

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

Что именно маршрутизировать

Есть два похожих, но экономически разных паттерна.

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

Второй — каскад. Сначала отвечает малая модель, затем валидатор решает, достаточно ли надёжен результат. Если нет, запрос вместе с контекстом уходит сильной модели. FrugalGPT описывает именно последовательный вызов: следующие модели включаются, пока ответ не сочтён достаточно надёжным. Такой подход проще объяснить бизнесу, но при частых отказах от первого ответа компания платит и за малую, и за большую модель, а пользователь ждёт обе.

Для процессов с разной ценой ошибки эти паттерны можно сочетать:

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

Модельный расчёт: экономия до и после цены ошибки

Ниже не рыночный тариф, а модель с явными допущениями. Компания обрабатывает 20 000 запросов в месяц. Внутренняя себестоимость одного вызова малой модели принята равной 0,35 рубля, сильной — 2,80 рубля, а маршрутизации и журналирования — 0,05 рубля на запрос. В эти ставки условно включены аренда или амортизация GPU, электричество и базовая эксплуатация; разработка интеграции считается отдельно.

Роутер отправляет 65% запросов малой модели. Из них 18% не проходят проверку и повторно обрабатываются сильной моделью.

Расчёт без цены незамеченной ошибки:

малая модель: 13 000 × 0,35 = 4 550 рублей;
сильная модель сразу: 7 000 × 2,80 = 19 600 рублей;
сильная модель после отказа каскада: 2 340 × 2,80 = 6 552 рубля;
роутер и трассировка: 20 000 × 0,05 = 1 000 рублей;
итого: 31 702 рубля вместо 56 000 рублей при обработке всех запросов сильной моделью.

На этом уровне экономия составляет 24 298 рублей, или около 43%. Выглядит убедительно — пока в модели нет стоимости неверно принятого ответа.

Малая модель окончательно обслужила 10 660 запросов. Допустим, 0,3% этих результатов прошли автоматическую проверку ошибочно, а средняя стоимость исправления одного такого случая — 300 рублей. Дополнительный ущерб равен примерно 9 594 рубля. Реальная экономия падает до 14 704 рублей, или примерно 26%.

При тех же допущениях точка безубыточности наступает, когда доля незамеченных ошибок среди принятых ответов малой модели приближается к 0,76%. Это главный управленческий вывод: даже редкая ошибка может съесть выгоду от дешёвого инференса, если она приводит к возврату, повторной работе менеджера или неверной операции в системе.

Универсальная формула месячной стоимости выглядит так:

`N × Crouter + N × p × Csmall + N × (1 − p + p × f) × Cstrong + N × p × (1 − f) × e × L`

где `N` — число запросов, `p` — доля маршрутизации в малую модель, `f` — доля последующего отказа и перехода к сильной модели, `e` — доля незамеченных ошибок среди принятых ответов, `L` — средняя стоимость такой ошибки.

Почему лабораторная экономия не равна вашему TCO

RouteLLM сообщает крупное снижение стоимости на MT Bench, MMLU и GSM8K при сохранении заданной доли качества сильной модели. Это важное доказательство принципа, но не готовое коммерческое предложение. Бизнес-задача отличается как минимум в пяти местах.

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

Во-вторых, стоимость локальной модели не линейна по токенам. Если для сильной модели зарезервирована отдельная GPU и она простаивает, уменьшение числа запросов не всегда уменьшает счёт. Экономия появляется, когда можно сократить аренду, повысить полезную загрузку общего кластера или отложить покупку следующей карты.

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

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

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

Минимальная архитектура без магии

Практичная схема для локального контура состоит из восьми узлов:

1. Шлюз аутентифицирует пользователя, применяет права доступа, удаляет запрещённые поля и присваивает идентификатор трассы.
2. Правила риска сразу исключают операции, которые нельзя отдавать слабой модели.
3. Роутер оценивает домен, длину, наличие инструментов, тип требуемого ответа и похожесть на размеченные примеры.
4. Малая модель создаёт ответ или структурированный результат.
5. Валидатор проверяет JSON-схему, обязательные поля, ссылки на источники, бизнес-правила и порог качества.
6. Сильная модель получает исходный запрос и необходимые данные, если первая попытка отклонена. Черновик слабой модели лучше не передавать автоматически: он может закрепить ошибку.
7. Человек принимает решения для высокорисковых и спорных случаев.
8. Трасса сохраняет выбранную модель, причину маршрута, токены, задержку, исход проверки и итоговое исправление без лишних персональных данных.

Какие данные собрать до переключения трафика

Нужен золотой набор не из случайных диалогов, а из слоёв, отражающих бизнес-риск:

простые типовые запросы;
длинные или многошаговые запросы;
редкие категории;
случаи с персональными и коммерчески чувствительными данными;
запросы, требующие инструмента или записи во внешнюю систему;
исторические ошибки и эскалации сотрудников.

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

Порог выбирают не по максимальной доле запросов малой модели. Строят кривую «стоимость — качество» и отдельно смотрят:

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

Что измерять в локальном инференсе

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

Если обе модели работают на одной GPU, пилот обязан проверить взаимное влияние очередей. Если на разных — считать стоимость зарезервированной мощности, а не только активные секунды. Для пакетного процесса можно заполнять дешёвую очередь ночью; для клиентского чата важнее запас по p95.

Приёмочный пилот на четыре недели

Первая неделя — собрать 1 000–3 000 репрезентативных запросов, удалить лишние персональные данные, разметить риск и критерии принятия. Вторая — прогнать обе модели и простой роутер в теневом режиме, не меняя ответ пользователю. Третья — выбрать два или три порога и сравнить стоимость, качество и p95. Четвёртая — включить малую модель только для низкорискового слоя с автоматическим откатом на сильную.

До расширения трафика должны выполняться четыре условия:

экономия остаётся положительной после стоимости ошибок и ручной проверки;
незамеченные ошибки не превышают заранее утверждённый предел по каждому классу риска;
p95 каскадного маршрута соответствует SLA;
обновление любой модели автоматически запускает повторную оценку и позволяет быстро вернуть весь трафик на сильную модель.

Следующий шаг руководителю

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

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