ainews
Как мы исправили тихого убийцу в нашем LLM-кластере на Mac Studio
Команда столкнулась с регулярными падениями распределённого LLM-кластера из пяти Mac Studio (96 ГБ памяти), связанных через Thunderbolt 5. Проблема оказалась многослойной: баг в mlx.launch не убивал удалённые процессы при сбое, orphan-процессы в состоянии Us+ накапливались сотнями и истощали пул RDMA protection domains, что приводило к RuntimeError при инициализации новых задач.
Практический разбор реальной production-проблемы в распределённом inference на Apple Silicon с MLX. Полезно инженерам, работающим с распределёнными LLM-системами, RDMA, или сталкивающимся с resource leaks в долгоживущих сервисах — показывает, как debugging многослойных проблем требует понимания взаимодействия разных уровней (Python, SSH, kernel, RDMA).
Это аннотация к авторской статье. Мы не публикуем и не пересказываем чужие тексты целиком — полная версия у автора.
О чём статья
- Баг в mlx.launch: при падении главного процесса удалённые rank-процессы на peer-узлах не убивались из-за ошибки подстановки переменной (tmpfile = tmp.None)
- Процессы в состоянии Us+ (uninterruptible sleep) невозможно убить даже через kill -9, они застревают в ожидании внутри RDMA-стека jaccl
- Существующая логика очистки искала orphan-процессы по ppid=1, но пропускала основную массу — те, чей родитель sshd тоже завис в ожидании дочернего процесса
- Каждый orphan-процесс удерживает RDMA protection domain навсегда, истощая конечный пул ресурсов, что делает кластер неработоспособным до полной перезагрузки
Комментарии