OCP 2026: Racks Keep Getting More Open
Why platforms remain hard to replace
Chip supply and deployment capacity are now constraining AI infrastructure together. NVIDIA is widening what it opens around racks, facilities, and operations software; AMD is using Helion to organize the execution and inference resources of agents; Intel is stressing the chance to add capacity inside existing air-cooled facilities. All three routes are competing for the ability to come online faster — but drawings being available, parts being swappable, and platforms being migratable are still three different things.
From October 12 to 15, 2026, the Open Compute Project (OCP) Global Summit took place in San Jose. NVIDIA contributed Vera Rubin rack and compute-tray designs, AMD announced plans to contribute the Helion rack specification, and Intel updated its GPU D-Series inference cards while showing an open accelerator-card form factor and its Xeon rack ecosystem. Put together, what stands out is not who added another card, but how much work that used to be negotiated project by project vendors are turning into interfaces their partners can jointly implement. [1]
This is not a story of the leader suddenly embracing openness. Back in 2024, NVIDIA had already contributed its MGX/GB200 NVL72 rack and tray designs to OCP. What is new in 2026 is that openness keeps extending toward higher-power racks, facility conditions, grid behavior, and deployment software. In step, the purchasing and acceptance boundary of frontier-scale clusters is widening: buyers increasingly need to evaluate a system that can be brought online and maintained, not just compare single-card performance. [2]
"The open rack wars" therefore has a more specific meaning: whoever gets more manufacturers, integrators, and operators working around their own architecture has a better chance of becoming the default choice for the next round of construction. Openness can widen supply options; it can also widen one platform's reach. The two are not in conflict.
The Bottleneck Has Not Moved Neatly
For two years, discussions of AI infrastructure tended to start from the supply of GPUs, HBM, and advanced packaging. By the fall of 2026 those constraints had not gone away, yet power access, cooling retrofits, rack integration, and acceptance were also getting harder to sidestep. Rather than declaring that the bottleneck has "moved" from chips to deployment, it is more accurate to say the critical path that decides the online date now differs from project to project.
On its August earnings call, NVIDIA talked about supply constraints and about land, power, and buildings needing to be secured two to three years ahead. This explains why vendors care about supply and deployment at once: even with accelerators in hand, the other preconditions may not be ready in step. IEA's analysis estimates that grid constraints could delay roughly 20% of the global data-center capacity planned for construction before 2030. The former is a company's operating judgment; the latter is scenario analysis. Both support the importance of deployment constraints; neither proves that chips are no longer scarce. [3] [4]
A project's path to production can be simplified into parallel tracks — equipment delivery, power access, cooling and network preparation — converging at system integration and acceptance. Under the simplifying assumption that the pre-work proceeds in parallel while final acceptance must wait for all of it, the online time approaches "the latest-ready precondition, plus the remaining integration-and-acceptance time." Real projects involve overlapping construction and phased commissioning; this relation is a lens for identifying constraints, not a schedule forecast.
The value of an open reference design lives at exactly these junctions. Manufacturers learn the mechanical envelope of the rack earlier; power and cooling suppliers can stock against common interfaces; integrators do not have to reinvent a set of connections for every customer. If standardization cuts rework, it can shorten the time from equipment arrival to usable compute.
But this is a causal chain that still needs verification. Publishing a specification is evidence that a vendor is trying to reduce deployment friction; it is not yet evidence that delivery cycles have shortened. The metrics that can actually test this round of openness include the number of qualified suppliers, first-pass acceptance rates, on-site commissioning time, and fault-replacement time — not just how many documents were contributed.
Openness Has to Pass Four Gates
Before comparing the three companies, a much-repeated word needs to be taken apart.
The first gate is specification availability: which documents are public, and under what license. The second gate is implementability: whether the design data, critical components, and realization conditions are sufficient — whether others can actually build it. The third gate is interchangeability: whether parts from different suppliers pass compatibility validation, and whether swapping parts affects safety, performance, and warranty. The fourth gate is portability: after moving workloads to another platform, whether model quality, service latency, and operational capability survive.
These four gates are not one unified "openness score." Contributing a mechanical design is not contributing a chip implementation; adopting PCIe does not mean every server can take the card directly; open-sourcing software does not make the hardware capabilities it depends on cross-platform at the same time. An open license is not the same as a work entering the public domain, either — the specific rights and conditions still live in the corresponding documents. [5]
For buyers, the distinction is very practical: adding two more manufacturers within the same architecture and moving your business from one accelerator family to another solve different problems. The former mainly improves supply and bargaining position; the latter also requires redoing software, networking, performance, and operational responsibility.
NVIDIA Lets More People Build — Still Around the Same Platform
Through MGX 1.2, NVIDIA this time contributed the Vera Rubin rack and compute-tray designs to OCP. The published support envelope includes rack deployments up to 250 kW, a 5,000-amp liquid-cooled busbar, blind-mate liquid-cooling connections, fanless liquid-cooled compute trays, and standardized power and cooling interfaces. These numbers describe a design envelope and interface capabilities — not performance results from independently tested, complete racks. [6]
The meaning of a tray cannot be read from parameters alone. How modules insert and lock, how cooling and power connections align, and which parts must come apart during service all shape assembly and repair. NVIDIA's official tray-assembly animation presents these relationships more clearly than a front view of a rack: the value of modularity lands first on manufacturing and service actions. An animation can help understand structure; it cannot substitute for measured assembly times. [7]
Openness keeps extending beyond the rack. ODCS v0.7 was published jointly by NVIDIA, AMD, Google, and Meta, covering facility power, cooling, and physical layout; the grid disturbance-performance specification was contributed by Google, Meta, Microsoft, and NVIDIA. The two specifications took effect in August and September respectively, and the summit pushed previously formed standards in front of more manufacturers and operators. Different signatory lists indicate different scopes of cooperation, but the lists alone are not enough to derive camp alignments. [8] [9]
The easiest part to misread is the "two-second recovery." What the grid specification says is: within defined voltage ride-through conditions, once the voltage at the point of interconnection returns to its normal range, computing loads restore to 90% of pre-fault load within two seconds. It is not a guarantee that all business recovers within two seconds after any blackout, and the recovery of the cooling system is not part of the same commitment. Writing the conditions out clearly does not weaken the specification; it is precisely what lets engineering teams test and accept the requirement. [9]
Higher power also pushes electrical retrofits to the foreground. The open work around low-voltage DC power discusses both paths that reuse existing AC facilities and transition paths aimed at new data halls; Visionbay's K-1, introduced at this summit, organizes power and thermal around NVIDIA's 800 VDC reference architecture. There is more than one option besides "tear down and rebuild": where power conversion is concentrated, and whether the change reaches the rack or the data hall, both change the engineering scope. Open interfaces help these steps coordinate, but whether a given site is worth changing, and how, still has to be designed case by case. [6] [20]
Why interface openness has to reach engineering detail also shows in liquid cooling. Publishing the mating dimensions of a quick disconnect solves only part of "how to connect"; sealing, material compatibility, pressure loss, and lifetime still need validation. A cold plate additionally faces the combined constraints of contact, retention, flow, and thermal performance. A common specification reduces repeated coordination; it does not waive product validation, and it does not make different suppliers' parts equivalent by default. [10] [11]
Software has entered this deployment chain too. The four open-source DSX components NVIDIA added cover network configuration, cluster readiness checks, rack management, and bare-metal provisioning. On October 13, NVIDIA announced it was open-sourcing the complete Run:ai platform while keeping commercial support channels. This round of moves, therefore, cannot be summarized as "only opening the hardware periphery." [6] [12]
The more accurate boundary is this: opening code and interfaces can still revolve around one platform's capabilities. Run:ai's GPU Fractioning Operator using CUDA-native capabilities is a concrete example. NVLink Fusion likewise widens partners' paths to attach custom CPUs and XPUs — but access to NVIDIA's interconnect system is not the same as other vendors being able to independently replace the whole implementation. [12] [13]
NVIDIA's route is therefore better described as widening participation in the platform: letting more companies build, deploy, and operate this system, while continuing to organize it through interconnect, software compatibility, and the validation hierarchy. For buyers, this may lower construction friction; for NVIDIA, it may also make its own architecture more likely to become the de facto default.
AMD Uses a Rack to Split an Agent's Two Workloads
AMD's Helion is easy to confuse with Helios, but the two are not the same product. Helios targets large-scale GPU training and inference; Helion is an OCP-spec-based agentic AI reference design whose point is combining agents' execution resources and model-inference resources as needed.
Helion has two representative configurations. The CPU-only rack for hyperscale customers uses sixth-generation EPYC, provides up to 32,768 CPU cores, and connects to separate model-inference infrastructure. The enterprise configuration puts CPU and GPU nodes into one solution: the official product page lists up to two eight-GPU MI350P nodes, 16 accelerators in total, and the two nodes do not form a unified GPU scale-up fabric domain. Deploying in the same rack does not merge the two GPU groups into one scale-up system. [14]
What is more informative than the core count is the split of workloads. Beyond calling models, agents also execute code, run tools, process data, and maintain isolated environments. This work should not all scale with GPU inference capacity. Being able to build CPU and inference resources separately means operators can tune the ratio to actual load, instead of buying more accelerators just to add execution capacity. The right ratio still depends on tool types, concurrency, and isolation requirements; a rack's core count by itself cannot prove how many agents it can sustain.
AMD also folds a token router into its integrated software capability, distributing requests between frontier and open-source models. It hints at another axis of competition: rack offerings are starting to include the operating logic of "how models are used." The official announcements, however, do not adequately explain this component's license, policy export, and replaceability — whether it creates a new dependency remains to be seen. The questions worth asking are whether users can keep their own policies, swap the router out, and reach models running on other platforms. [15]
This is still a blueprint that lands through partners. AMD's release uses the wording "plans to contribute" the specification to OCP, and says partner-developed Helion configurations are planned to become available starting November 2026. Specification contribution, specific systems reaching the market, and delivery at scale should be watched separately; the official material cited here does not yet provide rack-level measurements suitable for cross-vendor comparison. AMD's opportunity is to make it easier for partners to form deliverable solutions around its CPUs and accelerators; what buyers actually gain can only be judged once concrete configurations, software, and services land together. [15]
Intel Turns "Touch the Facility Less" into a Competitive Condition
Intel's angle is different. The GPU D-Series, formerly code-named Crescent Island, is built on the Xe3P architecture; published specifications include 1.5 TB/s of memory bandwidth, 1.3 PFLOPS peak FP8, and a 350-watt power envelope in a standard PCIe air-cooled form factor. Capacity must be read in parts: Intel's own card carries 160 GB of LPDDR5X, and 480 GB is an optional ceiling for ODM partner designs. The product is currently in customer sampling. [16]
What this design stresses is adding inference capacity inside existing facilities. For enterprises that cannot immediately build high-power liquid-cooled environments, changing less of the power, cooling, and servers may matter more than chasing the highest single-card peak. But "fit for existing facilities" is not "plug-and-play in any old server": slot dimensions, power, airflow, firmware, drivers, and service software all still need validation.
Air-cooled deployment is not a market Intel owns, either. NVIDIA itself has the air-cooled RTX PRO 6000 Blackwell Server Edition: 96 GB of GDDR7, 1.597 TB/s of bandwidth, and up to 600 watts. What is distinctive about the D-Series is a larger optional capacity at a comparable class of bandwidth — not a monopoly on air cooling. And 350 watts versus 600 watts are power specifications; they do not directly tell you which card completes the same task on less energy. [17]
Intel is not without open contributions. Its summit release introduced the Open Adapter Card workgroup's work on a standardized accelerator-card form factor and showed a Xeon rack ecosystem built on OCP Open Rack v3. The difference is that its D-Series narrative leans on making use of existing infrastructure rather than centering on contributing a new full-rack blueprint. [16]
When Does Big Capacity Become Cheap Tokens?
Intel's route raises a good question: does inference require re-valuing memory? The answer is yes — but it cannot be reduced to "training only cares about bandwidth, inference only cares about capacity." Training was always jointly constrained by compute, capacity, bandwidth, and interconnect; and inference has internal phases of its own.
Prefill, which processes the input, can exploit massive parallel compute; decode, which generates output step by step, is usually more sensitive to memory access. The KV cache grows with context length and concurrency and can occupy a large share of capacity. More memory can hold more weights and cache, cut some swapping, and leave room for batching; but once the requests fit, there is still the question of how quickly they get answers. [18]
The simplest capacity arithmetic shows what promotional parameters leave out. A 300-billion-parameter model, at 2, 1, and 0.5 bytes per weight, needs roughly 600, 300, and 150 GB for the weights alone — before quantization metadata, KV cache, activations, and runtime overhead. "480 GB hosts a 300B model" therefore holds only under a given precision and serving configuration; it does not imply that any 300B model runs efficiently on a single card. This is a capacity calculation, not a throughput prediction for the D-Series.
Online serving adds a set of conditions that cannot be skipped: the same model and quality bar, the same input/output length distribution, and the same time-to-first-token (TTFT) and time-per-output-token (TPOT) targets. MLPerf's online-serving scenario uses exactly this kind of latency requirement. Offline jobs can wait for batches to grow; interactive services may hit the user-waiting ceiling before capacity fills up. [19]
Going across cards is not automatically a losing trade, either. Model parallelism introduces communication but also adds available compute, memory, and aggregate bandwidth; under some latency targets, multiple cards can beat squeezing onto one large-memory card. Which route is cheaper depends on the real model, communication paths, runtime, and workload — not on concluding directly from "fewer cards."
At purchase time, the account can be compressed into two metrics. Cost per million qualified output tokens equals full-system cost per hour, divided by the qualified output tokens actually delivered in that hour, times one million. "Qualified" means meeting quality and the agreed latency; full-system cost should include hardware amortization, hosts and networking, facilities, power, and operations, with idle and unavailable time counted in. Energy per token is the actually measured system energy divided by the qualified tokens delivered in the same window.
One conditional calculation shows why watts alone are not enough: suppose two candidate boards run at sustained powers of exactly 350 watts and 600 watts. For the first to achieve lower board energy per token, its qualified throughput must exceed about 58% of the second's. That is an algebraic relation — not a measurement, and it excludes whole-system, network, and cooling energy. Until price and qualified throughput are both available, the D-Series is first and foremost a capacity route worth testing; whether it delivers cheaper inference awaits same-condition comparison.
Less of One Dependency, Not Necessarily Less of Another
Back at the rack, the most direct commercial gain from openness is that more suppliers get to participate in building and delivering around a shared design. That can reduce duplicate adaptation and widen same-platform sourcing options. But "integrator margins must fall" still moves too fast: the premium on duplicated design may compress, while validation, liquid-cooling commissioning, fault handling, and delivery guarantees may become more valuable. Value can be redistributed rather than vanish from the chain.
The platform-migration account also needs to be kept separate. CUDA, kernels, and the software ecosystem never lived on a single card, so lock-in did not only "move up" from chips to software in 2026. The more important change is that the system boundary needing joint validation has grown: accelerators, CPUs, interconnect, power, liquid cooling, firmware, scheduling, and service software together decide system behavior. Even with mechanical drawings open, swapping out one of the core architectures can still trigger re-adaptation and re-acceptance.
This enlargement does not require every buyer to purchase whole racks. Frontier clusters value rack-scale communication and delivery; enterprise inference may keep scaling by server, by card, or by cloud service. Intel's route itself reminds the market: with different deployment conditions and workloads, the sensible unit of purchase differs too. Whole-rack procurement is one route; the other form factors retain clear demand and boundaries.
So the most valuable reading of this round of openness is not how high a wall each of the three companies built, but which kind of participation threshold each of them lowered. NVIDIA lets more partners build and operate systems around its platform; AMD organizes agents' execution and inference capabilities with a configurable blueprint; Intel puts standard form factors, open software, and compatibility with existing facilities up front. All three are racing into production environments — but cross-platform freedom of movement does not grow automatically with the number of contributed documents.
What to watch next is not only which specification gained another signature. Whether Helion's planned contribution lands as usable documents, and whether specific systems ship as promised; when the D-Series has comparable pricing, software, and serving performance; whether open interfaces bring more validated second sources; and whether deployment time and failure recovery improve in real projects. Those are the signals that will turn "openness for deployment speed" from a plausible explanation into an observable result.
Racks are opening up, and what grows first may be the freedom to participate in construction. Whether the platform becomes easier to replace still depends on what exit costs. For buyers, what is worth fighting for is not an abstract promise of openness, but clarity before going live: which parts can be swapped, which performance must be re-tested, and which software and operational capabilities you can take with you.
Sources and Caveats
Fact-checking for this article is current as of October 16, 2026. Product parameters follow the respective vendors' published material and are not independent measurements; specification clauses describe design or acceptance requirements, not conformance of every product. Helion's contribution and delivery use planning language; Intel's 480 GB is an ODM design ceiling. Original diagrams and the capacity arithmetic state their assumptions; official structural, assembly, cross-section, and topology figures are used for their original purpose, with no undisclosed structure redrawn.
References and Figure Sources
Photographs, official design figures, and logical schematics in the figures are labeled separately. Original proportions and structure are preserved, with interpretive captions placed outside the original images; device ceilings and historical parameters in the figures follow the corresponding sources, dates, and conditions.
[1] 2026 OCP Global Summit — Open Compute Project, October 12–15, 2026
https://www.opencompute.org/summit/global-summit
[2] NVIDIA Contributes Blackwell Platform Design to Open Hardware Ecosystem — NVIDIA, October 15, 2024
https://nvidianews.nvidia.com/news/nvidia-contributes-blackwell-platform-design-to-open-hardware-ecosystem-accelerating-ai-infrastructure-innovation/
[3] NVIDIA Q2 FY2027 Earnings Call Transcript — NVIDIA Investor Relations, August 26, 2026
https://investor.nvidia.com/files/content_files/TRANSCRIPT_-NVIDIA-Corp-NVDA-US-Q2-2027-Earnings-Call-26-August-2026-5_00-PM-ET.pdf
[4] Energy and AI: AI and Energy Security — International Energy Agency, 2025
https://www.iea.org/reports/energy-and-ai/ai-and-energy-security
[5] Contribution Templates & Agreements — Open Compute Project, checked October 16, 2026
https://www.opencompute.org/contributions/templates-agreements
[6] OCP Global Summit: NVIDIA Opens Vera Rubin Architecture — NVIDIA, October 12, 2026
https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/
[7] Inside the NVIDIA Rubin Platform: Six New Chips, One AI Supercomputer — NVIDIA Technical Blog, 2026; checked October 16, 2026
https://developer.nvidia.com/blog/inside-the-nvidia-rubin-platform-six-new-chips-one-ai-supercomputer/
[8] Open Data Center Specification v0.7.0 — NVIDIA, AMD, Google, Meta / OCP, effective August 27, 2026
https://www.opencompute.org/documents/open-data-center-spec-revision-0-7-0-4-pdf
[9] Interface Specification Between Hyperscalers and Utility Grid for Disturbance Performance v1.0 — Google, Meta, Microsoft, NVIDIA / OCP, effective September 17, 2026
https://www.opencompute.org/documents/ocp-base-spec-interface-specification-between-hyperscalers-and-utility-grid-for-disturbance-performance-pdf
[10] Universal Quick Disconnect Design Specification v2.0.0 — Open Compute Project, v2.0.0; checked October 16, 2026
https://www.opencompute.org/wp-content/uploads/2026/10/OCP-Design-Spec_UQD_v2.0.0.pdf
[11] Cold Plate Test Specification v1.0.0 — Open Compute Project, v1.0.0; checked October 16, 2026
https://www.opencompute.org/wp-content/uploads/2026/10/OCP-Cold-Plate-Test-Specification-V1.0.0.pdf
[12] NVIDIA Run:ai Is Now Open Source as Part of NVIDIA DSX AI Factory Platform — NVIDIA Technical Blog, October 13, 2026
https://developer.nvidia.com/blog/nvidia-runai-is-now-open-source-as-part-of-nvidia-dsx-ai-factory-platform
[13] NVLink Fusion: Build Semi-Custom AI Infrastructure — NVIDIA, checked October 16, 2026
https://www.nvidia.com/en-eu/data-center/nvlink-fusion/
[14] AMD Helion Agentic AI Rack: product page and FAQ — AMD, checked October 16, 2026
https://www.amd.com/en/products/rackscale-solutions/helion.html
[15] Introducing AMD Helion, Agentic AI Compute at Rack Scale — AMD Investor Relations, October 12, 2026
https://ir.amd.com/news-events/press-releases/detail/1301/introducing-amd-helion-agentic-ai-compute-at-rack-scale
[16] Intel Accelerates Open Infrastructure for the Agentic AI Era — Intel, October 2026; checked October 16, 2026
https://www.intel.com/content/www/us/en/newsroom/news/artificial-intelligence/intel-accelerates-open-infrastructure-agentic-ai-era.html
[17] RTX PRO 6000 Blackwell Server Edition: official specifications — NVIDIA, checked October 16, 2026
https://www.nvidia.com/en-us/data-center/rtx-pro-6000-blackwell-server-edition/
[18] Mastering LLM Techniques: Inference Optimization — NVIDIA Technical Blog, November 17, 2023; checked October 16, 2026
https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/
[19] MLPerf Inference v5.0 Advances Language Model Capabilities for GenAI — MLCommons, April 2025
https://mlcommons.org/2025/04/llm-inference-v5/
[20] Powering the Next Era of AI: Transition to LVDC — Open Compute Project, checked October 16, 2026
https://www.opencompute.org/news/powering-the-next-era-of-ai-how-google-microsoft-and-nvidia-are-standardizing-and-accelerating-the-industry-transition-to-lvdc/
[21] NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Project — NVIDIA, October 15, 2024
https://developer.nvidia.com/blog/nvidia-contributes-nvidia-gb200-nvl72-designs-to-open-compute-project/
[22] Intel GPU D270 | Inference-Optimized Data Center GPU — Intel, October 16, 2026
https://www.intel.com/content/www/us/en/products/details/discrete-gpus/data-center-gpu/d-series.html
[23] Open Adapter Card — Open Compute Project, October 16, 2026
https://www.opencompute.org/projects/semi-private-workstreams/open-adapter-card/
[24] AMD Instinct MI355X GPU product datasheet — AMD, October 2025 datasheet, checked October 16, 2026
https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/product-briefs/amd-instinct-mi355x-gpu-brochure.pdf
[25] NVIDIA Vera Rubin NVL72 official product specifications — NVIDIA, current product page, checked October 16, 2026
https://www.nvidia.com/en-us/data-center/vera-rubin-nvl72/