Nvidia's Moat Isn't the Code. It's the Eighteen Years You'd Have to Re-Live to Catch Up.

An engineer at a well-funded AI lab wants to run her model on AMD's silicon. The hardware is right there: AMD's MI300X carries 1.5 times the theoretical compute of Nvidia's H100, and her finance team would love to stop paying Nvidia's margin.⁷ She runs the workload. It hits maybe half the H100's real throughput - 37 to 66 percent, depending on the day.⁷ The chip isn't slow. The chip is starved. The fast version of the kernel she needs - the attention math, the quantization tricks - was written for CUDA first, and the AMD port arrived months later, or never.⁷ She switches back to Nvidia by lunch. Nobody made her. The path was just easier.

The official story is that Nvidia's lock-in is the code: that CUDA is some proprietary language you can't escape. Almost none of that is true. AMD's HIP translates most CUDA source with minimal changes.⁸ You can leave the language any afternoon. What you cannot leave is the eighteen years of work that happened on the other side of the language - and that is the real wall.

The moat isn't the language. It's everything written in it.

Nvidia introduced CUDA in November 2006 and shipped the public SDK on February 15, 2007 - a platform built by a team Nvidia had hired starting in 2004, including Ian Buck, who had created the Brook GPU language at Stanford.¹⁵ None of that founding history is the asset. The asset is what got piled on top of it for the next eighteen years: roughly 250 widely-used CUDA libraries, hand-tuned by people who knew exactly which memory access pattern the silicon rewards.³ When a new technique appears - a faster way to do attention, a smarter way to page memory - it ships as a CUDA kernel first, because that is where the developers are. Every one of those kernels is a small switching cost. Stack up a decade of them and you have a wall nobody planned and nobody can climb in an afternoon. The thesis is simple: Nvidia isn't defended by what CUDA is. It's defended by everything 5.9 million developers have already written in it.²

Look at how that number got there and you see why it's a moat rather than a marketing figure. Nvidia's own developer blog said it took thirteen years to reach a million registered developers - and less than two more years to reach two million.⁴ That curve is the tell. Early on, a developer platform grows on its own merits, slowly. Past a certain density it grows because it's already big: tutorials exist, answers exist, the libraries you need are already written, the person next to you already knows it. Nvidia crossed that inflection a decade ago. Its FY2025 filing now puts the count past 5.9 million.² Each new developer makes the next one's choice more obvious, and the choice is rarely the rival chip.

Where the wall is concrete, and where it's already cracking

Here is the part the bulls and the bears both get wrong, because they treat 'the CUDA moat' as one thing. It is two. In training - building the model from scratch, the most compute-hungry and least forgiving workload - Nvidia's share runs above 90 percent, and the dependence is near-total, because the frontier libraries that make training tractable are CUDA-first by default.⁶ If your stack leans on TensorRT-LLM or FlashAttention 3, CUDA is simply the only viable option.⁸ But inference - running a finished model in production - is a different game. It's a more standardized, more repeatable workload, and that is exactly where a challenger can get a real foothold. AMD's MI355X posted MLPerf Inference 6.0 results in April 2026 within single-digit percentage points of Nvidia's B200 - tying on Llama 2 70B Offline throughput and reaching 97% of B200 Server performance on the same benchmark.¹⁰⁸ The moat is near-absolute at the hard end and leaking at the easy end. Treating it as uniform is how you misprice it in both directions.

Isn't a software lead the easiest kind to lose?

The fair objection is that software moats are the flimsiest of all. There's no patent on knowing CUDA. Open-source ports exist. AMD's silicon is genuinely competitive now, sometimes ahead on raw numbers - so why won't this lead evaporate the way software leads usually do? Two reasons. The first is that the rival doesn't get to copy the destination, only the language - the libraries arrive 'months later, sometimes never,' which means a challenger is permanently running last year's kernels against this year's.⁷ The second is the honest one the bulls skip: the moat is not eternal, and it is thinnest exactly where the market is growing fastest. Inference volume dwarfs training over a model's life - the aggregated compute cost of inference often greatly exceeds training because the same model serves an enormous number of requests⁹ - and inference is where the gap has narrowed to single digits.⁸ Note, too, that AMD was never technically irrelevant - it was strategically absent. Its earlier failure wasn't a worse chip; it was the decision not to fund a comparable developer platform while Nvidia spent eighteen years funding one. That is the asymmetry. You can match the silicon in a product cycle. You cannot match eighteen years of someone else's developers in one.

Nvidia's competitors keep winning the argument they think matters - the benchmark, the teraflops, the price per chip - and keep losing the one that actually decides the purchase: which platform the next fast kernel will appear on first. That race was settled eighteen years ago and it compounds daily. The chip is the part you can buy. The eighteen years are the part you'd have to re-live. Nvidia didn't build a wall. It built a head start so old that catching up means starting in 2007 - and the developers, all 5.9 million of them, have no reason to wait for you.