RDMA can reduce communication overhead in distributed machine learning systems, but realizing these benefits in production requires more than replacing TCP. Variable-size messages, concurrent connections, bursty incasts, and service failures introduce challenges that hardware offload alone cannot address. This paper reports our experience deploying ByteExpress, a software communication layer over hardware RDMA, in ByteDance's parameter-server-based inference and training systems. We present three lessons from the deployment: efficient RDMA requires buffer management across application and transport layers; scalable communication requires coordinated management of connections, receive capacity, and outstanding data; and service availability requires recovery above the transport layer. ByteExpress combines an RDMA-aware allocator, zero-copy transfers, QP multiplexing, receive-credit flow control, a software send window, and RPC-assisted recovery. In production inference, ByteExpress reduces mean and P99 model parameter fetch latency by 35.7% and 43.7%, respectively, and total CPU usage by 10.69% compared with kernel TCP. In training, ByteExpress reduces P99 model parameter push latency by up to 74.0% compared with TCP, with no PFC pauses observed at runtime.
Figures & tables
Figure 1: Parameter-server architecture: rankers fetch sharded model parameters for inference; trainers also push parameter updates.
RC
UC
UD
SEND/RECV
✓
✓
✓
WRITE
✓
✓
✗
READ/ATOMIC
✓
✗
✗
Connection-oriented
✓
✓
✗
Reliable
✓
✗
✗
Maximum message size
2GB
2GB
MTU
Table 1: Comparison of RDMA transports.
Figure 2: Communication stack: Archon provides RPCs; ByteExpress manages buffers and message transfers over hardware RDMA.
Link rate
MTU
RC (Gbps)
UD (Gbps)
25G
1024B
23.15
22.97
100G
1024B
92.26
48.29
100G
4096B
97.03
95.74
200G
4096B
191.36
114.70
Table 2: RC and UD throughput measured with ib_send_bw at different link rates and MTUs.
Figure 4: Allocator operation rate and peak memory versus thread count. Large allocations span 64 KB–1 MB; small allocations span 16 B–16 KB.
Figure 5: Registered RDMA memory footprint on one inference node, sampled every 30 s from startup and stabilizing near 2.2 GB.
Figure 6: Large-message transfer: exchange destination-buffer metadata, write payload fragments, and notify the receiver with a final WRITE_WITH_IMM .
Figure 7: RDMA engine: one QP, receive resources, and a work-request chain partitioned into in-flight, pending, and free entries.
Figure 9
Figure 12: RDMA engine assignment—each engine (and its QPs) belongs to one I/O thread; one thread manages multiple engines.
Figure 11
Resource
Allocation
QP
One per remote address
RQ
One per QP, without SRQ
SRQ
One per thread, when enabled
CQ
One per thread
TD
One per thread
MR
One per registered block
Table 3: Allocation of RDMA resources in BE . Dedicated RQs and per-thread SRQs are alternative configurations.
Figure 15: PS performance in the synthetic inference workloads with no software window or 4, 8, and 16 KB windows.
Window size
Servers before PFC
4 KB
1,218
8 KB
567
16 KB
273
No software control
63
Table 4: Reported server count before PFC is observed, by software window size.
Figure 16: PS performance in a production recommendation inference workload: mean and P99 for TCP and RDMA in microseconds, sampled at one-minute intervals for the busiest rankers.
CPU metric
RDMA
TCP
Reduction
Total CPU usage
51.31%
57.45%
10.69%
Software interrupts
0.16%
1.70%
90.6%
System
4.18%
7.08%
41.0%
User
47.0%
48.7%
3.5%
Table 5: CPU usage during the peak-load Toutiao inference interval. Reductions are relative to TCP.
Latency
RDMA
TCP
Reduction
Mean
8.1 ms
12.6 ms
35.7%
P99
35.5 ms
63.1 ms
43.7%
Table 6: PS Pull latency at inference peak.
Metric
TCP
RDMA HW only
RDMA HW + SW
Fetch P99
650 ms
1.04 s
338 ms
Push P99
1.03 s
1.12 s
268 ms
PFC duration
N/A
1 s per 30 s
0
Loss indicator
1%–4%
3K NAKs per 30 s
0
Table 7: Metrics for the busiest trainers. HW: hardware congestion control; SW: software send window. TCP loss rates and RDMA NAK counts are not directly comparable.
Communication-efficient distributed training reduces the data exchanged among devices so models can be trained faster and over limited-bandwidth networks.
Tail latency dominates the performance of synchronous pretraining jobs when running at very large scales. We describe a three-pronged approach: (1) a new RDMA-based transport protocol, MRC, sprays across many paths and actively load-balances between them, eliminating the issue of flow collisions (2) the use of multi-plane Clos topologies to get the benefits of high switch radix and redundancy, allowing training clusters well over 100K GPUs to be built as two-tier topologies while increasing physical redundancy, and (3) the use of static source-routing using SRv6 to allow MRC the freedom to bypass failures by itself. We describe our experiences running MRC and static SRv6 routing in production in OpenAI and Microsoft's largest training clusters, where it has been used to train the latest frontier models. We demonstrate how MRC allows AI training jobs to ride out many network failures that previously would have interrupted training.
Most recent state-of-the-art (SOTA) large language models (LLMs) use Mixture-of-Experts (MoE) architectures to scale model capacity without proportional per-token compute, enabling higher-quality outputs at manageable serving costs. However, MoE inference at scale is fundamentally bottlenecked by expert load imbalance and inefficient token routing, especially in multi-node deployments where tokens are not guaranteed to be routed to local experts, resulting in significant inter-node all-to-all communication overhead. To systematically characterize these challenges, we profile SOTA open-source MoE models, including Llama 4 Maverick, DeepSeek V3-671B, and Qwen3-230B-A22B, on various datasets and collected over 100k real expert activation traces. Upon studying the expert activation patterns, we uncover various persistent properties across all the frontier MoE models: variable expert load imbalance, domain-specific expert activation where expert popularity shifts across task families (code, math, chat, general), and a strong correlation between prefill and decode expert activations. Motivated by these findings, we propose workload-aware micro-batch grouping and an expert placement strategy to maximize token locality to the destination expert, thereby reducing inter-node communication. Across models and datasets, these optimizations help reduce all2all communication data up to 20, resulting in lower MoE decode latency and better accelerator utilization.
Abhimanyu Bambhaniya, Geonhwa Jeong, Jason Park +6
1Georgia Institute of Technology, USA · 2Meta Platforms, Inc.
The rapid scaling of large language model training requires distributing GPU resources across multiple data center buildings and regions. We refer to such paradigm as "scale-across" training. As infrastructure expands, the system design space becomes increasingly intricate, encompassing new model architectures, hardware heterogeneity, and evolving communication patterns. Drawing from Meta's production experience, we highlight the complexities of deploying training jobs across a few data centers housing hundreds of thousands of GPUs. To accelerate exploration of the large design space and to enable efficient training for frontier model development, we conduct in-depth characterization of three key design dimensions: parallelism placement, parallelism scheduling, and network layer technologies. We then propose ScaleAcross Explorer, an optimizer that considers the interplay of design dimensions and holistically optimizes scale-across training. Testbed experiments and simulations demonstrate up to 64.62% training speedups over production configuration and up to 37.59% training speedups over the state-of-the-art baseline across a wide range of design points.