Strix Halo vs DGX Spark vs Mac Studio for local LLMs: what 128 GB gets you

In CanRun's calculation, a 128GB Ryzen AI Max+ 395 (Strix Halo) machine, a 128GB NVIDIA DGX Spark and a 128GB Mac Studio (2025) with the M4 Max hold the same large models at their default quants: gpt-oss-120b fits on the GPU of all three. What separates them is memory bandwidth, which sets how fast text comes out, and how much of the 128GB each system lets its GPU use. A dense model shows the gap: in CanRun's estimates, Gemma 4 31B runs slowly on the DGX Spark but runs well on the M4 Max, which has twice the bandwidth.

What fits in 128GB of unified memory

On all three machines the CPU and GPU share one pool of memory, called unified memory. There is no separate VRAM, so a model has to fit in the part of the pool the GPU may use. CanRun adds up the whole GGUF file, the KV cache (the memory that holds the conversation so far) and a compute buffer, the runtime's working memory. On the Strix Halo and the Mac it compares that total with about 70% of the pool, 89.6 GB on a 128GB machine. On the DGX Spark it uses what Linux and the desktop leave free, taken from public boot logs: 116.9 GB. The next section explains where both figures come from and how each system really behaves.

The table lists what some of the largest models in CanRun's catalog need at an 8k context with an f16 (unquantized 16-bit) KV cache. Each is at its default quant: Q4_K_M, the 4-bit GGUF quant CanRun uses as its baseline; MXFP4, the format gpt-oss ships in; and IQ4_XS for Solar Open 2 250B, which has no Q4_K_M file in our data.

Llama 3.3 70B, gpt-oss-120b and Solar Open 100B fit within the GPU share on each of the three machines. So does Qwen3.5 122B-A10B, larger than those three, and on all three it stays inside the share even at 128k with an f16 KV cache. Solar Open 2 250B, Upstage's 250B model, needs 137.2 GB at IQ4_XS. That is about the size of the whole 128GB pool, with nothing left for the operating system, so it fits on none of them.

The next table counts how every catalog model fares on each memory configuration of six chips: the Strix Halo, the DGX Spark, the M4 Max with the 40-core GPU, and the M5 Ultra, M3 Ultra and M2 Ultra from the Mac Studio.

Of the four 128GB rows, the DGX Spark's has more usable memory than the other three, because CanRun counts its GPU share differently (see the next section). The DGX Spark also has a 64GB row, for the configuration NVIDIA's partner makers sell, and there gpt-oss-120b no longer fits. Beyond that, the two Apple chips have more models that run great than the Strix Halo and the DGX Spark. The Strix Halo and the DGX Spark have nearly the same bandwidth and, in CanRun's estimates, about as many such models. The M2 Ultra has about half again the M4 Max's bandwidth but no more such models, because CanRun's factor for Ultra chips is lower (explained under "How sure are these numbers?"). Qwen3 32B, for example, runs well on both and great on neither. The M5 Ultra in the 2026 Mac Studio has half again the M3 Ultra's bandwidth. Even its smallest configuration, 96GB, has more models that run great than any row of the other chips, and Qwen3 32B runs great on it.

In the Mac Studio (2025), only the M4 Max with the 40-core GPU comes with 128GB; the M3 Ultra has no 128GB option. Apple launched the M3 Ultra in March 2025 with 96GB, configurable up to 512GB, but that Mac Studio's spec page now lists 96GB up to 256GB. The table's 512GB row is for machines bought with that option before Apple dropped it. The M2 Ultra in the 2023 Mac Studio came with 64GB, 128GB or 192GB.

Since September 2026, a new Mac Studio with the M5 Max or the M5 Ultra has been on sale. There, too, only the M5 Max with the 40-core GPU comes with 128GB, a configuration the MacBook Pro also offers, and gpt-oss-120b runs great on it in CanRun's estimate. The M5 Ultra starts at 96GB, and its 256GB option comes only with the 80-core GPU. CanRun calculates the M5 Ultra in the 96GB and 256GB configurations on sale now.

How much of the 128GB the GPU can use

For the Macs and the Strix Halo, CanRun uses one figure: about 70% of the pool. The real limit depends on the operating system and its settings, and the three makers handle it differently. For the DGX Spark, CanRun uses a figure taken from public boot logs instead, explained below.

Mac Studio

macOS caps how much unified memory the GPU may take. According to code quoted in llama.cpp discussion #2182, macOS keeps back about a quarter of the memory on Macs with more than 32GB. A 128GB Mac therefore gives its GPU about three quarters by default, more than CanRun counts. The limit can be raised in macOS Terminal with sudo sysctl iogpu.wired_limit_mb= followed by a value in megabytes. Running local LLMs on a Mac (M4, M5): how much unified memory? covers the default, the command and the risk of leaving macOS too little memory.

Strix Halo

On Windows, AMD's Variable Graphics Memory turns part of system RAM into dedicated graphics memory; you set it in AMD Software: Adrenalin Edition. AMD's FAQ says a 128GB Ryzen AI Max+ 395 system can dedicate up to 96GB. With that setting the GPU can address 112GB in total by also using shared memory, though AMD says performance is highest when workloads stay within 96GB.

On Linux, AMD's ROCm documentation describes a different pool. By default, the kernel driver lets the GPU map about half of system RAM, a limit called GTT, so it applies whether llama.cpp runs through ROCm or Vulkan. AMD recommends keeping the dedicated reservation in the BIOS small and raising the shared limit instead. Its amd-ttm tool, from the amd-debug-tools package, shows the current limit and sets a new one, and the change applies after a reboot. amd-ttm counts binary gigabytes, so its figures read about 7% lower than CanRun's. Half of 128GB leaves little room above the 64.3 GB that gpt-oss-120b needs, so raise the limit before loading it.

DGX Spark

NVIDIA lists the DGX Spark's memory as unified system memory and gives no separate figure for the GPU. Its product page now lists a 64GB configuration next to the 128GB one; the 64GB model is sold only by NVIDIA's partner makers and has the same bandwidth. NVIDIA's known-issues page explains that nvidia-smi shows total memory use as Not Supported, because the GPU has no dedicated framebuffer memory, though it still lists each process's GPU memory. The same page warns that the free memory a CUDA program reads can be lower than what it can actually allocate.

On Linux the GPU takes its memory from the same pool as every other program, so CanRun counts what is left after the system and the desktop. Owners have posted the kernel's boot log on NVIDIA's developer forum, and the lowest figure there comes from DGX OS 7.5.0: a new kernel feature reserves several gigabytes more than earlier kernels did, and a reply in that thread says updates to address it are rolling out. CanRun starts from that lowest figure and subtracts what the desktop uses when idle, as another owner reported it. That leaves 116.9 GB on the 128GB model. There is no public figure for the 64GB model yet, so CanRun subtracts the same fixed amount and counts 48.2 GB. Public single-unit runs agree with this: the largest DeepSeek V4 Flash 0731 file one tester loaded on a single DGX Spark fits within it at a short context, and the next larger file, which the tester found too large for one unit, does not.

Where CanRun's figures sit

On a 128GB Mac, CanRun's 70% is below the macOS default. On the Strix Halo it sits between the Linux default and the Windows maximum. On the DGX Spark, CanRun's figure starts from the lowest boot log, so a system on an earlier or a fixed kernel, or one running without a desktop, has some room to spare. The difference matters only for models whose need lands between those lines. The Q2_K file of Solar Open 2 250B, a 2-bit quant with heavy quality loss, needs 96.4 GB. That is more than the 70% share, so on a 128GB Strix Halo or Mac CanRun computes it CPU-only, and CPU-only setups are capped at Runs slowly whatever the speed (a theoretical estimate). On the DGX Spark it fits within the GPU share and runs well. With a higher limit it may fit on the GPU of the other two as well, so check where it actually loaded with ollama ps or the llama.cpp load log.

Generation speed: public results for gpt-oss-120b

Each generated token reads the model's active weights and the KV cache from memory, so CanRun estimates generation speed from memory bandwidth. The Strix Halo has 256 GB/s, the DGX Spark 273 GB/s and the M4 Max with the 40-core GPU 546 GB/s. The M3 Ultra has 819 GB/s and the M2 Ultra 800 GB/s, about three times the bandwidth of the Strix Halo and the DGX Spark, while the M4 Max has about twice. The M5 Ultra has 1,228 GB/s, half again as much as the M3 Ultra.

gpt-oss-120b is a mixture-of-experts (MoE) model. Each token uses only a small share of its parameters (the memory table lists both counts), so it reads far less per token than a dense model of its size. Public llama.cpp results exist for three of the machines in this guide:

All three are rated Runs great, each backed by a public measurement, even under the stricter thresholds CanRun uses for models that think before they answer. The M4 Max has no public gpt-oss-120b result in our data, and CanRun's calibrated estimate for it also rates Runs great.

Read the DGX Spark result with its build in mind. Our data takes it from the llama.cpp maintainers' DGX Spark results file, last re-run in February 2026. Results in the llama.cpp thread on the DGX Spark, which opened in October 2025, have moved with software and settings: the maintainers' first gpt-oss-120b run there generated about two thirds as fast as the current file. In that thread, one participant ran a DGX Spark and a Strix Halo machine on the same llama.cpp build. With default settings, gpt-oss-120b generated text at nearly the same speed on both. Turning off mmap, which maps the model file into memory instead of reading it in, changed that on the DGX Spark only: it then generated about a fifth faster than the Strix Halo at the start of a conversation and about a tenth faster 32k tokens in. A newer Linux kernel later cut the DGX Spark's model loading time but left generation speed about where it was. CanRun's DGX Spark estimates are fitted to the maintainers' file, which was run with mmap off, so they assume it is off. If you run llama.cpp on a DGX Spark, turn mmap off: --load-mode none in current builds, --no-mmap in older ones. With it on, expect generation to fall below CanRun's estimates.

Dense models show the bandwidth gap

The grid compares five models on the five chips and on an RTX 5090 at an 8k context. Each unified-memory cell names the smallest memory size that reaches that chip's best verdict for the model ("with N GB"). A cell can therefore name a smaller size, such as 32GB or 48GB, even though this guide is about 128GB. Once a model fits on the GPU, CanRun gives every larger configuration of the same chip the same speed estimate. The RTX 5090 row assumes 32GB of system RAM. Every model in this grid has a thinking mode (Gemma 4 31B's is off by default), so every cell uses CanRun's 1.5× stricter speed thresholds.

Qwen3.5 35B-A3B, an MoE model that uses about 3B parameters per token, runs great on all six.

Dense models read every weight for every token, and there the gap opens. Gemma 4 31B runs slowly on the Strix Halo and the DGX Spark, runs well on the M4 Max, the M3 Ultra and the M2 Ultra, and runs great on the RTX 5090. It also runs great on the M5 Ultra, which is not in the grid. The DGX Spark result is a public measurement, and the others are calibrated estimates. On the Strix Halo and the DGX Spark the stricter thresholds decide the result: their Gemma 4 31B estimates sit between the normal and the stricter Runs well line. Gemma 3 27B, a dense model of similar size with no thinking mode, runs well on both.

Llama 3.3 70B, not in the grid, shows the same pattern one size up. At Q4_K_M it fits fully on the GPU of every 128GB machine here. It runs slowly on the Strix Halo and the DGX Spark, and runs well on the M4 Max, the M3 Ultra and the M2 Ultra, the 96GB M3 Ultra included. Even the M5 Ultra, with the most bandwidth of the unified-memory machines here, only runs it well. If dense 70B models are what you want to run, none of these machines makes them quick in CanRun's estimates.

The two large MoE models split the chips differently. Qwen3.5 122B-A10B activates about twice as many parameters per token as gpt-oss-120b. It runs well on the Strix Halo and the DGX Spark, and runs great on the M4 Max and the 128GB M2 Ultra. The M3 Ultra cell names 256GB because the 96GB configuration does not leave the GPU enough room. There CanRun computes the model CPU-only, and CPU-only setups are capped at Runs slowly whatever the speed (a theoretical estimate).

Solar Open 2 250B shows Won't run at IQ4_XS on the 128GB machines, and the grid suggests its Q2_K file instead: CPU-only on the Strix Halo and the M4 Max, as described above, and fully on the GPU of the DGX Spark. The 256GB M3 Ultra and the 256GB M5 Ultra hold the IQ4_XS file on the GPU and run it great. On the 192GB M2 Ultra it misses CanRun's GPU share by a small margin, so CanRun computes it CPU-only, capped at Runs slowly whatever the speed (a theoretical estimate). The macOS default limit is higher than CanRun's figure there, so check ollama ps before you rule it out.

Long contexts and prompt processing

gpt-oss-120b keeps its KV cache small: half its layers use a sliding window that keeps only recent tokens, and the rest store small keys and values. At 128k with an f16 KV cache it needs 69.9 GB, still within the GPU share of all three 128GB machines.

The table is for the Strix Halo in its 128GB configuration. Every context fits in the GPU share, but with an f16 cache the verdict drops a level at 128k, because the whole KV cache is read for every token. A dense model fills memory much faster. Llama 3.3 70B's KV cache at 128k with f16 is 42.9 GB, against 4.8 GB for gpt-oss-120b. For why the KV cache differs by model, see KV cache explained: how context length eats VRAM.

CanRun's verdicts rate generation speed. Before the first token appears, the machine has to process the whole prompt. With long prompts, such as a large document or a coding agent's context, that wait can matter more than generation speed, and this guide's tables do not show it.

Here the DGX Spark stands apart. In the same-build comparison from the llama.cpp thread, it processed gpt-oss-120b prompts not quite twice as fast as the Strix Halo at the start of a conversation. At 32k tokens in, where both machines slow down, it was more than three times as fast. The M2 Ultra result in our data comes from the same llama-bench prompt test, on an older build. At the start of a conversation it processed prompts faster than the Strix Halo and slower than the DGX Spark. We have no Mac result 32k tokens in.

Compared with a graphics card plus system RAM

A desktop PC with a graphics card is the other common route to large models. The RTX 5090 has 32GB of VRAM and 1,792 GB/s of bandwidth, about twice that of the M3 Ultra and the M2 Ultra and six to seven times that of the Strix Halo and the DGX Spark. In CanRun's estimates, a model that fits in its memory runs faster there: Gemma 4 31B runs great on it, at least a step above every unified-memory machine in the grid.

gpt-oss-120b does not fit on the card, so the expert layers that do not fit go to system RAM. With 32GB of RAM the model still does not fit, and with 64GB it runs well. That is a theoretical estimate (±30%) that depends on RAM speed, while the Strix Halo and the DGX Spark run the model great with public measurements behind them. For how the split works, see Running MoE models bigger than your GPU: gpt-oss-120b with system RAM.

A dense model larger than the card falls back to partial offload, with some layers in RAM. Llama 3.3 70B runs slowly on the RTX 5090 that way, just as it does on the unified-memory machines, though for a different reason: there bandwidth holds it back, here the layers left in RAM.

Where the PC route reaches further is total memory. With 128GB of system RAM, the 32GB card plus RAM holds Solar Open 2 250B at IQ4_XS, which no 128GB unified-memory machine does. There it runs slowly, a theoretical estimate.

This guide does not compare prices. Our data lists the DGX Spark at $3,999 launch MSRP, the price of NVIDIA's own 128GB model at launch. The partner makers' models, the 64GB configuration and the machines with the Strix Halo and the Apple chips come from several makers or in several memory sizes, and our data has no dated street prices for them.

Where to go next:

• Every catalog model on each chip: Ryzen AI Max+ 395 (Strix Halo), NVIDIA DGX Spark, Apple M4 Max (40-core GPU), Apple M5 Ultra, Apple M3 Ultra and Apple M2 Ultra.
• Running local LLMs on a Mac (M4, M5): how much unified memory?: the macOS limit and smaller Macs.
• Running MoE models bigger than your GPU: gpt-oss-120b with system RAM: the graphics card plus system RAM route in detail.

How sure are these numbers?

Memory figures are calculated with a formula: real GGUF file sizes, KV cache sizes from each model's configuration, and a compute-buffer formula. The approximation is the GPU share: 70% for the Macs and the Strix Halo, and for the DGX Spark a figure taken from public boot logs. The second section compares both with each system's real limit.

Speeds are measured where a cell says so. In this guide, the other cells running fully on the GPU of these machines are calibrated estimates with a ±20% band; the ±12% band applies only to dense models on NVIDIA and AMD graphics cards. CPU-only cells and the RTX 5090 with experts in RAM are theoretical estimates (±30%).

CanRun turns bandwidth into speed with one efficiency factor per type of machine, fitted to public results. The DGX Spark factors come from the llama.cpp maintainers' results file: five models on one build, at the start of a conversation and 8k tokens in, and CanRun's estimates land within a fifth of each. They all come from one machine with mmap off, though. The Strix Halo factors come from results on current llama.cpp builds with the Vulkan backend, from several machines: CanRun's estimates land within 4% of six dense-model results and within a tenth of seven MoE results. With these factors CanRun puts the two machines within about 2% of each other on dense models, and the DGX Spark ahead on MoE models by about 5% to 17%. The two machines' factors come from different public results, so treat the size of that gap with caution. Public results on Apple silicon show the Ultra chips turning less of their bandwidth into speed than the Max chips, so CanRun uses a lower factor for them. Both Apple factors for dense models are fitted to results on current llama.cpp builds. The summary table of the llama.cpp Apple thread still uses a 2023 build, and on the same M2 Ultra the current build generated about a third faster.

Software also moves these numbers. The Strix Halo runs llama.cpp through ROCm or Vulkan. In public comparisons on the same machine and build, ROCm generated text about 3% to 12% slower than Vulkan, so with ROCm expect speeds toward the low end of CanRun's range. The DGX Spark results changed with the llama.cpp build and the mmap setting, and Macs can also run MLX models. CanRun's estimates are for GGUF files on llama.cpp. Not modelled: prompt processing time, power modes, a raised GPU memory limit, other programs' memory, and more than one request at a time.

On your own machine, ollama ps shows what happened: SIZE, PROCESSOR (100% GPU) and CONTEXT. With llama.cpp, read the load log. On the DGX Spark, nvidia-smi shows total memory use as Not Supported but still lists each process's GPU memory.

Verdict names in this guide's text refer to the 8k context, f16 KV baseline. Models with a thinking mode, even one that is off by default such as Gemma 4 31B's, can spend extra tokens thinking before they answer, so CanRun makes their speed thresholds 1.5× stricter; the legend below does not show this. The thresholds:

FAQ

Can a 128GB unified-memory machine run 70B models?

It can hold them; how fast it runs them depends on bandwidth. At Q4_K_M, Llama 3.3 70B fits fully on the GPU of the Strix Halo, the DGX Spark and the 128GB M4 Max. CanRun expects it to run well on the M4 Max and on the M5, M3 and M2 Ultra, but slowly on the Strix Halo and the DGX Spark, even one step down at IQ4_XS. For dense models this size, bandwidth is the limit, not memory. gpt-oss-120b, an MoE model, runs great on the same machines.

Is the Strix Halo or the DGX Spark faster for local LLMs?

For generating text, they are close. In one participant's runs on the same llama.cpp build, the two were nearly even with default settings; with mmap off, the DGX Spark was about a fifth faster at the start of a conversation and about a tenth faster 32k tokens in. Its clear lead is prompt processing, especially with long prompts. CanRun's estimates put the two within about 2% of each other on dense models and the DGX Spark ahead on MoE models, by less than the mmap-off result at the start of a conversation. The two machines' factors come from different public results, so treat the size of the gap with caution. Both have 128GB of memory, though CanRun counts a larger GPU share on the DGX Spark, from public boot logs, than the 70% it uses for the Strix Halo.

Is a Mac Studio faster than the Strix Halo or the DGX Spark?

For generation, yes in CanRun's estimates, because the M4 Max has about twice the bandwidth, the M3 Ultra and the M2 Ultra about three times and the M5 Ultra more than four times; the grid above shows the gap, which is widest on dense models. For prompt processing, the M2 Ultra result in our data falls between the Strix Halo and the DGX Spark at the start of a conversation, and we have no Mac result 32k tokens in.

Is 128GB enough for gpt-oss-120b with a long context?

Yes, in CanRun's calculation. At 128k with an f16 KV cache it needs 69.9 GB, inside the GPU share of a 128GB machine. The verdict drops a level at 128k on both the Strix Halo (the table above) and the DGX Spark. On the Strix Halo under Linux, raise the GPU memory limit first, as described in the second section.

Sources

• llama.cpp discussion #16578: DGX Spark performance: the history of the maintainers' runs since October 2025, a participant's DGX Spark and Strix Halo runs on the same build at the start and at a 32k depth, their rerun with mmap off, and the later run on a newer kernel with faster model loading and the same generation speed.
• llama.cpp DGX Spark results file, February 2026: the DGX Spark gpt-oss-120b result in our data and the five results CanRun's DGX Spark factors are fitted to (mmap off).
• llama.cpp server README: --load-mode, which uses mmap by default and loads without it when set to none.
• quozul.dev: gpt-oss-120b on the Ryzen AI Max+ 395: the Strix Halo result in our data, on a 128GB Framework Desktop with ROCm.
• llama.cpp discussion #10879: Vulkan performance: a Strix Halo run on an October 2026 build with Vulkan and ROCm side by side, one of the dense-model results CanRun's Strix Halo factor is fitted to.
• llama.cpp issue #24438: ROCm and Vulkan on the Strix Halo: an MoE model on both backends, with an AMD engineer's rerun that found ROCm about 12% slower than Vulkan for generation.
• llama.cpp discussion #15396: running gpt-oss with llama.cpp: the M2 Ultra gpt-oss-120b result, generation and prompt processing, measured on a 192GB M2 Ultra, and gpt-oss-20b results on M1, M4 and Ultra chips from 2025 llama.cpp builds.
• llama.cpp discussion #4167: Apple silicon performance: generation speed by Apple chip for a dense model, and one M2 Ultra's results by llama.cpp build. CanRun's Apple factors for dense models are fitted to the results on current builds, not to the summary table's 2023 build.
• llama.cpp discussion #2182: VRAM/RAM split on Apple silicon: the memory macOS keeps back by default and iogpu.wired_limit_mb.
• AMD: Variable Graphics Memory FAQ: up to 96GB of dedicated graphics memory on 128GB Ryzen AI Max+ 395 systems, 112GB addressable with shared memory, and the Adrenalin setting.
• AMD ROCm docs: RDNA3.5 system optimization: the kernel's GTT limit at about half of system RAM by default, the small BIOS reservation, and amd-ttm, whose figures are in binary gigabytes.
• NVIDIA DGX Spark product page: the 64GB and 128GB configurations at the same bandwidth, with the 64GB one sold only by partner makers.
• NVIDIA DGX Spark user guide: hardware: 128GB of unified system memory and its bandwidth.
• NVIDIA developer forum: less RAM available at boot on DGX OS 7.5.0: owners' boot logs of the memory the kernel leaves available on several kernels, the lowest of which CanRun's DGX Spark figure starts from, and the reply about updates to address it.
• NVIDIA developer forum: memory the DGX system takes up: an owner's reading of the desktop's memory use at idle, which CanRun subtracts, and why a dashboard can show more (file cache).
• Classmethod: DeepSeek V4 Flash 0731 on one and two DGX Sparks: which file sizes loaded on a single DGX Spark and which did not.
• NVIDIA DGX Spark user guide: known issues: nvidia-smi showing total memory use as Not Supported while still listing per-process GPU memory, and free memory reported below what can be allocated.
• Apple: Mac Studio (2025) tech specs: M4 Max and M3 Ultra memory options (the M3 Ultra now listed up to 256GB) and bandwidth.
• Apple: Mac Studio (M5 Max or M5 Ultra) tech specs: M5 Max and M5 Ultra memory options and bandwidth, with the 256GB option only on the 80-core GPU M5 Ultra.
• Apple newsroom: Mac Studio with M5 Max and M5 Ultra: on sale from September 2026.
• Apple newsroom: Mac Studio with M4 Max and M3 Ultra: the M3 Ultra configurable up to 512GB at launch in March 2025.
• Apple: Mac Studio (2023) tech specs: M2 Ultra memory options and bandwidth.
• Apple: MacBook Pro 16-inch (M5 Pro or M5 Max) tech specs: the M5 Max with the 40-core GPU and 128GB.
• gpt-oss-120b model card: total and active parameters.