Не все экспертные модели одинаково полезны... но теперь они одинаково быстрые
Mixture of Experts (MoE) – архитектура, ставшая популярной благодаря способности наращивать «интеллект» модели без радикального роста вычислительных затрат. Проще говоря: вместо того чтобы прогонять каждый запрос через всю огромную нейросеть, система выбирает несколько «экспертов» из большого пула и активирует только их. Звучит элегантно, но есть проблема: до недавнего времени обучение таких моделей было крайне медленным и требовало огромного объема памяти.
Команда Unsloth выпустила набор оптимизаций, которые ускоряют обучение MoE-моделей примерно в 12 раз по сравнению с классическими подходами, сокращают требования к видеопамяти более чем на треть и позволяют работать с контекстом в шесть раз длиннее. Всё это – без потери точности.
Почему MoE до сих пор было неудобно обучать
Представьте себе модель, у которой сотня экспертов – отдельных нейронных сетей, каждая со своими весами. Когда поступает токен, система решает, какие из этих экспертов активировать (обычно 6–8 штук). Остальные остаются в режиме ожидания.
Проблема заключалась в том, что веса экспертов хранились как список отдельных слоев. Чтобы обработать данные, приходилось проходить по этому списку циклом: сначала один эксперт, потом второй, третий. Это было очень медленно.
Недавно в PyTorch добавили функцию grouped_mm – способ выполнять несколько матричных умножений за раз вместо последовательного прохода. Библиотека Transformers версии 5 начала использовать эту функцию, что дало шестикратное ускорение. Unsloth пошел дальше и написал собственные ядра на Triton, которые увеличивают скорость еще в два раза и сокращают потребление памяти более чем на треть.
Как это работает: Split LoRA вместо материализации
Обычно при обучении MoE с помощью LoRA (Low-Rank Adaptation – метод дообучения, добавляющий небольшие адаптеры к модели вместо обновления всех весов) происходит следующее: система сначала объединяет адаптер с базовыми весами, а затем прогоняет данные через эту объединенную версию. Проблема в том, что такое объединение требует хранения промежуточной матрицы для каждого эксперта. Если экспертов 128 (как в Qwen3-30B), это мгновенно исчерпывает память.
Unsloth использует иной порядок операций. Вместо того чтобы сначала собирать полный вес, а потом применять его к данным, система сначала применяет LoRA-адаптер к данным, а затем умножает результат на вторую часть адаптера. Математически результат не меняется (матричное умножение ассоциативно), но порядок операций позволяет обходиться без хранения громоздких промежуточных матриц.
Это экономит колоссальное количество памяти и времени. Для Qwen3-30B-A3B такой подход позволяет работать с контекстом до 32 тысяч токенов. Для gpt-oss – еще больше.
Бенчмарки: от «железа» для дата-центров до пользовательских GPU
На NVIDIA B200 обучение gpt-oss с контекстом в 8192 токена стало быстрее в 7 раз по сравнению с Transformers v5, а потребление памяти сократилось на 36%. На контексте в 16K токенов Transformers v5 выдает ошибку нехватки памяти, в то время как Unsloth продолжает работать.
Qwen3-30B-A3B на B200 показывает ускорение примерно в 1,7 раза при экономии памяти в 35%. На H100 зафиксирован рост скорости в 1,77 раза, при этом на контексте в 8K токенов Unsloth использует меньше памяти, чем базовая версия при 4K.
GLM 4.7 Flash – модель с 64 экспертами и одним общим (конфигурация в стиле DeepSeek). На RTX PRO 6000 Unsloth обеспечивает ускорение в 2,1 раза и экономию памяти на 15%.
Важно: все эти оптимизации работают не только на серверных GPU вроде H100 или B200, но и на пользовательских видеокартах уровня RTX 3090 или старых A100. Поддержка начинается с архитектуры NVIDIA T4.
Автоматический выбор бэкенда
Unsloth самостоятельно выбирает метод ускорения в зависимости от вашего оборудования. Если используется H100 или более новая карта – включается grouped_mm, оптимизированная функция PyTorch. Если установлена A100 или старые версии PyTorch – автоматически активируются собственные Triton-ядра Unsloth, которые на A100 работают в 2,5 раза быстрее grouped_mm. Если же оборудование не поддерживает эти функции, используется базовая версия PyTorch, но даже в этом случае сохраняются все оптимизации по памяти.
Режимы можно переключать вручную через переменную окружения UNSLOTH_MOE_BACKEND, но по умолчанию система сама выбирает оптимальный вариант.
Какие модели поддерживаются
Обновление затрагивает семейства Qwen3 (включая версии Thinking, Instruct, VL, Coder), gpt-oss (20B, 120B, safeguard), GLM (4.5, 4.6, 4.6-Air, 4.7, 4.7-Flash) и DeepSeek (V3, R1, V3.1, V3.2). Unsloth также должен поддерживать и другие MoE-модели, даже если они не указаны в документации.
Бонус: другие обновления
Вместе с ускорением MoE команда представила еще несколько улучшений:
- Gemma-3 теперь использует Flex-Attention по умолчанию, что снижает сложность потребления памяти с O(N²) до O(N) и ускоряет обучение более чем в три раза. На контексте в 8K экономия составляет 24,8 ГБ, а на 16K модель перестает выдавать ошибку нехватки памяти.
- Дообучение визуальных моделей теперь поддерживает смешанные данные: можно подавать текст и изображения вперемежку.
- Windows теперь поддерживается официально, без необходимости использования WSL.
- Совместимость с trl==0.27.1 и transformers==5.1.0 доведена до 80% (для всех 120 ноутбуков Unsloth; ранее было 30%). Полная поддержка ожидается в ближайшие дни.
Зачем это нужно
MoE-модели позволяют создавать масштабные нейросети без пропорционального роста вычислительных затрат. Однако до недавнего времени процесс их обучения оставался дорогим и медленным. Новые оптимизации Unsloth делают MoE доступнее: теперь дообучать модели уровня 30B параметров можно на одной пользовательской GPU, а не только на кластерах. Это значительно расширяет круг исследователей, способных экспериментировать с такими архитектурами.
Если вкратце: быстрее обучать, тратить меньше памяти и поддерживать длинный контекст – и всё это без потери качества работы модели.
