Проблема, из которой выросла идея
Долгое время развитие языковых моделей шло по простому принципу: больше параметров — выше качество. Принцип работал, но упёрся в арифметику.
В классической, так называемой плотной модели при обработке каждого токена задействуются все параметры без исключения. Модель на 100 миллиардов параметров использует все 100 миллиардов на каждое слово — и на сложное рассуждение, и на служебный предлог.
Отсюда прямая зависимость: вдвое больше параметров означает примерно вдвое больше вычислений на каждый токен. Растут расходы на обучение, на инференс, на память, на электричество. В какой-то момент дальнейший рост перестаёт окупаться качеством.
Mixture of Experts, «смесь экспертов», предлагает выход: разорвать жёсткую связь между размером модели и объёмом вычислений на один токен.
Как это устроено
Основная идея — вместо одного большого блока обработки использовать множество меньших, задействуя каждый раз только несколько из них.
Эксперты. Слой модели разделён на несколько параллельных подсетей. Каждая — самостоятельный блок со своими весами. Их может быть восемь, шестьдесят четыре, несколько сотен.
Маршрутизатор. Небольшая обучаемая сеть, которая для каждого токена решает, каким экспертам его отправить. Обычно выбирается два эксперта из общего числа.
Объединение результатов. Выходы выбранных экспертов взвешиваются в соответствии с уверенностью маршрутизатора и складываются в итоговый результат.
Ключевой момент: остальные эксперты для этого токена не вычисляются вообще. Их веса лежат в памяти, но операций с ними не производится.
Что это даёт в цифрах
Возьмём условную модель на 400 миллиардов параметров, где из 64 экспертов на каждый токен активируются два.
Общее число параметров — 400 миллиардов. Именно столько нужно держать в памяти. Но фактически на обработку одного токена задействуется лишь малая доля — скажем, 30 миллиардов.
Результат: качество и объём знаний соответствуют крупной модели, а стоимость вычислений — гораздо меньшей. Именно этот размен и сделал архитектуру массовой.
Разделение труда между экспертами
Распространено представление, будто эксперты специализируются по темам: один на медицине, другой на программировании, третий на юриспруденции. Это красивая, но неточная картина.
Специализация возникает сама в процессе обучения, и она гораздо менее наглядна. Эксперты чаще разделяются по языковым и структурным признакам: один тяготеет к синтаксическим конструкциям определённого типа, другой — к числовым выражениям, третий — к специфической лексике. Осмысленных ярлыков этим специализациям обычно не подобрать.
Важно и другое: маршрутизация происходит на каждом слое отдельно и для каждого токена отдельно. Один и тот же токен на разных слоях уходит к разным экспертам. Никакого единого «выбора специалиста для запроса» не существует — это множество независимых мелких решений.
Что архитектура даёт на практике
Дешевле инференс. Главное преимущество. При сопоставимом качестве вычислений на токен требуется существенно меньше, что напрямую влияет на стоимость обслуживания запросов.
Дешевле обучение. Та же логика: меньше операций на токен обучающей выборки.
Больше знаний при той же скорости. Модель может хранить существенно больший объём информации в весах, не замедляясь пропорционально.
Гибкость масштабирования. Наращивать число экспертов можно, не увеличивая стоимость обработки каждого токена.
Что архитектура усложняет
Раздел, о котором в популярных объяснениях обычно умалчивают.
Память нужна на всю модель. Это главное практическое следствие. Активируются два эксперта из шестидесяти четырёх, но все шестьдесят четыре должны быть загружены — заранее неизвестно, какие понадобятся следующему токену. Экономия идёт по вычислениям, но не по объёму памяти.
Для подбора оборудования это критично. Модель на 400 миллиардов параметров требует памяти под все 400 миллиардов, даже если активная часть в десять раз меньше. Рассчитывать конфигурацию по активным параметрам — распространённая и дорогая ошибка.
Неравномерная загрузка экспертов. При обучении маршрутизатор склонен «облюбовывать» отдельных экспертов, отправляя им непропорционально много токенов. Остальные недообучаются и простаивают. Против этого применяют специальные штрафы в функции потерь, выравнивающие распределение нагрузки, и ограничения на количество токенов, которое может принять один эксперт.
Сложность распределённого исполнения. Эксперты одного слоя часто размещаются на разных ускорителях. Значит, токены приходится пересылать между устройствами — и скорость соединения между ними становится узким местом. При медленном интерконнекте выигрыш в вычислениях съедается расходами на передачу данных.
Нестабильность обучения. Маршрутизация — дискретное решение, что осложняет обучение. Плюс возможен эффект самоусиления: эксперт, получивший больше данных, обучается лучше, поэтому получает ещё больше данных.
Хуже предсказуемость задержки. Разные токены проходят разные пути, а при переполнении эксперта включаются механизмы перераспределения. Время ответа становится менее стабильным, что имеет значение для сервисов с жёсткими требованиями к задержке.
MoE или плотная модель: когда что
| Критерий | Плотная модель | Mixture of Experts |
|---|---|---|
| Вычисления на токен | Пропорциональны размеру | Существенно ниже |
| Требуемый объём памяти | По размеру модели | По размеру модели (не по активной части) |
| Сложность развёртывания | Ниже | Выше, чувствительна к интерконнекту |
| Предсказуемость задержки | Выше | Ниже |
| Экономика при массовых запросах | Хуже | Лучше |
| Работа на одном ускорителе | Проще | Возможна, но требует много памяти |
Плотная модель предпочтительнее, когда развёртывание должно быть простым, задержка — стабильной, а масштабы — умеренными. Для компактных моделей преимущества MoE не окупают усложнения.
MoE предпочтительнее, когда нужно максимальное качество при контролируемой стоимости обработки запросов и есть инфраструктура, способная разместить модель целиком и обеспечить быструю связь между ускорителями.
Что учитывать при подборе оборудования
Практические выводы для тех, кто планирует запускать такие модели.
Считайте память по полному числу параметров. Повторю, потому что это главная ошибка: активная часть определяет скорость, полный размер — требования к памяти.
Проверьте скорость связи между ускорителями. Если модель распределена по нескольким картам, интерконнект становится критичным. На медленном соединении преимущество архитектуры теряется.
Оцените требования к стабильности отклика. Если сервис требует предсказуемого времени ответа, поведение MoE под нагрузкой нужно проверять на реальном профиле запросов.
Рассмотрите квантование. Снижение точности хранения весов уменьшает требования к памяти — для крупных моделей это часто единственный способ уложиться в доступную конфигурацию.
Коротко
Mixture of Experts разрывает связь между размером модели и стоимостью обработки токена: параметров много, но на каждый токен работает лишь малая их часть. Это сделало возможными очень крупные модели с приемлемой стоимостью инференса.
Плата за это — усложнение. Память нужна под всю модель целиком, обучение менее стабильно, распределённое исполнение чувствительно к скорости связи между ускорителями, а задержка становится менее предсказуемой.
Главный практический вывод при планировании железа: ориентируйтесь на полное число параметров при расчёте памяти и на активную часть при оценке скорости. Путаница между этими величинами приводит к покупке конфигурации, в которую выбранная модель попросту не поместится.
Нужна помощь с расчётом конфигурации под конкретную модель — напишите нам, посчитаем требования по памяти и подберём вариант.