Cloud RDMA virtualization is often treated as a choice between native performance and tenant isolation. Alibaba’s Stellar paper shows a different problem: the usual SR-IOV path couples three independent limits. Virtual functions reserve host memory and device state before a container runs. GPU Direct RDMA depends on PCIe address-translation settings that can conflict with host networking. A queue pair then sees only a small number of network paths even when the fabric contains dozens of equal-cost routes.
Stellar changes all three layers[1]. At the host, para-virtualized direct memory access (PVDMA) pins guest pages only when DMA first touches them. At the RNIC, an extended memory-translation table (eMTT) records whether an address belongs to host or GPU memory and selects the correct PCIe path. In the fabric, oblivious packet spraying distributes one connection across 128 paths and relies on short retransmission timeouts for failure recovery. Alibaba implemented the design on a 400G FPGA-based RNIC and reports more than one year of serverless AI production use.
The result is important because it is not a new congestion-control algorithm attached to an unchanged host. Startup time, GPU access, and in-network queues improve only after virtualization, PCIe translation, and multipath are designed together. It is also company-reported evidence from one cloud architecture. The mechanisms are concrete, but the percentages should not be assumed for a different hypervisor, RNIC, topology, or model parallelism.
Why SR-IOV becomes an AI density limit
An SR-IOV virtual function looks attractive because a guest can submit I/O directly to hardware. The cost appears before useful work starts. VFIO pins a guest’s physical address range and installs IOMMU mappings so a device cannot DMA into another tenant. With hundreds of gigabytes or terabytes assigned to an AI container, setup time and pinned host memory grow with the configured capacity rather than the pages actually touched.
Hardware function counts add a separate ceiling. In Alibaba’s described server, four RNICs sit behind four PCIe switches together with eight GPUs. Each RNIC can expose at most eight virtual functions in the deployed arrangement, for 32 per server, while production GPU servers may need hundreds of virtual instances. More VFs also consume RNIC context and flow-steering resources. The virtualization unit becomes a fixed hardware allocation that does not follow workload lifetime.
PVDMA replaces that eager contract with a para-virtualized one. No guest memory is pinned for Stellar at container startup. On the first DMA to a guest physical region, the guest and hypervisor path register the corresponding host pages with the IOMMU and place the mapping in a cache. Repeated transfers reuse the mapping. The paper uses a 2 MiB registration granularity to balance map-cache size and registration frequency.
On-demand mapping creates a correctness hazard because device registers are mapped at 4 KB granularity while a 2 MiB DMA mapping can overlap them. A stale mapping could cause a GPU command queue to target RNIC doorbell memory after virtual addresses are reused. Stellar separates the address spaces and controls their lifetime so PVDMA mappings cannot alias direct-mapped device registers. This detail is central: lazy pinning is safe only when the hypervisor can prove that guest memory and MMIO regions do not overlap under different page sizes.
GPU Direct needs the RNIC to understand PCIe memory type
GPU Direct RDMA bypasses host copies by allowing the RNIC to access GPU memory. In a virtualized server, the address can pass through the root complex, PCIe switches, an IOMMU, and device translation caches. Alibaba observed that enabling address translation services and changing the IOMMU mode to preserve GPU Direct performance could degrade the host TCP path. One global PCIe configuration was being asked to optimize two different memory targets.
Stellar extends the RNIC memory-translation table with the type of the destination. Host-memory accesses follow the normal IOMMU-protected path. GPU-memory accesses use information in eMTT to select a direct peer path and bypass the root-complex translation and address-translation-cache miss that would otherwise add round trips. The RNIC chooses per registered region instead of forcing the whole server into one PCIe mode.
This mechanism is more general than a GPU optimization. Whenever devices behind different PCIe branches require different translation and isolation rules, a uniform address table can force a compromise. Carrying memory type into the I/O translation decision lets the RNIC preserve protection while choosing a path suited to the target. The price is hardware and control-plane complexity inside a cloud-specific NIC.
Why 128 simple paths beat four sophisticated paths
Large AI collectives create regular but synchronized traffic. If many flows hash onto a few links, queues grow even when the fabric has unused equal-cost paths. Stellar evaluates BestRTT, round robin, dynamic weighted round robin, flowlet-style choices, and oblivious spraying with four and 128 paths per connection. With only four paths, algorithm choice matters. At 128 paths, most multipath schemes converge to similar queue behavior because the fan-out itself covers the topology.
Alibaba’s network has 60 aggregation switches. The paper reports that idealized port balance emerges only near 128 paths, enough to sample all available routes repeatedly. Stellar therefore chooses a simple oblivious packet-spraying algorithm and one shared congestion-control context across the paths. Per-path congestion windows would consume substantially more state and reduce the number of paths the RNIC can support.
The evaluation includes a 512-GPU AllReduce under background traffic that alternates between five seconds active and five seconds idle. The 128-path configurations absorb the burst pattern better than four paths, and oblivious spraying is more stable than round robin. In a 960-GPU AllReduce, the authors inject 1% and 3% packet loss on one link. With 128 paths, the loss is diluted across the connection and performance degradation is almost unobservable; complete link failures use a short retransmission timeout.
Packet spraying requires reordering and a transport that can distinguish a lost packet from a slow path. It also assumes the topology offers enough path diversity. A smaller network may not justify 128 paths, while a less regular workload may benefit from congestion-aware selection. The authors explicitly state that future workload patterns could require a more advanced algorithm. The production lesson is not that oblivious routing is universally optimal. It is that high fan-out can make a simple algorithm robust when RNIC state and topology are designed for it.
Production numbers with different denominators
Stellar supports up to 64,000 virtual devices in the presented architecture and creates a vStellar device in about 1.5 seconds. In controlled experiments, the mechanism accelerates container startup by up to 30×. Production monitoring over more than a year reports a 15× reduction because the denominator includes the broader container path. When configured memory grows from 160 GB to 1.6 TB, startup with PVDMA remains below 20 seconds; the remaining 11-second increase is attributed to general hypervisor work rather than vStellar.
The production deployment reports a 1.37% increase in average RDMA throughput, a 90% reduction in switch queue length, and a 14% improvement in average training speed. The detailed training comparison reports a 6% average improvement and a maximum of 14% across evaluated frameworks and models. These statements use different populations, so the safest reading is that the tail of network congestion changes more than fleet-average link throughput, and communication-heavy training benefits most.
The 90% queue reduction does not imply a 90% application speedup. Queue occupancy is an intermediate network condition. The 1.37% average throughput gain can coexist with a 14% training gain because synchronized collectives are sensitive to the slowest participant and to temporary congestion. Removing a queue tail may have little effect on a long-term byte average while shortening a barrier-bound training step.
Where Stellar is specific to Alibaba
Stellar relies on an FPGA RNIC, a para-virtualized guest driver, hypervisor changes, modified translation tables, a known dual-plane multi-rail topology, and control over the RDMA transport. A cloud using off-the-shelf NIC firmware without programmable translation cannot reproduce eMTT in software. A customer who requires unmodified SR-IOV guests may not accept the para-virtualized interface. The deployment also benefits from Alibaba knowing the collective patterns and routing structure of its AI platform.
PVDMA moves pinning from startup to first use. A workload that touches most of its assigned memory immediately may shift rather than remove the cost, though it still avoids pinning unused capacity. On-demand mappings require cache sizing and safe reclamation. The 2 MiB granularity is a design point, not a property of RDMA. eMTT adds memory-type state that must remain synchronized with GPU allocation and teardown. Packet spraying adds reorder buffers, sequence tracking, and recovery work.
These costs are acceptable when one operator owns the host, NIC, and fabric and can amortize them across a large service. They are harder in an interoperable environment where RNICs, hypervisors, and switches come from different vendors. The paper is therefore strongest as an account of vertical co-design, not as a drop-in recipe.
Cloud RDMA should be admitted as a full path
Stellar changes the unit of capacity planning. A virtual RDMA device is not only a VF count. It consumes pinned memory, IOMMU mappings, RNIC translation and reorder state, PCIe peer paths, and a share of fabric routes. Oversubscribing any one of them can make a nominally available virtual NIC unusable for an AI collective.
Operators evaluating RDMA virtualization should measure at least four stages: time and pinned bytes before the container runs, first-touch registration cost, GPU-to-NIC throughput under the required isolation mode, and collective step time under bursty background traffic. Link throughput alone misses the two places where Stellar finds its largest benefits, startup and queue tails.
The broader lesson is that AI network performance is determined before packets enter the network. Host memory registration chooses the startup envelope. PCIe translation chooses whether GPU Direct remains direct. Path fan-out chooses whether the fabric’s installed links are usable by one synchronized job. Alibaba’s contribution is to treat these as one RDMA product rather than three independent teams’ settings.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the paper’s mechanisms, production measurements, and limits in our own words. No source sentence, table, or figure is reproduced; all figures were created for this article. The paper is available through its ACM DOI. Copyright is held by the authors, with publication rights licensed to ACM, 2025.