Product Strategy + Infrastructure

A Custom Silicon Roadmap Needs Checkpoints

Christopher Mitchell 4 min read

Custom silicon trades flexibility for optimization. Multi-generation deals need checkpoints before today's workload assumptions harden into tomorrow's chips.

Sixty billion dollars changes things.

Qualcomm and Amazon announced a multi-generation collaboration today around customized silicon for AWS AI infrastructure, a deal that stretches product planning unusually far into the future. The companies plan to work on inference chips plus optical connectivity reaching 1.6 terabits per second, while Qualcomm will expand its own use of AWS for chip-design workloads.

Reuters adds the commercial machinery underneath it. Amazon received warrants to buy roughly $4 billion of Qualcomm stock, tied to as much as $60 billion in business agreements over ten years. For product leaders, the interesting part is the time horizon because custom silicon turns an infrastructure purchase into a sequence of coupled product bets.

A roadmap can live inside the supplier contract

Buying a standard accelerator preserves optionality because another vendor or architecture can compete for the next deployment if workload economics change. Custom silicon trades some of that freedom for tighter optimization around the buyer’s actual workload, power envelope, network topology, software stack, and expected scale.

Then physics joins the roadmap.

A chip arriving several years from now has to serve workloads nobody can specify cleanly today, so requirements can’t stop at throughput targets. The product team needs assumptions about model mix, memory behavior, inference latency, utilization, networking, power, cooling, software compatibility, migration from the previous generation, and probably several constraints that haven’t become painful yet.

Some assumptions will be wrong. The commercial and technical plan therefore needs room to discover them before the next design hardens, when changing direction becomes expensive in a hurry.

I’d treat each silicon generation as a product option with explicit checkpoints rather than one giant commitment disguised as a roadmap. At each checkpoint, ask whether the workload forecast still holds, whether the previous generation delivered its expected economics, and which assumptions moved enough to justify changing the next design.

That is less tidy than a ten-year architecture diagram, and considerably more useful.

Optimize the system, not the impressive component

Qualcomm’s announcement includes optical connectivity for a reason: at data-center scale, accelerator performance alone doesn’t determine throughput. Memory movement and communication between devices can become the expensive part of the system, especially as clusters grow and inference workloads spread across hardware today.

The product boundary gets wider.

A custom accelerator that benchmarks beautifully but forces costly changes in networking, cooling, software, or rack design can still lose at the system level. Performance per watt, tokens per dollar, rack density, network utilization, software-porting cost, and deployment lead time belong in the same decision model.

This is where custom hardware starts looking surprisingly product-manager-y: the specification is a negotiated hypothesis about future customer demand, technical constraints, and economics. Then that hypothesis gets frozen into something much harder to patch than software, with manufacturing lead times waiting behind it.

I’ve argued before that a roadmap is a portfolio of bets, not a list of promises; custom silicon makes that painfully literal. Software teams can move a roadmap item next quarter, while silicon teams eventually tape it out and live with what they decided.

Ten years is a long bet.

The useful product question isn’t whether the plan is correct, because no team gets that luxury. It’s whether the agreement contains enough checkpoints to discover where it became wrong before the next generation hardens around yesterday’s assumptions.

Sources

Comments

Comments are powered by GitHub Discussions through Giscus.

← All MitchellCo Notes