architecture

A Real GPU Reference Architecture VCF 9.1 on Supermicro HGX, Down to the Cable

Two B200 nodes, one liquid-cooled and one air-cooled, 3.2 Tb/s of GPU fabric per node, and a four-host EPYC management domain. This is what the AI Factory announcement looks like when somebody actually builds it.

Most of the Explore AI announcements were platform-level. This one is a build, with model numbers, cable types and bandwidth figures, and it's the most useful thing published during the week for anyone who has to turn the AI strategy into a bill of materials.

It's an HGX reference architecture pairing Supermicro SuperCloud hardware management with VCF 9.1 and vSphere Kubernetes Service, on certified Supermicro servers using NVIDIA HGX GPUs.

The compute layer, and a genuinely interesting choice

Two Supermicro servers with NVIDIA HGX B200 GPUs. One direct-to-chip liquid-cooled, one air-cooled.

That's not a hedge, it's the point. The same workload runs across both thermal designs so they can be compared directly. For anyone weighing a liquid-cooling decision, having both in one validated architecture is far more useful than two separate papers each arguing for its own approach.

The specific models are named: the liquid-cooled AS-4126GS-NBR-LCC and its air-cooled counterpart the AS-A4126GS-TNBR. Being able to quote a part number in a design document rather than a product family is the difference between a reference architecture and a marketing diagram.

The GPU fabric

This is the part most enterprise architects have the least experience with, and the numbers are worth reading carefully.

Fabric type      RoCEv2 Ethernet
Switch           Supermicro, Broadcom Tomahawk 4 silicon
Per node         8 x NVIDIA ConnectX-7 adapters
Rate             400G per adapter
Cabling          OSFP112 passive copper
Aggregate        3.2 Tb/s GPU fabric bandwidth per node

Three things to take from that.

RoCEv2 over Ethernet rather than InfiniBand. That's a deliberate architectural position, and it matters for enterprises with existing Ethernet operational skills and tooling. It means the GPU fabric is something your network team can reason about rather than a parallel technology they've never touched. The trade is that RoCEv2 needs a genuinely lossless fabric, so PFC and ECN configuration stop being optional.

Passive copper on OSFP112 rather than optics. Passive copper is cheaper, draws no power and has no transceiver to fail, but it's distance-limited. That constrains your physical layout, so the rack design and the fabric design are the same conversation here, not two separate ones.

And 3.2 Tb/s per node is the number that tells you why this can't be retrofitted onto a general-purpose cluster design. Eight 400G adapters per node is a different physical and power proposition from the two 25G NICs most enterprise hosts carry.

The management domain

Four AMD EPYC hosts running the VCF control plane on vSAN ESA.

Worth noticing that the management domain is deliberately not GPU-bearing and deliberately a different CPU architecture from whatever's running the workloads. The control plane's job is to be reliable and cheap, not fast. Putting expensive accelerated hardware into the management domain is a mistake I've seen made, and this design quietly makes the counter-argument.

Four hosts on vSAN ESA is also the standard, unremarkable VCF management pattern. The AI part of this architecture is confined to the workload domain, which is exactly how it should be.

What it delivers

The stated outcome is cloud-like operational agility on GPU infrastructure: self-service Kubernetes clusters, policy-driven storage, and automated network isolation. That's the AI Factory pitch expressed as a working system rather than a slide.

The multi-tenancy point is the one that justifies the whole exercise. A pool of GPU-accelerated infrastructure, wired with a lossless high-speed fabric, operated as a single multi-tenant system. Without that, you have expensive hardware allocated to whoever asked first.

The certification check you should actually run

The post is specific about how to verify your own configuration, and this is the practical takeaway even if you never build this exact design.

Go to the Broadcom Compatibility Guide, filter the VM Direct Path IO for General GPU program by partner Supermicro Computer, Inc. and by GPU partner NVIDIA. That gives you certification status for specific configurations.

The post also notes the servers used are a representative subset rather than the full list. Other certified Supermicro Hopper, Ada and Blackwell platforms include the AS-4125GS-TNRT2, SYS-221GE-NR and SYS-421GE-TNRT. GPU options beyond the B200 include HGX B300 NVL8, RTX PRO 6000 Blackwell Server Edition, and L40S.

That last detail matters for procurement. The reference architecture uses B200, but the certified envelope is wider, and the L40S in particular is a very different price point for inference-only workloads.

What to take into a design

• If you're sizing GPU infrastructure, start from the fabric, not the GPU. Eight 400G adapters per node dictates switch selection, cabling, rack layout and power before you've chosen a model.

• Decide the cooling question early and treat it as a facilities conversation. Direct-to-chip liquid cooling is a data centre commitment, not a server option.

• Keep the management domain boring. Four hosts, standard CPUs, vSAN ESA. Don't put accelerators where they'll idle.

• Run the BCG filter before any conversation about specific hardware. The certified list is wider than the reference architecture, which gives you room on price.

• If you don't have lossless Ethernet experience in the team, that's the skills gap to close first. RoCEv2 is unforgiving of a fabric that hasn't been configured for it.