Представьте, что в компании из 50 отделов каждый отдел набирает собственный штат юристов, бухгалтеров и инженеров — независимо от того, нужны ли они именно этому отделу. Звучит безумием, но именно так работают современные Mixture-of-Experts модели: каждый слой трансформера содержит собственный набор «экспертов», которые другие слои не могут использовать. Исследователи из Китайского университета Гонконга и Huawei предложили архитектуру UniPool, которая ломает эту традицию — и добилась лучших результатов, используя на 58% меньше экспертных параметров.

Что такое Mixture-of-Experts

Mixture-of-Experts (MoE) — архитектура нейросети, где вместо одной полносвязной сети (FFN) в каждом слое размещается несколько «экспертов» — параллельных FFN-модулей. Специальный маршрутизатор (router) для каждого токена выбирает одного-двух экспертов, а остальных игнорирует. Это позволяет наращивать общий объём параметров модели, сохраняя вычислительные затраты почти неизменными: каждый токен обрабатывает лишь малую часть сети.

Подход стал стандартом де-факто для больших языковых моделей. Mixtral, DeepSeek, Qwen, Gemini — все они используют MoE в своих топовых конфигурациях. Ключевое ограничение: в классической схеме каждый слой владеет собственным набором экспертов. Добавили 10 слоёв — нужно добавить 10 новых наборов. Параметры экспертов растут линейно с глубиной модели, и никакой обмен знаниями между слоями невозможен.

Это фундаментальная архитектурная проблема. Когда модель углубляется, каждый новый слой требует свежих экспертных параметров, даже если предыдущие слои уже выучили похожие паттерны обработки. Слои не могут «одолжить» эксперта у соседа — каждый содержит свой изолированный набор. Результат — раздувание параметров, которое не конвертируется в пропорциональный рост качества.

Проблема: половина экспертов не нужна

Прежде чем предлагать решение, авторы UniPool задались неудобным вопросом: а действительно ли каждый слой нуждается в собственных экспертах? Чтобы это проверить, они провели элегантный эксперимент — заменили обученный маршрутизатор на случайный выбор в глубоких слоях нескольких production-моделей MoE.

Результат ошеломляет: точность упала всего на 1.0–1.6 процентных пункта. Иными словами, маршрутизатор в глубоких слоях практически не принимает значимых решений — эксперты настолько взаимозаменяемы, что случайный выбор работает почти так же. Это означает, что стандартная архитектура MoE тратит значительную долю экспертных параметров впустую, создавая дублирующие функции от слоя к слою.

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

UniPool: один пул на всю модель

Архитектура UniPool (Unified Expert Pool) предлагает радикально иной подход. Вместо того чтобы каждый слой владел собственными экспертами, все слои разделяют единый глобальный пул. Каждый слой сохраняет независимый маршрутизатор, который выбирает нужных экспертов из общей кассы — но сами эксперты больше не привязаны к конкретному слою.

Такая конструкция создаёт две фундаментальные проблемы. Первая — балансировка нагрузки. В классическом MoE вспомогательная функция потерь (auxiliary loss) гарантирует, что каждый эксперт в слое получает свою долю токенов. Но когда пул общий, эксперт, который не используется одним слоем, может активно использоваться другим. Принуждать каждый слой использовать каждого эксперта бессмысленно — это противоречит самой идее разделения. Авторы решили это, введя pool-level auxiliary loss: балансировка считается по всему пулу в целом, а не по отдельным слоям. Если эксперт востребован хотя бы частью слоёв — он не считается «мёртвым».

Вторая проблема — стабильность маршрутизации. Когда маршрутизаторы из разных слоёв (с разным масштабом скрытых состояний) выбирают из одного и того же большого пула, стандартный softmax-gating создаёт хаос: слои с крупными активациями доминируют. UniPool использует NormRouter — маршрутизатор, который нормализует входы через L2-норму и ReLU перед выбором top-k экспертов. Это делает оценки маршрутизатора независимыми от масштаба слоя и создаёт разреженную конкуренцию за эксперты.

Важный технический нюанс: NormRouter не использует softmax. Вместо этого он применяет L2-нормализацию к скрытому состоянию и вектору эксперта, затем пропускает результат через ReLU — и только после этого выбирает top-k. Это даёт два преимущества: оценки маршрутизатора не подвержены влиянию масштаба скрытых состояний конкретного слоя, а ReLU естественным образом отсекает слабых кандидатов, создавая разреженный выбор без дополнительных порогов.

Результаты: меньше параметров, выше качество

Авторы протестировали UniPool на пяти масштабах архитектуры LLaMA: от 182M до 978M параметров, обучая на 30 млрд токенов из датасета The Pile. На каждом масштабе UniPool превосходит классический MoE по validation loss. Улучшения составляют 0.0288 (182M), 0.0346 (469M), 0.0308 (650M), 0.0386 (830M) и 0.0172 (978M). Обе MoE-архитектуры существенно превосходят плотный baseline — например, на масштабе 182M MoE даёт validation loss 1.9029 против 2.042 у dense модели.

Но самый впечатляющий результат связан не с улучшением loss, а с эффективностью параметров. Уменьшенные варианты UniPool, использующие только 41.6%–66.7% экспертного бюджета классического MoE, соответствуют или превосходят baseline по качеству. На масштабе 830M UniPool побивает vanilla MoE, имея лишь 41.6% экспертных параметров — то есть экономит почти 60% параметров, выделенных на экспертов. На масштабе 469M достаточно 50% бюджета, чтобы превзойти baseline.

Интересно, что UniPool особенно эффективен на глубоких моделях. Конфигурация 830M (48 слоёв, скрытый размер 1024) получает больший выигрыш, чем 978M (24 слоя, скрытый размер 1536), хотя последняя имеет больше параметров. Авторы объясняют это тем, что дополнительные слои создают больше «точек входа» в глобальный пул — каждый слой может повторно использовать уже обученных экспертов, вместо того чтобы обучать новых с нуля. В этом смысле UniPool превращает глубину модели из «налога» на параметры в преимущество: чем больше слоёв, тем больше возможностей для повторного использования.

Отдельный эксперимент подтверждает, что преимущества UniPool складываются с более мелкой декомпозицией экспертов. Когда эксперты разбиваются на более мелкие блоки (finer-grained expert decomposition), общий пул получает ещё больший выигрыш — мелкие эксперты легче комбинируются и повторно используются разными слоями.

Эксперты перестают быть взаимозаменяемыми

Чтобы проверить, действительно ли UniPool делает экспертов более специализированными, авторы повторили эксперимент со случайной маршрутизацией — но уже на собственных моделях UniPool. Если в vanilla MoE случайный выбор в глубоких слоях снижал точность на 1.3–1.5 пункта, то в UniPool аналогичная интервенция обходится в 4.1 пункт — почти втрое дороже.

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

Эти два результата — малый штраф за рандомизацию в vanilla MoE и большой штраф в UniPool — две стороны одной медали. В первом случае система толерантна к потерям, потому что терять особо нечего: эксперты взаимозаменяемы. Во втором случае каждый эксперт уникален и незаменим, и его потеря hurts. Это и есть свидетельство настоящей специализации.

Практическое значение

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

Во-вторых, UniPool предлагает конкретный рецепт экономии вычислительных ресурсов. При обучении MoE-моделей значительная часть GPU-памяти уходит на хранение экспертных параметров. Если те же 40–60% экспертов можно выкинуть без потери качества — это прямая экономия на inference и хранении. Для моделей вроде DeepSeek-V3 с 671 млрд параметров, где большая часть — экспертные веса, потенциальная экономия измеряется сотнями гигабайт VRAM.

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

Ограничения тоже стоит упомянуть. Эксперименты проведены на масштабах до 978M параметров и 30 млрд токенов — это серьёзные, но не frontier-масштабы. Авторы прямо признают, что вопрос о том, сохранятся ли преимущества UniPool на моделях в сотни миллиардов параметров, остаётся открытым. Также не проводились тесты throughput и потребления памяти при inference — а для практического применения эти метрики критичны. Глобальный пул может создать узкое место при параллельном выполнении на нескольких GPU, и эта проблема в статье не исследована.

Часто задаваемые вопросы

Чем UniPool отличается от обычного MoE?

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

Зачем нужен pool-level auxiliary loss?

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

Применим ли UniPool к большим моделям вроде GPT-4 или Llama 3?

Исследование протестировано на масштабах до 978M параметров. Перенос на frontier-модели с сотнями миллиардов параметров требует дополнительных экспериментов — как по эффективности, так и по технической реализуемости (потребление памяти, throughput). Концептуальный аргумент в пользу UniPool силён, но эмпирическое подтверждение на больших масштабах пока отсутствует.

Итог

UniPool предлагает элегантную и экономную альтернативу стандартной архитектуре Mixture-of-Experts. Единый разделяемый пул экспертов не только снижает validation loss на всех протестированных масштабах, но и позволяет сократить экспертный бюджет на 40–60% без потери качества. Глубокие модели с тонкими слоями выигрывают больше всего — каждый новый слой получает доступ к уже обученным экспертам, а не начинает с чистого листа.

Если вы работаете с MoE-архитектурами или интересуетесь методами эффективного масштабирования LLM — точно стоит прочитать оригинальную статью на arXiv (2605.06665). Код доступен в открытом репозитории на GitHub.