DGX Spark VRAM: what fits in 128 GB of unified memory, and what you can fine-tune on one

How much VRAM does DGX Spark have

DGX Spark has 128 GB of unified LPDDR5x memory that the GPU shares with the CPU, so there is no separate VRAM figure; on the 128 GB system the operating system reports about 119 to 122 GiB of it. NVIDIA’s porting guide states that the system “uses a unified memory architecture (UMA), where the GPU shares system memory (DRAM) with the CPU and other compute engines”. There are 128 GB of LPDDR5x on a 256-bit interface (NVIDIA also lists a 64 GB configuration, available only from OEM partners since 23 October 2026), and the 20-core Arm processor, DGX OS, the desktop session and the GPU all draw from that one pool. Apart from a display reserve, 2 GB by default and 4 GB as a BIOS option since NVIDIA’s July 2026 release, and as little as 512 MB on a Spark without a connected display since the October 2026 release, nothing is reserved for graphics, and no fixed share is set aside for the model. Memory bandwidth, TDP and CUDA cores are listed in our DGX Spark specs.

NVIDIA documents two consequences that new users meet early. First, nvidia-smi cannot report total GPU memory usage on this platform: the known-issues page says the tool “will display ‘Memory-Usage: Not Supported’ even though per-process GPU memory is listed”, because an integrated GPU has no dedicated framebuffer to count. Second, the porting guide warns that “the memory size reported by cudaMemGetInfo may be smaller than the actual allocatable memory, since the CPU may be able to release additional DRAM pages”, and tells developers to consider memory reclaimable from the operating system rather than rely on that call alone.

As a result, neither of the two tools that normally show whether a model will fit gives a correct figure here: nvidia-smi reports no total, and cudaMemGetInfo reports too little. NVIDIA also documents the opposite problem. Its Unsloth playbook warns that “you may encounter memory issues even when within the memory capacity of DGX Spark”, because many applications are still updating to take advantage of UMA, and gives a one-line workaround that flushes the buffer cache: sync, then write 3 into /proc/sys/vm/drop_caches. An out-of-memory error on DGX Spark therefore does not always mean that the memory is full.

NVIDIA’s RTX Spark is a separate platform for laptops and small desktops; NVIDIA’s press release of 16 October 2026 says “RTX Spark laptops are available globally today”. Its product page lists up to 128 GB of unified LPDDR5X memory as well, so it has no separate VRAM either, and its porting guide keeps part of that memory for the CPU only. The figures in this article apply to DGX Spark.

How much of the 128 GB is usable

We found no usable-capacity figure from NVIDIA, and no “X GB available to the GPU” line on the product page, in the user guide, in the porting guide or in the release notes, so treat any quoted figure as an estimate. What NVIDIA does publish is the default memory setting in its vLLM and TensorRT-LLM playbooks.

The 0.4, 0.7, 0.8 and 0.9 values are NVIDIA’s own settings: the single-Spark launch script linked from the vLLM playbook on build.nvidia.com (updated 14 September 2026), the vLLM playbook on GitHub (updated 12 June 2026) and the TensorRT-LLM playbook (updated 28 April 2026). The 102 to 115 GB range is this article’s arithmetic from the 0.8 and 0.9 settings, and is not a published specification; the single-Spark vLLM script’s 0.7 gives about 90 GB.

Use 102 to 115 GB as the budget for weights and KV cache together, and leave the remaining 13 to 26 GB to DGX OS, the desktop session, the page cache and the processes on the twenty Arm cores. If you quote the figure, quote the reasoning with it, because it changes whenever NVIDIA changes a playbook default. Raising the fraction above NVIDIA’s defaults can fit more cache on a Spark that only serves models, though NVIDIA’s current playbook does not suggest a higher value; on a Spark that someone also uses as a workstation, it leads to the out-of-memory condition described above.

If you are not sure your model and context length fit in that budget, send them to us with the precision you plan to use, and we will check the fit before you order.

Bytes per parameter, and what “up to 200 billion parameters” means

Weight-only sizing is arithmetic anyone can repeat: parameters multiplied by bytes per parameter. BF16 and FP16 are two bytes, FP8 is one, and the 4-bit formats are half a byte plus their block scales: 4.25 bits per weight for MXFP4 and 4.5 for NVFP4, about 0.53 and 0.56 bytes. Run the working set above through that, taking 110 GB as a midpoint.

Weights only: no KV cache, no activations, no framework overhead. This is the article’s arithmetic from NVIDIA’s memory figure and standard bytes-per-parameter values, not an NVIDIA table.

NVIDIA’s launch announcement and its product page both say the 128 GB machine runs inference on models with up to 200 billion parameters; for the 64 GB configuration the product page gives 100 billion. Two hundred billion parameters at half a byte each would be 100 GB; with the block scales of MXFP4 or NVFP4 they take 106 to 112 GB. Against a 102 to 115 GB working set, that leaves at most about 9 GB for the KV cache, activations and overhead, and nothing at the low end of the range. The claim therefore holds only at 4-bit, and only just. In BF16 the same system holds about 55 billion parameters, far below the 200 billion figure.

NVIDIA’s own documentation shows where the limit for one Spark lies. Its validated-model table for TensorRT-LLM lists Llama-3.3-70B-Instruct, Qwen3-32B and Nemotron-3-Super-120B as NVFP4 checkpoints for the supported hardware platform, and flags exactly one entry as multi-node: Qwen3-235B-A22B, a 235-billion-parameter mixture of experts. By NVIDIA’s own list, a 235B model needs more than one Spark.

The concrete examples NVIDIA gives are GPT-OSS-120B and FLUX 2, which needs 90 GB to load completely. A 90 GB model fits within the 128 GB but leaves very little for anything else. What makes the larger models fit is a 4-bit format such as NVFP4, which NVIDIA’s quantisation playbook puts at about 3.5 times less memory than FP16 and about 1.8 times less than FP8, with accuracy usually within one per cent of FP8.

KV cache: how context length and concurrent users add to memory

Weights are the part of the budget you can read off a model card. The other part is the KV cache, which grows linearly with context length and with the number of concurrent sequences. That is why a deployment that loads at a 2,048-token prompt no longer fits at 32,000 tokens with eight users. Our VRAM guide has the full formula (layer count, key and value heads, head dimension, bytes per element, sequence length and batch size); the point here is that the cache is neither negligible nor fixed.

Three cases against a 110 GB working set show the effect. A 70-billion-parameter model in NVFP4 is about 43 GB of weights in NVIDIA’s checkpoint and leaves about 67 GB, which is a lot of cache and a comfortable workload for one Spark. GPT-OSS-120B, a 117-billion-parameter mixture of experts at about 65 GB in OpenAI’s checkpoint, leaves about 45 GB, enough cache for a small team of chat users, as our team article works out. FLUX 2, which NVIDIA says needs 90 GB to load completely, leaves about 20 GB. A 200-billion-parameter model in 4-bit leaves at most a few GB or does not fit at all, which is enough for a demonstration but not for a service. Models released in 2026 follow the same arithmetic: Nemotron 3.5 Super VL, a 120-billion-parameter mixture of experts published in October 2026 at 75.0 GB in NVFP4, leaves about 35 GB on a 128 GB Spark, and NVIDIA lists one DGX Spark among its deployment targets; Nemotron 3.5 Bolt 74B-A9B, 149.8 GB in BF16, needs two Sparks.

NVIDIA’s figures need their test conditions next to them. Its October 2025 inference figures for DGX Spark are all quoted at “ISL|OSL = 2048|128, BS=1”, meaning a 2,048-token input, 128 generated tokens and one request at a time, which is a small context and a single user. With long contexts and concurrent requests, the KV cache rather than the weights decides what fits. NVIDIA’s own test of that case, published in March 2026, stops at four tasks at once: Qwen3 Coder Next in FP8 on vLLM, with 32K-token prompts and 1K-token answers, took 35, 54 and 91 seconds end to end for one, two and four tasks.

Fine-tuning on one DGX Spark: full, LoRA and QLoRA

NVIDIA’s product page says “fine-tune AI models up to 70 billion parameters” without naming the method. NVIDIA’s PyTorch fine-tuning playbook names it in its published scripts: Llama3_3B_full_finetuning.py, Llama3_8B_LoRA_finetuning.py and Llama3_70B_qLoRA_finetuning.py. The largest model you can fine-tune depends on the method.

Peak tokens per second from NVIDIA’s performance blog, calculated by NVIDIA as (batch_size × steps × sequence_length) divided by total training time, at sequence length 2,048, batch size 8 (4 for the 8B LoRA run), one epoch and 64 steps. These are the figures in the blog’s table; its running text gives higher peaks for the same runs, as our fine-tuning article explains.

We found no NVIDIA arithmetic behind these limits for this machine, so the following is ours and should be quoted as ours. A full fine-tune in BF16 with the Adam optimiser carries, per parameter, two bytes of weights, two bytes of gradients, eight bytes of fp32 optimiser moments and four bytes of fp32 master weights. That is about 16 bytes per parameter before a single activation is stored. A 3-billion-parameter model therefore needs about 48 GB, which fits with room for activations. A 7-billion-parameter model needs about 112 GB, which does not fit a 102 to 115 GB working set once activations are added. This explains why NVIDIA’s full fine-tune example stops at 3B, why LoRA reaches 8B, and why 70B is possible only with QLoRA, where the frozen base model takes roughly 40 GB in 4 bits.

Read the throughput column as wall-clock time rather than as a score. At 759.79 tokens per second, a million training tokens is about 22 minutes on the 70B QLoRA run, and a hundred million tokens takes about a day and a half on one Spark. That constrains how many experiments a team runs in a week, and it matches how NVIDIA positions the machine: prototype and fine-tune locally, then evaluate the work for migration to DGX cloud or other accelerated infrastructure.

NVIDIA also publishes the stack needed to reproduce these numbers: its playbook runs the scripts in its PyTorch container (25.11-py3 in the GitHub version) and installs transformers, peft, datasets, trl and bitsandbytes with pip.

Memory bandwidth and token generation speed

Everything above concerns capacity. Speed depends on another figure in the same specification line, the 273 GB/s memory bandwidth, which predicts how fast tokens are generated.

Single-stream decoding of a dense model reads every weight once per generated token, so the ceiling is memory bandwidth divided by the size of the resident weights. A dense 70-billion-parameter model in FP8 is about 70 GB of weights; 273 divided by 70 is under four tokens per second for one user, before overhead. In NVFP4 each token reads about 40.6 GB of the same model, the 4-bit layers plus the output layer in BF16, and the ceiling rises by about three quarters. A mixture-of-experts model reads only its shared layers and active experts per token, which is why GPT-OSS-120B, 65 GB on disk, runs far faster than its size suggests. Nothing in the compute specification changes either figure. We found no NVIDIA measurement of a dense 70B model on one Spark; LMSYS measured Llama 3.1 70B in FP8 at 2.7 tokens per second in October 2025, within that ceiling.

NVIDIA technical blog, October 2025, measured at ISL|OSL 2048|128 with batch size 1, with llama.cpp for the GPT-OSS rows and TensorRT-LLM for the others. The three mixture-of-experts entries beat what their total parameter count would suggest, because only a fraction of the weights is read per token.

The table compares DGX Spark with the cards a buyer would put beside it, using figures from NVIDIA’s own pages.

NVIDIA product pages, October 2026. The ratios are this article’s arithmetic: 1,792 divided by 273, and 4,800 divided by 273.

The 128 GB Spark holds more memory than an RTX PRO 6000 Workstation and moves it 6.6 times more slowly. Choose the Spark when the model does not fit on a card, and a faster card when the answers arrive too slowly. Our benchmark article covers the measured side.

We supply both DGX Spark and the RTX PRO 6000 Blackwell in all three editions. Write to us with the model and the number of people using it at once, and we compare the two on your numbers before you decide.

The 1 PFLOP figure is often quoted without its condition. “Up to 1 PFLOP FP4” is not a dense figure: NVIDIA’s datasheet footnote reads “Theoretical FP4 TOPS using the sparsity feature”, the user guide spells it out as up to 1 petaFLOP at FP4 precision with sparsity, and the product page, updated on 21 October 2026, now carries the same footnote on its “Tensor Performance” row. We found no dense FP4 number for GB10 from NVIDIA, so a “1 petaflop” figure without the word sparse should not be read as a dense specification. In any case it does not predict token generation speed; the 273 GB/s memory bandwidth does.

Linking two or more DGX Spark systems

DGX Spark is often described as limited to two Sparks. NVIDIA’s clustering documentation states that it “supports up to three DGX Spark systems connected directly through cables, and up to four systems when using a switch”. NVIDIA ships separate playbooks for two Sparks, for three in a ring topology and for four through a switch, plus an NCCL guide explicitly covering two, three or four Sparks. Two linked Sparks are the common case. Up to four are supported with NVIDIA’s playbooks and its Cluster Assistant, and NVIDIA has announced support for clusters of up to eight Sparks in manual configuration (NVIDIA blog, 21 October 2026).

The link is a direct 200 GbE QSFP connection between the ConnectX-7 ports, with approved cables named by part number and a RoCE device alongside each Ethernet interface. NVIDIA’s own RDMA write benchmark reports 92.57 and 97.28 Gb/s across the two logical links, 189.85 Gb/s in total, about 95 per cent of the 200 Gb/s rating, and that measured figure is the one to plan with. Because of the unified-memory design, GPUDirect RDMA is not supported: pinned device allocations cannot be coherently accessed by the CPU complex or by PCI Express devices, so zero-copy paths from the network card into GPU memory are not available. Our two-node article covers the wiring.

A second Spark mainly adds another 128 GB of memory; speed per request can improve only with tensor parallelism, and at most in part. NVIDIA’s measured figure for two Sparks is Qwen3 235B in NVFP4 at 11.73 tokens per second, so the model loads but runs slowly.

On the model size claimed for linked Sparks, NVIDIA’s own pages give two different figures for two Sparks, and a buyer should know both. As of October 2026, the live DGX Spark product page gives up to 400 billion parameters for two 128 GB systems and up to 700 billion for four. NVIDIA’s own Markdown mirror of that page, its datasheet and the hardware overview of its user guide (updated 21 October 2026) still give two systems and up to 405 billion parameters. The live page is the one consistent with the clustering documentation and with the NCCL playbook for four Sparks, so treat 400 billion on two Sparks and 700 billion on four as the current claims, and 405 billion on two as the figure that NVIDIA’s datasheet and documentation still carry. Both claims assume 4-bit weights. At 4.5 bits per weight, 700 billion parameters take about 394 GB of the 512 GB in four Sparks, and 400 billion take about 225 GB of the 256 GB in two.

For models that do not fit in 128 GB, our guide to LLM hardware requirements by model gives the smallest RTX PRO 6000 or H200 NVL configuration for each model.

What we supply

We supply the NVIDIA DGX Spark Founders Edition (128 GB, 4 TB) across the EU on one contract and invoice, with manufacturer warranty. We also supply the cards this article compares it with, the RTX PRO 6000 Blackwell in all three editions and the H200 NVL, on their own or in AI servers built to order. With the model, the precision, the context length and the number of concurrent users, we run the same arithmetic on your numbers before you order; the answer may be DGX Spark, two or four linked Sparks, or a GPU server.

FAQ