More Bandwidth Will Not Fix a Passive AI Network: Introducing Active Compute Fabric
Key takeaways:
AI performance is now a network problem. As clusters scale, communication, synchronization, and collective operations can leave expensive accelerators waiting. More bandwidth alone does not fix the underlying coordination problem.
A network that computes recovers that time. Active Compute Fabric makes the network an active participant in AI processing by performing computation and collective operations closer to where data is already moving.
Open standards keep the choice with the buyer. An open, standards-aligned approach gives organizations a path to in-network compute without locking their infrastructure into a proprietary ecosystem.
AI infrastructure is a utilization business
AI needs a network that computes. Connecting accelerators is no longer enough. At AI Infra Summit in Santa Clara, Cornelis introduced a new category of network built for that job. Active Compute Fabric™ is an AI and HPC interconnect that works for the workload rather than only carrying it. While InfiniBand and Ethernet forward packets between endpoints, the Active Compute Fabric computes at every hop, so congestion control and collectives run in the network instead of on your accelerators. One open architecture, across scale-up and scale-out.
AI infrastructure operators invest in accelerators, servers, networking, power, cooling, data center space, and operations. The return on that investment depends on how much useful work the entire system produces.
When accelerators wait instead of compute, the costs keep accumulating. Capacity has been purchased, powered, cooled, and staffed, but it is not producing output. At scale, small utilization losses raise the cost of training and inference, extend time to results, and create pressure to buy more hardware. That makes accelerator utilization a business metric as much as a technical one. Operators need more useful work from existing clusters, lower cost per workload, faster time to results, and better returns on infrastructure they have already funded.
Cornelis model from published training profiles. MFU range: Meta, Llama 3 (2024). Communication share: arXiv 2509.15940, 2608.15118, 2402.06787. Pipeline bubbles: Meta, ISCA 2025.
Active Compute Fabric addresses this economic problem at the fabric level by helping AI infrastructure deliver more productive output from every accelerator-hour. And the economics of AI are bringing networking into the center of infrastructure decisions. As Tony Pialis of Qualcomm Technologies notes, moving data efficiently across the rack is becoming just as important as compute itself:
“As AI systems continue to scale, moving data efficiently across the rack becomes just as important as the compute itself. Improving utilization and AI economics will require a more integrated approach across compute, memory, and networking, and Cornelis’ vision for an open, programmable fabric aligns with that industry direction. Giving customers more choice and flexibility across the infrastructure stack will be critical as AI moves toward rack-scale architecture.” — Tony Pialis, EVP and GM, Data Center, Qualcomm Technologies, Inc.
The economics of idle AI infrastructure
AI infrastructure is becoming a single system. A cluster with 1 million GPUs could draw 1.2 GW at one site, with every xPU communicating across the system. At that scale, network behavior directly affects compute performance. When the fabric only forwards traffic, synchronization and data movement leave expensive accelerators waiting.
A Cornelis model estimates that only 52% of machine time produces useful compute in a large AI cluster. The remaining 48% is unproductive time, including 25% spent waiting for communication, 13% lost to pipeline bubbles, and 10% lost to memory stalls. Not all unproductive time comes from the network, but communication wait is a direct network tax. It lowers accelerator utilization, extends time to results, and raises the cost of every workload.
The economic impact grows with cluster size. Under the Cornelis cost model with an assumed $4 per GPU-hour , each percentage point of utilization is worth approximately $3.5 million at 10,000-GPU scale. At 100,000-GPU scale, the model estimates $1.68 billion in wasted capacity and 500 GWh of wasted energy each year. A cluster of that size may also include more than $2 billion in network infrastructure that moves the workload without directly helping perform it.*
*Cornelis model from published training profiles. MFU range: Meta, Llama 3 (2024). Communication share: arXiv 2509.15940, 2608.15118, 2402.06787. Pipeline bubbles: Meta, ISCA 2025
Cornelis model: $4.00/GPU-hr, ~48% unproductive; U.S. home energy ~10,500 kWh/yr (EIA).
That is why Cornelis is not selling faster networking. The argument is that the network can recover productive output from the billions of dollars of AI infrastructure already installed and the billions more being planned. Operators need more useful work from every accelerator-hour, lower cost per job and per token, faster time to results, and better returns on capacity they have already bought. A passive network makes every one of those goals harder to reach.
The network was built to forward traffic, not to participate in computation
Compute, storage, and memory have evolved to understand the workloads they support. The network has mostly remained unaware of what runs on it. It moves bits faster but treats AI traffic as packets to forward rather than as part of a coordinated operation.
Those synchronized exchanges create a transport problem. Distributed AI generates bursts of synchronized traffic, and thousands of accelerators may need to make progress together. Routing, delivery, congestion, and timing all affect whether the cluster continues to move forward. A conventional fabric provides transport, but it does not actively manage the progress of the workload.
The same limitation appears in collective operations. In an AllReduce operation, each accelerator contributes partial results that must be exchanged, combined, and distributed across the group. A conventional fabric forwards those messages, but the endpoints remain responsible for much of the collective work. Adding bandwidth may move the messages faster, but it does not remove the communication work.
Some intelligence has been added at the network edges through technologies such as Data Processing Units (DPUs) and Infrastructure Processing Units (IPUs). These technologies can reduce work at individual endpoints, but they do not create broad coordination throughout the fabric. In a conventional network, each hop forwards traffic without contributing to the computation.
That is why the problem is difficult to solve. The network must maintain predictable transport, accelerate operations while data is in motion, and provide programmable compute throughout the path. It must do this while preserving ordering, reliable delivery, congestion control, high-speed performance, software compatibility, and interoperability.
The fabric must transport, accelerate, and compute
Active Compute Fabric treats the network as an active part of AI processing. The architecture combines active transport, active acceleration, and active compute, and it applies them to both sides of the network problem. Scale-out fabric is where Cornelis built its reputation in HPC and AI. Scale-up, the interconnect inside the rack where accelerators share memory and exchange the highest volume of traffic, is where this launch extends that work. Most vendors address one side or the other. Treating scale-up and scale-out as one coordinated fabric is what lets the network manage workload progress end to end, rather than handing the problem off at the rack boundary.
Active transport is the foundation. Intelligent routing, lossless delivery, congestion management, and predictable performance help the fabric keep synchronized workloads moving under changing traffic conditions. For a 100,000-GPU cluster, the architecture is designed to provide 17 Pbps of injection bandwidth. The objective is not simply to move more bits. It is to move traffic in a way that supports workload progress.
Active acceleration performs network operations where the data is already moving. In-network collectives can reduce repeated transfers between endpoints, while network-assisted KV cache movement can help limit unnecessary data movement during inference. Five acceleration engines address collectives, KV cache movement, Mixture-of-Experts dispatch, MPI and HPC, and PGAS and SHMEM workloads. Cornelis model projections show up to 2x effective AllReduce bandwidth in modeled configurations.
Active compute distributes programmable compute throughout the fabric rather than concentrating intelligence only at the endpoints, with our Distributed Compute Fabric™ (DCF). A 100,000-GPU configuration includes over 1.1 million RISC-V cores and approximately 1.2 TB of distributed SRAM across the network. That is compute at every hop. NICs and switches can filter, reduce, route, and process data in flight before passing it onward.
Programmability matters because models, software, data types, and communication patterns will continue to change. A fixed-function fabric can only accelerate the operations that were hardwired into the ASIC when it taped out, so every new collective or dispatch pattern waits for the next silicon generation. Active Compute Fabric puts programmable cores at every hop, and fabric functions are not limited to what the silicon shipped with. New collectives, new dispatch patterns, and new inference techniques can be added in software as workloads evolve.
Planned capabilities for Active Compute Fabric
Active Compute Fabric includes capability engines that act on data as it moves through the network. The engines run on one shared substrate of embedded processors in the SuperNIC, and several extend into the switch when a Cornelis switch is in the fabric. Each targets a specific place where AI and HPC workloads lose accelerator or CPU time. The six engines below make up the initial set. Cornelis can add more through firmware updates as workloads change.
KV cache acceleration. Offloads the scatter-gather transfers of KV cache blocks between inference nodes, quantizes them in flight (skipped when the source is already FP8 or FP4), routes requests to nodes that hold a matching prefix, and multicasts shared prefixes to many nodes at once. The target is faster time to first token and less redundant data movement.
Mixture-of-Experts dispatch. Packs, filters, deduplicates, and routes tokens for the all-to-all exchange between experts, and reports per-expert telemetry so the gating function can balance load. Dispatch work moves off the accelerators in every MoE layer.
In-network collectives. Runs AllReduce, Reduce-Scatter, and AllGather in the SuperNIC, with optional in-network quantization. The switch is designed to conform to the in-network collectives defined in the Ultra Ethernet Consortium 1.0 specification. Accelerators spend fewer cycles on collective operations.
MPI and HPC offload. Hardware tag matching, persistent schedule replay, and reductions in the SuperNIC take small-message progress off the host CPU.
PGAS and SHMEM. One-sided put and get, hardware completion, atomic operations on NIC-local memory, and batch submission give partitioned global address space applications low-overhead access to remote memory.
Checkpoint acceleration. Compresses and encrypts checkpoint streams at line rate on their way to remote storage, and multicasts restores back out to the cluster. Shorter checkpoint and restore windows mean more goodput from long training runs.
Together, these engines target the two largest communication overheads in distributed training and HPC simulation: GPU time spent on collectives and host CPU time spent on small-message progress. Because they run on programmable cores, Cornelis can add to this list in software.
Recapture wasted compute cycles with network intelligence
Cornelis model projections show training GPU utilization rising from 50% to 60% with Active Compute Fabric, a recovery of 10 percentage points. Using the cost model above, that recovery is worth roughly $38.5 million per year at 10,000 GPUs and roughly $385 million per year at 100,000 GPUs. The same projections show 2.5x to 4x better cost per token for Mixture-of-Experts workloads and 1.8x to 2.5x better cost per token for long-context workloads.
Cornelis model: CN7000 design target of projected benefit; not final and subject to change.
Open standards keep the choice with the buyer
Open standards matter to buyers for a practical reason: they decide who controls the next purchase. A proprietary fabric ties the network roadmap, the software stack, and often the accelerator choice to one vendor. Every expansion inherits that dependency.
Active Compute Fabric builds on the standards the industry is converging on. For scale-out, the CN7000 SuperNIC runs UE+, RoCEv2, MRC, and standard Ethernet on one port, with a UEC-conformant transport as the primary AI protocol. Cluster architects choose the protocol per workload on one SuperNIC and one fabric. For scale-up, Cornelis builds on UALink and ESUN.
The modeling above shows what that choice is worth. Most of the projected gain from the capability engines comes from the SuperNIC on a standard Ethernet fabric. A Cornelis switch adds more, but it is not a prerequisite. Active Compute Fabric is built as an open, standards-aligned architecture that preserves interoperability and ecosystem choice.
Open-standard scale-up and scale-out networking for AI represents more than $55 billion of opportunity by 20301. (1. 650 Group, Jan 2026. Dell’Oro Group AI NIC and Backend Network Forecasts, Feb 2026)
Work at the Ultra Ethernet Consortium and the UALink Consortium is defining that open direction, and Active Compute Fabric connects to it rather than competing with it. Buyers get in-network compute without another proprietary dependency or another set of free handcuffs.
Economic, utilization, and inference figures are based on Cornelis models and stated assumptions. Actual results vary by workload, system configuration, and operating conditions.
Evaluate the fabric by the useful work it produces
Choice only helps if buyers know what to measure. Most AI networking evaluations start with port speed, bandwidth, and latency. Those metrics describe the link. They do not show how much useful work the cluster completes, and that is the number that determines the return on the infrastructure.
Start with representative training and inference workloads and measure where the current fabric leaves capacity unused: accelerator utilization, time to results, endpoint overhead, and cost per job or per token. Identify the collective operations that matter most in your environment and watch for the ones where waiting persists even after bandwidth has increased. That is where an active fabric has the most to recover.
Then test under production-like conditions, with realistic traffic patterns, congestion, message sizes, and the scale your organization plans to operate. Confirm integration with existing hardware and software, alignment with open interfaces, and support across the broader AI networking ecosystem.
Run this evaluation before the next capacity purchase. Another generation of accelerators will expose the same coordination bottleneck, and a passive network will become the reason to buy more compute.
Make the next capacity decision about useful work
In every infrastructure cycle so far, the network has been treated as plumbing, a passive pipe under your most critical infrastructure. This is the cycle where that changes, because the economics finally force the question. When half of compute time in a large cluster is unproductive, the network is the largest lever operators have not pulled.
Last week we put a name and an architecture on that lever, one that spans scale-up and scale-out so the fabric manages the workload end to end instead of handing it off at the rack boundary. What follows is the more interesting work of proving it in production, building it with partners who share the open-standards view, and expanding what the fabric can do as workloads keep changing.
If you are planning your next cluster, start measuring where the current fabric leaves compute capacity on the floor. That number is the opportunity, and it is bigger than any bandwidth upgrade on the market.
Reclaimed capacity is not the end goal. It shows up as more tokens served per dollar, more training runs per quarter, and inference that gets cheaper as you scale. Cornelis has spent years making fabrics that keep large systems productive. Active Compute Fabric is that work applied to the economics of AI.
FAQ
1. What ships when?
CN5000 is shipping. CN6000 is sampling ahead of expanded availability in Q4 2026. CN7000, which delivers the full vision of the Active Compute Fabric, is targeted for customer deployments in 2028.
2. What is an Active Compute Fabric?
An Active Compute Fabric™ is an AI and HPC interconnect that works for the workload rather than only carrying it. Where InfiniBand and Ethernet forward packets between endpoints, it computes at every hop, so congestion control and collectives run in the network instead of on your accelerators. One open architecture, across scale-up and scale-out. Cornelis introduced Active Compute Fabric in September 2026.
3. How is Active Compute Fabric different from a DPU or SmartNIC?
DPUs and SmartNICs offload network overhead at individual endpoints. Active Compute Fabric puts programmable RISC-V cores in both the Cornelis SuperNIC and the switch, so the network runs AI and HPC functions as data moves through it. Those functions include collectives, KV cache movement, and Mixture-of-Experts dispatch. A 100,000-GPU configuration includes 1.1 million RISC-V cores across the fabric.
4. How much can Active Compute Fabric improve GPU utilization?
GPUs in large AI clusters often run at about 50% utilization. Cornelis estimates an active network can raise that by five to ten points. Under a Cornelis cost model of $4 per GPU-hour, each point is worth about $35 million a year on a 100,000-GPU cluster. Cornelis modeling for CN7000 projects training utilization rising from 55% to 66%.
5. Does Active Compute Fabric require a Cornelis switch?
No. The Cornelis SuperNIC runs on standard Ethernet fabrics, and Cornelis modeling shows it delivers most of the projected gain from the capability engines there. Adding a Cornelis CN7000 switch increases that gain. Active Compute Fabric builds on open standards: Ultra Ethernet, RoCEv2, and standard Ethernet for scale-out, and UALink and ESUN for scale-up.