Use Cases › Multi-Vendor Clusters
A leading Korean university federated three GPU rooms — one with H100s for training, one with A100s for evaluation, and an L40S inference farm — under a single CNLab scheduler. Pool size tripled effectively; queue depth fell from twelve hours to ninety minutes.
| Effective pool | 2.4× |
| Queue depth (P95) | 12h → 90m |
| Idle resources | −54% |
| Architecture | Multi On-Prem |
The university operated three independent GPU clusters across two campuses. Each had its own scheduler (Slurm in two, Kubernetes in the third), its own login process, and its own queue. Researchers in one department often waited days while another department's GPUs sat idle.
A previous attempt at unification with home-grown scripts failed: the schedulers fought each other, jobs were lost, and faculty trust evaporated. Any new approach had to be incremental — keep the existing schedulers running while CNLab took over orchestration.
CNLab Federated Orchestrator was deployed on a small dedicated control-plane server. Each of the three clusters joined as a peer; existing schedulers were replaced with CNLab's per-cluster scheduler over a four-week phased migration. Live migration between H100 and A100 clusters was enabled where workload compatibility permitted.
"Live migration was the moment it clicked. Watching a job start on the H100 cluster, then move to the A100 room mid-training when load shifted, with no checkpoint — that's when the senior faculty stopped doubting."
— Director of AI Research, top-five Korean university