DEV Community: sonic components

The AI Boom Isn’t Just About GPUs — The Network Is Becoming the Bottleneck

sonic components — Sat, 19 Sep 2026 17:56:35 +0000

800G InfiniBand Explained: Why AI Clusters Need More Than Faster GPUs

Inside the networking challenge behind Blackwell GPU clusters, NVIDIA Quantum-X800, 800G fabrics, RDMA, optical interconnects, and the emerging AI factory

Cover Image: Use the NVIDIA Quantum-X800 / AI Infrastructure banner

For years, increasing compute performance was largely a processor problem.

Need more performance?

Add faster CPUs.

Add more cores.

Add GPUs.

Add more GPUs.

Modern artificial intelligence has changed that equation.

When hundreds or thousands of accelerators participate in the same distributed workload, the performance of an AI system depends not only on how quickly each GPU can calculate.

It also depends on how quickly those GPUs can communicate.

That makes networking a fundamental part of AI compute architecture.

And it explains why the industry is moving toward technologies such as:

400G and 800G networking
InfiniBand
RDMA
high-speed Ethernet
GPU-aware networking
intelligent network offload
800G optical interconnects
extremely high-density switching fabrics

One example illustrates just how far this architecture is scaling:

NVIDIA Quantum-X800.

A Quantum-X800 Q3400-class switching platform can provide 144 × 800Gb/s ports and up to 115.2 Tb/s of aggregate bidirectional switching capacity.

Those numbers sound like networking specifications.

But in an AI factory, they are increasingly compute specifications too.

1. Why Doesn't Adding More GPUs Automatically Solve the Problem?

Imagine one GPU processing an AI workload.

The workload fits entirely within the resources available to that accelerator.

Networking may not be the dominant concern.

Now imagine eight GPUs.

Then 64.

Then 512.

Then thousands.

At that scale, the workload is distributed.

Individual accelerators process different pieces of the same larger computational job.

Those GPUs must exchange information throughout the process.

Conceptually:

GPU 01 ──┐
GPU 02 ──┤
GPU 03 ──┤
GPU 04 ──┼──── HIGH-SPEED FABRIC ──── GPU CLUSTER
GPU 05 ──┤
GPU 06 ──┤
GPU 07 ──┤
GPU 08
The faster the GPUs become, the more important it becomes to prevent communication from slowing them down.

An accelerator waiting for data isn't delivering useful compute during that waiting period.

This creates a basic AI infrastructure principle:

> **Compute performance and communication performance have to scale together.**

---

# 2. What Are GPUs Actually Sending Across the Network?

Distributed AI training can involve significant communication between participating accelerators.

Depending on the workload and architecture, network traffic may include:

* gradients
* model parameters
* training data
* intermediate results
* synchronization information
* checkpoint-related traffic
* storage traffic

A distributed training workload isn't simply thousands of independent computers doing unrelated work.

The nodes frequently participate in the **same computational process**.

That means communication latency and available bandwidth can affect how effectively the overall cluster operates.

---

# 3. Why 800G?

800Gb/s represents an enormous amount of bandwidth for a single connection.

The theoretical raw line rate is:

text
800 gigabits per second


Divide by eight:

text
800 / 8 = 100 gigabytes per second


So an 800Gb/s link represents a theoretical raw rate equivalent to approximately:

text
100 GB/s


before accounting for protocol overhead and other real-world factors.

But the more interesting part isn't a single 800G connection.

It is what happens when a switching architecture contains **large numbers of them**.

---

# 4. NVIDIA Quantum-X800 Shows the Scale

Consider the NVIDIA Quantum-X800 Q3400 architecture.

## Key Data Sheet

| Specification                     | Quantum-X800 Q3400                |
| --------------------------------- | --------------------------------- |
| Network Technology                | InfiniBand                        |
| Maximum Port Speed                | 800Gb/s                           |
| High-Speed Ports                  | 144 × 800G                        |
| Aggregate Bidirectional Switching | 115.2 Tb/s                        |
| Target Workload                   | AI / HPC                          |
| Infrastructure Role               | GPU cluster fabric                |
| Primary Environment               | Large-scale accelerated computing |

The relationship is straightforward:

text
144 × 800 Gb/s = 115,200 Gb/s


which equals:

text
115.2 Tb/s


That is the scale of fabric being developed for modern accelerated computing.

---

# 5. The AI Network Isn't a Traditional Enterprise LAN

A conventional enterprise network may handle:

text
Users
↓
Applications
↓
Servers
↓
Storage / Internet


An AI fabric introduces enormous amounts of east-west communication:

text
GPU ↔ GPU
GPU ↔ GPU
GPU ↔ GPU
GPU ↔ Storage
Node ↔ Node
Rack ↔ Rack
Cluster ↔ Cluster


This distinction matters.

AI networking isn't simply about providing an internet connection to GPU servers.

The fabric itself participates in the operation of distributed workloads.

---

# 6. Why InfiniBand?

InfiniBand has a long history in high-performance computing and has become an important technology for large accelerated-computing environments.

The reason isn't simply raw bandwidth.

AI/HPC networking involves several performance characteristics:

### High Bandwidth

Large quantities of data need to move between compute nodes.

### Low Latency

Delays between participating nodes can affect synchronized workloads.

### RDMA

Remote Direct Memory Access can enable data movement between systems with less CPU involvement than traditional networking approaches.

### Network Offload

Moving certain communication operations away from general-purpose processors can reduce overhead.

### Congestion Management

Large synchronized workloads can create challenging traffic patterns that require sophisticated fabric management.

This is why simply saying:

**"The switch supports 800G."**

doesn't describe the entire engineering problem.

The objective is building a fabric capable of operating efficiently under AI/HPC communication patterns.

---

# 7. RDMA: Moving Data Without Taking the Long Route

One important concept in high-performance networking is **Remote Direct Memory Access**.

A simplified conventional communication path might look like:

text
APPLICATION
↓
OPERATING SYSTEM
↓
CPU
↓
NETWORK STACK
↓
NIC
↓
NETWORK


High-performance RDMA architectures are designed to reduce some of this processing overhead.

Conceptually:

text
APPLICATION MEMORY
↓
HIGH-PERFORMANCE NETWORK INTERFACE
↓
NETWORK FABRIC
↓
REMOTE MEMORY


The exact implementation is more complex, but the architectural objective is straightforward:

**Move data efficiently while minimizing unnecessary processing overhead.**

At small scale, those efficiencies may appear incremental.

At AI-factory scale, small inefficiencies multiplied across enormous numbers of communications can become significant.

---

# 8. The Network Becomes Part of the Computer

This leads to an important architectural shift.

Traditionally:

text
COMPUTER → NETWORK → COMPUTER


With large distributed AI systems, it can be more useful to think of the architecture as:

text
┌─────────────────────────────────────────┐
│ DISTRIBUTED AI COMPUTER │
│ │
│ GPU ─ GPU ─ GPU ─ HIGH-SPEED FABRIC │
│ │ │ │ │ │
│ GPU ─ GPU ─ GPU ─ SWITCHING FABRIC │
│ │ │ │ │ │
│ GPU ─ GPU ─ GPU ─ STORAGE │
└─────────────────────────────────────────┘


The network isn't merely connecting independent machines.

It is helping those machines operate as one distributed computational system.

---

# 9. 800G Doesn't End at the Switch

Now another engineering problem appears.

You can build an 800G-capable switch.

You can deploy high-performance network adapters.

But something still has to physically connect them.

That's where the optical layer becomes critical.

An AI network may involve combinations of:

text
800G TRANSCEIVERS
+
ACTIVE OPTICAL CABLES
+
DIRECT ATTACH CABLES
+
FIBER INFRASTRUCTURE
+
PATCHING
+
OPTICAL TRANSPORT
+
DATA CENTER INTERCONNECT


The appropriate technology depends on reach, topology, density, architecture, power requirements and other engineering considerations.

---

# 10. AI Is Becoming an Optical Networking Story

The physical scale of AI clusters makes optical infrastructure particularly interesting.

Inside a rack, short-reach connections may be practical.

Across rows, halls or facilities, the requirements change.

Across campuses or geographically separated facilities, they change again.

The architecture can evolve into:

text
BLACKWELL GPU
↓
800G NETWORK INTERFACE
↓
QUANTUM-X800
↓
800G OPTICS
↓
FIBER
↓
OPTICAL TRANSPORT / DCI
↓
SECOND AI ENVIRONMENT


The AI boom is therefore creating demand far beyond GPUs.

It touches switching, optics, cabling, fiber and transport infrastructure.

---

# 11. Then You Hit the Next Bottleneck: Power

Suppose the networking problem is solved.

There is another constraint waiting:

**Power.**

Higher-density accelerated computing means significant electrical requirements.

More GPUs require more power.

More switches require more power.

Optical modules consume power.

Storage consumes power.

Cooling consumes power.

The infrastructure chain becomes:

text
MORE AI COMPUTE
↓
MORE NETWORK CAPACITY
↓
MORE OPTICAL CONNECTIVITY
↓
MORE ELECTRICAL LOAD
↓
MORE HEAT
↓
MORE COOLING
↓
MORE FACILITY INFRASTRUCTURE


Suddenly an AI deployment isn't merely an IT project.

It's also an electrical and mechanical infrastructure project.

---

# 12. The Four-Layer AI Factory

A useful mental model is to divide the AI factory into four layers.

## Layer 1 — Compute

text
GPUs
Accelerated Servers
AI Systems
High-Performance Storage


This is where AI computation happens.

## Layer 2 — Network

text
800G InfiniBand
High-Speed Ethernet
HCAs / NICs
AI Switching Fabrics


This is where distributed compute becomes connected compute.

## Layer 3 — Optical

text
800G Transceivers
AOCs
DACs
Fiber
Optical Transport
DCI


This is how high-speed connectivity extends across the physical environment.

## Layer 4 — Facility

text
UPS
PDUs
Transfer Switches
Power Distribution
Cooling
Environmental Monitoring


This is what keeps the entire AI factory operational.

---

# 13. Why Developers Should Care About Infrastructure

It might be tempting to treat all of this as somebody else's problem.

Developers write software.

Infrastructure engineers handle switches.

Data-center teams handle power.

But AI increasingly crosses those boundaries.

The architecture underneath a distributed workload can affect:

* training time
* GPU utilization
* scalability
* storage performance
* workload placement
* system efficiency
* infrastructure cost

Understanding the physical system underneath AI software can therefore help developers understand why distributed applications behave the way they do at scale.

---

# 14. The Next AI Question Isn't "How Many GPUs?"

The first stage of the AI infrastructure boom focused heavily on acquiring compute.

The industry asked:

text
HOW MANY GPUs CAN WE GET?


The next phase introduces a more complicated question:

text
HOW DO WE MAKE THOUSANDS
OF GPUs OPERATE EFFICIENTLY
AS ONE SYSTEM?




That requires networking.

It requires optics.

It requires storage.

It requires power.

It requires cooling.

And increasingly, it requires thinking about the data center itself as one enormous distributed computer.

---

# Final Thought

The headline numbers around NVIDIA Quantum-X800 are impressive:

**800Gb/s ports.**

**144 high-speed connections.**

**115.2 Tb/s of aggregate bidirectional switching capacity.**

But the bigger story isn't the number on the switch data sheet.

It's what those numbers tell us about where AI infrastructure is heading.

As accelerated computing scales, the network is no longer secondary infrastructure.

**The network is becoming part of the machine.**

---

## Continue Reading

For the broader AI-factory discussion covering Blackwell GPUs, 800G networking, optical interconnects, power and cooling, read the full AI infrastructure analysis from **Sonic Components LLC**:

**The AI Boom Isn't Just About GPUs — The Network Is Becoming the Bottleneck**

Sonic Components supplies enterprise, data-center, AI/HPC, optical and high-performance networking infrastructure.

**RFQ / Equipment Availability:**
**[scs@soniccomponents.com](mailto:scs@soniccomponents.com)**

**Website:** SonicComponents.com

---

**DEV Tags:**

`#ai` `#nvidia` `#networking` `#datacenter`

**Additional discovery terms:**
#InfiniBand #800G #HPC #Blackwell #QuantumX800 #AIInfrastructure #GPU #RDMA #OpticalNetworking #AIFactory

How 1Tb Packet/OTN Switching Works: Inside the Ciena 6500 NTK763VA

sonic components — Fri, 18 Sep 2026 15:00:25 +0000

How 1Tb Packet/OTN Switching Works: Inside the Ciena 6500 NTK763VA

When engineers talk about modern optical networks, the headline numbers tend to get most of the attention:

100G. 400G. 800G. 1T.

But moving more bits across a fiber is only part of the problem.

A carrier network also has to aggregate traffic, switch it, groom it into appropriate transport containers, monitor it, and ultimately map that capacity onto optical wavelengths.

The Ciena 6500 NTK763VA provides a useful real-world example of how these functions come together.

The NTK763VA is a 1T 3xUSS Packet/OTN Interface Module for the Ciena 6500 T-Series architecture.

Let's break down what that actually means.

Start With the Name

The description contains most of the important architectural information:

Ciena NTK763VA
1T 3xUSS PKT/OTN Interface Module

There are three key pieces:

1T      = 1 terabit-per-second capacity class

3xUSS   = Three Universal Sub-Slots

PKT/OTN = Packet + Optical Transport Network

Together, those features create a modular interface between high-speed client traffic and the Ciena 6500 packet-optical switching environment.

1T Is Bandwidth, Not Storage

The NTK763VA is sometimes informally described as a "Ciena 1TB module."

That's potentially confusing.

This isn't a 1-terabyte storage device.

We're talking about approximately one terabit per second of networking capacity.

The basic calculation is straightforward:

1 Tb/s = 1,000 Gb/s

10 × 100 Gb/s = 1,000 Gb/s

Therefore:

10 × 100G = 1T

That gives us a useful way to visualize the scale.

If an aggregation node is dealing with ten 100G traffic units, the aggregate bandwidth is already one terabit per second.

Now consider 400G:

2 × 400G = 800G

3 × 400G = 1.2T

Only three 400G interfaces can exceed a terabit of aggregate bandwidth.

That's how quickly the capacity requirements change as interface speeds increase.

Where Does the NTK763VA Sit?

Let's simplify a carrier network.

             CLIENT / EDGE NETWORK
                     |
          +----------+----------+
          |          |          |
         10G        100G       400G
          |          |          |
          +----------+----------+
                     |
                     v
         +-----------------------+
         |   Universal Sub-Slot  |
         |       Interfaces      |
         +-----------------------+
                     |
                     v
         +-----------------------+
         |       NTK763VA        |
         |     1T 3xUSS          |
         |     PKT / OTN         |
         +-----------------------+
                     |
                     v
         +-----------------------+
         | Ciena 6500 T-Series   |
         |   Switching Fabric    |
         +-----------------------+
                     |
                     v
         +-----------------------+
         |   Coherent Optical    |
         |      Transport        |
         +-----------------------+
                     |
                     v
                   DWDM
                     |
                     v
                   FIBER

This is obviously simplified, but it demonstrates the important point:

The NTK763VA isn't the entire optical system.

It is an interface into a much larger packet/OTN switching and optical transport architecture.

What Is 3xUSS?

The next part of the description is:

3xUSS

USS stands for Universal Sub-Slot.

The NTK763VA provides three of them.

Conceptually:

+---------------------------------------+
|              NTK763VA                 |
|                                       |
| +---------+ +---------+ +---------+   |
| |  USS 1  | |  USS 2  | |  USS 3  |   |
| +---------+ +---------+ +---------+   |
|                                       |
|        1T Packet / OTN Interface      |
+---------------------------------------+
                  |
                  v
         T-Series Switching

Why create sub-slots instead of putting fixed ports directly on the card?

Because interfaces change much faster than carrier chassis.

The Interface Lifecycle Problem

Consider the progression of Ethernet speeds:

1G
 |
10G
 |
40G
 |
100G
 |
400G
 |
800G
 |
1.6T and beyond

Now compare that with the expected operational life of a large carrier transport platform.

Operators don't want to replace an entire optical switching system every time the preferred client interface changes.

That's expensive.

It also affects:

Power infrastructure
Cooling
Cabling
Network management
Operations
Spare inventory
Training
Software integration
Maintenance procedures

A modular interface architecture helps separate the lifecycle of the interface from the lifecycle of the larger platform.

That's the interesting engineering idea behind USS.

Packet vs. OTN

Now we get to:

PKT/OTN

These aren't two names for the same thing.

They address different parts of the networking problem.

Packet Networking

Ethernet traffic consists of packets.

Packet switching allows many flows to share network capacity dynamically.

Conceptually:

Flow A ----\
Flow B -----\
Flow C ------> PACKET SWITCH ----> Network
Flow D -----/
Flow E ----/

The traffic doesn't necessarily need a permanently dedicated transport channel for each individual flow.

That's one of the reasons packet networking is so efficient.

OTN

OTN stands for Optical Transport Network.

OTN provides structured digital transport for carrying client services through optical infrastructure.

Among other things, OTN is used for:

Transport containers
Traffic grooming
Service monitoring
Performance monitoring
Fault isolation
Carrier-grade operations
Organizing client signals for optical transport

A useful conceptual model is:

PACKET
   |
   |  Aggregates and switches traffic
   v
OTN
   |
   |  Organizes/grooms transport capacity
   v
COHERENT OPTICS
   |
   |  Converts traffic for optical transmission
   v
DWDM
   |
   |  Places wavelengths onto fiber
   v
FIBER

Again, production networks are considerably more complicated, but this helps explain the relationship between the technologies.

Why Doesn't Faster Ethernet Eliminate OTN?

This is an interesting question.

If we have 400G Ethernet, why bother with OTN?

And if 800G Ethernet becomes common, why not just transport Ethernet everywhere?

Because raw interface speed and transport management solve different problems.

Imagine ten 100G services arriving at an aggregation node:

A ----100G----\
B ----100G-----\
C ----100G------\
D ----100G-------\
E ----100G--------> AGGREGATION NODE
F ----100G-------/
G ----100G------/
H ----100G-----/
I ----100G----/
J ----100G---/

That's one terabit of aggregate bandwidth.

But the services might not all be traveling to the same place.

For example:

300G ---> Data Center A

200G ---> Metro Node B

100G ---> Peering Location

200G ---> Regional Core

200G ---> Data Center B

The problem isn't simply carrying 1T.

The problem is efficiently organizing, switching, grooming, monitoring, and transporting those services.

That's where the transport architecture matters.

Packet/Optical Convergence

Historically, carrier networks could involve several distinct layers of equipment.

A simplified older design might look something like:

Ethernet Switch
      |
      v
Aggregation Platform
      |
      v
OTN Transport
      |
      v
DWDM System
      |
      v
Optical Amplification
      |
      v
Fiber

Each platform potentially requires:

Power
Cooling
Rack space
Management
Cabling
Software
Spare parts
Operational knowledge

Packet-optical convergence attempts to integrate appropriate functions into a common infrastructure.

That doesn't mean every network layer disappears.

Instead, functions that logically work together can be brought into a common platform.

The Ciena 6500 is an example of this approach.

From Ethernet to a Wavelength

Let's follow a highly simplified 100G service through the architecture.

Step 1: Client Traffic Arrives

Customer / Router
       |
      100G
       |
       v
Ciena Interface

Step 2: Interface Processing

The client interface terminates the appropriate Ethernet or transport signal.

100G Client
    |
    v
USS Interface
    |
    v
NTK763VA

Step 3: Packet/OTN Switching

Depending on the configured service, the traffic participates in the appropriate Packet or OTN switching architecture.

NTK763VA
    |
    v
Packet / OTN Fabric

Step 4: Optical Transport

The traffic is eventually directed toward the optical transport resources.

Packet / OTN
     |
     v
Coherent Interface
     |
     v
Optical Wavelength

Step 5: DWDM

Multiple wavelengths can share the same fiber pair.

λ1 ----\
λ2 -----\
λ3 ------> DWDM ---> Fiber
λ4 -----/
λ5 ----/

This is how enormous aggregate bandwidth can be transported over optical infrastructure.

Why Coherent Optics Matter

At shorter distances, conventional optical interfaces can work extremely well.

Longer-distance high-capacity transmission presents a more difficult problem.

As speeds increase, optical impairments become increasingly important.

Coherent optical technology uses sophisticated optical and digital signal-processing techniques to recover high-capacity signals over fiber.

This technology has been central to the growth of modern DWDM systems.

Ciena has been particularly associated with coherent optical networking through its WaveLogic technology.

From an architectural perspective, the key point is:

CLIENT BANDWIDTH
       |
       v
PACKET / OTN
       |
       v
COHERENT OPTICAL SIGNAL
       |
       v
DWDM WAVELENGTH
       |
       v
LONG-DISTANCE FIBER

The NTK763VA sits upstream of that optical transmission process.

100G vs. 400G Capacity

Here's where things become interesting.

Suppose we have a 1T interface budget.

With 100G Traffic

100G × 10 = 1,000G

Ten 100G units consume a terabit.

With 400G Traffic

400G × 2 = 800G

Only two interfaces represent 80% of a terabit.

Add another:

400G × 3 = 1,200G

We've exceeded 1T.

This demonstrates why networking architecture must evolve as interface speeds increase.

The jump from 100G to 400G isn't merely "four times faster."

It changes port density, switching requirements, optical design, power consumption, and capacity planning throughout the system.

QSFP28 vs. QSFP-DD

Two form factors illustrate this transition.

QSFP28

QSFP28 became one of the dominant pluggable formats for 100GbE.

A simplified association is:

QSFP28 ---> 100G generation

QSFP-DD

QSFP-DD increased electrical lane density and became a major form factor for 400GbE and newer high-speed applications.

QSFP-DD ---> 400G and higher-speed generations

The exact capabilities always depend on the particular optic and host platform.

But the evolution demonstrates why modular interface architectures are useful.

The interface technology can evolve independently from some of the surrounding switching infrastructure.

Ciena 6500-T12 and T24

The NTK763VA belongs to the Ciena 6500 T-Series environment, including platforms such as the:

6500-T12

and

6500-T24

These systems provide the larger switching environment required for high-capacity Packet and OTN applications.

Think of the architecture as:

             +-------------------+
             | CLIENT INTERFACES |
             +---------+---------+
                       |
                       v
             +-------------------+
             |     NTK763VA      |
             |    1T 3xUSS       |
             +---------+---------+
                       |
                       v
             +-------------------+
             |   T12 / T24       |
             | SWITCHING FABRIC  |
             +---------+---------+
                       |
                       v
             +-------------------+
             | OPTICAL TRANSPORT |
             +---------+---------+
                       |
                       v
                     FIBER

This is why looking only at the NTK763VA part number doesn't describe the entire system.

The Base Card Doesn't Tell You the Whole Configuration

This is particularly important if you're working with secondary-market carrier hardware.

Suppose you find:

Ciena NTK763VA

That tells you the identity of the base module.

It doesn't necessarily tell you:

Which USS modules are installed?

Which optics are installed?

Which hardware revision is present?

Which services were provisioned?

Which software release is required?

Which licenses are required?

Which T-Series switching configuration is installed?

Whether the card was used for Packet, OTN, or both?

Two cards with the same NTK763VA designation may therefore have very different practical value to a particular network.

NTK763VA vs. NTK763VN

Another similar Ciena identifier is

NVIDIA DGX Spark GB10 — Product Reference: 940-54242-0006-000

sonic components — Sun, 13 Sep 2026 20:21:18 +0000

What Can Developers Actually Do With 128GB of Unified Memory on NVIDIA DGX Spark?

NVIDIA DGX Spark GB10 — Product Reference: 940-54242-0006-000

When people first see the specifications for NVIDIA DGX Spark, one number tends to dominate the conversation:

Up to 1 PFLOP of FP4 AI performance.

That's impressive, but for developers, I think another specification may be considerably more interesting:

128 GB of coherent unified memory.

Why?

Because when you're experimenting with large language models locally, raw compute isn't always the first wall you hit.

Very often, it's memory.

Let's look at the architecture behind NVIDIA DGX Spark, what its 128 GB unified-memory system changes for local AI development, and where a machine like this actually fits between a conventional workstation and data-center GPU infrastructure.

First: What Is NVIDIA DGX Spark?

DGX Spark is NVIDIA's compact desktop AI development system built around the GB10 Grace Blackwell Superchip.

Instead of combining a conventional x86 CPU with a discrete GPU, GB10 integrates NVIDIA's Grace CPU architecture with a Blackwell GPU architecture in a tightly coupled AI computing platform.

The basic hardware is unusual for something this small:

NVIDIA GB10 Grace Blackwell Superchip
Blackwell GPU architecture
20-core Arm CPU
128 GB LPDDR5x coherent unified memory
Approximately 273 GB/s memory bandwidth
Up to 1 PFLOP FP4 AI performance with sparsity
NVIDIA ConnectX-7 high-speed networking
10 Gigabit Ethernet
NVMe storage
Wi-Fi 7
NVIDIA DGX OS

And the entire machine is roughly 150 × 150 × 50.5 mm.

That's small enough to sit on a desk.

But physically fitting on your desk isn't what makes it interesting.

Juinper Networks

sonic components — Wed, 02 Sep 2026 15:49:35 +0000

Upgrading Juniper MX Networks from 100GbE to 400GbE: What Engineers Need to Know

Moving a production network from 100 Gigabit Ethernet to 400 Gigabit Ethernet sounds simple on paper:

Replace a 100G interface with a 400G interface and get four times the bandwidth.

In a real carrier or data-center network, however, the interface is only one part of the equation.

The router's forwarding silicon, switch fabric, midplane, power system, cooling, optics, software release, slot selection, redundancy configuration, and licensing can all determine whether the expected capacity is actually available.

Juniper's MX240, MX480, and MX960 platforms provide an interesting example because these systems can be upgraded with newer generations of Modular Port Concentrators rather than requiring an immediate chassis replacement.

One particularly useful case study is the Juniper MPC10E-15C, a Trio 5-based line card capable of supporting both 100GbE and 400GbE interfaces.

This article isn't about whether you should buy a particular line card.

Instead, we'll use the MPC10E-15C to examine the engineering questions that should be answered before attempting a 100G-to-400G upgrade on an existing Juniper MX network.

Video Overview

The video provides a short overview of the hardware. Below, we'll go deeper into the architecture and the deployment considerations that matter when integrating this class of line card into an existing MX environment.

Why Moving from 100G to 400G Isn't Just a Port Upgrade

Suppose an edge router has four heavily utilized 100GbE connections.

At first glance, replacing those links with 400GbE interfaces appears straightforward.

But consider what happens behind the physical port.

Traffic entering that 400G interface must travel through several parts of the system:

Interface → Packet Forwarding Engine → Fabric → Other line cards/interfaces

Every component in that path needs sufficient capacity.

A 400GbE optic connected to a router that cannot move 400 Gbps through its internal architecture does not magically create a 400 Gbps forwarding system.

This distinction becomes especially important when installing modern line cards into chassis that may have been deployed years earlier.

Understanding the MPC10E-15C Architecture

The MPC10E-15C is a fixed-configuration Modular Port Concentrator designed for the MX240, MX480, and MX960.

It contains 15 multirate interfaces divided into three groups.

Each group contains:

Four QSFP28 interfaces
One QSFP56-DD interface

Across the entire card, that becomes:

12 × QSFP28

plus

3 × QSFP56-DD

The QSFP28 interfaces support 10GbE, 40GbE, and 100GbE operation.

The QSFP56-DD interfaces add support for 400GbE.

This mixed architecture is useful because most networks don't transition from 100G to 400G everywhere simultaneously.

Why Mixed 100G and 400G Connectivity Is Useful

Network upgrades normally happen incrementally.

Imagine an ISP with several 100GbE upstream connections, peering links, aggregation paths, and data-center interconnects.

Perhaps only two links are approaching capacity.

Replacing every 100G interface would make little sense.

Instead, the operator might move the highest-utilization links to 400G while leaving other connections at 100G.

A mixed-port line card makes that possible.

The twelve QSFP28 interfaces can continue serving the existing 100G environment while the three QSFP56-DD interfaces provide a migration path toward 400G.

That is a much more realistic network transition than assuming everything becomes 400G overnight.

Three Packet Forwarding Engines

The MPC10E-15C contains three Packet Forwarding Engines.

Each PFE provides a maximum bandwidth of:

500 Gbps

Therefore, the theoretical aggregate forwarding capacity is:

3 × 500 Gbps = 1.5 Tbps

The architecture uses Juniper Trio 5 silicon.

This matters because forwarding capacity isn't simply determined by how many ports exist on the front panel.

The Packet Forwarding Engines perform the actual high-speed packet processing required by the router.

Modern service-provider networks may simultaneously need to handle:

IPv4 and IPv6 forwarding
MPLS
VPN services
Internet peering
Subscriber traffic
Traffic engineering
Data-center connectivity
Large forwarding tables
High packet rates

As interface speeds increase, forwarding architecture becomes increasingly important.

The Midplane Question: 800 Gbps or 1.5 Tbps?

This is one of the most important details when considering an MPC10E upgrade.

The same line card can operate at substantially different aggregate throughput depending on the MX chassis configuration.

With a compatible standard midplane, Juniper documents throughput of up to:

800 Gbps

With an enhanced midplane, maximum line-rate throughput can reach:

1.5 Tbps

That is a substantial difference.

So the question shouldn't simply be:

Does my MX960 support this MPC?

A better question is:

What throughput can my specific MX960 configuration actually provide to this MPC?

Those are not the same question.

Check the Midplane from Junos

Before planning an upgrade, one of the useful commands to run is:

show chassis hardware

Juniper documents different descriptions for the standard and enhanced backplanes.

An enhanced configuration reports an enhanced platform backplane, while a standard configuration reports the regular platform backplane.

This is an excellent example of why network upgrades should begin with an inventory of the existing chassis rather than with an assumption based solely on the router model number.

Two MX960 routers can carry the same model designation while containing different generations of internal infrastructure.

The Switch Fabric Matters Too

The midplane isn't the only consideration.

To achieve maximum line-rate performance, the switch fabric must also provide sufficient capacity.

For the MPC10E-15C, Juniper documents requirements involving SCBE3-MX Switch Control Boards and increased-bandwidth fabric operation.

For maximum performance, Juniper specifies:

MX960

3 × SCBE3-MX

MX240 / MX480

2 × SCBE3-MX

The MPC's fabric redundancy mode also needs to be configured appropriately for increased bandwidth.

This is an important engineering lesson:

A 1.5 Tbps line card does not automatically create a 1.5 Tbps system.

The entire forwarding path has to support that capacity.

Redundancy Can Affect Available Bandwidth

There is another tradeoff worth considering.

Network engineers naturally want redundancy.

But fabric redundancy and maximum bandwidth can interact.

Juniper's technical material for the MPC10E architecture shows that achieving full line-rate performance can require all available fabric planes to participate.

That means engineers need to understand the relationship between:

Maximum throughput
Fabric configuration
Redundancy mode
Failure scenarios

This isn't unique to Juniper.

It is a general principle of modular routing systems: maximum theoretical capacity and maximum capacity under every redundancy condition aren't necessarily identical.

When planning a 400G migration, both normal operation and failure-state behavior should be modeled.

Don't Forget Power and Cooling

High-capacity forwarding silicon consumes significant power.

Juniper documents a maximum power requirement of approximately:

785 watts

for the MPC10E-15C under its specified 40°C test configuration.

At 25°C, Juniper documents approximately:

720 watts

under the specified test conditions.

That is just one line card.

In a chassis containing several high-capacity MPCs, total power and thermal requirements can become significant.

Juniper therefore specifies high-capacity power supplies and fan trays for these configurations.

Before adding several modern MPCs to an older chassis, check:

Available power capacity
Installed power-supply generation
Power redundancy
Fan-tray generation
Airflow
Ambient temperature
Rack power budget
Facility cooling

The fact that a line card physically fits into a slot doesn't mean the chassis is ready to operate it.

MX960 Slot Placement Requires Attention

The MX960 introduces another planning consideration: slot selection.

High-power, high-capacity line cards can have placement restrictions because of cooling and chassis architecture.

Juniper documentation for the MPC10E family includes MX960 slot restrictions that engineers should review before installation.

This means an upgrade plan should include a map of the existing chassis.

Document:

Which slots are occupied
Which MPCs are installed
Which slots are available
Current power consumption
Current fabric configuration
Routing Engine configuration
Switch Control Board configuration

Doing this before purchasing hardware can prevent a surprisingly expensive installation problem.

400G Optics Are Part of the Design

The line card is only half of a 400GbE link.

The optical layer matters just as much.

A network architect needs to determine:

Required distance
Fiber type
Connector type
Optical standard
Link budget
Patch-panel losses
Existing DWDM infrastructure
Breakout requirements
Supported Juniper optics

For short data-center connections, the optical design may be relatively straightforward.

For metro or long-distance carrier networks, the optical transport architecture can become considerably more complex.

Don't select the router interface independently from the optical path.

Design them together.

Jumbo Frames and MTU Planning

The MPC10E-15C supports large MTUs.

Juniper documents transit traffic MTUs up to:

16,000 bytes

and host-bound packet MTUs up to:

9,500 bytes

This can be valuable in environments using jumbo frames, MPLS encapsulation, data-center interconnects, and other applications where additional packet overhead needs to be considered.

But changing one interface doesn't solve an end-to-end MTU problem.

The entire path should be validated.

That includes:

Router interfaces
Transport equipment
Switches
Firewalls
MPLS paths
Data-center fabrics
End systems

MTU mismatches can create difficult-to-diagnose problems even when every individual device appears healthy.

What About MACsec?

The interfaces on the MPC10E-15C provide hardware support for MACsec.

That can be useful for organizations requiring encrypted Ethernet connectivity between network locations.

But hardware support and feature entitlement aren't always the same thing.

Engineers should verify the appropriate Juniper software and bandwidth licensing for the intended MACsec deployment.

This is another reason to include licensing in the technical design rather than treating it as a purchasing detail that can be handled afterward.

Software Release Matters

Hardware compatibility alone isn't enough.

The MPC10E-15C was introduced with Junos OS 19.1R1 support, while support for operation with a standard midplane begins with Junos OS 19.2R1.

In a production environment, however, the goal shouldn't simply be to run the earliest software release that recognizes the hardware.

Before deployment, evaluate:

Current Junos release
Recommended Junos release
Other installed MPCs
Routing Engine compatibility
Feature requirements
Known issues
Maintenance windows
Upgrade path

Adding a new generation of forwarding hardware may therefore trigger a broader software lifecycle discussion.

A Practical Pre-Upgrade Checklist

Before moving an existing MX240, MX480, or MX960 toward 400GbE, I would collect at least the following information.

1. Chassis

Identify the exact MX platform and hardware revision.

2. Midplane

Determine whether the chassis has the standard or enhanced backplane.

3. Switch Fabric

Identify the installed Switch Control Boards and determine available fabric capacity.

4. Fabric Mode

Understand whether the desired redundancy configuration provides the bandwidth required by the new MPC.

5. Slots

Confirm that the intended line-card position is supported.

6. Power

Calculate existing and projected chassis power consumption.

7. Cooling

Verify fan trays, airflow, ambient temperature, and facility cooling.

8. Junos

Confirm software compatibility and determine whether an upgrade is required.

9. Optics

Select supported transceivers based on distance and optical architecture.

10. Licensing

Identify any feature or capacity licenses required by the intended configuration.

11. MTU

Validate the complete path if jumbo frames or additional encapsulation are used.

12. Failure Scenarios

Determine what happens to forwarding capacity if a fabric component or other redundant element fails.

Upgrade the Chassis or Replace It?

This leads to the bigger architectural question.

When traffic outgrows an existing router, should the operator replace the entire platform?

Not necessarily.

One of the advantages of modular platforms such as the MX240, MX480, and MX960 is that several generations of interface and forwarding technology can potentially coexist with the chassis over its operational life.

A network originally designed around 10G interfaces may have subsequently moved through 40G and 100G generations and can, in the right configuration, reach 400G connectivity.

That can protect a substantial infrastructure investment.

But there is a limit.

If upgrading requires replacing the midplane, switch fabric, power supplies, fan trays, software, optics, and most line cards, engineers should compare that investment against migrating to a newer routing platform.

The technically possible upgrade isn't always the economically sensible upgrade.

Final Thoughts

The transition from 100GbE to 400GbE demonstrates why router capacity planning must be performed at the system level.

Using the Juniper MPC10E-15C as an example, the front panel tells only part of the story.

Yes, the card provides:

12 QSFP28 interfaces
3 QSFP56-DD interfaces
400GbE capability
Three 500 Gbps Packet Forwarding Engines
Trio 5 forwarding silicon
Up to 1.5 Tbps aggregate throughput

But achieving that performance depends on the infrastructure behind those interfaces.

The midplane matters.

The switch fabric matters.

Fabric configuration matters.

Power matters.

Cooling matters.

Slot placement matters.

Software matters.

Optics matter.

Licensing matters.

And redundancy matters.

That is the real lesson for engineers planning a 400GbE upgrade:

Don't design around the speed printed next to the port. Design around the capacity of the complete forwarding system.

When those pieces are evaluated together, existing MX infrastructure can potentially provide a practical migration path from 100GbE into the 400GbE era.

References

Juniper Networks — MPC10E-15C hardware specifications
Juniper Networks — MX Series Interface Module Reference
Juniper Networks — MPC10E-15C-MRATE hardware documentation

Topics

Juniper MX, Network Engineering, 400GbE, 100GbE, Routing, Service Provider Networks, Data Center Networking

Four QSFP28 interfaces
One QSFP56-DD interface

Across the entire card, that becomes:

Deploying NVIDIA GB300 NVL72: The Infrastructure Checklist Engineers Shouldn't Skip

sonic components — Tue, 01 Sep 2026 15:17:32 +0000

Deploying NVIDIA GB300 NVL72: The Infrastructure Checklist Engineers Shouldn't Skip

The NVIDIA GB300 NVL72 is not a conventional GPU server.

It is a rack-scale AI platform built around 72 NVIDIA Blackwell Ultra GPUs and 36 NVIDIA Grace CPUs.

That distinction matters when you're planning an actual deployment.

The hardware specification may look impressive, but the real engineering challenge is making the compute, networking, storage, power and cooling infrastructure work together.

Here's how I'd approach a GB300 deployment from an infrastructure perspective.

Start With the Workload

Before designing the rack, define what you're trying to run.

Typical GB300 workloads can include:

Large-model training
Post-training
AI inference
Reasoning models
Agentic AI
Generative AI
Multimodal workloads
High-performance computing

Don't size the infrastructure simply because "72 GPUs sounds good."

Determine:

How large are the models?

How much inference concurrency is required?

How quickly will the workload grow?

Will additional GB300 racks be added?

Those answers influence everything downstream.

Understand the 72-GPU Architecture

GB300 NVL72 combines:

72 Blackwell Ultra GPUs

with:

36 Grace CPUs

and creates a large NVLink scale-up domain.

NVIDIA currently specifies 130 TB/s aggregate NVLink bandwidth.

That's important because distributed AI workloads can generate enormous amounts of GPU-to-GPU traffic.

A useful mental model is:

The goal is to keep data moving efficiently between the accelerators.

Don't Treat Networking as an Accessory

This is probably one of the biggest mistakes in AI infrastructure planning.

The GB300 architecture supports high-speed scale-out networking using NVIDIA ConnectX-8 SuperNIC technology.

NVIDIA specifies networking capabilities reaching 800 Gb/s per GPU.

That means the network design has to be considered at the beginning of the project.

You'll need to determine:

InfiniBand or Ethernet
Switch architecture
Number of switch ports
800 Gb/s transceivers
Fiber requirements
DAC/AOC requirements
Cable lengths
Redundancy
Storage connectivity
Management connectivity

The network isn't simply connecting the servers.

It's part of the AI computing system.

Calculate Power Before Ordering Hardware

This sounds obvious, but high-density AI infrastructure can expose facility limitations very quickly.

A rack-scale AI deployment requires the electrical team to validate:

Utility
↓
Electrical Distribution
↓
UPS
↓
PDU
↓
AI Rack
↓
GB300 NVL72

Don't stop at checking whether the rack PDU has enough outlets.

Check:

Available rack power
PDU capacity
Circuit capacity
UPS capacity
Facility electrical capacity
Redundancy
Future rack expansion

A successful AI deployment starts with knowing that the building can actually support it.

Plan Liquid Cooling

GB300 NVL72 is a fully liquid-cooled architecture.

This changes the facility conversation considerably.

The cooling system needs to be designed around the rack rather than treating the AI system like a normal air-cooled enterprise server.

Engineering teams should evaluate:

Coolant distribution
CDU capacity
Heat rejection
Facility water infrastructure
Rack connections
Redundancy
Monitoring
Maintenance procedures

Power and cooling should be designed together.

If you know the electrical load but don't understand the thermal architecture, you don't yet have a complete deployment plan.

Storage Is Another Potential Bottleneck

GPU performance doesn't matter much if the accelerators are constantly waiting for data.

Large AI environments may require high-performance shared storage for:

Training datasets
Model checkpoints
Model weights
Logs
Inference data
Generated content

The storage architecture needs to be evaluated based on actual workload throughput rather than simply total capacity.

Ask:

How much data must reach the GPUs per second?

That question is often more useful than:

How many terabytes do we need?

Memory Changes Model Deployment

NVIDIA lists up to 20 TB of GPU memory for GB300 NVL72 and 17 TB of CPU memory.

GPU memory capacity affects what models can be loaded and how they can be distributed.

It also influences:

Context length
Batch size
KV cache
Inference concurrency
Model parallelism
Data movement

For large models, memory architecture can become a primary system-design consideration.

Think About Expansion Before Deployment

Suppose you deploy one GB300 rack today.

What happens when the AI team needs four?

Or eight?

If the original deployment wasn't designed for expansion, the organization may encounter:

Network-port limitations
Insufficient power
Cooling limitations
Storage bottlenecks
Rack-space constraints

The better approach is to design the AI zone before deploying the first rack.

Think beyond:

"Where will this rack go?"

Think:

"Where will the next ten racks go?"

GB300 NVL72 vs. DGX B300

These platforms should not be treated as interchangeable.

DGX B300 is an integrated eight-GPU AI system.

GB300 NVL72 scales to 72 Blackwell Ultra GPUs in a rack-scale architecture.

For organizations evaluating the two, the question isn't simply which system is faster.

The better question is:

What scale does the AI workload require?

DGX B300 can make sense for organizations building an enterprise AI deployment around individual integrated systems.

GB300 NVL72 is designed for organizations operating at substantially larger AI infrastructure scale.

Sonic Components has published a separate analysis of DGX B300:

NVIDIA DGX B300 — Blackwell Ultra Infrastructure

https://www.soniccomponents.com/nvidia-dgx-b300-blackwell-ultra-infrastructure/

And the complete GB300 article is available here:

NVIDIA GB300 NVL72 — 72-GPU Blackwell Ultra AI Platform

https://www.soniccomponents.com/nvidia-gb300-nvl72/

A Practical GB300 Deployment Checklist

Before approving a purchase, I'd work through this list.

Compute

☐ 72 Blackwell Ultra GPUs
☐ 36 Grace CPUs
☐ GPU memory requirements
☐ CPU memory requirements

NVLink

☐ GPU topology
☐ NVLink architecture
☐ Scale-up requirements

Networking

☐ InfiniBand or Ethernet
☐ ConnectX-8
☐ AI switches
☐ 800 Gb/s connectivity
☐ Transceivers
☐ Fiber
☐ DAC/AOC cables

Storage

☐ Dataset capacity
☐ Dataset throughput
☐ Checkpoint storage
☐ Shared filesystem
☐ Backup

Facility

☐ Rack space
☐ Electrical capacity
☐ UPS
☐ PDU
☐ Liquid cooling
☐ Heat rejection
☐ Service access

Operations

☐ Monitoring
☐ Orchestration
☐ NVIDIA Mission Control
☐ Software stack
☐ Maintenance procedures

What About GB300 Pricing?

Don't build a procurement decision around a random "GB300 price" found online.

Rack-scale systems can involve substantially more than the compute hardware.

The project may include:

GB300 system + networking + switches + optics + cabling + storage + support + installation + facility infrastructure

That's why an enterprise RFQ should specify the actual deployment requirements.

If you're requesting pricing, include:

Quantity
Configuration
Delivery location
Networking requirements
Support requirements
Installation requirements
Required delivery date
Request a GB300 NVL72 RFQ

Sonic Components works with organizations sourcing:

NVIDIA AI infrastructure
GPU systems
Data-center equipment
Enterprise networking
Telecom infrastructure
High-performance computing equipment

For a NVIDIA GB300 NVL72 RFQ, contact:

scs@soniccomponents.com

Include your required configuration, quantity, delivery location and target deployment date.

Final Takeaway

The NVIDIA GB300 NVL72 is an impressive piece of computing infrastructure.

But the hardest part isn't installing 72 GPUs.

The hard part is building the environment around them.

A successful deployment requires coordination between:

Compute

NVLink

Networking

Storage

Power

Cooling

Software

Operations

That's why GB300 NVL72 should be treated as an AI infrastructure project, not simply a server purchase.

As AI reasoning, agentic workloads and large-scale inference continue to increase, rack-scale architectures such as GB300 NVL72 are likely to become increasingly important.

The fundamental shift is already happening:

GPU → Server → Cluster → AI Factory

And the engineers who plan the infrastructure around the GPUs will determine how effectively that compute can actually be used.

DEV tags

nvidia #ai #gpu #datacenter #infrastructure #machinelearning #blackwell #devops

NVIDIA DGX B300

sonic components — Tue, 01 Sep 2026 14:54:40 +0000

What It Takes to Deploy an NVIDIA DGX B300 in a Real Data Center

Buying an AI server is easy compared with deploying one.

The NVIDIA DGX B300 is a good example.

On paper, the specifications are impressive:

8 Blackwell Ultra GPUs
14.4 TB/s aggregate NVLink bandwidth
Up to 800 Gb/s networking
2 BlueField-3 DPUs
8 × 3.84 TB NVMe E1.S drives
10U rack space
Approximately 14 kW power consumption

But if you're the engineer responsible for actually installing it, the interesting questions start after the specification sheet.

Step 1: Check rack capacity

DGX B300 occupies 10U.

That sounds manageable until you start adding:

AI switches
patch panels
cable management
storage
additional compute
power distribution

If you're designing a multi-rack AI environment, don't allocate space based only on the DGX system.

Design the entire rack architecture.

Step 2: Check power

This is probably the first facility question.

NVIDIA's User Guide specifies 14.5 kW power consumption and 12 AC power inlets for the AC configuration.

That is a serious amount of power for a 10U system.

Before deployment, verify:

Rack capacity
↓
PDU capacity
↓
Electrical distribution
↓
UPS capacity
↓
Facility capacity

Don't discover the problem after the hardware arrives.

Step 3: Check cooling

Power becomes heat.

NVIDIA lists approximately 49,476 BTU/hr maximum heat output in the DGX B300 User Guide.

The cooling design therefore needs to be evaluated alongside the electrical design.

A rack that can electrically support DGX B300 may not necessarily have adequate thermal capacity.

Step 4: Design the network

DGX B300 supports networking up to 800 Gb/s using ConnectX-8 VPI networking. It also includes BlueField-3 DPUs supporting up to 400 Gb/s InfiniBand/Ethernet.

That means you need to plan:

Switch ports
Transceivers
DAC/AOC cables
Fiber infrastructure
InfiniBand or Ethernet
Network topology
Redundancy

For multiple systems, the network becomes part of the computing architecture.

Step 5: Understand NVLink

The system provides 14.4 TB/s aggregate NVLink bandwidth.

Why is that important?

Because AI workloads frequently require GPUs to exchange information.

More GPUs aren't necessarily better if the GPUs spend too much time waiting for data.

High-bandwidth GPU interconnects help keep the accelerators working together efficiently.

Step 6: Plan storage

DGX B300 includes:

2 × 1.9 TB NVMe M.2

and:

8 × 3.84 TB NVMe E1.S.

That's useful local storage, but large AI deployments frequently require additional shared storage.

Consider:

Dataset size
Checkpoint storage
Training throughput
Shared filesystem requirements
Backup
Replication
Storage networking
Step 7: Plan for expansion

One DGX B300 might solve today's requirement.

What happens six months later?

If your AI team expects to expand from one system to four, eight or more, design the network, power and cooling architecture accordingly.

Otherwise the first DGX deployment can become an infrastructure constraint.

Step 8: Compare against GB300 NVL72

At some scale, DGX B300 may no longer be the right comparison.

NVIDIA's GB300 NVL72 architecture includes 72 Blackwell Ultra GPUs and 36 Grace CPUs with 130 TB/s NVLink bandwidth.

That's a completely different infrastructure class.

So before buying, ask:

Are we building an AI server deployment or an AI factory?

That distinction can dramatically change the architecture.

Final Takeaway

The NVIDIA DGX B300 is an impressive AI system, but successful deployment requires more than purchasing the hardware.

The engineering checklist should include:

Compute → Interconnect → Network → Storage → Power → Cooling → Operations

When those pieces are designed together, DGX B300 becomes a powerful foundation for enterprise AI.

For organizations sourcing NVIDIA DGX B300 systems, configurations and related AI infrastructure, Sonic Components accepts enterprise RFQs at:

scs@soniccomponents.com

Publishing order I recommend

Don't release all five on the same day.

Day 1: Sonic cornerstone page
Day 2: LinkedIn
Day 3: Medium
Day 5: Substack
Day 7: Hashnode
Day 9: DEV

Then our next major article should be GB300 NVL72, and we repeat the same multi-platform strategy.

This gives Sonic a connected content network around Blackwell → DGX B300 → GB300 → HGX B300 → B200 → H200, rather than six unrelated product articles.