Built Together: Inside the Dell + CoreWeave Engineering Partnership Powering Next-Gen AI
A candid panel between Dell and CoreWeave leaders on co-engineering GB200, GB300, and Vera Rubin rack-scale AI platforms. The discussion covers why early access and stabilization matter in the AI arms race, how the industry moved from server-level to rack-as-computer architecture, and how joint development, standardized Redfish tooling, and shifting diagnostics left have enabled scale. It closes with where rack-scale infrastructure is heading toward pods, denser heterogeneous systems, and the need for automation in liquid cooling and power.
Overview
This panel brings together Sarat Krishnan, who leads AI rack-scale system development at Dell, and Jacob, VP of computer architecture at CoreWeave (the “server guy” responsible for hardware engineering, NPI for custom SKUs, firmware, systems, OS and kernel, and the software glue). Harsh, CoreWeave’s product lead for compute hardware, moderates. The conversation covers how the two companies co-engineered GB200, GB300, and Vera Rubin rack-scale platforms, what that shift from server to rack required, and where the infrastructure is heading.
Origins of the partnership
The relationship was forged in a Las Vegas data center during the first GB200 bring-up, where the teams spent long stretches cranking on the first rack-scale system deployed anywhere. Jacob describes the Dell relationship as already good before that, but the current tight joint development model was born in that crucible. Thousands of racks later, Jacob is jokingly described as the most demanding customer, which the panel frames as affectionate.
Why being first matters
Jacob argues that early access to new hardware is decisive in an AI arms race. Training the next generation of frontier models may require the next generation of hardware, and getting it hours, days, or months ahead of competitors can be make-or-break. Equally important is runtime: early platforms give CoreWeave time to stabilize firmware, hardware, and software before handing them to customers, so that when a customer receives a rack it is ready to go rather than being debugged in production alongside other CSPs.
Sarat frames first-mover advantage as a mindset and process change. Moving from building individual servers and networking them together in the data center to building and testing a rack as one integrated system was a paradigm shift. Being first forced both companies to learn how to integrate, test, and scale such systems quickly.
Shifting from servers to racks
A central theme is that the rack is now the unit of computing. Sarat explains that Dell has moved much of the complexity left in the manufacturing pipeline. Firmware settings, network topology, switch cabling, and other configuration are handled in the L10 compute and L11 rack factories, so racks can move from dock to deployment in a matter of hours. Diagnostics that catch hardware issues are pushed upstream because remediation becomes progressively more expensive the closer you get to the data center. Dell also built more configurability into L11 racks to accommodate different data center layouts, such as bottom feed versus top feed, informed by feedback from CoreWeave’s deployments.
Jacob outlines the technical change on the GB200 NVL72 rack design: an OCP-style busbar with power shelves that changed power delivery, liquid cooling for all devices including in-rack CDUs with manifolds and quick-disconnects, a new CPU architecture, and an external NVLink switch with roughly 1,296 individual connections. Life cycle management shifted from managing individual servers to managing an entire system where the NVLink switch must be configured, the fabric healthy, compute trays happy, power shelves and power delivery functioning, and the CDU and liquid cooling in good condition. CoreWeave responded by building services such as the Rack Life Cycle Controller (RLCC) and using Kubernetes CRDs to represent racks, CDUs, and NVLink switches. The key insight is that everything must be checkpointed and treated as one functioning unit, since healthy compute trays are meaningless if the cooling or power subsystem fails.
Rack manager and joint development
For Vera Rubin, Jacob describes Raki, CoreWeave’s rack manager, which manages the racks, valves, and power shelves. He admits he lacked confidence that it would work on the first racks and prepared backup plans, but it worked, requiring software and control plane changes along the way. Rather than maintaining two rack managers, Dell agreed to adopt CoreWeave’s Raki, integrating it into factory designs and manufacturing processes. Jacob notes an interesting role reversal: Dell is now the vendor, and CoreWeave can hold them accountable.
Sarat sees this as true joint development with cross-pollination of ideas. Dell has its own rack manager, and CoreWeave’s Raki is now used in Dell’s factories, including to test power shelves. The conversation highlights a drip tray concept, developed with CoreWeave’s early deployment, that catches rack-level leaks before they damage the system. Other customers now request it. Sarat calls CoreWeave a beacon customer: what CoreWeave wants today, the industry wants tomorrow.
Transparency and operational partnership
Jacob identifies transparency as the key trait he values in an OEM/ODM partner. Early on, the L11 factory throughput was poor and CoreWeave was frustrated. Dell opened its process, allowing CoreWeave engineers into the factory to find bottlenecks together. The result, in Jacob’s words, is that Dell now churns out racks faster than CoreWeave can take them. Several people from each company have visited the other’s facilities, and the panel stresses that transparency and willingness to roll up sleeves are central to the relationship.
Standardizing tooling at scale
Sarat describes collaboration on standardizing Redfish APIs, which give customers strong telemetry and observability. This work was formalized through the DMTF standard. He gives an example of engineer-to-engineer feedback: during Vera Rubin builds, CoreWeave engineers on site found that manifolds needed adjustments for better serviceability, and that change flowed back into Dell’s L11 factories so subsequent racks could be reconfigured immediately.
Jacob, who calls himself unabashedly team Redfish, explains a gap he identified: CoreWeave’s requirements were not fully captured by existing DMTF conformance and compliance tools. CoreWeave built a tool called Fisherawware, cleaned up from its internal version and made portable, and gave it to Dell to run in the factory before shipping hardware. Jacob’s point is that customers should not hit edge cases on the 500th or 1,000th rack, because the requirements are captured and validated upstream.
What to see in a data center
Sarat predicts the rack will soon be superseded by the pod as the unit of deployment: a GPU rack married to networking and storage racks, tested together and deployed together. Two years ago a single GB200 rack was remarkable, and now thousands are deployed. Cooling has evolved from one CDU per rack to end-of-row CDUs serving a row of racks, which adds complexity but requires sophisticated controllers such as valves and rack controllers that isolate and remediate individual racks. Power density has grown from roughly 10 to 20 kW per rack a decade ago to possibly a megawatt rack soon.
On naming, the panel jokes that Raki is a name CoreWeave fought to keep, and that Dell engineering names are often shot down by marketing.
Jacob recommends seeing Dell’s factory, where L10 assembly and rack integration at scale are impressive, and CoreWeave’s liquid cooling infrastructure, with multi-megawatt CDUs, stainless steel plumbing, and heat exchangers and pumps the size of construction equipment. He frames liquid cooling as IT gear now, directly managed by engineering as an extension of the GPU and rack. The row is the computer.
Looking ahead
Sarat argues that rack scale is only the beginning. The future is denser and more heterogeneous, combining GPUs with storage and networking, and connecting multiple racks into pods. Agentic workloads and long context windows, up to a million tokens, are driving that demand. He is bullish on rack-scale architecture and notes that inference models have adapted to it, where skepticism existed a year earlier.
Harsh cites a CoreWeave inference benchmark on Vera Rubin with a partner, Cognition, that achieved roughly a 5x performance improvement within days of access to the new rack. He expects further gains as the software ecosystem matures across SGLang, vLLM, and TensorRT-LLM.
Jacob closes on the operational gap: while compute has decades of standardized management through Redfish and similar interfaces, liquid cooling and power delivery lag in automation maturity. Some vendors still expect telemetry to be gathered from a front panel, which is untenable at tens of thousands of units. He expects aggressive expansion of standards to bring facility and cooling infrastructure to parity with infrastructure-as-code management of compute.