Distributed GPU Training Platform: EffDL and MultiGPU system design

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

Сначала фиксируют рабочую нагрузку: одиночные и распределённые задания, число и тип GPU, объём данных, длительность, требования к воспроизводимости и возможность вытеснения. Свободный ресурс ненадёжен, поэтому задание должно сохранять контрольные точки, возобновляться после потери узла и не зависеть от локального диска. Планировщик учитывает совместимость GPU, топологию, доступ к данным, квоты команд и стоимость простоя.

Синхронное обучение через медленные связи между дата-центрами обычно невыгодно: задержка all-reduce уничтожает пользу свободных ускорителей. Практичнее размещать один распределённый запуск внутри быстрого домена связи, а между площадками переносить очередь, артефакты и контрольные точки. Метрики платформы — полезная загрузка GPU, время ожидания, доля успешных возобновлений, стоимость задания и потери прогресса при вытеснении.

API валидирует и сохраняет спецификацию задания, очередь отделяет приём от запуска, а планировщик сопоставляет требования с ресурсами и создаёт попытку выполнения. Состояние и идемпотентность должны храниться отдельно от сообщений очереди.

API принимает неизменяемую спецификацию: образ, команду, данные, ресурсы, приоритет, квоту и политику повторов. После проверки прав он сохраняет задание в базе и публикует событие по схеме transactional outbox, чтобы запрос не потерялся между записью и очередью.

Планировщик читает ожидающие задания, фильтрует подходящие узлы по типу GPU, памяти, топологии и доступу к данным, затем ранжирует варианты по приоритету, справедливости и фрагментации кластера. Выбранный запуск оформляется как отдельная попытка с арендой ресурса; повторная доставка сообщения не должна создать второй запуск. Сердцебиения, тайм-аут аренды и конечный автомат состояний позволяют восстановиться после падения планировщика или рабочего узла.

Узел — это рабочая машина, модуль — наименьшая планируемая единица, содержащая один или несколько контейнеров, развертывание управляет нужными репликами и развертываниями, а служба обеспечивает стабильную работу сети и балансировку нагрузки для модулей.

Узел Kubernetes — это рабочая машина, физическая или виртуальная, на которой работают модули. У него есть kubelet, среда выполнения контейнера и сеть, необходимые для размещения рабочих нагрузок.

Модуль — это наименьший планируемый модуль Kubernetes. Обычно он содержит один контейнер приложения, но может содержать тесно связанные дополнительные приложения, которые совместно используют сетевое пространство имен и тома. Поды эфемерны; их можно убить и воссоздать с разными IP-адресами.

Развертывание — это контроллер для реплицируемых рабочих нагрузок без отслеживания состояния. Он управляет набором реплик, желаемым количеством реплик, чередующимися обновлениями, откатами и изменениями шаблонов модулей. Обычно вы обновляете развертывание, а не создаете модули вручную.

Служба обеспечивает стабильную сетевую идентификацию и абстракцию балансировки нагрузки для набора модулей, выбранных по меткам. Поскольку IP-адреса модулей меняются, клиенты обычно вызывают DNS/имя службы, а не отдельные модули.

FSDP шардирует параметры/градиенты/optimizer states, tensor parallelism делит операции внутри слоя, pipeline parallelism делит последовательность слоев между устройствами.

FSDP решает прежде всего проблему памяти: параметры, градиенты и optimizer states хранятся шардами на разных GPU, а нужные веса собираются на время computation. Это удобно, когда модель почти помещается по compute, но не помещается по optimizer/parameter memory.

Tensor parallelism делит матричные операции внутри слоя между GPU, поэтому помогает, когда один слой слишком большой или нужно ускорить compute конкретных блоков. Pipeline parallelism размещает разные слои на разных устройствах и прогоняет microbatches через pipeline; его риск - bubbles и сложность балансировки.

На практике техники комбинируют. Выбор зависит от размера модели, interconnect, batch size, activation memory, optimizer, sequence length и tolerable communication overhead.

MLflow фиксирует эксперименты и версии моделей, пайплайны воспроизводят весь расчёт, PySpark обрабатывает большие данные, а хранилище признаков согласует обучение и онлайн-применение.

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

Оркестратор пайплайнов задаёт зависимости, расписание, повторные запуски и наблюдаемость этапов подготовки данных, обучения, проверки и публикации. PySpark нужен не «для промышленности вообще», а когда объём и характер преобразований действительно требуют распределённой обработки.

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