Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Один и тот же LLM с одинаковыми весами у разных провайдеров работает как разные сервисы: меняются качество, задержка, доступность и цена. В нерецензированном препринте, где все числа получили сами авторы, цена указывала на скорость, но не позволяла предсказать качество и доступность. Значит, после выбора модели маршрутизатор должен отдельно решить, кому поручить запрос.
Как измеряли провайдера отдельно от модели
Работа рассматривает слой маршрутизации, который включается после выбора модели. Обычный маршрутизатор решает, какой LLM подходит запросу, а предложенная схема сравнивает провайдеров, которые обслуживают уже выбранную модель с открытыми весами.
Запросы отправляли через публичный агрегатор, жёстко закрепляя каждый вызов за одним провайдером и отключая автоматический переход на запасной сервис. Для каждой комбинации модели, типа задачи и провайдера измеряли точность, фактическую стоимость, среднюю задержку и доступность.
Проверка охватила шесть моделей. В лёгкие пробы вошли многошаговая математика, извлечение данных, классификация тональности и предсказание результата программы. Более крупные замеры провели на GSM8K, MMLU и HumanEval. Провайдеров сравнивали в трёх волнах, поэтому работа показывает не только разницу между сервисами, но и изменения со временем.
Маршрут считался допустимым, если провайдер сохранял качество, близкое к лучшему результату для конкретной модели и задачи, и оставался доступным. Это важная граница работы: выводы относятся к измеренным моделям, задачам и точкам доступа через агрегатор, а не ко всему рынку LLM-инфраструктуры.
Цена показывает скорость, но скрывает качество
Для одной модели разброс цен между провайдерами доходил до 8,8 раза, а задержки — до 68 раз. При этом дорогой сервис не обязательно отвечал точнее или чаще оставался доступным. Связь цены со скоростью оказалась устойчивее: более дорогие точки доступа обычно работали быстрее.
В пяти комбинациях модели и задачи самый дешёвый провайдер не достигал требуемого качества. Особенно опасны выборочные сбои: один сервис мог нормально отвечать на вопросы о фактах, хуже справляться с кодом и почти ломаться на многошаговых рассуждениях. Поэтому метки «надёжный провайдер» недостаточно — оценку нужно хранить отдельно для каждого типа нагрузки.
Выбор самого дешёвого провайдера среди доступных и сопоставимых по качеству дал медианную экономию 50% относительно дорогого варианта. Но такую карту нельзя считать постоянной. За 43 дня выбранные маршруты менялись из-за восстановления доступности, ограничений частоты запросов, ухода провайдеров и снижения качества, хотя цены в основном оставались прежними.
Отсюда следует практическое разделение сигналов. Прайс подходит для оптимизации стоимости, измеренная задержка — для соблюдения срока ответа, а качество и доступность нужно проверять прямыми пробами. Один показатель не заменяет остальные.
Что менять в архитектуре маршрутизатора
Командам, которые уже распределяют запросы между моделями, не нужно заменять этот слой. К нему стоит добавить второе решение: после выбора LLM определить провайдера по карте «модель — задача — провайдер». Если продукт использует единственную точку доступа, работа не даёт немедленной экономии, но описывает архитектуру для подключения альтернативных поставщиков без слепого переключения по цене.
Авторы предлагают FACET — маршрутизатор, который допускает провайдера к реальному трафику только после проверки на конкретном типе задач. Пока доказательств недостаточно, запрос уходит к заранее выбранному опорному провайдеру. После допуска система продолжает следить за ответами и отзывает разрешение, если качество падает.
Для внедрения потребуются закреплённые за провайдерами контрольные запросы, классификация рабочей нагрузки и доверенный сигнал качества. Если тип запроса определить нельзя, безопаснее считать его отдельной непроверенной категорией и отправлять опорному сервису. Если качество оценивает другая модель, нужны периодические проверки по эталонным ответам: систематически ошибающийся оценщик способен допустить слабого провайдера.
FACET проверили и на живом трафике: прогон длился 36 часов и охватил 12 провайдеров одной модели. С учётом контрольных запросов расходы снизились на 57,1% относительно опорного сервиса. За это время качество ни у одного провайдера не обрушилось, поэтому эксперимент подтверждает безопасный первоначальный допуск и перенос трафика, но не показывает, как быстро схема обнаружит реальную деградацию.
Работа меняет план системы там, где одну модель можно заказать у нескольких поставщиков. Статический список цен следует заменить обновляемой картой качества, задержки и доступности, а переключение — процедурой допуска с возвратом к проверенному провайдеру. Экономия возникает не от выбора самого дешёвого API, а от доказательства, что дешёвая точка доступа подходит именно текущей задаче.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
