RTX Spark vs DGX Spark vs Strix Halo vs Gorgon for Local LLM 2026

DGX Spark vs Strix Halo vs Gorgon Halo: Which Platform Fits Your Local LLM Workload?

A 192GB system is not automatically faster than a 128GB one. A 1-PFLOP specification does not tell you how quickly an LLM will generate tokens. And a benchmark without separate prefill and decode results can give a misleading picture of real-world performance.

Those distinctions matter when comparing NVIDIA’s platform, AMD’s 128GB option, and newer 192GB-class configs for local AI / local LLM work.

All three can address workloads that once pushed people toward large discrete-GPU towers: private inference, coding agents, RAG, long context, and multi-model pipelines. They just solve those problems differently.

The useful way to compare them is:

1. Can the model and its working data fit in memory?
2. How quickly can the system process a long prompt (prefill)?
3. How quickly can it generate tokens (decode)?
4. Does your software depend on CUDA?
5. What happens when your workload moves beyond 128GB?

The most important distinction is still:

Primary question this guide answers: how to choose among NVIDIA’s 128GB appliance, AMD’s 128GB Strix-class option, and 192GB-class Gorgon shorthand systems for local LLM inference - especially the 128GB vs 192GB capacity fork - without treating any single tokens/s screenshot as a ranking.

OEM RTX Spark Windows laptops also start shipping Oct 16, 2026—related Grace+Blackwell silicon, but not the same product as the DGX Spark deskside appliance. Don’t mix the two names; see the RTX Spark column in Quick Comparison and the short note below.

Quick Comparison

This table orients the platforms. It does not mean one column is universally faster - that depends on the workload.

AMD lists Gorgon Halo as the former codename on the Ryzen AI Max+ PRO 495 page (up to 192GB, Radeon 8065S). Here we use it as buyer shorthand for that 192GB-class deskside tier, not as a separate consumer architecture brand.

Quick planning: what 128GB vs 192GB usually buys

If 128GB already fits with headroom, treat 192GB as capacity insurance.

RTX Spark laptop vs DGX Spark deskside vs Strix Halo mini PC

RTX Spark is the Windows Grace+Blackwell line—OEM laptops from Oct 16 (entry about USD 2,599; up to 128GB) plus compact deskside boxes such as ASUS ProArt GR1X (~1.1L).

DGX Spark stays the DGX OS deskside appliance: NVIDIA lists the 128GB Founders config at USD 6,950; OEM 64GB configs start about USD 4,999 on Oct 23.

Strix Halo mini PCs remain the everyday x86 128GB local-LLM path. When the working set exceeds 128GB, Gorgon Halo / Ryzen AI Max+ PRO 495 (e.g. ACEMAGIC’s F9A) is the 192GB step—not a 256GB Strix Halo SKU. RTX Spark adds a Windows form-factor path; it does not obsolete Strix Halo for always-on x86, OCuLink / multi-NIC, or quieter desk agents. Many 70B / 120B quantized models still hit the 128GB wall—that is why Gorgon capacity matters.

LLM Hardware Bottleneck Map

This map is the point of shopping these platforms in 2026 - not a single tokens/s screenshot.

Why These Three Platforms Are Being Compared

The shift from AI PCs to local workstations

“AI PC” marketing still leans on NPU TOPS. Serious local LLM buyers care more about unified memory, GPU/APU inference paths, and whether the box can host private agents, RAG, and long-context work on a desk - which is why NVIDIA’s platform, AMD’s 128GB option, and 192GB-class configs show up together when people shop AI mini PC / compact workstation hardware.

Why memory capacity became a key spec

Once people started loading 70B-class and 120B+ weights locally, 128GB and 192GB stopped sounding like luxury and started sounding like “will this even load?” Unified memory is why these three deskside options share attention: they promise a single pool large enough for local LLM hardware that used to require multi-GPU towers.

(Chip-level 128GB vs 192GB diffs live in our PRO 495 upgrade guide. On AMD’s product page, Ryzen AI Max+ PRO 495 lists former codename Gorgon Halo, Radeon 8065S (40 CUs), and max 192GB LPDDR5X-8533 - that is the 192GB-class silicon this guide maps to deskside SKUs.)

What Is AMD Strix Halo?

Platform and Ryzen AI Max

Strix Halo is AMD’s high-end APU platform that puts a strong Zen 5 CPU, a large Radeon iGPU, and a wide LPDDR5X unified-memory bus into compact systems. Shoppers usually type AMD Strix Halo; Ryzen AI Max+ 395 is one of the best-known chips that implements that platform in Strix Halo mini PC and workstation SKUs.

For platform basics and form-factor context, see our platform overview. If you are comparing a Strix Halo PC against appliances, start there.

Why Strix is interesting for local AI

The platform matters for local AI because it combines:

• A large unified memory pool (commonly up to 128GB on flagship configs such as Strix Halo 128GB)
• Real GPU compute for LLM inference (not NPU-only marketing)
• Compact chassis options - from compact AMD mini PC designs to denser deskside boxes
• Enough headroom for everyday x86 software besides the model

It is not “a discrete 4090 in a tiny case.” It is an APU-first approach: fit large weights in one pool, accept that decode is often memory-bandwidth bound, and optimize the software path (ROCm, Vulkan, llama.cpp, Ollama).

For a deeper look at how Strix Halo handles Qwen 3.5, Ollama, ROCm, local LLM inference, AI Agents, and RAG in practice, see our AMD Strix Halo Mini PC for Local AI guide.

What Is AMD Gorgon Halo?

This is the information gap most Spark-vs-Strix posts still miss.

Capacity: 128GB vs 192GB-class AMD

AMD’s own product page lists Gorgon Halo as the former codename for Ryzen AI Max+ PRO 495 (Radeon 8065S, 40 CUs, up to 192GB LPDDR5X-8533). In this guide, we still use “Gorgon Halo” mainly as buyer shorthand for that 192GB-class deskside tier - not as a separate consumer architecture brand you need to shop by name.

For buyers, the useful distinction is simpler:

• AMD’s 128GB-class option → usually enough for many resident local LLM stacks
• the 192GB configuration → more room when weights, KV cache, and multi-service stacks stop fitting

Versus Strix, this is therefore mainly a capacity story (with configuration-dependent clocks and carve-outs), aimed at workloads that were already hitting the 128GB wall - multi-service RAG, longer context, larger MoE weight files, higher quants.

Versus NVIDIA’s 128GB appliance, this is a different question again: NVIDIA’s box still centers on CUDA and a 128GB coherent pool; the larger-memory AMD systems answer “what if 128GB resident memory is the real wall?”

Why higher memory capacity matters for local LLMs

Capacity shows up for larger weights, longer KV caches, multi-service stacks, or less aggressive quant.

Is more memory always better?

No. Capacity sets what you can load; speed still tracks bandwidth, compute, and software.

What Is NVIDIA DGX Spark?

Specs that matter for AI

From the NVIDIA product page, the DGX Spark specs that matter for local AI / LLM inference (and for reading performance claims carefully) are roughly:

• GB10 Grace Blackwell superchip
• 128GB coherent unified memory @ stated 273 GB/s
• FP4-class Tensor performance marketing (up to ~1 PFLOP sparse FP4 - theoretical)
• CUDA software stack, DGX OS, playbooks / NIM-oriented tooling
• Fast local storage (Founders configs include large NVMe)
• ConnectX-7 networking for multi-box scale-out stories

Founders Edition list pricing currently sits at $4,699 (price context only - this guide is not a price roundup).

Why CUDA is part of the Spark story

For many buyers, NVIDIA’s platform is not “another 128GB box.” It is access to the CUDA gravity well: frameworks, kernels, fine-tune recipes, and serving stacks that already assume NVIDIA. That software layer is part of measured LLM performance, not an accessory.

Key Hardware Differences (detail)

The Quick Comparison above is enough for most buyers. This table adds the denser spec layer.

The specs that actually matter for LLMs

For LLM inference, three numbers are not interchangeable:

1. Memory capacity - can weights + KV + runtime fit?
2. Memory bandwidth - how fast can decode move weights?
3. Compute + software - how fast is prefill, and which kernels exist?

TOPS / PFLOPS alone do not answer those questions.

Memory Capacity vs Memory Bandwidth for Local LLMs

Why 128GB can be more important than GPU FLOPS

If the model does not fit, FLOPS are irrelevant. This is why local LLM hardware conversations fixate on Strix Halo 128GB and Spark’s 128GB pool - and why Gorgon 192GB is a real product story for capacity-bound users.

Why more memory does not automatically mean faster inference

Once the working set fits, adding RAM rarely raises tokens/s by itself. Decode on unified-memory APUs is often memory-bandwidth bound. Extra capacity mostly reduces swapping, unloading, and forced down-quants.

What memory bandwidth changes

Bandwidth shows up hardest in:

• Decode (token-by-token generation)
• Weight streaming for large dense models
• Memory-bound LLM performance when the GPU is waiting on the bus

Spark’s stated 273 GB/s and Strix’s 256 GB/s peak help explain why generation gaps in some public matched runs look modest - even when prefill gaps look large. Max+ PRO 495’s 192GB-class configs also land at a 273 GB/s theoretical peak from 256-bit × LPDDR5X-8533 (OEM sustained may differ).

What happens when you add more context?

Longer context grows KV cache. Coding agents and RAG that re-send huge prompts punish prefill and cache footprint. That is a different bottleneck map than short chatbot turns.

Why Model Size Is No Longer Enough to Choose Local AI Hardware

“How many GB for a 70B model?” is the wrong standalone question.

A practical memory budget for local LLMs:

1. Model weights (quantization dependent)
2. KV cache (context length dependent)
3. Runtime overhead (framework, CUDA/ROCm graphs, OS)
4. Context/tools (agent scratch, retrieval buffers)
5. Multiple models/services (embedder, reranker, second LLM)

So the same “70B” label can be comfortable on 128GB in one stack and painful in another. Capacity planning is a sum, not a parameter count.

(See the early Quick planning table for 64 / 128 / 192GB ranges.)

LLM Inference by Model Class

Small and medium LLMs

For 7B-32B chat, compute, software maturity, cost, and power often matter more than chasing 192GB. An AI mini PC on AMD’s 128GB option can be the rational buy if your models already fit.

70B-class models

Here memory capacity, quantization, and bandwidth start to co-dominate. Both 128GB platforms compete in the same club; the differentiator becomes CUDA vs ROCm paths and how your workload splits across prefill and decode.

120B+ models

Capacity becomes gate #1. Quantization and context policy decide whether the machine is usable. The 192GB configuration is aimed at this band more than at “faster 14B chat.”

Large MoE models

Total parameters ≠ active parameters. A 200B+ MoE can look terrifying on a slide while activating far fewer experts per token. You still need capacity for weights on disk/in memory, but decode cost tracks active work plus routing overhead. Runtime quality matters as much as the headline parameter count - which is why MoE belongs in any serious desk-side inference guide.

Why 200B+ Parameter Models Are Not Always as Heavy as They Look

Dense models keep most parameters hot each token. MoE models activate only some experts, so per-token compute can look lighter than the headline parameter count.

Sparse activation reduces per-token compute, but it does not remove the need to store the model weights. That is why a large MoE can still need 192GB-class capacity even when decode feels manageable - and why total parameters, weight footprint, active parameters, KV cache, and measured tokens/s must stay separate in any LLM benchmark reading.

Why LLM Benchmarks Can Be Misleading

Prefill vs decode

Prefill processes the input prompt (often compute-heavy, parallel).

Decode emits tokens one by one (often bandwidth/latency sensitive).

This split also explains why DGX Spark performance figures can look uneven across tests: prefill may gap hard in one setup while decode stays close. A box can feel fast on a short chatbot and slow on “analyze this 20k-token repo.”

Tokens per Second is not the whole story

Results move with prompt length, context, batch size, quantization, backend, model, and runtime. A single Spark benchmark labeled as a DGX Spark benchmark or LLM benchmark number without those labels is incomplete.

Why two benchmarks show different results

Public matched runs are useful as directional evidence - not as a platform-wide ranking.

Sources: HardwareCorner, IntuitionLabs, Memeburn.

In that published comparison, Spark showed a substantial prefill advantage, while decode results were much closer - useful for prompt-heavy workflows, not a universal winner for every local LLM job.

CUDA vs ROCm: The Software Difference

CUDA on Spark

On DGX Spark vs AMD threads, CUDA is often the real decision: framework support, TensorRT-LLM / vLLM paths, fine-tune recipes, and less time chasing forks - even when 128GB AMD boxes exist.

ROCm and AMD hardware

On Strix / Gorgon-class systems, real AI inference and LLM inference often run through ROCm, Vulkan, llama.cpp, Ollama, LM Studio, and friends. The stack works; it may need more operator care.

Why software can change hardware performance

Same silicon, different backend → different prefill/decode. Inference performance is a stack, not a chip specification.

         AI Application
               ↓
     Model / Quantization
               ↓
      Inference Runtime
     ↙                  ↘
  CUDA                  ROCm/Vulkan
     ↘                  ↙
        GPU / APU
             ↓
     Memory Architecture
             ↓
      Cooling / Power

Hardware capability vs deployment friction

Raw specs are only half the purchase. The other half is how painful it is to get a model serving reliably:

• NVIDIA’s path: CUDA-native tooling, more “it just runs” recipes for common stacks (vLLM / TensorRT-LLM / playbooks). You often pay a premium for lower setup friction - not only for a tokens/s screenshot.
• AMD’s path: many real deskside setups run through llama.cpp, Vulkan, Ollama, LM Studio, and ROCm where supported. It works; operator care varies more by model/runtime.

So “is Spark worth it over a 128GB AMD box?” is often: CUDA ecosystem + lower friction + the published prefill gap in some matched tests - against price, Windows/x86 convenience, and decode that may be close.

Scenario Experiments (from Real User Questions)

Instead of dumping Reddit tokens/s, translate recurring LocalLLM debates into tests:

Scenario 1 - “I want to run a 70B model locally.” Check capacity → quantization → bandwidth → runtime.

Scenario 2 - “I want a local coding agent.” Check context + KV cache → decode feel → software agents tooling (CUDA can matter).

Scenario 3 - “I want 120B+.” Check capacity first → quant → whether the larger-memory system helps more than NVIDIA’s prefill path for your prompts.

Scenario 4 - “I want multiple models resident.” Check free memory after OS/runtime → concurrency → thermals for long runs.

Mini PC vs Compact AI Workstation for Local LLMs

When choosing a Strix-based mini PC for local AI, look beyond the processor name. Memory capacity, cooling, storage expansion, and sustained power matter more for long inference workloads than the brochure label.

Neither form factor wins universally - match duty cycle. And for desk-side LLM inference, NPU TOPS ≠ LLM performance: GPU/APU compute, unified memory, and runtime dominate.

Where Does ACEMAGIC Fit?

Which ACEMAGIC configuration fits each workload?

Local AI Hardware vs Cloud GPUs

When local hardware makes sense

Privacy, repeated inference, offline work, predictable daily agents, development loops you run every hour.

When cloud GPUs make more sense

Occasional huge jobs, burst training, models that still will not fit, distributed experiments.

How to think about total cost

Price the hours you actually run, not a viral “pays for itself in N months” claim without your token logs. Local wins on privacy and marginal cost; cloud wins on elasticity.

How to Choose Local LLM Hardware in 2026

1. Start with model size class - 7B / 14B / 32B / 70B / 120B+ - then immediately add context and multi-service needs.
2. Check memory capacity - can the full working set fit?
3. Check memory bandwidth + compute - will decode feel acceptable?
4. Check context length - KV cache and prefill path.
5. Check software - CUDA required or ROCm/llama.cpp OK?
6. Check thermals/form factor - mini PC vs workstation duty cycle.

The Local AI Hardware Decision Matrix

There is no single winner table. On 128GB-class stacks, choose on software, prefill/decode behavior, and system design. Cross the capacity wall, and 192GB is a different class of advantage - not a higher benchmark number.

Summary

Choosing among these three deskside options comes down to workload fit, not a single winner:

1. Capacity ≠ speed. 192GB helps when weights, KV cache, or multi-service stacks will not fit in 128GB - it does not automatically raise tokens/s.
2. Prefill ≠ decode. In the published GPT-OSS 120B MXFP4 llama.cpp matched test, Spark’s prefill was far ahead while decode stayed close - treat that as directional, not a universal ranking.
3. 128GB class: NVIDIA’s CUDA / lower-friction path versus AMD’s x86 Strix-class deskside path (e.g. M1A PRO+ or F9A-395), based on software stack and form factor.
4. 192GB class: when the working set is the wall, F9A-PRO495 maps to Max+ PRO 495 / 192GB LPDDR5X-8533 (Radeon 8065S). “Gorgon” here stays former-codename / buyer shorthand for that tier.
5. Buy the bottleneck you actually have: fit first, then bandwidth/compute, then CUDA vs ROCm/llama.cpp friction, then thermals and expansion.

FAQ

Is NVIDIA’s 128GB box worth it over AMD’s 128GB option for local LLM inference?

Depends what you are buying. In the published GPT-OSS 120B MXFP4 matched test above, Spark’s prefill was far ahead while decode was close. The premium more often buys CUDA ecosystem, lower deployment friction, and DGX-oriented tooling - not a universal 5× generation speed claim. AMD’s 128GB option stays competitive for many decode-heavy, Windows/x86 AI mini PC setups.

How much RAM do I need to run a 70B LLM locally?

Plan for weights + KV cache + runtime + extras, not the parameter label alone. Many 70B-class setups are comfortable in a 128GB unified-memory pool at common quants; long context, higher quants, or multi-service stacks raise the budget. Use the planning table above - it is guidance, not a hard limit.

Can I run 120B models on 128GB unified memory?

Yes, with heavy quantization and limited context length, but you lose headroom for KV cache, embedding models, and rerankers. That is where 192GB Gorgon-class hardware adds value. Fit is still the first gate; usable speed is the second.

Is 192GB better than 128GB for local LLMs?

192GB provides more model and KV-cache headroom, but it does not automatically increase tokens/s when the workload already fits within 128GB. Choose it for fit-bound stacks (higher quants, multi-model, long context, larger MoE weights) - not as a free speed upgrade.

When does the 192GB configuration matter more than either 128GB box?

When the working set refuses to fit: multi-model RAG, larger MoE weight files, higher quants, or long KV caches. See also the 192GB vs 128GB FAQ above.

Does more unified memory mean faster tokens/s?

No. Fitting the weights is not the same as generating tokens quickly - bandwidth, compute, quantization, and runtime still set the pace.

Is NPU TOPS a good way to pick on-device LLM hardware?

Usually no. For desk-side LLM inference, GPU/APU + memory + software dominate AI inference results more than NPU TOPS slides.

Mini PC or deskside workstation?

Chat and light agents often fit a mini PC. Large models, multi-service RAG, and long-running inference lean toward a workstation - including a compact workstation like F9A when you need 192GB-class memory.

Sources

• AMD. “AMD Ryzen AI Max+ PRO 495.” amd.com
• AMD. “AMD Ryzen AI Max+ 395.” amd.com
• NVIDIA. “NVIDIA DGX Spark.”
• NVIDIA. “NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI.” NVIDIA Blog. blogs.nvidia.com
• ASUS. “ProArt GR1X: RTX Spark Desktop & Agent Computer.”
• Tom’s Hardware. “Nvidia introduces 64GB DGX Spark… starts at USD 4999.” tomshardware.com
• NVIDIA. “RTX Spark: Hundreds of Games Oct 16.” GeForce News.
• NVIDIA Marketplace. “NVIDIA DGX Spark US — A Grace Blackwell AI supercomputer on your desk.” marketplace.nvidia.com
• Jake Roach. “Pre-orders are live on Nvidia RTX Spark devices… starting at $2,599.” Tom’s Hardware. tomshardware.com
• Tom Warren and Emma Roth. “The Surface Laptop Ultra finally has a release date — and a starting price of $2,599.” The Verge. theverge.com
• HardwareCorner. “First DGX Spark LLM Benchmarks.” hardware-corner.net
• IntuitionLabs. “NVIDIA DGX Spark Review.” intuitionlabs.ai
• Memeburn. “DGX Spark vs Ryzen AI Max 395: Is NVIDIA Worth the Premium?” memeburn.com