📊 Роутеры LLM не всегда выигрывают у одной сильной модели

На LLMRouterBench несколько маршрутизаторов не смогли уверенно превзойти одну лучшую модель из сравниваемого набора. Это главный контраргумент к схеме, где «простые» запросы уходят в Mistral Small, а сложные — в Claude Sonnet: сама по себе диспетчеризация не добавляет качества. Разбор на Habr описывает, когда маршрутизация действительно нужна: для снижения цены, повышения скорости, отказоустойчивости и разделения данных по контурам безопасности. Например, финтех может отдать внешней модели только нормативные акты, а внутренней — сопоставление выжимки с кодом компании.

Проблема глубже, чем «выбрать сильную модель для сложной задачи». В эксперименте Gemini решала задачи, а gpt-oss-20b проверяла ответы — проверяющая модель отклонила в том числе правильный результат. На 60 заданиях с автором и критиком на одной Llama 3.1 8B одобрение критика ни разу не завершило цикл раньше лимита в шесть раундов. Четыре модели по-разному классифицировали один и тот же комментарий к правилу USDA: Gemini увидела возражение, а GPT, Llama и Mistral — поддержку. Несогласованность моделей — это не теоретический риск, а измеримая цена многомодельной схемы.

Экономика тоже не сводится к цене за токен. В сравнении Arize и Fireworks более дорогая модель иногда обходилась дешевле, потому что требовала меньше повторных попыток. При этом переключение между моделями не гарантирует экономию, если неудачные итерации стоят слишком дорого. Роутер должен выбирать не «модель под тип запроса», а вариант с лучшей стоимостью готового проверенного результата.

Практический старт — не с индивидуального классификатора, а с готового шлюза: LiteLLM или OpenRouter. Но перед внедрением стоит проверить исходный вариант «одна модель на все задачи» на своём наборе входных данных и результатов. Авторы обзора отдельно отмечают устаревание роутера: схема, настроенная под фиксированный набор моделей, ломается после его обновления. Если маршрутизатор не обыгрывает лучшую одиночную модель на ваших же тестах, это не улучшение продукта, а дополнительный компонент с задержкой и инженерной поддержкой.

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

#LLM #роутинг #LiteLLM #OpenRouter #LLMRouterBench