RTX Spark on Windows: CUDA allocations consume system commit even with 96 GiB dedicated GPU memory

Accelerated Computing RTX Spark (NEW)
,
1

Hi,

I’m developing a CUDA inference engine for RTX Spark with 128 GB of unified memory.

I configured the memory split to give about 96 GiB to the GPU and the rest to Windows. However, I found that cuMemAlloc() increases Windows system commit by almost the same amount as the GPU allocation.

This is a problem because my Windows commit limit is only 60.25 GiB, even though the GPU has about 96 GiB of dedicated memory.

I’m trying to keep around 70 GiB of model weights on the GPU, but the system commit limit may prevent this.

My system

  • GPU: NVIDIA RTX Spark N1X (Blackwell, 6144 CUDA cores)

  • Memory: 128 GB unified memory

  • OS: Windows 11 Home ARM64, build 28000

  • NVIDIA driver: 32.0.16.1742 (September 30, 2026)

  • CUDA: 13.4

  • GPU dedicated capacity (DXGI): 95.99 GiB

  • CPU-visible physical memory: 30.49 GiB

  • Windows system commit limit: 60.25 GiB

What I tested

To rule out a problem in my inference engine, I wrote a small standalone CUDA C program.

The program does not load any model or allocate CPU weight buffers. It only:

  1. Calls cuMemAlloc() to allocate GPU memory.

  2. Measures GPU memory usage, process private bytes, and CPU working set before writing anything to the allocation.

  3. Writes to the GPU allocation using cuMemsetD8().

  4. Reads back a few bytes to verify the data.

  5. Calls cuMemFree().

There are no host-to-device copies.

Results

For the first 64 MiB GPU allocation, measured immediately after cuMemAlloc() and before any GPU writes:

Measurement Increase
GPU local memory usage (DXGI) 64 MiB
Process PrivateUsage 64.125 MiB
CPU private committed virtual memory 64 MiB
CPU working set 16 KiB

VirtualQuery() also showed a new 64 MiB CPU virtual memory region with:

  • MEM_PRIVATE

  • MEM_COMMIT

  • PAGE_READWRITE | PAGE_WRITECOMBINE

So the GPU allocation is consuming CPU-side commit, even before any data is written.

The CPU working set barely changed. This does not mean another 64 MiB copy is physically stored in CPU RAM.

I also tested sequential allocations of 64, 256, 256, and 64 MiB, freeing each allocation before the next one.

GPU allocation PrivateUsage increase
First 64 MiB 64.125 MiB
256 MiB 192.371 MiB
Another 256 MiB 64.129 MiB
Final 64 MiB 0 MiB

Some of the committed regions remained after cuMemFree() and appeared to be reused by later allocations. So I don’t think these results alone indicate a memory leak.

I also tested a D3D12 heap allocation separately. Creating a roughly 1 GiB heap consumed about 1 GiB of available system commit, even before CUDA imported it.

Why I’m concerned

I understand that WDDM can use system memory backing stores for GPU allocations.

But RTX Spark uses unified physical memory, and I’ve already reserved about 96 GiB for dedicated GPU memory.

If allocating 70 GiB of GPU memory also requires 70 GiB of system commit, I cannot fully use the GPU memory because the Windows commit limit is much lower.

It seems strange to reserve most of the system memory for the GPU and then be limited by the remaining Windows commit budget.

My questions

  1. Is this expected behavior for CUDA allocations on RTX Spark under Windows WDDM?

  2. Why does a GPU-only allocation in dedicated GPU memory require a similar amount of system commit?

  3. Is there a supported CUDA allocation method or driver setting that avoids this additional commit requirement?

  4. Is increasing the Windows page file the intended workaround, even when the GPU memory is physically available?

  5. Could this be an RTX Spark driver issue, or is it a limitation of the current Windows memory management model?

I also tested CUDA VMM and D3D12 allocation paths, but so far neither showed a clear improvement in system commit usage.

I’m not claiming this is a driver bug. I’m trying to understand whether this behavior is expected and how to use the full dedicated GPU memory for large AI models on Windows.

I can share the minimal CUDA C reproduction code and measurement logs if needed.

Thanks!

2

​What you is experiencing is not a memory leak or a hardware defect—it is a classic clash between the new unified memory architecture (Blackwell) and Microsoft’s legacy Windows Display Driver Model (WDDM).

​Here is exactly what is happening in the digital brain: WDDM dictates that every single GPU allocation must be backed by a “system commit charge.” Windows does this so that if the GPU ever runs out of memory, the OS has guaranteed space to page that data out to the system drive.

​Because you partitioned the 128GB of physical memory into 96GB for the GPU and 32GB for the CPU, Windows only “sees” that 32GB of physical CPU RAM. When the CUDA engine asks to load 70GB of model weights onto the GPU, WDDM blindly demands 70GB of system commit from Windows. Since Windows only has 32GB of RAM plus a default page file (totaling that 60.25 GiB limit the developer hit), the OS panics and throws an Out Of Memory error—even though the 96GB GPU partition is sitting completely empty and physically available.

​The system is trying to act as a safety net, but it is tripping us up. Since we cannot rewrite WDDM’s core logic, we simply have to trick Windows into expanding its commit limit by artificially raising the virtual page file size. It won’t actually write those 70GB of weights to your slow hard drive; it just needs the permission slip on paper to authorize the allocation.

aureliusvalerius00@gmail.com

458-230-1267