A look under our trunk: what’s in our compute
- Gammatek ISPL
- 14 hours ago
- 7 min read
Author: Gammatek ISPL
What Waymo actually revealed
The post, co-authored by VP of Engineering Satish Jeyachandran and Compute Lead Daniel Rosenband, is Waymo's first detailed look at the custom silicon behind the Waymo Driver. The headline piece is a purpose-built 5nm ASIC, a chip designed from scratch rather than bought off a shelf, engineered specifically to process raw lidar, radar, and camera data in real time. Waymo says the chip alone delivers over 1,000 TOPS of dedicated machine-learning performance, and that raw onboard compute power has scaled 20x in eight years. The system processes input from 13 high-resolution cameras simultaneously, with dedicated hardware for tasks like temporal denoising to improve low-light perception.
None of that is surprising for a company operating over 200 million fully autonomous miles. What's more interesting is why Waymo built custom silicon at all instead of buying faster off-the-shelf chips, and the answer comes down to three requirements it says are non-negotiable: the system has to be responsive, ruggedized, and redundant. Those three words are a better hardware evaluation framework than most IT procurement checklists, and they translate cleanly outside of automotive.
Three requirements that apply well beyond self-driving cars
Responsive means minimizing the delay between an input and an action. Waymo describes this as "pixels-to-actuation" latency, the time between a camera capturing a frame and the car responding to what's in it. For a self-driving car that gap has to be measured in milliseconds. For a business, the equivalent is the gap between a security camera detecting motion and an alert reaching a guard, or between a point-of-sale terminal reading a card and completing a transaction. Most companies never measure this gap until a customer complains about it.
Ruggedized means the hardware survives its actual operating environment, not a lab environment. Waymo's compute runs under constant vibration, shock, and temperature swings from Phoenix summers to Midwest winters, and it's integrated directly into the vehicle's liquid cooling system to hold performance steady regardless of conditions. Most business hardware doesn't face that kind of physical abuse, but a surprising amount of it lives in the equivalent of a bad environment anyway: a server closet with no climate control, a kiosk in direct sun, a warehouse scanner that gets dropped twenty times a day. Buying hardware rated for office conditions and deploying it somewhere closer to Waymo's operating envelope is a quiet, common cause of early hardware failure.
Redundant is the one worth spending the most time on, because it's the most transferable idea in the whole post. Waymo describes its compute as built like two independent engines that normally run in parallel, splitting the full workload, but if one experiences a fault, the other seamlessly absorbs the entire load without a gap. There's no human backup in a car with no driver, so failover isn't a nice-to-have, it's the design.
Off-the-shelf compute vs. co-designed compute: the trade-offs
Waymo's decision to design silicon, sensors, and software together instead of assembling off-the-shelf parts is the core engineering story here, and it's a decision every business eventually faces at a smaller scale: buy general-purpose hardware and accept its limits, or pay more for something purpose-built that fits the job better. Here's how that trade-off actually breaks down.
Factor | Off-the-shelf compute | Custom co-designed compute (Waymo's approach) |
Latency | Adequate for general workloads, not optimized for a specific pipeline | Tuned end-to-end for one workload; Waymo cites an 20x scale-up in raw power over eight years |
Redundancy | Usually bolted on afterward, if at all | Built into the architecture from day one, as parallel independent units |
Repairability | Standardized parts, broadly serviceable, easier and cheaper to fix | Highly specialized; failures often mean full-unit replacement, not component repair |
Upfront cost | Lower, since components are mass-produced | Higher, since silicon and software are built and validated together |
Best fit | General workloads, predictable environments, cost-sensitive deployments | Mission-critical, real-time workloads where failure has real consequences |
Waymo can justify the custom route because the cost of a compute failure is catastrophic and the workload is uniquely demanding. Most businesses aren't operating a fleet of driverless cars, so the honest takeaway isn't "go build custom silicon." It's "know which category your hardware decision actually falls into before you buy," because a lot of organizations either overpay for custom-grade reliability they don't need, or underpay for general-purpose gear running a workload that deserved better failover.
The security and compliance angle: redundancy is a business continuity decision, not just an engineering one
Waymo's parallel-engine design is really a business continuity plan expressed in hardware. If your organization runs access control systems, surveillance, transaction processing, or anything else where downtime has a compliance or safety consequence, the same question applies: if this component fails right now, what takes over, and how long is the gap? For a lot of businesses, the honest answer is "nothing, and the gap is however long it takes someone to notice and drive to the site." That's a bigger exposure than most risk assessments capture, because it usually shows up as a line item about "server redundancy" without anyone testing what an actual failover looks like under load.
If you haven't stress-tested your own failover path recently, that's worth doing before it's forced on you. We cover how to evaluate this properly in our post on {{PLACEHOLDER: link to your business continuity / uptime planning post}}, and our {{PLACEHOLDER: link to your device security assessment service page}} includes a review of exactly this kind of single-point-of-failure risk across a client's hardware stack.
The repair angle: specialization and serviceability pull in opposite directions
This is the part of Waymo's approach worth flagging for anyone who manages hardware lifecycle rather than just initial deployment. A purpose-built 5nm ASIC is extraordinary at the one job it was designed for, and functionally unrepairable in the traditional sense. There's no swapping a component or sourcing a replacement part from a third-party supplier; when custom silicon like this fails, the fix is a full board or unit replacement, not a repair ticket. Waymo can absorb that because it controls the entire supply chain and works directly with partners like AMD, Micron, NVIDIA, Samsung, Sandisk, Socionext, and TSMC to keep production moving.
Most businesses buying hardware don't have that luxury, and it's a real cost that rarely shows up during the purchasing decision. The more specialized and tightly integrated a piece of hardware is, the cheaper and faster it usually is to operate, and the more expensive and slower it usually is to fix when it breaks. That trade-off is worth pricing in explicitly, not discovering the first time a proprietary component fails outside its warranty window. It's a big part of why we push clients evaluating new hardware, especially anything with embedded, non-standard compute, to ask about repair pathways and part sourcing before the purchase order goes out, not after the first outage. Our {{PLACEHOLDER: link to your business hardware repair and lifecycle program page}} exists specifically to close that gap for fleets running specialized or aging equipment.
One more signal worth noticing: even Waymo doesn't build everything itself
It would be easy to read "custom silicon" and assume Waymo is doing all of this in isolation, but the post is explicit that it isn't. Alongside its own ASIC work, Waymo names a working partner list that includes AMD, Micron, NVIDIA, Samsung, Sandisk, Socionext, and TSMC. The company designs the pieces that are unique to its exact workload, driving without a human backup, and buys the rest from vendors who specialize in it.
That's a useful model for any business evaluating a build-versus-buy hardware decision, not just companies with Waymo's budget. The mistake is usually one of two extremes: either treating every hardware purchase as commodity and missing the one component where a mismatch actually creates risk, or trying to custom-build a solution for a problem that a specialized vendor already solves well and more cheaply. Waymo's approach suggests a narrower, more disciplined question: which single component, if it fails or underperforms, actually threatens the mission, and is that the one thing worth paying a premium to get exactly right? Everything else can reasonably come from an established vendor with a track record.
Implementation considerations before your next hardware decision
Waymo's framework is a genuinely useful evaluation checklist even for a business buying something far less exotic than autonomous vehicle compute:
Measure your actual "detection to action" latency for the systems where speed matters, rather than assuming general-purpose hardware is fast enough. You can't fix a gap you haven't measured.
Match the hardware to its real physical environment, not the environment it was rated for in a spec sheet. A device rated for office use in a warehouse or outdoor kiosk is a common, avoidable failure mode.
Ask what happens on failure before you buy, specifically whether there's a redundant path or a single point of failure, and what the actual recovery time looks like under a real test, not a theoretical one.
Price in repairability, not just performance, especially for specialized or embedded hardware where a failure means full replacement rather than a component swap.
Separate "nice performance gain" from "mission-critical reliability need" before paying a premium for custom or highly specialized hardware. Waymo's cost-benefit only works because the downside of failure is severe; most business hardware decisions don't clear that bar.
Frequently asked questions
What is Waymo's compute system, in plain terms? It's the onboard hardware that turns raw sensor data (from cameras, lidar, and radar) into real-time driving decisions. Waymo built custom silicon, including a purpose-built 5nm ASIC, specifically to process that data fast enough and reliably enough to drive without a human backup.
Why does Waymo use custom silicon instead of off-the-shelf chips? Off-the-shelf components weren't built for the specific combination of ultra-low latency, extreme physical durability, and built-in redundancy that driving without a human backup requires. Co-designing the chip, sensors, and algorithms together let Waymo optimize for that exact workload instead of accepting the limits of general-purpose hardware.
What does "redundant" mean in Waymo's compute design? Waymo runs its compute as two independent units operating in parallel under normal conditions. If one fails, the other takes over the full workload without a gap, so there's no single point of failure in a system with no human able to intervene.
Does any of this apply to a normal business, not an autonomous vehicle company? Yes, at a smaller scale. The three questions Waymo's design answers, how fast does the system respond, how well does the hardware survive its real environment, and what happens automatically if a component fails, are worth asking about any business-critical hardware, from security systems to point-of-sale infrastructure.
Is more specialized hardware always the better choice? No. Specialized, tightly integrated hardware performs better but is usually harder and more expensive to repair when it fails. It's the right call when the cost of downtime is severe, the way it is for Waymo. For most business hardware, general-purpose components with a clear repair and replacement path are the more practical choice.
Not sure whether your hardware has a real failover plan or just an assumed one?
Our device security assessment stress-tests your actual redundancy path, flags single points of failure across your fleet, and builds a repair and lifecycle plan before a hardware failure forces the decision for you.
Comments