Red HatLinoy BitanExplainer
Distributed training on OpenShift AI 3.4 with Kubeflow Trainer v2
Summary
Red Hat OpenShift AI 3.4 introduces Kubeflow Trainer v2, a unified training API that replaces framework-specific CRDs like PyTorchJob and TFJob with a single TrainJob resource. Under the hood, each TrainJob is translated into a JobSet, a Kubernetes-native API for managing groups of Jobs as a single unit, which handles headless services for pod discovery and automatic failure recovery. The post validates the stack through two phases: manual validation with a minimal NCCL all-reduce test across 2 nodes, and real-world training of an embedding-based neural network on a fraud detection dataset using 1, 2, and 4 NVIDIA A10G GPUs. Benchmarking shows near-linear Distributed Data Parallel scaling at 95% efficiency, successful checkpoint recovery after pod kills, and GPU utilization confirmed via DCGM Exporter. The TrainJob API simplifies distributed training by automatically configuring torchrun, environment variables, and pod coordination, while raw JobSets offer more control for multi-stage pipelines and differentiated failure handling.
Context
Running distributed training on Kubernetes required framework-specific CRDs (PyTorchJob, TFJob, MPIJob) with different semantics and configuration, making it complex to manage.
Approach / What changed
Kubeflow Trainer v2 introduces a unified TrainJob API that replaces framework-specific CRDs. It translates each TrainJob into a JobSet, which manages headless services for pod discovery, automatic failure recovery, and startup sequencing. The stack includes NVIDIA GPU Operator, Node Feature Discovery, cert-manager, and optionally Kueue for gang scheduling.
Takeaways
The TrainJob API automatically configures torchrun, environment variables, and pod coordination, eliminating manual MASTER_ADDR and entrypoint scripts.
Both TrainJob and raw JobSet paths delivered near-linear DDP scaling at 95% efficiency on a fraud detection dataset with 1, 2, and 4 NVIDIA A10G GPUs.
JobSet failure policies allow different actions per stage: FailJobSet for data preparation failures to avoid wasted GPU time, and RestartJobSet for training failures with checkpoint recovery.
FAQ
How does Kubeflow Trainer v2 simplify distributed training?
It provides a single TrainJob API that references a prebuilt ClusterTrainingRuntime, automatically handling torchrun, node coordination, and environment variables. You only specify training code, node count, and GPU requirements.
What is the difference between TrainJob API and raw JobSet?
TrainJob handles distributed setup automatically, while raw JobSet gives full control but requires manual configuration of MASTER_ADDR, WORLD_SIZE, and torchrun commands. Both use the same underlying JobSet Operator.
How does fault recovery work?
JobSet failure policies allow FailJobSet for data prep failures (no wasted GPU time) and RestartJobSet for training failures. Restarted runs resume from saved checkpoints, completing faster than starting from scratch.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.