Skip to content

Which AI Models Fit in 128 GB? DGX Spark and Strix Halo Sizing Guide

A 128 GB local-AI computer does not have one universal model limit. A model fits only when its exact artifact, runtime allocations, context cache, operating system, and concurrent workload fit inside the memory the application can actually use. NVIDIA documents DGX Spark as a 128 GB unified-memory system that supports models up to 200 billion parameters, but that is a platform capability statement—not a promise that every 200B checkpoint, precision, context length, or serving pattern will run well. AMD documents Ryzen AI Max+ 395 systems with as much as 128 GB of shared LPDDR5X memory, but the usable GPU mapping still depends on the operating system, kernel, driver, and runtime.

Reviewed 25 August 2026 against current NVIDIA and AMD documentation. This guide gives Canadian buyers a defensible sizing method. It deliberately does not publish invented tokens-per-second results, pretend that shared memory is dedicated VRAM, or label a model “supported” from parameter count alone. For the hardware decision, compare DGX Spark and Strix Halo. For a broader buying path, start with which local AI computer to buy in Canada.

What 128 GB means on each platform

NVIDIA’s DGX Spark hardware overview lists 128 GB of unified LPDDR5X memory, a 256-bit interface, 273 GB/s of memory bandwidth, and platform support for models up to 200 billion parameters. NVIDIA’s porting guide describes a dynamic unified-memory architecture rather than a fixed pool of dedicated GPU VRAM. The operating system, display, runtime, model, KV cache, and other processes all consume the same physical capacity.

AMD’s Ryzen AI Max+ 395 specification lists a 16-core x86 processor, Radeon 8060S graphics, a 256-bit LPDDR5X-8000 interface, and support for as much as 128 GB of memory. AMD’s Strix Halo system-optimization guide explains that GPU access uses GPU virtual memory and depends on supported kernel and ROCm combinations. Check the current ROCm compatibility matrix at deployment time; “ROCm works” without a version, operating system, and kernel is not a sufficient compatibility claim.

The two systems therefore share a useful headline—128 GB of physically shared memory—but not an identical implementation or software path. A file that fits in both pools may still behave differently because CUDA, ROCm, Vulkan, model format, kernel coverage, and runtime memory management are different.

The model-fit equation

Use this planning equation before buying:

model artifact bytes + runtime workspace + KV/context cache + operating-system use + concurrent requests + safety headroom = required usable memory

Every term matters:

  • Model artifact: use the byte size of the exact checkpoint or quantized file you will deploy. A family name and parameter count are not enough.
  • Runtime workspace: CUDA, TensorRT-LLM, vLLM, ROCm, Vulkan, llama.cpp, and Ollama do not allocate memory identically.
  • Context cache: longer prompts and retained context consume additional memory. Architecture, KV precision, layer count, attention design, and context length all affect the amount.
  • Concurrency: a single-user demonstration is not a capacity test for a multi-user service. Batch size and simultaneous sequences can materially change the envelope.
  • System use: shared memory is also used by the operating system, display, background services, and other applications.
  • Headroom: do not plan a production workload to the last available byte. Measure the loaded system and leave room for peaks, updates, and failure recovery.

Safe model-size guidance

Model class What can be said safely before testing Required validation
Small and mid-sized open-weight models Common quantized artifacts are usually the least demanding 128 GB use case, leaving more room for context and concurrent work. Confirm the exact artifact, runtime build, context target, and number of simultaneous requests.
70B-class dense models Quantized artifacts can fit inside a 128 GB shared-memory system; full-precision weights and large caches can change the result materially. Load the exact quantization and measure prompt processing, generation, cache growth, and sustained thermals on the selected runtime.
Large mixture-of-experts models Active-parameter count describes compute routing, not necessarily stored weight size. All required experts may still need to be resident. Use the actual downloaded artifact size and the runtime’s documented loading behavior. Do not size from “active parameters” alone.
Models near a vendor’s advertised ceiling NVIDIA’s “up to 200B” statement is a platform boundary, not a universal usability guarantee. AMD does not turn 128 GB into a parameter-count guarantee. Require a named model, format, context, runtime, software versions, and a witnessed load test before purchase.
Models larger than one machine’s tested envelope Do not assume that two computers become one transparent memory pool. NVIDIA documents supported multi-Spark paths; the AMD product is sold as a single-system offer. Scope networking, model parallelism, orchestration, failure handling, and software support as an integration project.

Context and concurrency are part of the model

A model that loads at a short context for one user has not yet passed a deployment test. KV cache grows with retained tokens, and serving frameworks may reserve additional workspace or maintain multiple sequences. Record at least the model artifact, quantization, runtime and version, operating system, driver or kernel, input length, output length, context ceiling, batch size, concurrency, memory high-water mark, and wall power. Without those fields, a tokens-per-second number cannot be compared responsibly.

This is also why a static “24 models that fit” table decays quickly. Model revisions, quantized artifacts, runtime releases, and cache implementations change. D-Central’s buying process should begin with the customer’s exact artifact and workload, then validate it on the intended software path.

DGX Spark or Strix Halo for the same model?

Choose DGX Spark when the required workload depends on CUDA, NVIDIA containers, DGX OS, TensorRT-LLM, NIM, or NVIDIA’s supported multi-system playbooks. Choose the Strix Halo 128 GB desktop when x86-64, Windows-or-Linux choice, ordinary PC software, or an AMD ROCm/Vulkan path defines the job. A custom GPU tower can be the better answer when the workload fits a discrete card and replaceable components or higher-bandwidth GDDR matter more than the largest shared-memory pool.

Neither selection should be made from an unsourced speed table. The focused DGX Spark versus Strix Halo comparison separates official specifications from unmeasured performance. D-Central confirms the exact chassis, storage, operating system, lead time, warranty path, and model-fit test before a made-to-order hardware purchase.

Pre-purchase validation checklist

  1. Name the exact model repository, revision, artifact, and licence.
  2. Record the artifact’s real byte size and quantization.
  3. Select the supported runtime, operating system, driver or kernel, and framework versions.
  4. Set the real context ceiling, batch size, and concurrent-user target.
  5. Load the artifact and record memory high-water mark before claiming it fits.
  6. Run a sustained workload with the intended prompt shape and measure latency, generation rate, errors, temperature, and wall power.
  7. Document what was tested and what remains an estimate.

Buying rule: do not buy “128 GB” in the abstract. Buy a documented path for one named workload. Use the Canadian local-AI chooser, review DGX Spark versus Strix Halo, or ask D-Central for a model-fit validation tied to the exact configuration on the invoice.

Related products, repair, and setup paths

Last reviewed August 25, 2026.