I have lost count of how many times someone has told me Nvidia's real advantage is its hardware. It is not. The hardware is excellent, obviously — nobody else ships anything like a Blackwell GPU — but hardware can be copied, undercut, and eventually matched. What cannot be copied overnight is twenty years of software. CUDA, Nvidia's parallel computing platform, launched in 2006, and it is the reason 4.5 million developers write code that only runs properly on Nvidia silicon. I have spent years working with GPU code, and I can tell you: leaving CUDA is not a technical decision. It is a divorce. And 2026 is the first year the divorce lawyers have shown up with a credible case.
What CUDA actually is, and why it is so sticky
CUDA — Compute Unified Device Architecture — is Nvidia's proprietary programming model for general-purpose computing on GPUs. Before it existed, a graphics card was a device that drew triangles. CUDA turned it into a programmable math machine, and over the following two decades Nvidia built an entire world on top of it: more than 250 GPU-accelerated libraries including cuDNN for deep learning, cuBLAS for linear algebra, TensorRT for inference, and NCCL for multi-GPU communication. There are university courses that teach CUDA. There are millions of lines of production code written against it. There are profiling tools, debuggers, and documentation that have been refined for nearly twenty years. When a developer says "my model runs on CUDA," they usually do not mean they wrote CUDA kernels. They mean their framework — PyTorch, TensorFlow, JAX — sits on top of CUDA libraries, and everything beneath it just works.
The numbers tell the story better than I can. Nvidia's fiscal 2026 revenue, which ended in January 2026, was $215.9 billion, up 65% year over year — and $193.74 billion of that, almost 90%, came from the data center. In the third quarter of fiscal 2026, data center revenue alone was $51.2 billion. For comparison, Intel and AMD's combined data center and CPU revenues in the same quarter were $8.4 billion. That is not a competition. That is a landslide. And the reason the landslide keeps happening is that every AI lab, every cloud provider, and every startup that wants to train or serve a model reaches for the stack that already works — and the stack that already works is CUDA.
Why developers cannot just leave
People who have never migrated a production system love to say "just switch to AMD." I wish it were that simple. Switching away from CUDA means rewriting your custom CUDA kernels for another platform, replacing cuDNN calls with alternatives like MIOpen, abandoning TensorRT optimizations, and rebuilding your distributed training around a different communication library. AMD's HIP layer deliberately mirrors CUDA's API almost function for function, and its HIPIFY tool can mechanically convert CUDA source into HIP code — but the migration cost concentrates in exactly the code that uses Nvidia-specific features with no HIP equivalent. The framework-level code moves. The tuned kernels, the fused operators, the hand-optimized inference paths — those do not.
And here is the part that rarely gets said out loud: the switching cost is not just technical. It is human. Your team knows CUDA. Your hiring pipeline produces CUDA engineers. Your incident runbooks assume Nvidia tooling. Your performance regressions get debugged with Nsight, Nvidia's profiler, which has no equal on any other platform. Moving to another stack means retraining people, rewriting documentation, and accepting months of slower iteration while everyone learns the new tools. For a startup racing to ship, that is not a trade-off. It is a non-starter. This is why Nvidia's moat has survived every challenger for almost twenty years: the lock-in is not in the silicon. It is in the skills, the libraries, and the habits of 4.5 million developers, up from 1.8 million in 2020.
The challengers, ranked by how serious they actually are
The challengers in 2026 are more credible than any group before them. Here is how I rank them, from most to least threatening.
AMD's ROCm is the most production-credible challenger, and it is not close. ROCm 7.0 shipped in September 2025 with day-zero PyTorch and vLLM support, and AMD released ROCm 10 in August 2026 with a new AI-assisted tuning tool called ROCm.ai, which AMD claims delivers 3.3 times the inference performance and 2.4 times the training performance of ROCm 7 on the same hardware. AMD holds roughly 7% of the AI GPU market, its hardware undercuts Nvidia's pricing by 15 to 40% depending on tier, and the performance gap has narrowed to 10 to 30% on compute-intensive workloads. AMD aims for 80 to 90% CUDA parity by the end of 2026, and Anthropic has committed up to 2 gigawatts of AMD Instinct MI455X capacity. But ROCm still lacks CUDA's stability, documentation, and library breadth.
The second challenger is not a company at all — it is a layer. OpenAI's Triton, the open-source GPU programming framework, has become what AMD's Elangovan calls "the great equalizer." You write a Triton kernel once, and it runs on AMD or Nvidia without targeting a proprietary API. Triton sits inside PyTorch 2.x, which means a lot of portability arrived without anyone asking for it: teams that write to PyTorch and let the framework worry about the accelerator are already portable, whether they know it or not. This is the most important structural shift in GPU computing in a decade, and it did not come from a competitor. It came from the framework layer deciding that vendor lock-in was everyone's problem.
The third challenger is the cloud giants themselves, and October 2026 was the month they stopped being polite about it. On October 20, Amazon put TorchNeuron into public beta and contributed code upstream to PyTorch so that PyTorch programs run on AWS Trainium chips with no rewrite. Barely twenty-four hours later, Google open-sourced TorchTPU — a joint initiative with Meta — to make PyTorch run natively on TPUs. The coalition behind it includes Meta, Hugging Face, vLLM, and SGLang, and their pitch is blunt: roughly 85% of global machine learning applications are written in PyTorch, and they should be able to migrate off Nvidia GPUs onto custom cloud silicon with nothing more than a configuration switch. Anthropic is already training models on 500,000 Trainium2 chips at Amazon's largest AI data center. If that number does not get your attention, nothing will.
Then there are the smaller, cleverer challengers. Modular's Mojo language promises Python-compatible GPU programming without CUDA. Spectral Compute's SCALE compiles unmodified CUDA code to run on AMD GPUs and claims roughly six times the performance of AMD's own HIPIFY conversion path. Khronos's SYCL offers a single-source C++ layer across CUDA, ROCm, and other backends, though a standards process moves far more slowly than a single vendor shipping its own product. None of these is a CUDA replacement on its own. Together, they are a reminder that the ecosystem is routing around the moat rather than attacking it head-on.
What still does not port
I want to be fair to Nvidia here, because the honest state of things is more nuanced than either side admits. If your serving stack is PyTorch plus vLLM or SGLang and you wrote no custom CUDA, moving to AMD in 2026 is closer to a reinstall than a rewrite — and that is a genuine change from two years ago. But if your stack is tuned around TensorRT-LLM, FlashAttention 3, or NCCL-based distributed training, there is no drop-in ROCm equivalent, and you are staying on CUDA. Custom CUDA kernels, vendor-specific intrinsics, and the accumulated tuning of years of profiling do not migrate with a tool. They migrate with engineers, slowly, and only if someone is paying for it.
The right way to think about lock-in, I have come to believe, is not as a yes-or-no property of your stack but as a property of specific dependencies. Most teams have never actually audited which parts of their code touch the accelerator directly and which parts run through a framework. Audit your code: separate custom kernels from model code. The model code is probably already portable; the kernels are the hostage. Once you know which is which, you can make a real decision instead of a tribal one.
What this means for developers like us
You might be wondering what any of this has to do with building WordPress sites, and I understand the question — but it matters more than it looks. Every AI feature we now ship on the web — the chatbots, the image generators, the content tools, the Elementor AI features our clients ask about — runs on GPU infrastructure whose cost is set by Nvidia's pricing power. When one vendor controls 90% of the data center GPU market and charges what it charges, every AI API call you make carries a Nvidia tax. Competition does not just lower prices. It changes what gets built. Cheaper inference means AI features that are economical at WordPress-plugin scale instead of enterprise scale. It means local models that run on hardware you can actually afford. It means the AI tools we use every day get cheaper, faster, and less dependent on a single company's roadmap.
My advice, as a developer, is practical rather than ideological. Write to frameworks, not to CUDA. If you are building anything with GPUs, use PyTorch, use Triton where it fits, and keep your custom kernels isolated and small. Do not build your product on TensorRT-specific optimizations unless you have measured the gain and accepted the lock-in consciously. And if you are running local AI — a local model for drafting, for image work, for testing — remember that your RTX card is a CUDA machine whether you like it or not, and the best way to keep your options open is to keep your code portable from day one. The moat will erode — slowly, then all at once — but only for the teams that prepared.
Frequently asked questions
What is CUDA?
CUDA (Compute Unified Device Architecture) is Nvidia's proprietary parallel computing platform and programming model, launched in 2006. It lets developers use Nvidia GPUs for general-purpose computing, and it includes more than 250 GPU-accelerated libraries such as cuDNN, cuBLAS, TensorRT, and NCCL. About 4.5 million developers use it.
Why is CUDA so hard to leave?
Switching requires rewriting custom CUDA kernels, replacing libraries like cuDNN and TensorRT with alternatives, retraining engineers, and rebuilding tooling and debugging workflows. The cost concentrates in code that uses Nvidia-specific features with no equivalent elsewhere, which is why most teams stay even when rival hardware is cheaper.
What is AMD ROCm?
ROCm is AMD's open-source GPU computing stack and the most production-credible CUDA challenger. ROCm 7 shipped in September 2025 with day-zero PyTorch and vLLM support, and ROCm 10 arrived in August 2026 with the ROCm.ai tuning tool. AMD aims for 80 to 90% CUDA parity by the end of 2026, though a gap in stability, documentation, and library breadth remains.
What is Triton, and why does it matter?
Triton is OpenAI's open-source GPU programming framework, built into PyTorch 2.x. It lets developers write GPU kernels once and run them on Nvidia or AMD hardware without targeting a proprietary API. AMD's AI software chief calls it "the great equalizer" of GPU programming.
What are TorchTPU and TorchNeuron?
TorchTPU, launched by Google with Meta in December 2025, makes PyTorch run natively on Google's TPUs. TorchNeuron, launched by AWS in October 2026, does the same for Trainium chips. Together they aim to let the roughly 85% of AI applications written in PyTorch migrate off Nvidia GPUs with minimal code changes.
Will CUDA be replaced?
Not soon, and not all at once. Standard inference and training workloads on PyTorch, vLLM, or SGLang are already portable to AMD. Custom kernels, TensorRT-LLM, and FlashAttention 3 have no equivalent elsewhere. The realistic path is gradual erosion of the moat as frameworks and open tooling make the hardware underneath interchangeable.
