A note on scope: chip architecture isn’t my research area. This is a synthesis of public reporting on a trend worth understanding, written with the same care about sourcing and overclaiming I try to apply to my own work.
In about 18 months, nearly every major AI lab and cloud provider has quietly become a chip company. Broadcom, now co-designing custom silicon with Google, Meta, and OpenAI, among others, is carrying a $73 billion AI backlog and telling investors it expects more than $100 billion in annual AI chip revenue by 2027. Amazon’s in-house silicon business, built to run in its own data centers rather than sold to others, is already generating revenue at a $20 billion annual run rate. Amazon, Google, Microsoft, and Meta combined are on track to spend roughly $725 billion on capital expenditure in 2026, a 77 percent jump from the year before, with a growing share of that aimed at infrastructure that isn’t a Nvidia GPU.
Here’s the detail worth sitting with before anything else: every company building custom silicon is also still buying Nvidia GPUs, often at enormous scale, often at the same time. This isn’t a replacement story. It’s closer to a hedge — and a fairly deliberate one. The rise of custom AI silicon is not primarily an attempt to eliminate GPUs. It’s an attempt to divide the compute stack: keep general-purpose accelerators for rapidly changing research and heterogeneous workloads, while moving sufficiently stable, high-volume workloads onto hardware whose economics, supply, and roadmap the operator can influence more directly.
That’s the argument this piece makes. The rest is evidence.
A few things pop out once it’s laid out this way.
A few things stand out once the programs are laid side by side.
Google has the longest head start — not because it’s the biggest company here, but because it started earliest. Its first TPU went into internal production in 2015, giving it roughly a decade to progressively co-optimize the hardware with TensorFlow, and later with XLA and JAX, into a software layer that makes the chips genuinely usable rather than just fast on paper.
OpenAI’s approach differs structurally from Google’s or Amazon’s. Google rents TPU access through the cloud; Amazon sells Trainium access to any AWS customer. OpenAI’s Broadcom-designed accelerators, by contrast, are being deployed across OpenAI’s own facilities and partner data centers rather than offered as a general cloud-compute product — a narrower and more defensible claim than saying OpenAI is “keeping every chip for itself,” which the public announcements don’t actually establish either way.
Anthropic complicates any framing built purely around hyperscalers. It doesn’t operate a consumer cloud, doesn’t sell chip access, and isn’t designing its own silicon — but it runs training and inference across a deliberately diversified mix of AWS Trainium, Google TPUs, and Nvidia GPUs, with multigigawatt commitments to both Amazon and Google. That suggests a more useful dividing line than “hyperscaler vs. everyone else”: compute scale. Once a company reaches a size where negotiating hardware directly — instead of just buying GPU instances — starts to pay off, it ends up on this list, regardless of whether it runs a public cloud.
It’s also worth being precise about maturity, since it varies a lot across this roster. TPUs and Trainium are already deployed at scale — Trainium2 is reportedly widely deployed, and Trainium3 began shipping in early 2026. Several of the newest generations and the most ambitious multigigawatt commitments, particularly Meta’s and OpenAI’s, remain in ramp-up or still-forward-looking stages. “Custom silicon is coming,” and “custom silicon is already load-bearing” are distinct claims that apply to different rows of the same table.
The pattern above explains why companies want to reduce dependence on a single vendor. It doesn’t yet explain why purpose-built hardware can actually be more efficient than a Nvidia GPU for a given workload — and this is the part of the story most prone to overclaiming, so it’s worth being careful.
Three distinctions matter more than the usual “GPU vs. ASIC” framing suggests:
That distinction matters because it’s easy to overstate what specialization buys. Google’s original TPU paper reported roughly 30–80x better performance-per-watt than contemporary CPU and Nvidia K80 systems on specific production inference workloads — a real result, but a 2017 comparison against hardware two generations obsolete by now, not a number that generalizes to today’s GPUs. The honest version is less quotable: gains can be substantial, but they vary sharply with workload, utilization, numerical precision, batch size, memory behavior, and the quality of the surrounding software stack. The relevant question isn’t whether an ASIC is universally more efficient than a GPU — it’s whether it’s more efficient for a large and stable enough workload, once migration and utilization costs are included.
That’s part of why every company on the list above still keeps GPUs in the mix. Designing competitive silicon is genuinely difficult — architecture, verification, physical design, packaging, HBM integration, yield, production ramp-up. What these programs are really betting on isn’t that silicon is easy; it’s that making a chip usable, portable, and economical across real production workloads is a second, often longer, problem than designing it — and one worth solving for the narrow, high-volume slice of a workload that’s stable enough to justify it, while leaving everything still in flux on a GPU.
If specialization only helped at the margins, it wouldn’t be worth the design cost. The strategic case is what makes it worth billions of dollars before a single chip ships, and it has more to do with concentration risk than raw speed.
Start with the supplier problem. NVIDIA remains the dominant supplier of data-center AI accelerators — exact market-share figures vary considerably depending on what’s being measured (GPUs specifically versus all accelerators, revenue versus unit share, which regional markets are included), so it’s more honest to describe the position than to lean on a single contested number. For a company spending tens of billions of dollars a year on compute, that concentration is a single point of failure for pricing, allocation priorities, and delivery timelines. Meta’s own account of why it started MTIA in 2023 makes the underlying condition concrete: a GPU shortage had driven up costs and made supply unpredictable enough that money alone couldn’t buy certainty.
Capex scale changes what’s worth building in-house. With Amazon, Alphabet, Microsoft, and Meta together projected to spend roughly $725 billion in capital expenditure in 2026 — total capex, of which AI infrastructure accounts for much of the increase — even a modest share redirected toward custom silicon represents real money, and real justification for standing up entire chip-design organizations. Amazon’s custom-silicon business is the clearest existing proof this isn’t theoretical: a reported $20 billion-plus annual revenue run rate through AWS, spanning Graviton, Trainium, and Nitro together, not Trainium alone.
For the cloud providers specifically, control has a second payoff: it becomes a product. Google doesn’t just use TPUs internally — it rents access to them, and has reportedly given select AI startups free access to TPU pods specifically to seed the kind of developer ecosystem Nvidia built around CUDA. If that works, Google converts hardware ownership into the same kind of lock-in Nvidia currently holds, except this time Google owns it.
For OpenAI and Anthropic — neither of which sells cloud access to the public — the logic is narrower but still about reducing single-vendor exposure rather than pure cost. OpenAI is simultaneously developing custom accelerators with Broadcom, running a large multi-year compute agreement with Cerebras, and has lined up a planned 10-gigawatt deployment of Nvidia systems, backed by up to $100 billion in progressive investment from Nvidia as that capacity comes online — not, as it’s sometimes described, a flat $100 billion GPU purchase. That’s a deliberate portfolio: several suppliers, so no single one can fully set price or timeline. Anthropic’s combined use of Trainium, TPUs, and Nvidia GPUs follows the same logic at a different scale.
None of this amounts to full independence, and it’s worth being clear about that rather than implying otherwise. Even a company running its own accelerator design still depends on TSMC for fabrication, on a small number of suppliers for advanced packaging and HBM, and on specialized networking components that aren’t easy to substitute either. What custom silicon buys is vendor diversification and more influence over your own roadmap — not an exit from supply-chain concentration altogether. It’s insurance, priced years in advance, against depending on exactly one company for the thing an entire business runs on.
Everything above treats hardware as the interesting problem. In practice, the harder constraint on whether a custom chip gets adopted at all is software — and it’s worth being specific about why, since this is where well-financed chip programs have historically stalled.
NVIDIA’s advantage was never only that its chips were fast. A decade and a half of engineers have learned to build, debug, and optimize models against one specific toolchain — libraries, kernels, profiling tools, documentation, and an accumulated base of fixes and workarounds. That familiarity is mostly invisible until a team tries to move away from it, at which point it becomes the highest real cost in any migration.
This is where Google’s early start actually pays off: TPU hardware was progressively co-optimized with TensorFlow, and later with XLA and JAX, over roughly a decade — giving Google a software-and-operations advantage newer accelerator programs have had far less time to build. Amazon has taken a similar lesson to heart with Trainium, whose Neuron SDK integrates directly into PyTorch, TensorFlow, and Hugging Face rather than asking developers to learn something new. Microsoft has gone further still, abstracting Maia entirely behind Azure’s APIs so a team building on Copilot or Azure OpenAI Service doesn’t need to know which chip is underneath.
In each case, the strategy is the same: hide the migration cost from the people who’d otherwise resist paying it. That’s realistic for a company that controls the model, the serving stack, the scheduler, the compiler path, and the data center all at once — a short list of companies. Most enterprises want portability and a stable API, not a hardware-migration project, which is a large part of why this move is currently limited to a handful of players rather than becoming general practice.
Worth naming plainly rather than folding into the confidence of the argument above: several of the specific figures and timelines here are still forward-looking rather than settled. Meta’s newest MTIA generation and OpenAI’s Broadcom-designed accelerator haven’t shipped in volume yet. The cost comparisons hyperscalers make internally aren’t public, and the efficiency figures that are public tend to be workload-specific rather than general. And because Broadcom, Marvell, and TSMC sit behind most of what gets called a “custom” chip, some of what looks like independent hardware strategy is really concentrated in a small number of shared suppliers further down the stack. The honest framing is a bet still being tested, not a bet already won.
Step back, and the throughline holds: this isn’t primarily a story about Nvidia losing. What’s changed is that a small number of companies have concluded that total dependence on one supplier is a risk large enough to justify billions of dollars in chip design, years before certainty about the payoff exists — not to eliminate GPUs, but to move the stable, high-volume slice of their workload onto hardware whose economics and roadmap they can influence directly, while everything still in flux stays on a GPU.
An accelerator gains efficiency by narrowing the space of problems it has to solve. A similar tension arises in machine learning research: a model can look impressive on a well-specified benchmark and still fail when the task moves beyond the assumptions built into its architecture, training data, or evaluation protocol. Specialization isn’t a weakness in either case — but its benefits only mean something if you’re explicit about what’s been specialized for, what’s been left out, and how stable those assumptions actually are.