Jensen Huang walked onto the GTC Taipei stage on May 31 holding the most impressive piece of consumer silicon NVIDIA has ever pointed at a laptop, and the audience reacted exactly the way NVIDIA wanted. The RTX Spark — internally the N1X, the chip that has been stuck in the rumor mill since 2023 — is a Grace-Blackwell superchip squeezed into a thin-and-light chassis. A twenty-core Arm CPU built with MediaTek, ten Cortex-X925 performance cores paired with ten Cortex-A725 efficiency cores running up to 4.1GHz. A Blackwell GPU with 6,144 CUDA cores, which is to say roughly the silicon of a desktop RTX 5070. Up to 128GB of unified LPDDR5X. Around one petaflop of FP4 AI compute. It is, by any honest measure, a data-center part wearing a laptop costume. It is essentially the GB10 from the DGX Spark mini-PC, the same chip that ships in a five-thousand-dollar Linux box, repackaged for Windows.
The markets believed the pitch. Intel dropped about six percent and AMD about five on the open while Arm Holdings soared, the first time in four decades that anyone has credibly crashed the x86 PC-processor party. The keynote was a triumph. The spec sheet is a monster. And if you are a developer — the precise person NVIDIA spent ninety minutes telling us this machine was built for — it is also, on the day it ships, a trap.
I want to be careful here, because the hardware deserves respect and the failure mode is not the hardware. The failure mode is a single decision, made years ago and locked in by the time anyone wrote a press release: NVIDIA built the most powerful personal computing chip in history and then chose to make it Arm-on-Windows. That decision quietly negates most of what makes the silicon worth buying, and it negates it hardest for the people Huang was pitching to.
What they actually built
Strip away the keynote language and the RTX Spark is a clean idea. Take the Grace-Blackwell architecture that has been selling into data centers, shrink the power envelope to between forty-five and eighty watts, fuse the Arm CPU complex to the Blackwell GPU over NVLink-C2C, and feed the whole thing from a single 128GB pool of unified memory so the GPU never has to copy a model across a bus. On a TSMC three-nanometer node, that gets you a portable machine that can hold a 120-billion-parameter model resident in memory and run it locally, edit 12K video, and play AAA games at 1440p over a hundred frames per second. NVIDIA’s own spokesperson described the GPU as roughly equivalent to its RTX 5070 laptop part. The OEM roster is everyone who matters: ASUS, Dell, HP, Lenovo, Microsoft Surface, MSI, with Acer and GIGABYTE to follow, thirty-plus notebooks and ten desktop systems landing this fall.
This is not a Qualcomm-style efficiency play dressed up as performance. NVIDIA is not selling battery life. It is selling a local AI workstation, and on raw capability it has the goods. Nothing else in a laptop chassis this year comes close to a petaflop of resident AI compute with 128GB of unified memory behind it. That is the part everyone gets right in the first paragraph and then stops thinking about.
How it stacks up — and why the spec war is a distraction
Put the field on a bench and the RTX Spark looks dominant on the metric NVIDIA chose. Apple’s M5, announced in October and joined by the M5 Pro and M5 Max in March, is a genuinely brilliant chip: a next-generation GPU with a neural accelerator in every core, over four times the M4’s peak GPU compute for AI, 153GB/s of unified memory bandwidth on the base part, and up to 128GB on the Max with its sixteen-core CPU and forty-core GPU built on Apple’s new Fusion Architecture. Intel’s Panther Lake — Core Ultra Series 3, the first consumer silicon on the 18A node with RibbonFET and backside power — finally made Intel competitive again, with a 48-TOPS NPU and a top configuration posting Geekbench multi-core scores around 17,283. AMD’s Ryzen AI 400 series pairs Zen 5 with RDNA 3.5 and a 50-plus-TOPS XDNA 2 NPU and currently holds the largest slice of the AI-laptop market. Qualcomm’s Snapdragon X2 Elite, the Arm incumbent NVIDIA is trying to displace, pushes an 80-TOPS NPU and a Geekbench multi-core figure near 18,400, slightly ahead of Panther Lake’s best.
Read those numbers and the RTX Spark wins the headline. But the spec war is a distraction, and it is worth saying why before we get to the actual problem. For a developer, the chip you buy is not the silicon — it is the silicon multiplied by the software that will actually run on it. A petaflop you cannot address is a petaflop you do not have. And that multiplier is exactly where the architecture decision starts to bite.
The Arm tax nobody on stage mentioned
Windows on Arm is not new. Microsoft has been trying to make it happen for well over a decade, from Windows RT through the Qualcomm always-connected era to the more credible Snapdragon X generation. Each attempt solved part of the problem and exposed another. Battery life improved. Emulation got less embarrassing. Native Arm apps slowly multiplied. And after all of it, Arm’s share of Windows never came close to the fifty percent Qualcomm floated in 2024, because the proposition always carried a quiet caveat: it works great, as long as your workflow fits inside the supported lane.
For a lot of developers, the supported lane is now wide enough. This is the part I will not pretend is broken, because it isn’t. The full Visual Studio 2026 IDE — not VS Code, the real thing — has been a native Arm64 application since the 17.4 GA release, building and debugging Arm64 apps without emulation. SQL Server Data Tools and .sqlproj support landed in the Arm64 build. And the .NET story is genuinely excellent: developers running complex desktop applications with heavy P/Invoke and native interop report them running natively under Arm64 without recompiling, no errors, no behavioral differences. If your world is C# and .NET and web apps, the toolchain is there and it is fast.
But the supported lane has walls, and the walls are exactly where serious work lives. Microsoft is explicit that kernel-mode drivers need native Arm64 builds — so any peripheral, capture card, security tool, or specialized hardware whose vendor has not shipped an Arm64 driver simply does not work, full stop, no emulation fallback. Anything without a native Arm build runs through the Prism x86 emulator, which NVIDIA says is present and optimized on the RTX Spark, and emulation is precisely where Windows on Arm has always bled: older creative tools, scientific software, professional applications that crash or misbehave under translation. You do not find out which of your tools are in that bucket until you have already bought the machine.
The local-AI contradiction at the center of the pitch
Here is where the whole thing collapses into irony, and it is the part that should stop any developer from preordering. NVIDIA’s headline use case — the entire reason this chip exists rather than another gaming laptop — is running AI agents and large models locally. Private, on-device, full CUDA stack, a teammate instead of a tool. That is the promise. Now go read the Ollama development documentation, because Ollama is one of the most widely used local-inference runtimes on earth and the fastest way most developers actually run a model on their own machine.
The section for Windows on Arm is two sentences long. It says, in full, that Windows Arm does not support additional acceleration libraries at this time, and instructs you not to use CMake but simply to run go build. Read that again with the spec sheet in your other hand. The machine has 6,144 CUDA cores and a petaflop of FP4. The most popular local-inference tool in the ecosystem, on this operating system and this architecture, will not load a GPU acceleration library at all. It falls back to the CPU. Ollama’s own prerequisites make the gap concrete: the CUDA SDK download it points Windows users to is the x86_64 build, and its library-detection logic states plainly that if the acceleration libraries are not found, it simply runs without them. On macOS Apple Silicon, by contrast, Metal is built into the binary and requires no steps; the MLX engine runs natively. On Windows Arm, you get a CPU.
This is the most powerful chip you cannot use, stated as precisely as I can state it. Not because the GPU is weak — it is enormous — but because on the platform NVIDIA chose to ship it, the software that would let a developer actually reach the GPU for local inference is not there on day one. NVIDIA and Microsoft will tell you this is temporary, and they will point to llama.cpp’s creator and the ComfyUI team being quoted in the launch materials as committed partners. Maybe. But “the ecosystem will catch up” is a promise about the future, and you are being asked to pay for the hardware now, into a software stack that has been perpetually catching up for ten years.
Then there is the database, which for anyone building real applications is not a footnote. Microsoft’s own current documentation states that SQL Server 2025 is not supported on Windows Arm64 — Intel and AMD x86-64 only. The flagship database from the same company co-engineering this Arm platform will not run natively on it. You can coax an emulated x64 build into running for local development, but that is an unsupported configuration running under translation, and the historical pain point, LocalDB, is x64-only and has tripped up Arm dev-box setups for years. The old escape hatch, Azure SQL Edge, was the Arm option and it was retired in September 2025. There is, right now, no native Arm build of SQL Server anywhere — not on Windows, not on Linux. If your stack sits on SQL Server, the most powerful developer laptop of 2026 cannot be your primary database machine.
Why Apple’s Arm works and this one won’t
The obvious objection is Apple. Apple silicon is Arm, Apple silicon is wonderful, developers love it, so what is my problem? The problem is that Apple’s success is the exact thing NVIDIA cannot replicate, and understanding why is the whole argument. Apple made Arm work by owning the entire vertical stack and bending the ecosystem to it over more than five years. They control the silicon, the operating system, the compiler, the frameworks, and a developer base willing to follow them through a hard transition because the destination was coherent. Metal is in the box. MLX is first-party. Rosetta carried x86 software through the gap while native builds arrived, and Apple had the leverage to make those native builds happen. By the time most developers noticed, the transition was over.
NVIDIA owns none of that. It owns a spectacular GPU and a CUDA ecosystem that was built, for two decades, on x86 Linux and x86 Windows. It does not own the operating system — that is Microsoft’s, and Microsoft’s Arm story is the decade-long work-in-progress we have been describing. It does not own the driver model, the database, or the long tail of professional Windows software. NVIDIA is not doing what Apple did. NVIDIA is renting Microsoft’s perpetually half-finished Windows-on-Arm and hoping that this time, with a better chip attached, the ecosystem finally shows up. It is the same bet Qualcomm made and lost, with more compute and the same missing software.
The decision that doesn’t make sense
So strip it to the core question. What actually makes the RTX Spark powerful? The Blackwell GPU. The 6,144 CUDA cores. The 128GB unified memory pool that keeps a large model resident. The petaflop of FP4. Every single one of those things lives on the GPU and memory side of the package. Not one of them depends on the CPU being Arm. The instruction set of the CPU is orthogonal to the thing you are buying the machine for.
Which means NVIDIA had a choice, and took the worse one. Put that same Blackwell GPU and that same 128GB unified pool behind an x86 CPU — pair it with the kind of platform Intel and AMD already ship — and every tool a developer owns just works. CUDA on Windows x86 is mature and battle-tested. Ollama loads its acceleration libraries. SQL Server installs natively. Every kernel driver, every emulation-hostile creative app, every piece of scientific software runs without a translation layer or a compatibility asterisk. You would lose some of MediaTek’s power-efficiency advantage and a bit of battery life. In exchange you would keep the entire reason a developer wants the machine. For a workstation-class part pulling up to eighty watts and being sold on local AI rather than all-day battery, that is a trade NVIDIA should have taken without blinking.
Instead they built a petaflop and then wrapped it in the one architecture that makes the petaflop hard to reach. The efficiency win Arm buys you is real, but it is the wrong optimization for this product. Nobody buying a local-AI workstation is choosing it for fanless silence. They are choosing it to run models, and the architecture decision puts a compatibility wall directly between the developer and the models. It is the most expensive way imaginable to save a few watts.
Who it’s actually for
None of this means the RTX Spark fails. It means it is mismarketed. As a creator’s machine running native Adobe Premiere and Photoshop — which Adobe committed to in native Arm builds, a concession Qualcomm could not extract in two years on the market — it will be excellent. For gaming at 1440p with DLSS and ray tracing, it will be excellent. For the .NET and web developer whose entire toolchain already runs native on Arm, it may be a fine daily driver. Those are real markets and NVIDIA will sell a lot of these.
But the keynote did not pitch a creator’s laptop. It pitched a developer’s local-AI teammate, a private agent workstation, a machine that runs frontier models on your desk. And for that buyer — the one who opens a terminal, types the command to serve a model locally, and watches it fall back to the CPU because the acceleration library will not load on Windows Arm — this is the most powerful chip they cannot use. The silicon is a triumph. The architecture decision is a self-inflicted wound, and it landed on exactly the customer the whole launch was aimed at.
NVIDIA spent thirty years and a trillion dollars of market cap building the most formidable AI compute stack on the planet, almost all of it on x86. Then it shipped its first personal AI computer on the one CPU architecture where that stack is least ready, and asked developers to trust that Microsoft will finally finish a job it has been not-finishing since Windows RT. I would love to be wrong by the fall. But I have watched this exact movie before, and Qualcomm was the one holding the popcorn.
About the Author
Gal Ratner is a software architect and entrepreneur based in Las Vegas with more than thirty years on the Microsoft and .NET stack. He is Chief Architect at Prana Entertainment and the founder and CTO of Inverted Software, which he started in 2001, and WhiteStar Labs. He delivered enterprise work for Microsoft, Sony, Yahoo, Best Buy, Rockstar Games, 2K Games, and Allegiant Air. His current focus is agentic AI, MCP servers, the Microsoft Agent Framework, and SQL Server 2025 vector search — which is also why a developer laptop that can’t run SQL Server natively is the kind of thing he notices. He writes a practitioner-first Substack for CTOs and technical executives who would rather read the spec sheet than the press release. He is also the author of the novel The Archive of Lost Suns. Find him at galratner.com and on LinkedIn at linkedin.com/in/galratner.
Could you use Linux instead of Windows? I think more developers prefer Linux.