Обучение с длинным контекстом в MoE

Стабильная документация: @docs/training/moe-optimization.md Карточка: @skills/nemo-mbridge-perf-moe-long-context/card.yaml

Что меняется при работе с длинным контекстом

Как только длина последовательности значительно превышает диапазон 4K, память внимания и резидентность активаций становятся доминирующими ограничениями. Для моделей MoE это обычно означает, что требуется некоторое сочетание следующих факторов:

• параллелизма контекста
• избирательного пересчёта
• снижение точности
• разгрузка ЦП для состояния оптимизатора
• диспетчера и макета PP, которые не тратят впустую оставшийся небольшой бюджет DP

Округлённые модели масштабирования

DSV3 на H100

Запуски DSV3 с длинным контекстом демонстрируют стабильную картину:

• выборочный пересчёт работает лучше, чем полный пересчёт, как только вы выходите за пределы самых коротких контекстов
• пропускная способность остается в довольно узком диапазоне от контекстов средней длины до очень длинных, если CP увеличено соответствующим образом
• по мере роста CP приоритет смещается с «вместимости памяти» на «осуществимость с учетом количества GPU»

Другими словами, длинный контекст не приводит к немедленному падению коэффициента использования, если разметка выбрана правильно, но он очень быстро расходует бюджет DP.

Qwen3-Next на GB200

Qwen3-Next ведёт себя скорее как чувствительная к памяти модель среднего масштаба:

• 8K и 32K остаются практичными при умеренном CP
• 64K возможно, но падение пропускной способности заметно, а памяти становится гораздо меньше
• улучшения компоновки конвейера и группированного GEMM важны почти так же, как CP

Qwen3 235B на GB200

Qwen3 235B показывает, что длинный контекст по-прежнему может быть эффективен на системах NVL72, когда TP, CP и HybridEP скоординированы. Лучшие конфигурации класса 128K — это не просто «рецепты» для «подгонки»; они могут оставаться высокоэффективными, если маршрутизация, параллелизм и повторные вычисления сбалансированы.

Практические правила определения размера CP

1. Начните с целевого размера фрагмента 4K: хорошим первоначальным приближением будет CP ~= seq_len / 4096, затем округлите до практичной комбинации, являющейся степенью числа два.

2. По возможности сохраняйте DP: масштабируемость с длинным контекстом становится неустойчивой, когда CP, EP, TP и PP вместе сжимают DP до предела.

3. Отдавайте предпочтение выборочному пересчёту: пересчитывайте модули, такие как up_proj, norm, moe, moe_act или mlp, прежде чем прибегать к полному пересчёту.

4. Избегайте пересчёта с интенсивным использованием SDPA при очень длинном контексте: пересчёт внутренних компонентов внимания может добавить много работы, принося меньшую выгоду по памяти, чем пересчёт более мелких модулей со стороны MoE и MLP.

5. Используйте TP в качестве дополнительного рычага на системах NVL72: при работе с GB200 и GB300 можно иногда пожертвовать частью CP в пользу TP, сохраняя при этом эффективность.

6. Исходите из того, что GBS придётся уменьшить: по мере роста CP и снижения DP вам, возможно, потребуется уменьшить глобальный размер партии или принять более высокое значение GA.

Типичные семейства конфигураций

DSV3 на 128K на H100

TP=1  CP=32  EP=32  PP=8  VPP=4
Точность: класс FP8
Диспетчер: DeepEP
Пересчёт: up_proj, norm, moe, mlp
Дополнительная помощь памяти: разгрузка процессора оптимизатором

DSV3 с размером 256K на H100

TP=1  CP=64  EP=32  PP=8  EDP=2  VPP=4
Точность: класс FP8
Диспетчер: DeepEP
Пересчёт: up_proj, norm, moe, mlp
Дополнительная поддержка памяти: разгрузка ЦП с помощью оптимизатора

Qwen3 235B при 128K на GB200

TP=4  CP=4  EP=32  PP=4  VPP=12
Точность: BF16 или MXFP8
Диспетчер: HybridEP
Пересчёт: moe_act, norm
Граф CUDA: attn + moe_router + moe_preprocess

Рекомендации по пересчёту и CUDA-графу

Для обучения MoE с длинным контекстом:

• начните с выборочного пересчёта
• добавляйте графы CUDA только после того, как формы и маршрут прокладки станут стабильными
• при использовании CUDA-графов поддерживайте фиксированную длину последовательности и MBS
• если выполнение зависит от очень динамичных партий данных, отдавайте предпочтение «eager»-выполнению

Полезные ссылки:

• @docs/training/activation-recomputation.md
• @skills/nemo-mbridge-perf-cuda-graphs/SKILL.md

Ловушки

1. CP не заменяет EP или PP: он добавляет ещё одно измерение; он не заставляет остальные исчезнуть.

2. Хороший базовый вариант для 4K по-прежнему может оказаться плохим для длинного контекста: режим маршрутизации, выбор пересчёта и стратегия выгрузки часто требуют изменения.

3. Реальное ограничение становится количество графических процессоров: очень длинный контекст может выглядеть нормально в отдельном рецепте, но становится невозможным, как только EP и PP добавляются по-настоящему по всей модели.

4. Графы CUDA требуют статических форм: пакеты переменной длины и стратегии оптимизации с заполнением могут незаметно нарушить путь.

5. Поддержка контейнеров и ядер имеет большее значение при размере 128K+: пути с длинным контекстом чаще полагаются на более новые версии ядер и исправления ошибок, чем при запуске с коротким контекстом.