Broadcom Tomahawk 6 vs Nvidia NVLink Fusion 2026

For a decade, buying an Nvidia AI cluster meant buying Nvidia’s network too — NVLink inside the rack, InfiniBand between them, and a bill of materials where the fabric quietly consumed 15 to 20 percent of the capital budget. Broadcom’s latest AI guidance breaks that assumption in public: hyperscalers are placing multi-billion-dollar orders for custom XPU pods stitched together with 102.4 Tbps Tomahawk 6 Ethernet, not for full GB300 NVL72 racks. The Broadcom Tomahawk 6 vs Nvidia NVLink question has moved from a whiteboard argument to a line item you have to defend in a 2026 capacity plan. If you are sizing training or inference capacity for next year, “Nvidia end-to-end” is now a choice you must justify rather than one you inherit.

What’s actually new in Broadcom Tomahawk 6 vs Nvidia NVLink

Tomahawk 6 is a single-die-class switch ASIC delivering 102.4 Tbps of switching capacity — double Tomahawk 5’s 51.2 Tbps, and enough to terminate 64 ports of 1.6T or 128 ports of 800G on one chip. Radix is the headline, not raw bandwidth. A 128-port switch collapses a three-tier Clos into two tiers for the same endpoint count, stripping out a full hop of latency, a full layer of optics, and a meaningful slice of the power budget. Broadcom also ships it in a co-packaged optics variant, which matters because at 1.6T per port the pluggable transceivers, not the ASIC, become the reliability and wattage problem.

The strategically interesting part sits above the ASIC. Scale-up Ethernet — the effort to make Ethernet behave like a memory-semantic interconnect inside a rack, with link-layer retry, credit-based flow control, and sub-microsecond switch latency — targets exactly the domain NVLink has owned. Nvidia’s answer, NVLink Fusion, opens the NVLink protocol to third-party CPUs and custom accelerators, letting a hyperscaler’s own silicon join an NVLink domain instead of being locked out of it. Both vendors are converging on the same customer: the hyperscaler that designs its own custom XPU and wants it to scale past a single chassis.

Broadcom’s forecast language tipped the read. AI networking revenue growing faster than AI accelerator revenue, plus disclosed multi-billion-dollar XPU commitments from a small set of named-but-unnamed customers, tells you the pods are being built with merchant Ethernet fabric. Nvidia still ships far more AI silicon by revenue, and NVL72 remains the fastest path from purchase order to running tokens. But “fastest path” and “only path” are different claims, and only one of them is still true.

Why it matters

• Fabric pricing becomes negotiable. When NVLink was the only scale-up option, the interconnect had no competitive substitute and priced accordingly. A credible scale-up Ethernet AI fabric gives procurement an alternative quote to put on the table, and that changes the number even for buyers who ultimately stay with Nvidia.
• Tier collapse beats bandwidth on TCO. The 102.4 Tbps switch’s value lies mostly in eliminating a switching tier at scale. Fewer tiers means fewer optics — often the single largest line in a large fabric — plus lower power and fewer failure domains. Model the optics count, not the port speed.
• Custom silicon gets a viable exit from the rack. A TPU-class or Trainium-class accelerator previously hit a wall at chassis boundaries without a scale-up interconnect. Ethernet-based scale-up removes the wall, which raises the expected return on every internal accelerator program and pulls more of them into production.
• NVLink Fusion is a defensive concession with teeth. Opening NVLink to third-party accelerators keeps custom XPUs inside Nvidia’s fabric rather than pushing them onto Ethernet. It is a real product, and for anyone mixing custom silicon with Blackwell-class GPUs in one coherent domain it is currently the more mature option.
• Software portability is the actual lock-in. If NCCL, the collectives library, and the topology-aware scheduler are tuned for NVLink domains, swapping the physical fabric does not free you. The 2026 fight is over collective-communication libraries, not cables.
• Lead time is a first-class variable. Merchant Ethernet switches come from many ODMs with shorter queues. If you can get Tomahawk 6 systems two quarters before your NVL72 allocation clears, the slower fabric that exists beats the faster one that does not.

How to use it today

You cannot buy a Tomahawk 6 pod this afternoon, but you can build the analysis that decides your 2026 order — and measure whether your current workload is even sensitive to the difference.

1. Measure your collective bandwidth ceiling first. Most teams assume they are interconnect-bound without checking. Run NCCL tests across the largest domain you have and compare bus bandwidth against the theoretical link rate.

   git clone https://github.com/NVIDIA/nccl-tests.git
   cd nccl-tests && make MPI=1 MPI_HOME=/usr/lib/x86_64-linux-gnu/openmpi CUDA_HOME=/usr/local/cuda
   
   # 8 GPUs per node, 8 nodes: sweep 8 MiB to 8 GiB
   mpirun -np 64 -N 8 --bind-to numa \
     ./build/all_reduce_perf -b 8M -e 8G -f 2 -g 1 -c 1
   

   If the busbw plateau sits well below your link rate at 512 MiB and up, you have a fabric or topology problem worth spending on. If it plateaus near line rate, your bottleneck is elsewhere and the Tomahawk 6 102.4 Tbps switch conversation is premature.

2. Confirm your topology is what you think it is. Rail-misaligned NICs silently cost 30 percent of collective bandwidth and are frequently mistaken for fabric limits.

   nvidia-smi topo -m
   nvidia-smi nvlink --status -i 0
   ibstat 2>/dev/null || rdma link show
   

3. Force a fabric A/B on the same job. Pin NCCL to RDMA-over-Ethernet, then to NVLink, and diff the step times. This is the closest local proxy for the scale-up Ethernet versus NVLink decision.

   # Ethernet/RoCE path only — disable intra-node NVLink shortcuts
   NCCL_P2P_DISABLE=1 NCCL_SHM_DISABLE=1 \
   NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3 \
   NCCL_IB_QPS_PER_CONNECTION=4 \
   NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=INIT,GRAPH \
     torchrun --nproc_per_node=8 train.py
   
   # NVLink-enabled baseline
   NCCL_P2P_LEVEL=NVL NCCL_DEBUG=INFO \
     torchrun --nproc_per_node=8 train.py
   

   Grep the INIT output for the ring or tree topology NCCL selected. If it chose a different algorithm between runs, your step-time delta includes an algorithm change, not just a fabric change.

4. Price the optics, not the ports. Build the switch-count model before you talk to any vendor. Radix drives everything downstream.

   # fabric_tco.py — tier and optics count for a non-blocking Clos
   def clos(endpoints, radix):
       leaf = -(-endpoints // (radix // 2))          # ceil
       spine = -(-(leaf * (radix // 2)) // radix)
       tiers = 2 if leaf * (radix // 2) <= radix * (radix // 2) else 3
       optics = endpoints + (leaf * (radix // 2)) * 2  # host + fabric ends
       return dict(leaf=leaf, spine=spine, tiers=tiers, optics=optics)
   
   for name, radix in (("TH5 800G", 64), ("TH6 800G", 128)):
       print(name, clos(endpoints=8192, radix=radix))
   

   Multiply the optics delta by your real transceiver price and your observed optics failure rate per year. That number, not the ASIC price, usually decides it.

5. Write the RFP question that actually separates vendors. Send the same paragraph to Nvidia, Broadcom’s ODM partners, and your integrator:

   For a 4,096-accelerator pod running 70B-class dense training with
   tensor parallelism inside the scale-up domain:
   1. What is the scale-up domain size in accelerators, and what breaks
      at the boundary — bandwidth, latency, or coherence semantics?
   2. Measured all-reduce busbw at 1 GiB and 8 GiB message sizes,
      on production silicon, with the collectives library you ship.
   3. Total pluggable optics count and expected annual optics AFR.
   4. Which collectives library, and what is the porting cost from NCCL?
   5. Delivery date for the full pod, not first article.
   

   Question 4 reveals lock-in. Question 5 usually decides the order.

How Tomahawk 6 and NVLink Fusion compare

Dimension	Broadcom Tomahawk 6 (scale-up Ethernet)	Nvidia NVLink Fusion / NVL72
Switch capacity	102.4 Tbps per ASIC; 64×1.6T or 128x800G	NVLink Switch inside the rack; InfiniBand or Spectrum-X between racks
Scale-up domain	Rack-scale and beyond via Ethernet; domain size set by your design	72 GPUs coherent in NVL72; extends via NVLink Fusion to partner silicon
Memory semantics	Message-passing with link-layer retry; load/store semantics still maturing	Mature load/store and coherent addressing across the domain
Third-party accelerators	Open by construction — any NIC that speaks Ethernet	Supported via NVLink Fusion, under Nvidia’s licensing and validation
Software stack	Vendor collectives libraries; NCCL portability varies by implementation	NCCL, and the full CUDA topology-aware tooling
Supply	Multiple ODMs, competitive pricing, shorter lead times	Allocation-constrained; single vendor sets the price
Integration risk	You own the design, tuning, and the blast radius	Reference rack; Nvidia owns the integration
Best fit	Hyperscalers with custom XPUs and platform engineering depth	Anyone who needs working capacity fast with existing CUDA workloads

What’s next

Watch Broadcom’s AI networking revenue line separately from its XPU line over the next two quarters. If networking keeps outgrowing accelerators, it confirms that customers are buying fabric independently of who supplies the compute — the whole thesis. If XPU revenue concentrates in two or three customers while networking broadens across many, Ethernet scale-up is winning generally, even where custom silicon is not.

The second signal is Ultra Ethernet Consortium spec maturity and, more importantly, whether shipping silicon implements the hard parts: packet spraying with in-order delivery at the endpoint, selective retransmission, and congestion control that survives incast from a synchronized all-reduce. Plenty of products will claim UEC compliance while implementing the easy subset. Demand measured all-reduce numbers on production hardware, not spec sheets.

Third, watch NVLink Fusion design wins. Nvidia opening its interconnect to third-party accelerators admits the closed domain was becoming a reason to leave. If a major cloud puts its own accelerator inside an NVLink domain in 2026, Nvidia has converted a defection into a partnership, and the GB300 NVL72 rack alternatives conversation cools considerably. If instead those clouds ship Ethernet-based pods, the fabric layer is genuinely contested for the first time — and every buyer below hyperscale eventually gets the benefit in pricing.

Frequently Asked Questions

Is Tomahawk 6 a direct replacement for NVLink?

Not yet, and the distinction matters. NVLink provides coherent load/store semantics inside a tightly coupled domain; Tomahawk 6 with scale-up Ethernet provides very fast, very low-latency message passing. For tensor-parallel workloads that assume memory semantics, that gap is real. For pipeline and data parallelism, and for most inference serving, it is largely irrelevant.

Should I cancel my GB300 NVL72 order?

No. If you have allocation and CUDA workloads, NVL72 remains the fastest route from purchase order to running tokens, and integration risk you do not own is worth paying for. Use the Ethernet alternative as leverage on price and terms, and build the analysis now so your 2027 order is not automatic.

Does this apply below hyperscale?

Indirectly and with a lag. Building a custom XPU pod requires a silicon program and a platform engineering team most companies will never have. But fabric competition compresses margins across the industry, and merchant Ethernet gear reaches the broader market at a fraction of proprietary interconnect pricing. You benefit as a price taker, not as a builder.

What is the real switching cost if I move off NVLink?

Software, not hardware. NCCL is deeply tuned for NVLink topologies, and your scheduler, checkpointing, and failure-recovery logic likely encode assumptions about domain boundaries. Budget engineer-quarters for collectives porting and re-tuning, and treat any vendor claim of drop-in NCCL compatibility as unverified until you have run your own all-reduce sweep on their hardware.

Is co-packaged optics required for Tomahawk 6?

No — it ships in both pluggable and co-packaged variants. CPO cuts power per bit and removes a large population of failure-prone pluggables, which is compelling at 1.6T. The tradeoff is serviceability: a failed co-packaged link is a chassis-level event rather than a five-minute transceiver swap. Decide based on your operational model and spares strategy, not on the power number alone.

How do I know if my workload is even fabric-bound?

Run the NCCL all-reduce sweep in step one and compare achieved bus bandwidth to link rate across message sizes. Then profile a real training step and check what fraction of wall-clock goes to collectives. If communication is under roughly 15 percent of step time, fabric upgrades will not move your throughput meaningfully, and the money belongs elsewhere.