An AI cloud has two requirements that pull the network in opposite directions. Bare-metal tenants expect direct GPU and RDMA performance, while the operator must enforce address virtualization, isolation and lifecycle control. Putting a full DPU in front of every RNIC satisfies the control requirement but raises server power. Sending all traffic through one shared DPU saves devices but creates a fast-path bottleneck. Tencent’s Pegasus divides the work instead[1].
Each reported server uses one DPU and eight RNICs. The DPU manages configuration, monitoring and virtualization, while tenant RDMA packets continue through the RNICs. Tencent reports that this arrangement saves 10.5% of GPU-server power compared with replacing all RNICs by DPUs. By February 2026, Pegasus had operated for two years across 8,000 GPUs in 1,000 servers[1].
Two flow-table levels preserve the cloud boundary
Separating the DPU from the data path creates a consistency problem. An underlay-to-overlay address change must be visible at both components without exposing one tenant’s traffic to another. Pegasus maintains two flow-table levels across the DPU and RNICs and updates them transactionally. A per-RNIC state machine reduces repeated validation and management exchanges.
This control design is the price of removing the DPU from packet forwarding. The operator gains lower power and direct RNIC throughput, but now depends on correct coordination across two programmable devices. The paper reports that flow-table hash collisions caused tenant interruptions during deployment, illustrating that virtualization faults can move rather than disappear.
Transport moves into the RNIC
Pegasus also avoids requiring tenants to modify their collective libraries. The RNIC spreads individual packets across paths and enforces a credit-controlled sending budget. Packet spraying creates finer path diversity than per-flow ECMP, while credits limit how much traffic enters the network before buffers overflow. Receiver-side reordering handles packets that take paths with different delays.
The design targets a multi-tenant problem. Training, inference and KV-cache transfer generate different patterns, and one cloud must support tenant software the operator does not control. Transparent RNIC offload lets the network react below that software boundary. However, the approach depends on the specific RNIC functions and firmware correctness, which makes hardware qualification part of fabric operations.
Tencent reports production comparisons against its previous AI cluster. Training throughput improved by 7.5% for a 70B dense model and 4.8% for a 7B MoE model on 32 GPUs. A 96-GPU LLaMA 7B run improved by 53.2%. Inference across 16 GPUs under different top-of-rack switches gained 3.7% throughput and reduced average request completion time by 7.2%[1]. The wide range shows that topology and communication mix determine the benefit; it is not a fixed accelerator speedup.
What production deployment proves
Two years and 8,000 GPUs establish that Pegasus is more than a simulator or testbed. The environment reportedly handles about 100 tenant tasks per day, with jobs spanning from one to 2,400 GPUs. This scale is large enough to expose operational bugs and workload diversity, although it remains below dedicated 100K-GPU superclusters.
The evidence supports a specific conclusion: DPU control and RNIC data movement can be separated without giving up tenant isolation, and transport offload can improve workloads without tenant changes. It does not show that every cloud should use one DPU per eight RNICs. The correct ratio depends on port speed, management traffic, failure domains and the capabilities of each device generation.
The DPU becomes a control appliance
Pegasus reframes the DPU as a shared control resource rather than a mandatory packet transit point. That choice resembles disaggregated systems elsewhere in the datacenter: centralize expensive policy and lifecycle functions, then distribute simple high-bandwidth execution. The benefit is independent scaling of control and data bandwidth.
The limitation follows from the same split. Consistency, firmware and state-machine behavior become network reliability concerns. Tencent’s production history makes the trade-off credible because the paper includes these operational failures instead of presenting only throughput. For AI cloud operators, the useful question is therefore not whether a DPU is present. It is which packets and which state must cross it.
Decoupling DPU and RNIC changes the scaling unit
A conventional design can pair one DPU with one high-speed network interface. That arrangement is simple to reason about, but adding link bandwidth also adds control cores, memory and board power whether the workload needs them or not. Pegasus separates the virtualization and policy work on the DPU from packet transport on several RNICs. One control device can therefore present multiple physical links to a bare-metal tenant without replicating the complete control plane for each port[1].
The separation creates a new internal protocol boundary. The DPU must install state, handle lifecycle events and maintain isolation while the RNIC forwards at line rate. If every packet crossed that boundary for a decision, the design would merely move the bottleneck. Pegasus instead places fast-path transport work in the RNIC and uses a per-RNIC state machine for control communication. The useful comparison is control messages and reaction latency per interface, not only the number of attached NICs.
Failure ownership also becomes more complex. An RNIC can lose link or enter an error state while the shared DPU continues serving the remaining interfaces. Conversely, a DPU fault can affect several network paths at once. Production design needs explicit reset domains, state replay and health reporting so one component can recover without exposing another tenant’s state or requiring a server reboot.
Two-level flow state performs translation and isolation
Bare-metal tenants want direct device access while the cloud operator still needs overlay addresses, underlay routing and policy enforcement. Pegasus divides flow-table work between the DPU and RNIC. The DPU holds the cloud-facing virtualization context; the RNIC applies the information needed for high-rate forwarding. This split avoids making the RNIC implement the full cloud control plane while keeping per-packet decisions close to the wire.
State consistency is the central cost. A rule cannot become active on one side while the other side still interprets the flow using an old mapping. Updates need ordering, versioning or a staged transition. Deletion is equally sensitive because delayed packets can arrive after control software believes a flow has ended. The paper’s two years of deployment are valuable evidence that this lifecycle can be operated, although the public summary does not quantify update latency or failure-recovery tails.
Scale should be measured in active flows and churn, not only GPUs. Training jobs may use a smaller number of long-lived elephant flows, while inference and shared services can create more connections. A table sized for one traffic mix can overflow under another. Useful capacity data would include entries per DPU and RNIC, insertion rate, eviction behavior and performance during bursts of tenant creation.
Packet spreading requires a reordering contract
Per-packet load balancing can use all available paths more evenly than assigning one long flow to one path. It can also deliver packets out of order when routes have different queueing or propagation delay. RDMA transports are sensitive to this effect because a missing sequence position can hold later data. Pegasus therefore needs reordering optimization together with path spreading; quoting link utilization without the receiver-side delay would hide the cost.
The relevant path set must avoid shared failure and congestion points. Two routes that diverge at one switch but reconverge on the same oversubscribed uplink do not provide independent capacity. The RNIC needs enough topology or performance feedback to distinguish useful alternatives. Hardware jitter matters because a credit or scheduling loop can mistake a short processing delay for persistent congestion and overcorrect.
Credit-based congestion control limits sending according to receiver or network capacity. Credits can prevent queues from growing without bound, but a conservative allocation leaves bandwidth idle on long paths. A large allocation increases in-flight data and the cost of a sudden hotspot. The control loop must cover several workload sizes and distances, which is why transparent transport offload is more than moving an existing algorithm into hardware.
Power savings need a full-system denominator
Tencent’s architecture is motivated partly by avoiding a complete DPU for every RNIC. That can reduce card count, memory and control-plane power. However, the saving should be reported against the whole server path: shared DPU, all RNICs, host CPU work, PCIe switching and any additional management logic. Moving a task off one device is not a system reduction if another component performs the same work at higher utilization.
Performance must use the same denominator. A single RNIC microbenchmark can show line rate while the shared DPU becomes the limit during simultaneous tenant changes or error recovery. The appropriate stress test drives every attached RNIC, creates and removes flows, injects route changes and measures both data-plane throughput and control-plane tail latency. Isolation should be checked under an adversarial tenant, not only balanced cooperative jobs.
The public deployment covers about 8,000 GPUs and more than two years[1]. This is strong operational evidence for the stated environment. It does not reveal total fabric size in bisection bandwidth, oversubscription, tenant count or energy per delivered bit. Those missing denominators prevent direct ranking against another cloud network, but they do not weaken the architectural lesson about separating control capacity from link capacity.
Operational lessons are part of the result
Multi-tenant bare metal removes some hypervisor overhead and also removes a convenient software interception point. The network hardware must enforce address translation and isolation without depending on a host agent that the tenant can modify. Observability must cross the DPU-RNIC split: operators need to correlate a virtual flow, both table entries, the selected paths, credit state and physical counters.
Safe upgrades are another requirement. RNIC transport firmware and DPU control software evolve at different rates, so protocol versions must coexist during a fleet rollout. A new feature cannot require every server to change simultaneously. Rollback must restore compatible state, including flows that were created during the transition. A two-year deployment implies that such procedures exist even though the paper’s abstract emphasizes data-plane mechanisms.
Pegasus should therefore be read as a cloud architecture, not only a congestion-control paper. Its main decision is to scale transport bandwidth with relatively focused RNIC resources while sharing the heavier virtualization control plane. Packet spreading and credits make those links useful for AI traffic, while state machines and two-level tables preserve the cloud boundary. The design is compelling where an operator controls both devices and can validate their joint lifecycle; it is harder to adopt as two independent commodity products.
Source and copyright notice
This article is an independent editorial summary of the Tencent-led SIGCOMM 2026 paper and official conference abstract. We restated the architecture, measurements and deployment limitations in our own words. No source text, table, figure or implementation diagram is reproduced. The explanatory figure was created specifically for this article. The paper is distributed under the rights statement shown by its publisher; copyright remains with the authors and ACM 2026 as applicable.