ASRock Rack OCP 2026 Puts Liquid Cooling Across the NVIDIA Server Lineup

ASRock Rack displayed NVIDIA systems spanning a 72-GPU rack and smaller servers at OCP 2026, extending liquid cooling beyond the largest accelerator platform. The ASRock Rack OCP 2026 lineup also included a liquid-cooled network switch, according to ServeTheHome’s November 1 booth coverage. Together, those systems show how cooling decisions increasingly shape the surrounding infrastructure, rather than ending at the server chassis.

The contrast is between buying individual servers and preparing an integrated computing installation. A graphics processing unit, or GPU, accelerates the parallel calculations used in AI workloads. Packing more GPUs into a cabinet changes requirements for electrical distribution, networking, maintenance, and heat removal. Those requirements follow the hardware into the customer’s building.

ASRock Rack’s announcement also draws an important availability distinction. The company described GB300 NVL72 systems as currently offered, while presenting its next-generation Vera Rubin platform as approaching deployment. Buyers therefore need to separate the hardware displayed at the event from configurations they can order, install, and support on a confirmed schedule.

ASRock Rack OCP 2026 Shows Cooling Across the System

The most visible exhibit was ASRock Rack’s implementation of NVIDIA’s Vera Rubin NVL72 platform. NVL72 identifies a rack configuration connecting 72 GPUs through NVIDIA’s high-speed interconnect. ServeTheHome’s liquid-cooled server lineup coverage describes 36 Vera central processing units, or CPUs, alongside the Rubin accelerators.

The reported rack contains 18 compute trays and nine NVLink switch trays. NVLink is NVIDIA’s interconnect for communication among accelerators and associated processors. That arrangement makes the cabinet an integrated computing system, with internal communications designed around the assembled rack.

The booth’s strongest signal was the breadth of liquid cooling across different infrastructure roles.

ServeTheHome also identified HGX Rubin NVL8 servers in 2U and 5U formats, alongside RTX PRO systems and a dual-Vera CPU server. Here, U denotes a standard unit of vertical rack space. HGX is NVIDIA’s integrated accelerator platform for server manufacturers, while NVL8 identifies an eight-GPU configuration.

The report additionally identified the liquid-cooled Spectrum-X SN6600-LD network switch. Spectrum-X is NVIDIA’s Ethernet networking platform for AI clusters, meaning groups of computers working together. Its presence matters because networking equipment has its own thermal requirements, separate from those of the compute trays.

ASRock Rack independently confirmed several central elements in its OCP server announcement. The company dated that announcement October 12 and identified the San Jose event as running October 12 through 15. It highlighted a dual-Vera CPU system, a liquid-cooled HGX Rubin platform, and a liquid-cooled RTX PRO server.

Those dates establish the chronology. The November booth coverage documents an October exhibition; it does not establish a new November product launch. Similarly, displaying a rack establishes its presence at the event, without establishing delivery volumes or customer acceptance.

The lineup also resists a simple interpretation that every buyer should purchase the largest available system. Different configurations address different workload sizes and installation constraints. A complete rack, a smaller accelerator server, and a CPU-focused machine represent distinct purchasing decisions.

That variety gives the event a practical focus. ASRock Rack showed several ways to assemble NVIDIA-based infrastructure while extending liquid cooling across them. The resulting question concerns which configuration fits a workload and facility, rather than which cabinet contains the most accelerators.

The Pressure Falls on Facilities and Procurement Together

For infrastructure buyers, the shift changes who needs to participate in a server decision. Accelerator selection remains important, but electrical and mechanical teams need to evaluate the same project. A procurement process that settles the computing specification first risks discovering installation constraints afterward.

Direct-to-chip liquid cooling carries coolant through cold plates attached to heat-producing components. This method transfers heat into a liquid circuit near its source. It still requires a path for moving that heat beyond the server and ultimately out of the facility.

A liquid-cooled server purchase requires agreement between the computing design and the building’s operating limits.

Consider an enterprise planning an on-premises AI service for internal document analysis. Its software team might focus on model quality, response time, and data controls. Infrastructure staff must also determine whether the selected hardware can operate within the available power and cooling arrangements.

The workload does not become deployable simply because the model runs successfully on a vendor demonstration. The intended installation needs a defined configuration, compatible connections, monitoring, and a maintenance plan. Each requirement belongs in the project before the equipment arrives.

This is where ASRock Rack liquid cooling becomes more than a component specification. It changes the boundary between the server supplier and the customer’s infrastructure team. Both sides need a shared understanding of which equipment transfers heat, which equipment rejects it, and who supports each connection.

A coolant distribution unit, or CDU, manages the interface between equipment cooling and the wider cooling installation. Its selection depends on the complete design rather than the accelerator name alone. Buyers need to know whether the proposed arrangement includes that equipment and the controls required to operate it.

Facilities teams also need operating information rather than broad efficiency descriptions. Coolant conditions, connection requirements, allowable pressure, and service procedures determine compatibility. A server described as liquid-cooled does not supply those answers by itself.

Procurement must translate that engineering work into clear responsibilities. The contract should identify the supported configuration and the boundary between rack support and building support. Otherwise, a problem crossing that boundary can become difficult to diagnose and resolve.

This pressure arrives during platform evaluation, not only during installation. Buyers comparing configurations should include facility preparation and operational staffing in the same assessment. The smaller server can be the better fit when its deployment requirements align more closely with the intended environment.

The booth therefore illustrates a change in purchasing coordination. Computing teams still choose the capabilities they need, but facilities teams help determine which capabilities can become usable capacity. Successful planning brings those decisions together early.

Liquid Cooling Expands Beyond the Accelerator

Cooling the accelerator addresses a major heat source, but an AI installation contains other equipment. Internal switches connect processors within a system, while external networks connect servers and racks. Those communication layers affect both workload behavior and the physical installation.

NVIDIA’s Spectrum-6 switch documentation describes the SN6600-LD as a fully liquid-cooled switch in a 2RU enclosure. It supports 128 ports at up to 800 gigabits per second. The product makes liquid cooling part of the network design as well as the compute design.

A liquid-cooled network switch extends cooling coordination into another essential part of the AI installation.

The distinction between internal and external communication matters here. NVLink connects accelerators within the relevant computing domain, meaning the group sharing that interconnect. Ethernet links can connect systems across a larger installation. Buyers should avoid treating their specifications as interchangeable measures.

A rack can offer extensive internal communication while still depending on external networking for a distributed workload. Distributed training divides model training across multiple computing devices. Its behavior depends on how computation and communication interact across the actual configuration.

This creates a deployment consideration rather than an automatic performance conclusion. A faster network specification does not establish application throughput. The workload, software configuration, and communication pattern determine how much of that capability becomes useful.

The same caution applies to cooling. Moving heat through liquid changes its route through the installation. It does not eliminate the heat produced by operating the equipment. The surrounding design must still provide an appropriate destination for that thermal load.

A liquid-cooled switch also adds operational questions. Teams need procedures for monitoring its cooling connections and servicing it alongside neighboring equipment. A network maintenance plan should account for those requirements before the switch becomes part of a production dependency.

The broader direction appears in facility planning as well. Schneider Electric’s Vera Rubin reference design describes a purpose-built data hall for Rubin clusters with shared networking racks. It includes floor-mounted liquid-to-liquid cooling distribution equipment and fluid coolers.

That document represents an engineered reference arrangement, rather than evidence that every customer needs the same building. Its relevance is the planning boundary it illustrates. The computing platform sits inside a coordinated electrical, mechanical, and networking design.

For buyers, the implication is straightforward. An evaluation limited to the server enclosure leaves out systems that the application depends on. Cooling and network plans need to describe the complete installation, including how equipment behaves during service.

ASRock Rack liquid cooling therefore belongs in a broader architectural conversation. The switch exhibit helps make that relationship visible. It shows why discussions about dense AI computing increasingly include network engineers, facilities specialists, and operations staff alongside server buyers.

Shared NVIDIA Hardware Moves Competition Toward Integration

ASRock Rack competes in a market where multiple suppliers build systems around NVIDIA platforms. Shared processors and interconnects give buyers useful comparison points. They also mean that accelerator identity alone cannot explain every meaningful difference between suppliers.

Lenovo’s GB300 cooling design offers a relevant reference. Its documentation describes liquid cooling across processors, NVLink switches, and power subsystems, with supplemental airflow handling remaining heat. The document also discusses service connections and leak detection.

Suppliers using related NVIDIA platforms still compete through implementation, serviceability, and deployment support.

That comparison does not establish that Lenovo’s configuration and ASRock Rack’s Rubin exhibit are equivalent. They involve different platform generations and supplier designs. It does establish that integrated cooling and maintenance features already belong in competitive evaluation.

A buyer should therefore compare the complete proposed systems. Questions about accessible components, supported replacement procedures, and monitoring deserve attention alongside accelerator specifications. The answers determine how the installation behaves after the initial acceptance process.

Serviceability becomes especially important when an application depends on tightly connected hardware. Buyers need to understand what remains available during a component replacement. They also need to know whether the proposed service procedure matches their own staffing and maintenance arrangements.

The larger rack does not automatically win that comparison. An organization running independent workloads might value scheduling flexibility and smaller maintenance boundaries. Another organization might prioritize a large connected accelerator domain because its workload benefits from that arrangement.

These are application choices, not universal rankings. The correct comparison starts with the work the system must perform. It then examines whether the proposed configuration delivers that work within the customer’s operational requirements.

Smaller configurations can also provide a different route through procurement. A buyer might have a defined requirement for a departmental service rather than a shared institutional computing installation. The availability of several server formats makes that distinction worth examining.

ASRock Rack’s range gives it entries into those different conversations. However, a broad exhibit does not establish equal readiness across every displayed configuration. Buyers still need configuration-specific information about ordering, software support, delivery, and maintenance.

The competitive pressure falls on suppliers to make those details concrete. If the underlying accelerator platform is shared, buyers can ask what the supplier contributes around it. Integration work, qualification, documentation, and accountable support become important parts of the answer.

For NVIDIA Rubin deployment, that makes supplier execution a central comparison. The question extends beyond access to the newest silicon. Buyers need evidence that the selected supplier can turn the proposed design into an accepted, supported installation at their site.

A Booth Display Leaves Performance and Availability Questions Open

The verified story establishes a varied hardware exhibit and a company announcement describing its direction. It does not establish independent application benchmarks for every displayed machine. It also does not establish a firm delivery date for each configuration.

ASRock Rack’s October announcement explicitly separated currently offered GB300 systems from the Vera Rubin platform awaiting deployment availability. That wording should guide interpretation. Buyers should request updated, configuration-specific commitments rather than infer availability from a cabinet’s presence at an event.

Displayed hardware, published specifications, and accepted customer installations answer different questions.

NVIDIA’s Vera Rubin platform announcement makes efficiency and performance claims for the architecture. Those remain company claims unless independently validated under relevant conditions. They do not directly establish the performance of ASRock Rack’s exhibited configuration.

A useful application comparison needs a defined workload and a consistent measurement boundary. Inference, the process of generating outputs from a trained model, varies with model settings and service requirements. Throughput figures become difficult to interpret when those conditions differ.

For an interactive service, response time and output quality belong beside throughput. A configuration serving more requests under relaxed conditions might not meet another application’s requirements. Buyers should ask how the proposed test reflects their intended service.

Training evaluations need similar discipline. The model, software configuration, and completion criteria should be explicit. Comparing hardware without those details risks attributing a workload difference to the server platform.

Energy comparisons require another boundary decision. Measuring only accelerator consumption answers a narrower question than measuring the complete installation. Pumps, network equipment, and heat-rejection systems can belong in the broader assessment, depending on the claim being evaluated.

Water claims also need careful interpretation. Coolant circulating inside equipment does not by itself reveal how the facility rejects heat. Buyers should request a site-specific account rather than infer facility water use from the server’s cooling description.

None of these gaps invalidates the exhibit. Trade-show hardware provides useful evidence about supplier priorities and implementation direction. It simply serves a different purpose from a customer acceptance test or a long-term operating record.

The appropriate skepticism is therefore specific. Ask which configuration was tested, what workload it ran, how measurements were collected, and which infrastructure components were included. Ask separately what can be delivered and supported under a contractual commitment.

For developers and enterprise AI teams, these distinctions affect planning. Model capability does not guarantee available computing capacity on the required schedule. NVIDIA Rubin deployment needs technical validation and delivery evidence before it becomes a dependable application dependency.

Watch Delivery, Workload Results, and Site Acceptance Next

The next useful evidence should connect the exhibition to customer operations. ASRock Rack OCP 2026 established the product direction and the breadth of the display. The following stage needs to show which configurations buyers can receive and how those configurations operate.

Delivery commitments, relevant workload measurements, and completed site acceptance will clarify the significance of the lineup.

First, watch for configuration-specific availability updates from ASRock Rack. A useful update would identify the system, supported components, ordering status, and delivery commitments. Those details would strengthen the case that the exhibited range is becoming accessible to customers.

Continued availability language without configuration details would leave that question unresolved. This does not necessarily indicate a technical problem. It means buyers still lack information needed to schedule procurement and installation.

The distinction matters particularly when comparing GB300 and Rubin options. An available configuration and a forthcoming configuration occupy different positions in a project plan. Buyers should compare the work each can support within the actual deployment window.

Second, watch for application results with clear testing conditions. Useful evidence would identify the system configuration, model, software, workload, and measurement method. It would also explain whether energy measurements cover the server or a wider installation.

Results matching customer workloads would strengthen the deployment case more than isolated peak specifications. Conversely, results that omit operating conditions would leave performance comparisons difficult. The test should help readers understand the application, rather than merely repeat architecture-level capabilities.

Independent testing would add another perspective, but transparency remains necessary regardless of who runs the benchmark. Buyers need enough detail to judge relevance. A reproducible methodology makes that judgment more useful than a headline multiplier.

Third, watch for documented customer acceptance at completed installations. Site acceptance is the process of verifying that installed equipment meets agreed operational requirements. Relevant evidence would address computing behavior, cooling integration, monitoring, and service procedures.

Such evidence would connect the server design to the surrounding infrastructure discussed throughout this story. A working installation shows that the interfaces can function together under specified conditions. It still would not establish identical results at every other site.

For infrastructure teams, the immediate action is to define those acceptance conditions before selecting a configuration. Identify the workload, service expectations, facility limits, and support responsibilities. Then ask suppliers to respond against the same requirements.

Keep deployment documentation connected to the application decisions that depend on it. Engineering teams can use a searchable knowledge base to preserve specifications, test results, and acceptance records. That record helps distinguish a product claim from a verified condition at the intended site. When reviewing the ASRock Rack OCP 2026 lineup, start with the application your team must deliver. Ask which configuration supports it, what the facility must provide, and what evidence will establish readiness. Carry those answers into procurement and acceptance planning. The useful next step is a deployment brief that every participating team can assess against the same documented requirements.