Waymo Built Its Own Chip. Then Plumbed It Into the Coolant.

In August, Waymo published a description of the computer in the back of its robotaxis. The headline everywhere was that the company had designed its own chip.

That part is not surprising. Everybody is designing their own chip. Tesla has disclosed that its AI5 and AI6 inference parts are headed for production in 2027 and 2028. Rivian is building one. The economics of custom silicon flip the moment your volume is high enough and your workload is narrow enough, and autonomy is an unusually narrow workload.

The interesting part is three details further down, and none of them are about the chip's performance.

It Only Does the Front End

Waymo describes a purpose-built 5nm ASIC delivering, in their words, over 1,000 TOPS of ML performance dedicated to front-end processing and ML models.

Read that qualifier again, because it is doing a lot of work. The chip is not driving the car. It sits at the sensor ingestion layer, where its job is to instantly extract critical information from raw lidar, radar, and camera streams and run sensor fusion models. Thirteen high-resolution cameras, processed simultaneously and in real time, plus lidar and radar.

So the company built its most specialised piece of hardware for the least glamorous layer of the stack.

That is a deliberate and, I think, correct choice. The front end is where the work is fixed, relentless and latency-critical. Every frame from every sensor must be handled, at full rate, forever, whether the scene is a motorway at 3am or a junction with a cyclist in it. The driving policy above it is where the interesting variation lives — but the front end is where the watts go.

It is also the layer where general-purpose hardware wastes the most. A GPU is built to be good at everything you might ask; a sensor front end asks the same narrow question tens of thousands of times a second. That is the textbook case for an ASIC, and it is the layer nobody writes press releases about.

Two Independent Engines

The second detail is the one I would put in front of any functional safety engineer.

“Our compute is designed like two independent engines,” Waymo writes. “While they normally operate as one unit running full parallel workloads, if one experiences a fault, the other seamlessly takes over.”

I want to be precise about what that does and does not say, because much of the coverage was not. This is failover — one path detects a fault, the other assumes the load. It is not the same thing as two channels computing the same result and comparing them, which is what lockstep architectures do and what gives them their diagnostic coverage. Waymo has described the first. Several outlets reported the second. They are different designs with different failure behaviour, and the distinction is not pedantry — it is most of what a safety case argues about.

What matters for this article is simpler. A dual-path compute architecture with a defined takeover behaviour is not how you build a research platform. It is how you build a vehicle system. The question it answers is not “how fast is it?” but “what happens at the moment it breaks, and can you say so in writing?”

Commercial vehicle engineers have been answering that question about braking, steering and powertrain control for decades. It is now being asked of the inference hardware.

The Detail I Keep Coming Back To

The third is a single clause, and it is the one that tells you where this technology actually is.

The compute integrates directly with the vehicle's liquid cooling system.

That is the sentence an automotive engineer should stop on. Not because liquid cooling is exotic — it obviously is not — but because of what sharing a coolant loop implies. It means the compute is no longer a box that was placed in a vehicle. It is a load on the vehicle's thermal system, competing for the same rejection capacity as everything else, and it has to behave across the full ambient range the vehicle is homologated for. Not room temperature. A loading bay in May, and the same vehicle at altitude in winter.

It also means the compute has a budget it cannot argue with. A data centre can answer a thermal problem with more cooling. A vehicle answers it with less compute, or a bigger radiator, or a heavier harness — each of which costs range, mass or money.

Waymo also mentions that raw compute power has scaled 20x in eight years. That is the number I would put next to the cooling clause, because the two are in tension. Compute has been growing at a rate the vehicle's ability to reject heat has not.

Why This Matters Away From Robotaxis

Almost nobody reading this is building a robotaxi. The reason it is worth attention is that the constraint being demonstrated is about to arrive everywhere else.

As driver assistance moves up the regulatory agenda for commercial vehicles, the engineering conversation tends to start with algorithms and sensors. In my experience it ends somewhere much more mundane: how many watts are available, where the heat goes, what the harness weighs, and what the system does in the second after something stops responding.

A truck cab is a worse thermal environment than a passenger car, not a better one. It sits in traffic and at loading docks with limited airflow, in ambient conditions that would be considered extreme in most product categories, for duty cycles measured in years of continuous operation rather than hours of demonstration. Any compute that lives there is inheriting that envelope.

Which is why I read Waymo's post as less of a chip announcement and more of a constraint disclosure. The performance figure — over 1,000 TOPS — is the part that travels. The architecture around it is the part that took the work: narrow the workload until custom silicon pays, split the path so a fault has an answer, and plumb the whole thing into a cooling system that was designed for an engine.

The Part That Is Actually Transferable

There is a pattern here that generalises past silicon, and it is the reason I wanted to write this one up.

A technology becomes a product at the point where the questions asked of it change. Early on, the only question is capability: can it do the thing at all? That phase produces demonstrations, and demonstrations are optimised for the best case.

The transition happens when the questions become boring. What does it draw? Where does the heat go? What is the behaviour at the failure boundary? How does it degrade rather than stop? Nobody films that phase, and it is where almost all the engineering is.

Waymo's post is a description of a system that has finished the first phase. Whether the driving works is a separate argument, and this article takes no position on it. But the compute has clearly stopped being an experiment, because the things they chose to disclose about it are thermal integration and fault behaviour rather than benchmark scores.

That is usually the most reliable signal you get that something has crossed over. Watch what a team volunteers about a system. When they stop telling you how fast it is and start telling you how it fails, they have started building it for real.