# Почему обучение MoEs так сложно Недавно я обнаружил, что хочу небольшой репозиторий для исследований, в котором я мог бы быстро и легко проводить небольшие эксперименты. Эти эксперименты варьируются от испытания новых архитектур внимания (MLA, SWA, NSA, KDA - все подключаемые) до многоточечного обучения и, в последнее время, до многопроцессорных настроек с "новыми" оптимизаторами. Я попробовал 3 основных претендента (Nemo, Megatron и Torchtitan), но по многим и различным причинам они совершенно не подходили для моих целей и были довольно болезненными в настройке, использовании и обеспечении стабильной работы. Я снова скучал по своим инструментам от Google, и переписывание моего производственного стека обучения для этой цели (который специально создан для мониторинга и стабильности крупной инфраструктуры) также казалось плохим использованием времени и ухудшило бы как старый, так и новый репозиторий. Тем не менее, это заставило меня задуматься, почему обучение качественным "маленьким" MoEs (скажем, менее 20B параметров в целом) так сложно? Почему репозиторий / библиотека, которую я хотел, уже не существовала? После некоторого размышления я пришел к выводу, что большинство проблем сводится к 3 различным вещам: - flops / эффективность flops - балансировка нагрузки / стабильность маршрутизатора - качество и количество данных Flops Обучение плотных моделей в наши дни довольно просто. Динамика обучения в основном связана, и если у вас достаточно параметров в архитектуре, модель будет учиться, несмотря на ваши многочисленные ошибки (это уже не раз оборачивалось против меня). [Ultra-sparse в стиле DeepSeek]( MoEs отличаются тем, что ваша динамика обучения несколько разъединена. Только часть ваших MLP активна для данного токена, и по мере обучения активные эксперты меняются и развиваются со временем. Именно это делает многопроцессорное обучение и перефразирование данных такими эффективными для MoEs (особенно для более крупных). Вы получаете большие выигрыши в эффективности вывода и небольшие выигрыши в эффективности обучения, но ценой разъединенной динамики обучения (что затрудняет предсказуемое и стабильное обучение), и вам нужно влить гораздо больше flops, чтобы убедиться, что вы изучаете несколько оптимальную политику маршрутизации и что эксперты, участвующие в различных политиках, адекватно обучены. Вот где возникает проблема flops / эффективности flops. Первая проблема заключается в том, что по своей природе ultra-sparse MoEs занимают огромное количество HBM для загрузки экспертов, но это означает, что вам нужно много GPU, и, следовательно, много неиспользуемых GPU в вашей системе. FSDP (и различные другие топологии шардирования) в основном являются реликтом плотного обучения и не очень хорошо справляются с адекватным использованием всех этих заброшенных flops. Это приводит к (низким) однозначным MFU для большинства людей, обучающих ultra-sparse MoE. И хотя есть несколько способов решения этой проблемы (об этом будет больше в будущем), я сосредоточился на 2 конкретных вещах: - новая топология шардирования (новая система параллельной отправки экспертов, которая держит GPU занятыми) - смешанное точное обучение Балансировка нагрузки / стабильность маршрутизатора Я оставлю новую топологию шардирования для отдельной записи, но смешанное точное обучение - это очевидный выбор. У вас есть все эти заброшенные HBM, поэтому уменьшите точность экспертов и сократите это на 1/2 или 1/4 (fp8 и nvfp4 соответственно). Это хорошо в теории, но на практике смешанное точное обучение обычно требует БОЛЬШЕ HBM, так как вам нужно хранить ваши основные веса и градиенты в более высокой точности, а затем квантизировать основные веса до их представления с более низкой точностью и кэшировать их для следующего прямого прохода. Таким образом, это помогает эффективности вывода (что, поскольку все больше и больше flops идет на RL и вывод, это действительно выигрыш), но ценой еще большего HBM и большего количества flops во время обучения. Снижение накладных расходов на смешанную точность - это то, на что следует обратить особое внимание. Однако все, что вы трогаете, что снижает точность и достоверность весов, в конечном итоге приводит к нестабильности в остальной динамике обучения. Для MoE первое место, где это обычно проявляется, - это стабильность маршрутизатора. Технический отчет DeepSeek-V3 описывает очень элегантную настройку обучения без вспомогательных потерь, где очень мало настроек, и динамика очень ясна. Это явно инструменты, предназначенные для опытного пользователя, так как правильно настроить динамику с помощью всего лишь нескольких настроек невероятно сложно. Критически важно, что DeepSeek сильно полагается на большие размеры пакетов для стабилизации своих маршрутизаторов - роскошь, которой у нас нет, когда мы проводим исследования на ограниченном оборудовании. Поэтому нам нужно работать дополнительно, чтобы сделать наши небольшие запуски стабильными, эффективными и информативными. Когда я начал экспериментировать с воспроизведением их настройки, специально для смешанных точных экспертов, стало очень ясно, что градиенты были слишком малы для fp8 или nvfp4, что не позволяло маршрутизаторам учиться, а эксперты голодали. Я попробовал все на свете, чтобы это сработало, сначала с уменьшенными точными обратными проходами, а затем даже с основными весами и градиентами fp32, но коллапс маршрутизатора продолжался. Хорошо подобранная статья была блог-постом Character AI, описывающим их различные вмешательства по стабильности int8. Я попробовал их все, но они в конечном итоге сделали систему гораздо менее стабильной. Поэтому я прошел через них один за другим. Первым было масштабирование muP в 10.66 и масштабирование логитов в 0.125. Здесь было много очевидных выигрышей, кроме стабильности маршрутизатора, но одно четкое, что эти масштабы сделали, это увеличили очень маленькие градиенты экспертов fp8 и nvfp4 до такой степени, что МАРШРУТИЗАТОР, НАКОНЕЦ, УЧИЛСЯ! Однако эти выигрыши также вызвали абсолютный взрыв нормы градиента bf16, и "нормальная лучшая практика" обрезка градиентов и масштабирования градиентов предотвращала любое обучение. Так что, решение? Удалите все обрезки и YOLO! Наконец, у нас были стабильные маршрутизаторы смешанной точности. Другим вмешательством Kaiju, которое оказалось невероятно полезным, было одно виртуальное масштабирование bungee на выходе экспертов перед нормализацией выхода, инициализированное на 2.0, чтобы соответствовать масштабу градиента bf16 и, таким образом, динамике обучения, так что nvfp4 и fp8 более или менее представляли те же кривые потерь, что и базовые запуски обучения bf16 (разрыв FP8-BF16 уменьшился с ~0.8 до <0.1 на 3k шагах). Здесь есть много других трюков и "лучших практик" (больше об этом в будущих постах), но основные моменты были: - добавьте масштабирование muP - удалите все остальные обрезки и живите на грани - виртуальный масштаб bungee перед нормализацией выхода - держите обучение без вспомогательных потерь и маршрутизацию выбора токенов (потому что мы знаем разницу между правильным и неправильным в этом доме) Данные Теперь, когда у нас была разумно стабильная динамика обучения, стало ясно, что если я когда-либо хотел поделиться этим репозиторием с кем-либо, нам понадобятся лучшие данные, чтобы действительно извлечь максимум из этой библиотеки обучения. Еще одним хорошо подобранным релизом был [OLMo-3]( с его рецептом смеси открытых данных (привет Ai2!!). Однако, когда я попытался использовать смесь OLMo-3 напрямую из huggingface, я получал довольно ужасные результаты (по сравнению с моим типичным базовым уровнем FineWeb-Edu). Так что началась охота за данными, и ... наборы данных были довольно грязными. Поэтому я сделал то, что сделал бы любой сумасшедший человек, и решил создать вдохновленный фронтиром конвейер данных, чтобы действительно извлечь максимум из этого репозитория обучения. Конвейер имеет несколько ключевых компонентов: - **Эвристические предварительные фильтры**: Идентификация языка, фильтры длины, MinHash дедупликация, повторение n-грамм, выбросы перплексии, токсичность - стандартные вещи для удаления очевидного мусора перед тем, как тратить циклы GPU...