RailX: Reconfigurable Optical Network

• RailX is a reconfigurable, flat optical-circuit-switched network architecture combining intra-node direct connectivity with inter-node circuit switching to enhance hyper-scale LLM training.
• It utilizes an on-package 2D mesh as a high-radix virtual switch and employs Hamiltonian decomposition to form rail-based rings for flexible topologies like 2D-Torus, HyperX, and Dragonfly.
• The design delivers high bisection bandwidth and reduced cost, enabling efficient ring collectives, all-to-all exchanges, and adaptable multi-tenancy in large AI clusters.

RailX is a reconfigurable, flat optical-circuit-switched network architecture for hyper-scale LLM training systems. It combines very high-bandwidth intra-node direct connectivity with scalable inter-node circuit switching, treats the on-package 2D mesh inside each node as a high-radix, high-bisection “virtual switch,” and organizes inter-node ports into rail-based rings that can be Hamiltonian-decomposed into all-to-all connectivity. In the formulation proposed for hyper-scale training, this organization is intended to optimize both ring collectives such as All-Reduce and all-to-all traffic such as MoE expert exchange, while sustaining diameters of 2–4 inter-node hops at scales exceeding 100K chips and reducing cost relative to Fat-Tree deployments (Feng et al., 25 Jul 2025).

1. Problem setting and architectural premise

RailX is motivated by a specific systems tension in large AI clusters: tree-based topologies such as the Rail-optimized network are extremely expensive, while direct topologies such as Torus have insufficient bisection bandwidth and flexibility. The proposed response is a reconfigurable network architecture based on intra-node direct connectivity and inter-node circuit switching, rather than a packet-switched multistage fabric (Feng et al., 25 Jul 2025).

The architecture’s central premise is that the on-package interconnect should be elevated from a local communication substrate to a network-building primitive. Inside each node, an $m \times m$ mesh of chips is directly interconnected using short-reach, high-bandwidth, low-latency die-to-die links such as UCIe and NVLink/UALink. A modern UCIe interface provides $\approx 1317$ GB/s/mm shoreline bandwidth and $\approx 2$ ns latency, with $<1$ pJ/bit energy. RailX uses this intra-node mesh as a bandwidth-rich stage that aggregates and redistributes traffic without the power and latency burden of packet switches.

This organization differs from conventional rail fabrics in two ways. First, the rail abstraction is not realized through high-radix electrical packet switches. Second, inter-node connectivity is not centralized into a single optical switching stage. Nodes and optical switches are physically 2D-organized, which is presented as the mechanism that avoids the scalability bottleneck of centralized circuit switching networks such as TPUv4’s single-stage layer. A plausible implication is that RailX treats package topology, circuit switching, and collective structure as a single co-designed object rather than as separable layers.

2. Physical organization and topology family

RailX defines its physical connectivity with a small set of parameters. Each node’s mesh edge exposes $n$ off-package ports per chip edge, giving

$r = m n$

rails per physical dimension, $X$ and $Y$. Ports are grouped into bidirectional rail pairs per row or column, and all inter-node links connect same-rail IDs. Nodes are arranged in an $(R/2)\times(R/2)$ grid, where $R$ is OCS radix. The rail-to-switch mapping is

• $\approx 1317$0-rail $\approx 1317$1 of node $\approx 1317$2 connects to $\approx 1317$3-OCS $\approx 1317$4
• $\approx 1317$5-rail $\approx 1317$6 of node $\approx 1317$7 connects to $\approx 1317$8-OCS $\approx 1317$9

Each node row or column fans into one group of $\approx 2$0 OCSes, and all identical rail IDs terminate on the same OCS (Feng et al., 25 Jul 2025).

RailX can realize multiple inter-node topologies through circuit configuration rather than through distinct physical fabrics.

Topology	Construction	Inter-node diameter
2D-Torus	Connect $\approx 2$1-rails into parallel rings system-wide	Up to $\approx 2$2 hops
2D-HyperX (switch-less)	Split rails into $\approx 2$3 and $\approx 2$4 sets and Hamiltonian-decompose each set	2 hops
Dragonfly (switch-less at group level)	Locally all-to-all connect $\approx 2$5 nodes with local rails; globally interconnect groups via a subset of rails	3 hops

The 2D-Torus configuration matches 2D ring collectives but has limited bisection for all-to-all. The 2D-HyperX construction is described as a 2D HyperX without packet switches, with two direct links per node pair per dimension. Dragonfly supports larger scales when $\approx 2$6 is very large or $\approx 2$7 is small. This topology family shows that RailX is not a single logical network; it is a circuit-programmable substrate that can instantiate ring-centric or all-to-all-centric organizations over the same physical node-and-OCS layout.

3. Hamiltonian decomposition and rail-based all-to-all

The graph-theoretic basis of RailX is Tillson’s result that directed complete graphs can be decomposed into Hamiltonian cycles. RailX instantiates this with rail-based rings. The key lemma is stated as follows: given $\approx 2$8 nodes, with $\approx 2$9, and each node having $<1$0 rails with $<1$1 ports per rail, one can construct an all-to-all topology from $<1$2 rail-based Hamiltonian rings such that any two nodes $<1$3 and $<1$4 are directly connected on two different rails: $<1$5 on rail $<1$6 and $<1$7 on rail $<1$8 (Feng et al., 25 Jul 2025).

Formally, RailX decomposes $<1$9 into $n$0 directed Hamiltonian cycles, with each cycle corresponding to a rail ring. For odd $n$1, the paper gives a constructive method: form $n$2 bidirectional Hamiltonian cycles from paths

$n$3

and close each path through vertex $n$4. The cycles are edge-disjoint.

This decomposition serves two communication objectives simultaneously. Each rail ring gives a natural ring for bidirectional ring collectives with low per-hop overhead. The union of the rings is an all-to-all fabric with two direct links per node pair, which reduces diameter and increases bisection bandwidth relative to Torus. In the paper’s terminology, RailX thereby organizes separate rail-based rings into all-to-all topology while simultaneously optimizing ring-collective and all-to-all communication.

Dimension splitting extends this idea. A set of rails per physical dimension can be partitioned into multiple logical dimensions with different interconnection patterns such as Torus, HyperX, and Dragonfly. This is the mechanism by which bandwidth can be traded among dimensions and scales, enabling heterogeneous high-dimensional parallelism mapping.

4. Routing, analytical models, and collective performance

RailX uses deterministic dimension-order routing for minimal paths in HyperX: $n$5 then $n$6. The stated deadlock-free condition is that the number of VCs is at least the inter-node diameter plus one,

$n$7

Non-minimal adaptive routing is also described. To avoid hot rails for all-to-all, RailX combines “free” misrouting, limited to $n$8 hops, with Torus-style $n$9 routing in a virtual network, using a small VC budget of $r = m n$0. $r = m n$1 routing on 2D torus is deadlock-free with two VCs; with Bubble flow-control, one VC suffices (Feng et al., 25 Jul 2025).

The paper gives closed-form throughput and latency expressions. For all-to-all throughput per chip,

$r = m n$2

$r = m n$3

$r = m n$4

The HyperX and Dragonfly expressions are notable because they are independent of $r = m n$5 and $r = m n$6.

For bidirectional ring Reduce-Scatter/All-Gather, the ring All-Reduce time is

$r = m n$7

where $r = m n$8 is ring size, $r = m n$9 is data volume, $X$0 per-link bandwidth, and $X$1 per-step latency. For 2D ring All-Reduce on RailX,

$X$2

The hierarchical RailX All-Reduce, which leverages the on-package mesh, is

$X$3

where on-package bandwidth is $X$4 external bandwidth. A direct all-to-all-based All-Reduce on 2D-HyperX is given as

$X$5

The paper’s simulation results for all-to-all report 0.8 flits/cycle/chip—close to the theoretical maximum of 1—when intra-mesh bandwidth is at least $X$6 the inter-node rail bandwidth. With internal equal to external bandwidth, the mesh becomes the bottleneck; at $X$7 the external rail becomes limiting. This result is central to the RailX argument: the mesh must behave as a sufficiently strong virtual switch for the inter-node optical organization to realize its modeled throughput.

5. Scale, cost, multi-tenancy, and failure handling

RailX gives explicit scaling laws. With $X$8-port OCSes, system size and OCS count are

$X$9

$Y$0

The paper states that this exceeds 100K chips with today’s 128-port OCS and modest $Y$1; for example, $Y$2 and $Y$3 give $Y$4. With $Y$5 OCS radices, comparable scales can be achieved even for smaller $Y$6 such as PCB-level modules. The corresponding claim is that more than 100K chips with hyper bandwidth can be interconnected with a flat switching layer (Feng et al., 25 Jul 2025).

The economic model assumes that a 128-port OCS is cost-equivalent to a 64-port electrical switch at approximately \$Y$71000, and that a passive copper 400G cable is approximately \$Y$8\times$Y$9n=9$(R/2)\times(R/2)$0m=7$(R/2)\times(R/2)$1r=63$(R/2)\times(R/2)$2R/2=64$(R/2)\times(R/2)$31.314B for 200,704 chips with 1.8 TB/s per chip injection. A comparable 4-tier nonblocking Fat-Tree is reported at approximately \$(R/2)\times(R/2)$422.1B with 2% of baseline bisection.

These totals are summarized by two normalized claims: the cost per injection or All-Reduce bandwidth of RailX is less than 10% of Fat-Tree, and the cost per bisection or All-to-All bandwidth is less than 50% of Fat-Tree. The paper also states that RailX halves cost relative to HammingMesh while increasing scalability and maintaining bisection throughput.

RailX is also positioned for MLaaS. Dimension splitting is the key mapping primitive: rails per physical dimension can be assigned to logical dimensions associated with TP, CP, EP, DP, or PP. For two target dimensions with traffic volumes $(R/2)\times(R/2)$5 and $(R/2)\times(R/2)$6, the objective can be either

$(R/2)\times(R/2)$7

or

$(R/2)\times(R/2)$8

The paper distinguishes static allocation, where OCS is configured at job start and reconfigured across training stages, from dynamic allocation, where non-overlapping communications such as CP then EP can be separated by an OCS reconfiguration and each use full-dimension bandwidth serially.

Failure handling follows directly from the 2D organization. Because nodes attach to both $(R/2)\times(R/2)$9 and $R$0 OCS groups, one failed node disconnects its row and column. For a single large job, the maximum available rectangle becomes $R$1 if failures are evenly distributed across $R$2 rows and $R$3 columns. The average-case availability is reported as remaining above 90% at 0.1% failure rate. The paper also proposes allocating disjoint sub-rectangles to smaller jobs to utilize functional nodes on faulted grids.

6. Position within optical-rail research and deployment trade-offs

RailX belongs to a broader line of work that rethinks rail fabrics around optical circuit switching. Related work on “Photonic Rails in ML Datacenters” argues that the rail abstraction should be retained while replacing electrical packet switches with OCS, and introduces “parallelism-driven rail reconfiguration” to time-multiplex optical connectivity across the sequential ordering of hybrid parallelism phases (Ding et al., 10 Jul 2025). The later “Photonic Rails in ML Datacenters with Opus” paper provides a concrete control plane, implemented as a PyTorch distributed backend, and reports evaluation on a physical OCS testbed, the Perlmutter supercomputer, and simulation at up to 2,048 GPUs; it shows over $R$4 network power reduction, $R$5 cost savings, and less than $R$6 training overhead at production-relevant OCS reconfiguration latencies (Ding et al., 13 Feb 2026).

Within that research landscape, RailX and photonic rails address related but distinct layers of the design space. RailX specifies a reconfigurable network architecture based on intra-node direct connectivity, inter-node circuit switching, 2D organization of nodes and OCSes, Hamiltonian decomposition, and dimension splitting. Opus-style photonic rails focus on the control-plane problem of safe, efficient in-job reconfiguration aligned to training phases. The data explicitly states that RailX can adopt photonic rails with Opus to retain rail semantics while achieving large power and cost advantages, provided that OCS supports non-blocking programming and $R$7 ms reconfiguration, that ring collectives on rails are acceptable, and that pipeline asymmetry is orchestrated per Send/Recv.

RailX’s deployment trade-offs are correspondingly specific. With “slow” OCSes, configuration occurs at job start or between non-overlapping phases; emerging fast OCS and AWGR fabrics can enable finer-grained reconfiguration but are not required. The architecture also assumes that the intra-node mesh bisection is at least $R$8 inter-node bandwidth to avoid bottlenecks, that path diversity from rail-based rings is sufficient under adaptive Torus routing plus dimension splitting, and that large all-to-all groups may need multiple HyperX or Dragonfly groups rather than a single rail group. The paper therefore presents RailX not as a universal replacement for all cluster topologies, but as a fabric specialized for hyper-scale ML systems in which both ring collectives and all-to-all communication are first-order requirements.