Исследователи объединили 200+ корпоративных LLM-приложений в одну модель через GRPO и SLERP
Требования к резидентности данных заставляют компании держать LLM на собственной инфраструктуре, а не в облаке. Проблема в том, что при переходе на новые модели старые версии обычно не выводят из эксплуатации, парк обслуживающих моделей растёт, и конечный пул GPU дробится между ними. Авторы работы решают эту проблему консолидацией: они сводят трафик более чем 200 внутренних корпоративных приложений на одну-единственную модель.
Чтобы такая консолидация не била по качеству, команда сначала проанализировала реальные ошибки в продакшен-трафике и выделила три оси, по которым модель проседала: следование инструкциям, вызов функций (function-calling) и распределение по внутренним типам задач. Качество отслеживалось офлайн-бенчмарками, специально стратифицированными под структуру продакшен-трафика, и оценивалось либо детерминированными верификаторами, либо откалиброванными LLM-судьями.
Ключевое архитектурное решение: вместо того чтобы оптимизировать все три цели совместно (это порождает взаимную интерференцию наград между доменами), авторы обучили для каждой оси отдельного GRPO-эксперта, а затем слили экспертов через двухэтапный SLERP (сферическую линейную интерполяцию весов). У каждого эксперта своя характерная поломка при наивном обучении: у эксперта по следованию инструкциям, семантический коллапс, у эксперта по вызову функций, избыточные вызовы (over-calling), у эксперта по распределению задач, накрутка многословности (verbosity hacking). Для каждой поломки понадобилось отдельное, специфичное для домена исправление.
В нерассуждающем режиме итоговая модель обходит базовую модель, которая примерно в 7 раз крупнее по общему числу параметров: 69.6 против 65.8 на внутренней Arena-арене, 0.85 против 0.83 по следованию инструкциям и 0.79 против 0.77 по вызову функций, при этом попутно подрастают и общие диалоговые бенчмарки. В проде модель забирает на себя 50% всего трафика self-hosted платформы, 116 миллионов запросов в месяц, и, по утверждению авторов, обходится в разы дешевле в обслуживании (точная цифра экономии не приводится). Название компании, конкретные модели (консолидированная и базовая), даты эксперимента и определения использованных бенчмарков ("in-house Arena", "general dialogue benchmarks") в тексте не раскрываются.
Ключевые факты
- Трафик 200+ внутренних корпоративных приложений свели на одну self-hosted модель вместо парка из множества моделей
- Для трёх осей качества (следование инструкциям, вызов функций, распределение задач) обучили отдельных GRPO-экспертов и слили их двухэтапным SLERP, совместная оптимизация всех целей давала интерференцию наград
- У каждого эксперта свой отказ при наивном обучении: семантический коллапс, избыточные вызовы функций, накрутка многословности, для каждого нужен отдельный фикс
- В нерассуждающем режиме модель обходит базовую модель примерно в 7 раз крупнее по параметрам: 69.6 против 65.8 на внутренней арене, 0.85 против 0.83 и 0.79 против 0.77 на бенчмарках
- Модель обслуживает 50% трафика платформы, 116 млн запросов в месяц, по утверждению авторов, заметно дешевле прежней схемы
Почему это важно
Требования к резидентности данных вынуждают компании держать LLM у себя, а не в облаке чужого провайдера. При этом обычная практика, постоянно добавлять новые модели, не выводя из эксплуатации старые, раздувает парк обслуживающих моделей и дробит конечный пул GPU между ними. Работа показывает, что вместо наращивания парка можно свести разнородный трафик на одну модель, целенаправленно закрыв именно те пробелы в качестве, которые мешают такой консолидации.
Кому это важно
В первую очередь, командам, которые сами держат инфраструктуру для LLM внутри компании: платформенным и ML-инженерам, отвечающим за GPU-парк и cost-эффективность обслуживания, а также исследователям, которые занимаются post-training и слиянием моделей (model merging) как инструментом объединения разных навыков в одной модели.
Как это применить
Метод состоит из трёх шагов. Сначала, анализ ошибок на реальном продакшен-трафике, чтобы найти конкретные оси, по которым модель не дотягивает (в этой работе, следование инструкциям, вызов функций, распределение по внутренним типам задач), и офлайн-бенчмарки, стратифицированные под структуру этого трафика. Затем, обучение отдельного GRPO-эксперта под каждую ось по отдельности, а не одной общей функции вознаграждения, чтобы избежать интерференции между доменами. Наконец, слияние экспертов в одну модель через двухэтапный SLERP вместо развёртывания нескольких специализированных моделей параллельно.
Можно ли доверять
Все числовые результаты, из самой работы: сравнение идёт с базовой моделью, которая описана только как «примерно в 7 раз крупнее по параметрам», без имени и точного размера; сама консолидированная модель тоже не названа. Метрики "in-house Arena" и "general dialogue benchmarks" упомянуты по названию без описания методологии, компания-владелец инфраструктуры не раскрыта, дата эксперимента не указана, а экономия на обслуживании названа как «доля от прежней стоимости» без конкретной цифры. Внешней проверки этих цифр нет, это самоотчёт авторов.
Риски и подводные камни
Метод явно построен вокруг проблем, которые он же и решает: наивное обучение под одну общую функцию вознаграждения даёт интерференцию между доменами, а каждый из трёх экспертов по отдельности склонен к своей поломке, семантическому коллапсу, избыточным вызовам функций или накрутке многословности ответов. Это показывает, что подход требует тщательного контроля за каждым экспертом отдельно, а не просто GRPO «из коробки». Отсутствие данных о названии модели, компании и точной экономии не позволяет проверить результаты независимо или оценить, насколько они переносимы на другую инфраструктуру.