New silicon does not carry its ecosystem automatically

RTX Spark combines three unusual choices for a Windows PC: a Grace Arm CPU, a Blackwell RTX GPU and up to 128 GB of unified memory. NVIDIA advertises up to 6,144 CUDA cores, 20 CPU cores and 1 PFLOP of FP4 compute. Microsoft adds scheduling tuned for the 20-core topology, shared thermal management and a higher GPU-accessible memory limit for large local models.

Every figure is an “up to” specification. RTX Spark covers laptops and compact desktops from Microsoft, ASUS, Dell, HP, Lenovo and MSI rather than one fixed system. The public material does not expose memory bandwidth, sustained package power or the amount of memory left for the GPU after Windows and applications reserve their share.

Our RTX Spark versus DGX Spark analysis already marks that hardware boundary. DGX Spark documents 273 GB/s of LPDDR5x bandwidth. RTX Spark does not. Assuming that both products use the same controller, frequency, bus width and power profile would turn a known DGX number into an invented RTX Spark specification.

The software problem begins above the chip. An LLM does not consume “CUDA” directly. It crosses a driver, runtime, tensor framework, compiled extensions, attention kernels, KV-cache manager and serving process. Every layer needs a compatible Windows Arm64 build. Windows x64 and Linux aarch64 support do not combine into Windows Arm64 support by themselves.

Shipped, preview and announced are three different states

LayerPublic statusWhat it enablesCurrent boundary
RTX Spark hardwareAnnounced for fallFinal laptop and desktop targetNo commercial system to benchmark
RTX Spark driverDeveloper PreviewCUDA development on Windows ArmKnown issues; final validation pending
CUDA Toolkit 13.4Developer PreviewNative Arm64 and cross compilationNot a production GA stack
TensorRT-RTX 1.6Official Windows Arm supportCompile and run AI graphs on RTXNot TensorRT-LLM
Windows ML + TensorRTIntegration announcedNative Execution Provider pathFinal versions and LLM coverage unclear
CUDA PyTorchPlanned; build path in previewExpected Python framework foundationBuilds may trigger GPU timeout
llama.cpp / Hugging Face / UnslothPlannedExpected local inference and tuningNo final RTX Spark validation
vLLMNo native Windows supportGeneral docs allow WSLNo validated RTX Spark WSL recipe
TensorRT-LLMLinux documentationOptimized LLM serving on supported systemsNo native Windows Arm guide
Table 1: public RTX Spark software status on August 12, 2026. Announced means vendor intent without a final package and support matrix.

NVIDIA labels its July 16 release RTX Spark Developer Preview. Developers are told to start on an existing Windows on Arm machine, port dependencies, validate CUDA paths and test on RTX Spark “when supported hardware and software become available.” That final clause prevents the current kit from becoming evidence of final-system compatibility.

This sequencing is not surprising. A new operating-system and CPU-architecture combination needs drivers, compilers, Python packages and third-party kernels before application developers can produce one-click installs. It does require a precise distinction between code that compiles and a serving system that survives production traffic.

Native CUDA solves the bottom of the stack

Prism lets Windows 11 on Arm execute x86 and x64 applications. Microsoft tunes it for RTX Spark’s CPU microarchitecture, so an editor, IDE or GUI can remain x64 while its vendor prepares a native build.

Prism does not translate the kernel. Microsoft requires kernel-mode drivers to be native Arm64 binaries. Compiled Python and CUDA extensions also have to match the architecture conventions of the process that loads them. A native Arm64 process cannot load an arbitrary x64 DLL, while x64 and Arm64EC processes follow a different interoperability model.

NVIDIA supplies the pieces emulation cannot create: an Arm64 driver, CUDA 13.4 compiler and an x64 cross-compilation driver. Teams can port CPU code, rebuild extensions and exercise the CUDA software path from another Windows on Arm device before final GPUs arrive.

Application UI or API Arm64 / x64
Framework PyTorch or runtime native wheels
Extensions attention, quantization C++ / CUDA
CUDA 13.4 runtime and compiler Preview
Driver GPU access Arm64 required
Figure 1: Prism may help an x64 frontend. The compute path still needs compatible Arm64 binaries at every layer.

This chain is why “CUDA works” does not imply “vLLM works.” vLLM compiles many kernels and binds itself to particular combinations of PyTorch, Triton, FlashAttention or FlashInfer, NCCL and system libraries. One missing wheel or ABI mismatch stops the server before the first generated token.

TensorRT-RTX is ready, but it is not TensorRT-LLM

TensorRT-RTX 1.6 is the clearest production-shaped building block. Its release notes add official Windows on Arm support for RTX Spark, CUDA 13.4 and zero-copy input/output for unified-memory systems. An application can allocate mapped buffers with cudaMallocHost() and avoid explicit host-to-device and device-to-host copies.

Zero-copy does not mean that bytes stop moving or that CPU and GPU accesses have equal cost. It means both processors address a mapped allocation without the application staging two separate copies. Performance still depends on physical memory traffic, page placement and coherence. RTX Spark’s unpublished memory bandwidth prevents a throughput estimate.

TensorRT-RTX compiles ONNX or PyTorch-derived graphs for RTX GPUs. TensorRT-LLM adds the generative-serving machinery: model runners, batching, KV cache, parallelism, speculative decoding and a server. TensorRT-LLM installation documents containers or pip on Linux, tested on Ubuntu 24.04. TensorRT-RTX gaining Windows Arm support does not silently extend that support to TensorRT-LLM.

PyTorch is the middle-stack maturity test

Microsoft’s wording is careful. Its NVIDIA partnership plans to bring CUDA-accelerated PyTorch, llama.cpp, TensorRT, Hugging Face frameworks, Unsloth and Kohya. The same announcement describes Arm-native creative applications as available today. The grammar separates a roadmap from a support matrix.

NVIDIA’s known issues show that PyTorch is not yet a routine path. Running PyTorch CI or build workflows may trigger a GPU timeout, leave the system unresponsive or restart it. That warning applies to building, not necessarily inference through a future final wheel, but framework installation is part of reproducible deployment.

llama.cpp has a narrower dependency graph than a large Python serving stack. Its GGUF loader and CUDA backend concentrate more of the path inside one project. That makes an early port plausible, not proven. NVIDIA and Microsoft publish no final RTX Spark binary, model matrix or reproducible benchmark with context length and quantization parameters as of August 12.

The practical question is not whether an executable opens. It is whether weights load without a hidden second copy, whether accelerated kernels cover the real graph, whether the KV cache stays within the GPU-accessible limit, whether long prompts trigger damaging paging and whether performance survives sustained laptop thermals.

vLLM under WSL is a path, not a validated recipe

vLLM documents two relevant facts. Its full system runs only on Linux, and Windows has no native support. Windows users are directed to WSL with a compatible Linux distribution or community-maintained forks. The project can also build linux/arm64 images for Grace Hopper and Grace Blackwell.

Combining those facts suggests a route, not a certified RTX Spark configuration. WSL must expose the Blackwell GPU to an Arm64 Linux guest. The host driver and guest CUDA runtime must align. PyTorch and every dependency need compatible aarch64 wheels, then kernels must recognize RTX Spark’s GPU target. No official guide publishes this full combination with performance data.

WSL may still become the fastest route into the Linux serving ecosystem. Microsoft explicitly promotes that access for DGX Station on Windows. The missing RTX Spark recipe only means buyers should not count it as a tested launch feature yet.

Unified memory removes capacity walls, not bandwidth walls

The 128 GB capacity can hold models that exceed a 24 or 32 GB mobile GPU. Raw four-bit values for a 70-billion-parameter model approach 35 GB; scales, KV cache, context and workspace increase the allocation. A 128 GB shared pool creates room that a mainstream discrete GPU does not offer.

CPU and GPU share both capacity and physical bandwidth. Windows, file cache, browsers and resident services take a portion. During decode, the GPU repeatedly streams weights. If RTX Spark delivers fewer bytes per second than a desktop RTX 5090, it may load a larger model while generating fewer tokens per second.

Microsoft raises the GPU-accessible memory limit and changes page-size handling for shared regions. Those improvements remove artificial allocation limits and reduce address-translation overhead. They do not manufacture DRAM bandwidth. That missing specification remains the central hardware unknown.

Known issues tell operators what to test

The developer preview reports lower-than-expected CUDA transfers with pageable host memory. NVIDIA recommends page-locked allocations through cudaMallocHost, cudaHostAlloc or cudaHostRegister. TensorRT-RTX’s zero-copy path is built around that choice. A Python application using ordinary pageable buffers may measure a very different system from an optimized native application.

TensorRT-RTX also documents possible cudaMallocAsync() failures on unified-memory systems even when physical memory remains free. The workaround is a custom allocator backed by cudaMalloc(), which may reduce performance and disables CUDA Graph support. Runtimes that preallocate large pools need to validate both paths.

The driver installer may leave the display blank for roughly two minutes, PyTorch builds can destabilize the system, and Nsight Copilot is unavailable in the Arm64 preview. These issues do not decide the platform’s future. They define a useful qualification matrix: pinned versus pageable buffers, asynchronous versus synchronous allocation, graphs on or off, build stability, timeout recovery and sustained thermal behavior.

A valid benchmark must publish the complete stack

An RTX Spark comparison with RTX 5090 or DGX Spark needs the exact machine, Windows build, driver, CUDA release, framework, runtime, commit, quantization and context. Native Windows results must be separated from WSL, and any x64 process under Prism must be identified.

Minimum measurements include load time, p50 and p99 time to first token, single-user decode, loaded throughput, usable memory, observed bandwidth, wall power and clocks after thirty minutes. Allocation failures, kernel recompilation and CPU fallbacks belong in the result, not in a hidden setup note.

No ranking published on August 12 could satisfy that protocol because commercial systems and their final stack are absent. The positive, evidence-backed conclusion is narrower: Microsoft and NVIDIA have crossed the Arm64 driver and compiler barrier; TensorRT-RTX already has an official path; the complete LLM stack has not reached the same proof level.

Windows can succeed without becoming Linux

RTX Spark does not need every Linux tool to become native on day one. TensorRT-RTX and Windows ML can serve end-user applications. WSL can host research servers and Linux-bound dependencies. Prism can preserve x64 tooling around the critical path.

Success depends on the boundaries between those environments. If an Arm64 Python process reaches native CUDA extensions without hidden copies, and WSL exposes the GPU without breaking aarch64 wheels, 128 GB becomes a credible local LLM workstation. If each project needs a private build and allocator workaround, integration cost will overshadow the hardware. Fall availability therefore needs to deliver more than machines: it needs a reproducible version matrix.

Sources and method