Что законы масштабирования вам не расскажут: чем больше модель, тем страннее баги
Законы масштабирования говорят нам, что способность модели будет стабильно расти с увеличением параметров и данных. Но законы масштабирования не говорят вам, что когда масштаб модели пересекает определённый порог, в процессе обслуживания появляются вероятностные, крайне трудно воспроизводимые garbled outputs (искажённый вывод).
Zhipu AI (THUDM) 29 апреля опубликовала технический блог под названием Scaling Pain: Debugging GLM-5 Serving at Scale, подробно описав опыт отладки проблем крупномасштабного вывода GLM-5. Пост получил 843 лайка и 295 закладок, вызвав широкое обсуждение в сообществе.
Проблема: спорадический искажённый вывод, только в масштабе
GLM-5 — это MoE-модель на 744B параметров. На одной машине или небольшом кластере всё работает нормально. Но при развёртывании в производственном распределённом кластере команда столкнулась со странной проблемой:
В выводе периодически появлялся garbled text (искажённый текст), но ошибки были крайне редкими и трудными для воспроизведения.
Это не была обычная проблема кодирования или ошибка токенизации — она появлялась только при определённых конфигурациях распределённого обслуживания с определённой вероятностью. Команда потратила значительные усилия на создание надёжного конвейера воспроизведения.
Методология отладки
Команда Zhipu поделилась трёхэтапной структурой отладки в своём блоге:
| Этап | Метод | Результат |
|---|---|---|
| Воспроизведение | Создание детерминированных тестовых случаев, принудительный триггер с конкретными seed | Воспроизводимые образцы искажённого вывода |
| Локализация | Послойная проверка тензорной коммуникации в конвейере распределённого вывода | Обнаружен численный дрейф между определёнными узлами |
| Исправление | Настройка стратегии смешанной точности, введение guard численной стабильности | Искажённый вывод устранен, без потери производительности |
Ключевое открытие: в крупномасштабном MoE-выводе inconsistency числовой точности между различными expert может накапливаться до степени, влияющей на качество вывода. Это особенно заметно при высокой конкурентности.
Почему это важно
Этот блог ценен тем, что это один из немногих первичных раскрытий Scaling Pain обслуживания крупных моделей. Индустрия переполнена дискуссиями о «способностях моделей», но материалов о «как заставить MoE-модель на 744B стабильно работать в продакшене» — считанные единицы.
Для предприятий и разработателей, рассматривающих самостоятельное развёртывание отечественных крупных моделей, эта информация имеет высокую практическую ценность:
- Не предполагайте, что тесты на одной машине означают готовность к продакшену: распределённый вывод вводит совершенно новые режимы отказов
- Численная стабильность — скрытая задача для MoE: при экспертной параллелизации дрейф точности между разными GPU усиливается
- Создание детерминированного воспроизведения эффективнее слепого тюнинга: первый шаг команды Zhipu — создание воспроизводимых тестовых случаев
Рекомендации к действию
Если вы планируете развёртывание GLM-5.1 или аналогичных по масштабу отечественных MoE-моделей в продакшене:
- Проведите стресс-тест перед запуском: симулируйте конкурентность уровня продакшена и наблюдайте за спорадическим искажённым выводом
- Мониторьте числовую точность: проверяйте распределение значений активаций между разными GPU-узлами
- Обратитесь к стратегии смешанной точности Zhipu: их подход использования FP32 вместо BF16 для определённых слоёв заслуживает внимания
- Следите за обновлениями THUDM: исправление уже включено в открытый исходный код GLM-5
GLM-5.1 (выпущена 27 марта) уже является зрелой версией, достигая 94-95% уровня Claude Opus 4.6 на SWE-Bench. Этот блог — своего рода «руководство по избеганию ошибок» для тех, кто последует за ними — инженерный опыт, distilled из боли масштабирования.