Leaf-centric Logical Topology Design for OCS-based GPU Clusters

TL;DR

This paper proposes a leaf-centric logical topology design for OCS-based GPU clusters to improve ML training throughput by balancing traffic loads and avoiding routing polarization.

Contribution

It introduces a novel leaf-centric paradigm, provides a theoretical condition to prevent routing polarization, and offers an efficient topology design algorithm.

Findings

Achieves up to 19.27% throughput improvement in simulations.

Reduces logical topology computation overhead by 99.16%.

Validates the approach through large-scale simulations.

Abstract

Recent years have witnessed the growing deployment of optical circuit switches (OCS) in commercial GPU clusters (e.g., Google A3 GPU cluster) optimized for machine learning (ML) workloads. Such clusters adopt a three-tier leaf-spine-OCS topology, servers attach to leaf-layer electronic packet switches (EPSes); these leaf switches aggregate into spine-layer EPSes to form a Pod; and multiple Pods are interconnected via core-layer OCSes. Unlike EPSes, OCSes only support circuit-based paths between directly connected spine switches, potentially inducing a phenomenon termed routing polarization, which refers to the scenario where the bandwidth requirements between specific pairs of Pods are unevenly fulfilled through links among different spine switches. The resulting imbalance induces traffic contention and bottlenecks on specific leaf-to-spine links, ultimately reducing ML training throughput. To mitigate this issue, we introduce a leaf-centric paradigm to ensure traffic originating from the same leaf switch is evenly distributed across multiple spine switches with balanced loads. Through rigorous theoretical analysis, we establish a sufficient condition for avoiding routing polarization and propose a corresponding logical topology design algorithm with polynomial-time complexity. Large-scale simulations validate up to 19.27% throughput improvement and a 99.16% reduction in logical topology computation overhead compared to Mixed Integer Programming (MIP)-based methods.