Part II: Build Your Own Servers for AI and HPC? When the Hyperscaler Model Starts to Pay Off

The pitch is familiar: Skip the OEM markup, buy directly from original design manufacturers (ODMs) and save millions. It worked for the hyperscalers, so it should work for your AI cluster.

Part I of this series argued that ODM and whitebox sourcing are purchasing decisions that require an operating model that most enterprises don't have. Its test was simple: Cheap hardware is rational only when the operating model can absorb failures.

Part II applies that test to AI and high-performance compute (HPC) clusters, where scale is greater, and the wrong sourcing call costs more. Rack-scale architectures push the sourcing decision away from server price and toward the cluster operating model, because a device-level failure can propagate across a validated system.

The sections that follow check that claim against failure recovery, the fabric, storage, facilities and the team that runs the system. Use them before you build a supplier comparison. They're written for the infrastructure executives and technical leaders who make this decision together.

Key takeaways

• ODM sourcing can work for AI and HPC when you can own fabric validation, checkpoint design and facilities readiness. If you can't, treat the hardware savings as unproven.
• Evaluate the sourcing model at the cluster, scalable unit, pod, rack and data hall levels. The server is the wrong unit.
• ODM direct still accounts for about half of worldwide server revenue, but its share fell from 64% to 50% year over year in the first quarter of 2026 as branded OEMs won more AI infrastructure work. Most ODM direct volume is hyperscaler buying, so it is a weak benchmark for an enterprise.
• Schedulers do not fully absorb node failure. Tightly coupled jobs restart from the last checkpoint, so price recovery into the business case. Design the fabric and storage for that recovery from day one: interconnect validation, checkpoint size, restart time, metadata pressure and dataset staging.
• Rack-scale systems are designed together with the facility. Validate density, cooling loops, commissioning, leak response, service access and expansion runway before the sourcing decision. Compare measured efficiency, not sourcing channel, because bill-of-materials (BOM) savings can be lost at the meter.
• Success with an AI/HPC supercluster tells you little about sourcing the ISV-certified enterprise estate (see the success fallacy below).

Change the unit of analysis first

Comparing an OEM server to an ODM server uses the wrong unit of analysis for an AI/HPC sourcing strategy, since no one deploys a single training node.

Instead, many accelerated nodes operate across a rail-optimized network fabric, a storage tier sized for elephant flows (checkpoint traffic, for instance), power and cooling engineered as a single block, and a scheduler and operational software stack that treats the whole thing as a single resource.

This is evident in accelerators such as GPUs and TPUs, which formalized and kick-started the industry's shift toward systems designed, validated, shipped and serviced as rack-scale units.

"Sourcing" a rack-scale system shifts the decision unit from "the server" to "the cluster." Node homogeneity supports a validated topology and tuned collectives, which can depend on exact switch and smart NIC combinations.

Everything in Part I about firmware ownership, qualification labs and self-support still applies. But it now applies at supercluster scale, where the blast radius can be cluster-wide even when the failure itself is device-level, because the business feels it immediately.

Simulation and machine learning now share the same infrastructure. The same GPU-dense, high-bandwidth-interconnect architecture that runs a climate model on Monday trains a foundation model on Tuesday, and the centers writing exascale procurement checks are frequently the same ones standing up AI-on-demand platforms.

Michael Resch and Bastian Koller predicted that machine learning would reshape HPC through convergence, with simulation and learning reinforcing each other on the same silicon.

Why the ODM case appears defensible

ODM sourcing has real arguments in AI and HPC. Start with scale.

In June 2026, the top spot went to LineShine at the National Supercomputing Center in Shenzhen: nearly 2.2 exaflops on HPL at 42.2 megawatts, and the first CPU-only machine ever to sustain more than two exaflops. LineShine is a custom national design from the processor to the interconnect, and most other top systems are OEM-integrated. 

You should read every ODM success story with one fact in mind: most frontier AI clusters never appear on a public ranking. Microsoft's Eagle system, at number seven on the TOP500, is the exception. The rest disclose a GPU count, a theoretical FP8 figure or a tokens-per-second claim, and some disclose nothing. MLPerf offers an AI-native alternative. The operators whose ODM playbook you might be tempted to copy publish almost nothing about their performance. Their success is a claim with no ranking behind it, which is thin ground for a business case.

Here's why ODM looks tempting:

• Reference architecture (RA): With platform engineering (RAS features, validated peripherals, firmware lifecycle) as a baseline, RAs extend the specification to include topology, power, thermal and management planes. In theory, you can follow an RA with ODM-sourced parts. In reality, GPU parts are single-source, and the most performant parts may only be sold as part of rack-scale systems.
• Many HPC and AI workloads already tolerate failure: Checkpoint and restart limit the damage, but each failure still costs time (see Handling failures).
• Workforce alignment: Mature HPC and AI teams already have skills that ODM operations demand, because they have always run systems at the frontier.
• The economics are concentrated: Accelerators and their memory often account for three-quarters or more of the bill of materials (BOM), and total spend scales accordingly. The same fact cuts the other way: if accelerators and memory are largely priced by a single supplier, the ODM discount applies to the remaining quarter. Ask what savings are addressable. Spare pools can be modeled as insurance premiums rather than dead capital.
• Commercial pressure is real: OEM markup on memory, NVMe and optics, and support lock-in, are legitimate costs. In a supply-constrained market (IDC calls supply the primary ceiling on near-term server growth), allocation can favor either route.

Handling failures

In Part I, we concluded that cheap hardware is rational when failures can be absorbed, which is hard to guarantee with an ODM strategy on enterprise workloads. 

So, for enterprise estates, the answer is to pay for RAS and support (i.e., go the OEM route). Third-party maintenance late in the lifecycle is a separate, later decision and doesn't change day-one sourcing. 

But in AI and HPC, teams argue that "the scheduler" absorbs failures. Here is what the scheduler absorbs and what it doesn't.

Mean time between failures

Component-level assembly without OEM-grade burn-in and qualification removes a layer of screening that catches early-life defects, so model failure rates are instead assumed. A traditional MPI-based simulation running across 512 nodes cannot survive the loss of a single node. 

The job dies. 

What survives is the last checkpoint. Recovery costs all wall-clock time since that checkpoint across all nodes in the job, plus requeue time. Mean time between failures (MTBF) must be much larger than the checkpoint interval, or the supercluster spends most of its life recovering instead of computing.

Here is an illustrative example (with assumptions you are free to replace): Your system MTBF scales inversely with node count. At 512 nodes, each with an assumed five-year node MTBF (about 43,800 hours), the system MTBF is about 86 hours. The Young–Daly checkpoint interval is roughly the square root of (2 × checkpoint cost × MTBF). With a 10-minute checkpoint cost, that works out to about 5.3 hours. That means the checkpoint overhead plus expected rework costs about 6% of runtime, before restart and requeue time.

AI training

AI training has the same failure geometry as the MPI jobs above: one failed node stalls the collective, and the run restarts from a checkpoint. Meta's published account of training Llama 3 405B across 16,384 GPUs logged 466 job interruptions in 54 days, 419 of them unexpected, roughly one every three hours. GPU-related causes accounted for about 59% of the unexpected ones. 

At the frontier scale, hardware failure is a daily operational reality, mitigated by fast checkpointing to local NVMe, asynchronous checkpoint drains, hot spares held in reserve, and health-check preemption. These are largely software and operational behaviors, and they don't come with the hardware from either channel. An OEM reference architecture can add validated integration and a vendor accountable for it; in a component-sourced build, you handle integration and validation yourself. Ask each bidder which of these capabilities it ships and supports. Meta ran this on its own server designs, with the operating model that, as we saw in Part I, most enterprises lack.

Julian Kunkel, professor of high-performance computing at Göttingen, compares an HPL result to a sports car's top speed: It proves the machine can get there, and nothing else. What operators buy is time-to-solution. His example is a weather forecast that takes 25 hours to compute, worthless because tomorrow has already arrived.

TOP500 co-founder Jack Dongarra makes the same point from the other side. Any credible verdict on a system now rests on time-to-solution, reliability, programmability, cost and power. The same logic governs sourcing. The metric that matters is time-to-solution across the fleet's life, with failure recovery, checkpoint overhead and requeue time priced in, and the hardware discount is one input to it. A single bill-of-materials number is the HPL of procurement, and it tells you just as little.

Latency-sensitive inference

In an inference fleet, a service-level objective (SLO) replaces the checkpoint as the design element. Node loss costs capacity and raises tail latency, so inference runs closer to an enterprise estate than to a training job. Before committing to ODM, define how much failure the workload tolerates.

Designers need to know which layer absorbs a failure in each workflow class and what the expected failure-rate costs are. Where failure cannot be absorbed, Part I's conclusions apply: buy from the OEM.

Leading operators point machine learning at their own infrastructure. This approach was demonstrated in HPC research on predicting job runtimes from hardware-event data and tuning cooling, scheduling and applications from center-wide telemetry. Under an OEM or reference-architecture engagement, those telemetry pipelines and much of that tooling arrive as platform features. In a self-sourced supercluster, they are one more function you build and staff yourself, and the gap between operators who have it and those who don't is widening.

Interconnect is the platform

If your evaluation of ODM sourcing has a hardware BOM and no fabric validation plan, it is incomplete.

In AI and HPC superclusters, the interconnect is core infrastructure. Consider its topology and protocols together with the collectives that will run on the supercluster. The industry has ranked supercomputers for decades using benchmarks like HPL, HPCG and HPL-MxP, whose results depend as much on interconnect and memory behavior as on raw FLOPS. Weigh the same factors in an ODM sourcing decision, or when selecting which RA to follow.

• Topology and rail design: An oversubscribed or non-rail-aware leaf-spine fabric congests under all-reduce. Match topology to the collective patterns of your actual jobs. Reference architectures usually specify topology, and deviating to save money is where self-sourced clusters often go wrong.
• Protocols: Ethernet-based RoCE is now a mature technology. Meta has run large GenAI training on both it and InfiniBand. OEM and RA builds will ship with these decisions already made and validated. Component-sourced builds leave the integrator (you) to work through NIC firmware, switch OS, congestion parameters and collective library versions. Get one wrong and a single misbehaving link degrades every job on the machine, while a bad node degrades only one job.
• Diagnosis: Part I asked what happens to the mean time to repair (MTTR) when the diagnostic path runs through your own engineers. On the fabric, the answer is measured in cluster-days. At an assumed $2 per GPU-hour, one cluster-day on a 16,384-GPU system is about $786,000; substitute your own cost. Intermittent fabric problems (a link that flaps under thermal load, a congestion collapse that appears only with a particular job mix) are among the hardest faults to root-cause.

A component-sourced fabric introduces permanent integration and fault-isolation risks for your engineering organization. That risk shows up as headcount and downtime, not in the bill of materials. Your architecture team should validate the details above before you accept it.

Storage: The forgotten layer

Storage sized after compute is bought forces either a checkpoint interval you cannot afford or a restart time you cannot accept. You cannot evaluate AI/HPC sourcing without treating storage as a core part of the system. When you do, fabric considerations extend to the storage layer as well.

High-performance storage is where failure gets its price. Checkpoint size, which reaches terabytes at frontier scale, bounds how often you can afford to checkpoint, and the time to read a checkpoint bounds restart timing.

Those numbers, multiplied by the failure rate, price each failure. The sourcing delta is the difference in failure rate and repair time between options, which you should ask each bidder to evidence. Hardware savings should never come at the expense of checkpoint architecture.

Tiering: A designer needs to plan data movement across several tiers:

• Local NVMe for fast checkpoint landing.
• Burst buffers and flash tiers in front of a parallel file system.
• The parallel file system and storage architecture behind it.
• Object storage for dataset and artifact durability.

During dataset staging, metadata pressure under swarms of small-file loads and read-storm behavior is hard to predict, and some failure modes are only testable at full scale. RAs increasingly specify certified storage partners based on OEM and partner testing.

Data governance/obligations: Training data arrives with provenance, access control, residency and other governance obligations. Those obligations attach to the data, however you source it. What changes is whether validated access-control and audit tooling arrive with the platform or you assemble it.

Sourcing processes that finalize compute first often push storage into later phases. Decide storage alongside compute, ideally using measured checkpoint and staging traffic. Once you count reliability and operations, ODM starts to look like adopting an OEM RA, and the addressable savings can shrink sharply. Model it before you assume it.

Energy efficiency is its own competitive axis

Power and cooling have shifted from a facilities constraint to a competitive axis, with efficiency replacing peak performance as the binding limit in the field. An ODM configuration that saves on the BOM but trades back efficiency through a lower-grade powertrain, a generic cooling package or a topology that burns switch watts during congestion, pays for that saving every hour the fleet runs, when the megawatt envelope is the scarcest thing on the site. Open-rack designs can also beat branded equivalents on efficiency, so compare measured efficiency across options.

Facilities

Part I flagged racks, power, floor loading and liquid cooling as facilities concerns. AI/HPC scale amplifies all of them. Rack-scale systems are engineered as end-to-end units spanning compute, network, cooling and power distribution, which means facilities infrastructure is integrated into the overall design, whether you planned for it or not.

Racks: Modern accelerated racks with direct-to-chip liquid cooling draw 130 to 150 kW today, with designs projected to exceed 200 kW. They also include mechanical requirements: busbars, manifolds, blind-mate connections and service clearances. You must validate facilities compatibility against the design, and the variability of an ODM sourcing strategy makes that validation harder.

Rooms: Have you considered in-rack, in-row or facility-level CDUs and secondary loop designs? Water quality, leak detection and leak response? Who is trained? What's the isolation procedure? What's the blast radius? Rack-scale systems are also serviced differently from individual nodes, and service access should be planned for.

Sites: The site's power envelope and expansion runway belong in the sourcing decision because ODM sourcing is often chosen for large projects, as absolute savings on paper increase with project size. In WWT's experience, a second pod frequently follows a commercially successful first pod well inside the first refresh cycle. Can the site host that growth across utility feeds, substation headroom and heat-rejection capacity?

 Renegotiating those commitments can take months you don't have. An ODM plan with no written expansion runway fails the Facilities precondition below.

The success fallacy

Teams sometimes justify ODM sourcing for enterprise estates by pointing to prior success with ODM sourcing for HPC clusters that follow an RA: "We built the GPU cluster ourselves, and that went fine, so we should do the same for the rest of the estate."

The general-purpose estate is heterogeneous by accumulation. It runs purchased software with hardware certification matrices and supports ERP, EMR, trading platforms, databases and VDI, where a lost node typically results in a performance-degradation incident for one business owner.

The supercluster earns its ODM case by fencing itself off. The estate has no fence.

The supercluster's success rides on the fleet's homogeneity: one or two SKUs, many identical nodes, a limited class of scheduler-managed and checkpointed workloads staffed by a specialized team, often operating in a physically separate, engineered-for-purpose facility. 

A supercluster that follows a reference architecture can meet Part I's conditions only by accepting the operating burden described here in Part II.

Supercluster preconditions

Part I's precondition scorecard still applies, and the list gets longer. For an AI/HPC supercluster, you should also consider:

• Failure absorption per workflow: For each workflow (batch training, tightly coupled simulation, interactive development, production inference), have you identified the layer that would absorb a node failure, determined the expected failure rate and priced the lost work?
• Fabric ownership: Do you have engineers who can own topology design, congestion tuning, collective-library qualification and fabric-level fault isolation as a permanent function? Will your switch, smart NIC and optics vendors help with cluster failures?
• Checkpoint arithmetic: Do you know your checkpoint size, write time, restart time and target interval, and does the storage tier in your design support them at full job scale?
• Facilities: Have you evaluated rack-to-room-to-site concerns and made appropriate commitments at every layer, in writing, including the expansion runway?
• Spare "insurance": Have you sized and funded the accelerator spare pool against current RMA lead times, and communicated this to the business as the price of self-sourcing?
• Supply and allocation: Have you confirmed lead times and allocation for accelerators, memory and NVMe against your delivery date and planned for a slip?
• Software and support stack: Who qualifies and supports driver, CUDA and collective-library versions, and who is accountable when a version change breaks the fabric?
• Refresh cadence: Accelerator generations arrive roughly annually. What does that do to the value of your spare pool and to the timing of your second pod?
• Governance: Is there an explicit agreement across the organization that an ODM sourcing decision for AI/HPC will not be used as evidence in sourcing decisions for the ISV-certified estate?

How WWT validates AI/HPC sourcing

For supercluster-scale decisions, WWT runs workshops and a structured validation sprint in our Advanced Technology Center (ATC). The sprint produces named deliverables your CFO, CIO and general counsel can act on.

• Workflow classification: Your actual jobs, characterized by failure geometry.
• Cluster architecture comparison: WWT works across our partner OEMs' reference architectures. In the ATC, we can validate fabric behavior by a scalable unit with failures present, storage behavior under your checkpoint traffic and your recovery procedures.
• Facility readiness: We can perform rack-to-room-to-site assessments with your facilities or colocation provider, producing a costed retrofit plan, or a documented "no."
• Benchmarks and fault injection: We can run benchmarks for your workflow mix that include deliberate failure injections (killing a node mid-training, flapping a link, failing a CDU sensor) to measure recovery costs on candidate platforms.
• Lifecycle TCO: We have built quantitative TCO (total cost of ownership) models that weigh firmware, qualification, sparing, support, compliance, the accelerator spare pool, licensing and facility work per scalable unit over the fleet's life.
• Decision memo: We can produce a recommendation document stating the preconditions and risks accepted, and what the sourcing decision does, or does not, say about the rest of your estate.

If the conclusion favors an ODM sourcing route, WWT will help you build it and say plainly where our support ends. If the conclusion favors a tier-two platform or a hyperscale-derived OEM line with a named warranty counterparty, we'll help you pressure-test the promises before you write the check.

Conclusion and next steps

For AI/HPC superclusters running fault-tolerant, homogeneous workloads, ODM-derived sourcing has been a normal operating model, particularly in CPU-only contexts. Accelerators, especially rack-scale systems, are changing that. You need to evaluate preconditions against the realities of the fabric, storage and facilities that exist outside the BOM. 

A third option worth pricing against both sourcing routes is to rent capacity from a traditional cloud provider or a neocloud — a purpose-built platform that delivers AI compute at scale.

A working rule: If you can't answer yes to the fabric ownership, checkpoint arithmetic and facilities items in the preconditions list, treat the ODM savings as unproven and use the OEM reference architecture as your pricing baseline.