Why a programmable valve is the most interesting thing CoreWeave shipped this week

CoreWeave announced yesterday that it is the first cloud to complete a validated bring-up of NVIDIA's Vera Rubin NVL72 — the rack-scale system with 72 next-generation GPUs welded into a single compute unit. The headline is the GPUs. The more interesting story is the two boxes CoreWeave built around them, called Valvey and Racky, and what they tell you about where the engineering work in AI infrastructure has moved.

This piece walks through what an NVL72 rack actually is, why it cannot exist without software-defined cooling, and what CoreWeave's two proprietary appliances are doing inside the cabinet. By the end you should be able to picture the rack and understand why the valve is the part worth pointing at.

What "rack-scale" means, and why it isn't a rack of servers

When most people picture a server rack, they picture a tall cabinet with maybe forty individual servers stacked inside it, each one a self-contained computer with its own CPUs, memory, and network port. The servers talk to each other over the network. If you want more compute, you add another server.

NVL72 is not that. The 72 GPUs in an NVL72 are wired together by NVLink, NVIDIA's proprietary chip-to-chip interconnect, at the rack level. NVLink moves data between GPUs roughly an order of magnitude faster than the network between two servers. From the software's perspective, those 72 GPUs behave much more like one very large GPU than like 72 small ones.

This matters because modern large models do not fit on a single GPU. The weights have to be sharded across many chips, and during inference those shards have to talk to each other constantly as a request flows through the model. If the interconnect is slow, the GPUs spend most of their time waiting. NVLink at rack scale is what lets a 72-GPU unit serve a single huge model at low latency, instead of behaving like 72 separate machines pretending to cooperate.

The cost of welding 72 GPUs into one logical unit is thermal. A rack of conventional servers might dissipate 20 kilowatts of heat. An NVL72 is in the neighbourhood of 120. Air cannot move that much heat out of a cabinet. So the rack is liquid-cooled — coolant flows through cold plates pressed against each GPU, carries the heat out, dumps it into a facility loop, and circulates back.

That liquid loop is where Valvey lives.

Valvey: the valve as a software endpoint

In a traditional liquid-cooled rack, coolant flow is governed by mechanical valves and fixed control loops. A thermostat senses temperature, a valve opens or closes, coolant moves faster or slower. The behaviour is wired in. If you want to change it, you change the hardware.

That sounds small. It is not. Once flow is programmable, the rack can do things a mechanical loop cannot. It can pre-cool a specific GPU group before a known-hot inference batch lands on it. It can route more coolant to chips running a long-context request and less to chips sitting idle. It can respond to firmware telemetry from the GPUs themselves, instead of waiting for a coolant-side thermistor to notice that something has gotten too warm.

The shift here is the same shift that happened to networking a decade ago. Networks used to be configured by walking to a switch and typing commands; software-defined networking turned the switch into something a controller could reconfigure on the fly, and the entire cloud industry was built on top of that change. CoreWeave is doing the same thing to cooling.

I want to flag what I do not know. Valvey's internals are not documented publicly. CoreWeave has not published a spec, a paper, or a repo. The description above is reconstructed from what the product has to do given the constraints of an NVL72 rack — not from CoreWeave engineering disclosure. Treat the mechanism as the most plausible reading rather than a confirmed one.

Racky: one control plane for the cabinet

Racky is the other half of the story. An NVL72 rack is not just GPUs and coolant. It is also power distribution, NVLink switches, network uplinks, telemetry from dozens of sensors, and firmware on every component. In a conventional rack each of these is managed by a different system, with different protocols, often by different teams.

Racky collapses that into a single appliance. One control plane reads telemetry from every component in the rack, thermal, power draw, link health, firmware state, and exposes them as one unified surface. The scheduler that decides which inference requests go to which GPUs can see, in one place, what the rack is doing physically.

Paired with Valvey, this is what makes software-defined cooling actually useful. Racky knows which GPUs are about to get hot. Valvey adjusts the coolant before they do. The rack becomes a closed loop where workload placement and physical cooling are coordinated by the same controller.

Why CoreWeave built these and the hyperscalers didn't ship them

Google, Microsoft, and Amazon all run liquid-cooled GPU fleets at enormous scale, and they all have internal cooling automation. CoreWeave's "industry first" claim is really "first for a neocloud, in a product you can rent." The hyperscalers keep their cooling stacks proprietary and undocumented because cooling is not what they sell — compute is.

CoreWeave is in a different position. It rents NVIDIA GPUs. So does every other neocloud. So, increasingly, do the hyperscalers themselves. If the only thing CoreWeave offers is NVIDIA-on-tap, it is one price cut away from being undercut by whoever has cheaper power. Valvey and Racky are CoreWeave's argument that the rack itself, not just the GPUs in it, is engineered IP worth paying for.

This is also why being first to bring up Vera Rubin matters more than it sounds. Bring-up is the hardware engineer's term for powering on new silicon for the first time and validating that every subsystem, firmware, drivers, interconnect, power delivery, cooling, initialises and behaves correctly under load. For a 72-GPU rack-scale unit, a single misconfigured coolant valve can trigger thermal shutdown across the whole cabinet. Being first means CoreWeave's engineers have already done the debugging that every other operator will have to do later.

The one thing worth holding lightly: NVIDIA owns roughly $2 billion of CoreWeave stock. Some portion of "first" reflects engineering skill, and some portion reflects preferential access to early hardware from a supplier that is also a shareholder. Both are real. The engineering is not less real because the access was easier.

The piece of this I'd encourage you to remember is the valve. GPUs are scarce and expensive, and that is the part of the story that gets covered. The bottleneck moving from one GPU generation to the next is increasingly thermal and electrical — how do you get the heat out, how do you get the power in. Whoever turns those physical constraints into software endpoints first gets to charge a premium for it. Valvey is a small box. It is also a claim that the next layer of cloud infrastructure is the rack, not the chip.

Footnotes and links

Further reading

• NVIDIA's Vera Rubin architecture overview (when published): https://www.nvidia.com/en-us/data-center/
• CoreWeave engineering blog: https://www.coreweave.com/blog
• Background on software-defined networking, the closest historical analogue to what Valvey is doing to cooling: https://www.opennetworking.org/sdn-definition/

¶