Strix Halo 128 GB Local AI Desktop in Canada (Ryzen AI Max+ 395)

This page has a deliberately narrow job. It does not repeat the DGX Spark comparison, resolve the separate Ryzen AI Halo naming question, or replace a written product order. It explains what remains constant across Ryzen AI Max+ 395 systems, what changes with the system vendor, how Windows and Linux support differ, and what a Canadian buyer should settle before configuration begins.

Start with the processor boundary

“Strix Halo” is the commonly used platform name for AMD Ryzen AI Max 300-series processors that combine Zen 5 CPU cores, RDNA 3.5 integrated graphics and a large shared-memory interface. AMD’s official Ryzen AI Max+ 395 specification lists 16 CPU cores, 32 threads, x86-64 architecture and Radeon 8060S graphics with 40 graphics cores. It also lists a 256-bit LPDDR5x-8000 memory interface and a maximum supported memory capacity of 128 GB.

Those processor-level facts travel with a correctly identified Ryzen AI Max+ 395 system. They do not define the whole computer. AMD’s processor page lists capabilities exposed by the platform, but the system vendor decides which display outputs, USB ports, network controllers, storage devices and firmware controls appear in a particular machine. Cooling also matters because the processor can be configured across a range of power targets. A specification attached to one vendor’s computer must not be copied onto another chassis simply because both use the same AMD processor.

The 128 GB configuration is also physically integrated. LPDDR5x is not a set of desktop DIMMs that D-Central can upgrade after purchase, and the Radeon 8060S is integrated graphics rather than a removable graphics card. A buyer who expects future memory replacement, PCIe accelerator expansion or a standard ATX service model should consider a custom discrete-GPU inference rig instead. This is an architecture boundary, not a defect in the platform.

Processor facts versus system-vendor facts

Question	Source of truth	What must be confirmed
CPU and integrated GPU	AMD Ryzen AI Max+ 395 documentation	Correct processor identity and Radeon 8060S graphics
Installed memory	System configuration plus firmware/OS inspection	128 GB LPDDR5x installed; shared-memory policy documented separately
Storage	Named system-vendor configuration	Drive model or class, usable capacity, encryption and expansion path
Ports and networking	Named chassis documentation	Exact USB, display, Ethernet and wireless interfaces needed on site
Power and cooling	Named chassis and adapter documentation	Included adapter, input requirements, firmware power modes and suitable room conditions
Operating system	System-vendor support plus AMD’s current software matrices	Windows 11 or a qualifying Linux release, license and recovery method
AI runtime	Runtime project and AMD compatibility documentation	Exact version, backend, model format and validation task

This separation protects the buyer from an increasingly common category error: treating a processor specification, an OEM specification and an integrator’s service description as one document. AMD deserves credit for the silicon and ROCm ecosystem. The system vendor deserves credit for the computer surrounding it. Ollama, llama.cpp, vLLM and other projects deserve credit for their runtimes. D-Central is responsible for accurately identifying the sourced system and completing only the setup written into the order.

How shared memory works on Ryzen AI Max

The installed 128 GB is one physical system-memory pool used by the CPU, operating system, applications and integrated GPU. It is not 128 GB of dedicated GDDR. AMD’s RDNA 3.5 system-optimization documentation explains that these APUs use GPU Virtual Memory, or GPUVM, with a virtual address space for each process. GART and GTT describe mapping limits and uses; they are not separate physical memory chips.

That distinction matters when reading a task manager, firmware menu or runtime log. Terms such as dedicated GPU memory, VRAM reservation, carve-out and GTT limit may appear to describe the same thing, but they control different views or mappings of a shared pool. Reserving more memory in firmware can make less memory available to the operating system. A large dynamic mapping can give an AI process access to more system memory without permanently reserving all of it. Neither setting makes LPDDR5x behave like discrete high-bandwidth GDDR.

Model fit therefore needs a budget. Start with the actual weight files, then allow space for the runtime, context and KV cache, temporary buffers, the operating system and simultaneous requests. “128 GB installed” is not “128 GB free for one model.” Quantization changes the weight footprint but can also change model quality and backend support. For a fuller capacity explanation, use VRAM versus unified memory for local LLMs.

Linux shared-memory configuration

AMD’s current Ryzen Software for Linux installation guide says ROCm uses a shared system-memory pool and configures the usable amount to approximately half of system memory by default. AMD recommends keeping the minimum dedicated memory reservation in firmware small and adjusting the Linux Translation Table Manager limit when a workload needs a larger GPU-accessible mapping. The documented amd-ttm helper reports and changes that limit, with a reboot required after a change.

D-Central does not apply a maximum-looking number by reflex. The requested model, expected context and other services on the machine determine the target. A system also needs headroom for the kernel, desktop or server processes, model transfer and failure recovery. The handoff should record the firmware reservation, effective TTM/GTT limit and the command used to verify it. That creates a reproducible configuration instead of a screenshot with an unexplained “VRAM” value.

Kernel level is part of the support boundary. AMD’s RDNA 3.5 documentation identifies minimum Linux kernel requirements for gfx1151 queue creation and memory checks. The current ROCm compatibility matrix must be read together with the selected distribution’s kernel. “Ubuntu” by itself is not a complete compatibility statement.

Windows memory configuration is a different path

Windows exposes shared-memory and Variable Graphics Memory controls through the system firmware and AMD driver path rather than Linux TTM settings. The available controls can differ by system vendor and firmware revision. AMD has documented expanded VGM use on 128 GB Ryzen AI Max+ 395 systems, but that does not prove that every chassis exposes the same menu or that every runtime uses the allocation in the same way.

The order confirmation should therefore state whether Windows is required, which firmware memory control is present, which driver branch is targeted and what value D-Central will validate. A Windows deployment should be chosen because the required application and backend have a documented Windows route—not merely because the processor supports Windows. Linux commands, ROCm containers and native Linux serving instructions cannot be copied into Windows and called equivalent.

Windows and Linux support matrix

ROCm changes quickly, so this is an orientation matrix rather than a permanent promise. At the 25 August 2026 review, AMD’s current Ryzen compatibility documentation lists gfx1151 Ryzen AI Max+ 395 support on both Linux and Windows, but the supported scope is not symmetrical.

Deployment question	Windows 11 path	Linux path
Official processor OS family	AMD lists Windows 11 64-bit	AMD lists Ubuntu and RHEL x86-64; the current ROCm matrix narrows the validated release
Current ROCm/PyTorch scope	AMD’s Windows matrix lists PyTorch on Windows for gfx1151, while warning that the entire ROCm stack is not supported	AMD’s Linux matrix identifies the validated Ubuntu, ROCm, Python, PyTorch and data-type combination
ROCm tools and containers	Do not assume parity with Linux; check each component	Broader native ROCm path, subject to the exact matrix and kernel requirements
llama.cpp/Ollama-style local inference	Use a documented Windows AMD or Vulkan build	Use a documented ROCm/HIP or Vulkan build appropriate to the release
vLLM serving	Not a native Windows target in vLLM’s official installation path	Use a supported ROCm Linux combination and validate the exact model
Shared-memory tuning	Firmware/driver VGM controls; capabilities depend on the named system	Firmware reservation plus documented TTM/GTT configuration
Best fit	Daily-driver and Windows application requirements with a verified inference backend	ROCm development, containers and Linux-native serving where the current matrix supports the workload

AMD’s Ryzen limitations page is as important as the compatibility table. At review time it states that Windows supports PyTorch rather than the entire ROCm stack and lists additional version and feature limitations. On Linux, AMD also records known workload issues. “Supported hardware” is the beginning of due diligence, not proof that an arbitrary framework, extension or model is production-ready.

Select the backend before selecting the operating system

Write down the application and model first. If a deployment depends on CUDA, TensorRT or an NVIDIA-only container, Strix Halo is the wrong accelerator regardless of memory capacity. If the model server is vLLM, native Linux and a supported ROCm combination are the practical starting point. If the goal is a private desktop interface on Windows, an Ollama, llama.cpp, LM Studio or other documented AMD/Vulkan path may fit better. Our CUDA versus ROCm versus Vulkan guide separates these backend choices.

Then specify the exact model repository or file, quantization, context, expected simultaneous users and interface. Model licenses remain the buyer’s responsibility. Some repositories require authentication or acceptance before files can be staged. An offline deployment needs a transfer method for drivers, packages, containers and model files; “offline” is an operational design, not a checkbox that appears after setup.

No universal throughput result belongs on this page. Prompt length, generated length, quantization, runtime build, kernels, context, batching, concurrency, memory mapping and power mode can all change measured performance. A number measured on one chassis, driver and model file cannot be presented as a platform-wide fact. When performance is a purchasing condition, define a reproducible acceptance test in the order.

Canadian sourcing without chassis ambiguity

A Canadian order should name one actual computer, not “Strix Halo or equivalent.” D-Central confirms the system vendor, model or configuration identifier, processor, installed memory, storage, ports, networking, power adapter and included operating-system entitlement before sourcing is committed. If any material element changes, the buyer should receive a revised written envelope and approve it before work proceeds.

This guide intentionally does not name a current chassis. The same Ryzen AI Max+ 395 and 128 GB memory target can appear in systems with materially different I/O, cooling, firmware and storage. Publishing one system’s attributes as the permanent definition of “Strix Halo Canada” would make this guide wrong as soon as another vendor configuration is selected. The exact deliverable belongs in the transactional PDP and order confirmation.

Decision table: is this platform aligned with the job?

If this is the requirement	Orientation	Confirm before proceeding
128 GB shared-memory x86 desktop	Strong architectural match	Installed memory, firmware mapping controls and model memory budget
Windows daily-driver plus local inference	Potential match	Exact Windows backend, driver, model format and unsupported ROCm components
Linux ROCm development or serving	Potential match	Current gfx1151 matrix, distribution, kernel, framework and data type
CUDA-only application	Not a match	Use an NVIDIA architecture; compare in the hardware pillar
Replaceable GPU or memory	Not the intended architecture	Use a serviceable discrete-GPU tower
Air-gapped local assistant	Possible with planning	Dependency and model transfer, authentication, update and backup procedures
Measured multi-user service target	Requires explicit validation	Model, prompt/context method, concurrency, runtime version and pass/fail test

Order-confirmation envelope

Before payment commits a configured system, the written record should answer every item below:

• Hardware identity: system vendor, model/configuration identifier, Ryzen AI Max+ 395, Radeon 8060S and 128 GB installed LPDDR5x.
• System configuration: storage, ports, networking, power adapter, included accessories and physical form factor.
• Operating system: Windows 11 or exact Linux distribution/release, license responsibility, recovery method and update starting point.
• Shared memory: firmware reservation, Windows VGM or Linux TTM/GTT target, and how the effective value will be recorded.
• Inference scope: runtime/backend, private interface, exact test model, model-file responsibility and online/offline policy.
• Acceptance: what D-Central will demonstrate at handoff and any explicitly defined application or performance test.
• Commercial boundary: price, applicable taxes, shipping, payment trigger, return status and any separately scoped integration.

If an item is absent, do not infer it from a photograph, another vendor’s specification or a processor page. Ask for it to be added. The current D-Central Return and Refund Policy and the written order govern returns; this deployment guide does not create separate commercial terms.

Deployment checklist

1. Identify the workload: record the model file, quantization, context, concurrency, runtime and license.
2. Choose the OS from the support matrix: validate the application’s documented Windows or Linux backend before deciding.
3. Confirm the computer: record the exact system configuration and compare its ports, power and network interfaces with the site.
4. Set the memory boundary: document the firmware reservation and Windows VGM or Linux TTM/GTT configuration while leaving operating headroom.
5. Install the agreed stack: pin the driver, runtime and interface versions rather than mixing instructions from unrelated releases.
6. Validate reproducibly: launch the agreed model and record what was tested. Do not substitute a smaller or unrelated model for an acceptance requirement.
7. Harden the handoff: set credentials, network exposure, update ownership, backups and an offline transfer process where required.

For the practical software handoff, continue to first boot with Ollama and a private interface. For the broader hardware decision, use the Canadian local AI computer decision pillar and the local AI hardware guide.

Strix Halo 128 GB Canada FAQ

Is Strix Halo one specific desktop model?

No. It is a platform name associated with AMD Ryzen AI Max 300-series processors. This guide focuses on systems using Ryzen AI Max+ 395 with 128 GB installed memory. The order must separately identify the system vendor, configuration, storage, ports, cooling and firmware.

Does 128 GB mean the GPU can use all 128 GB?

No. The CPU, operating system and applications share the physical memory. GPUVM, firmware reservations and operating-system mapping limits determine how GPU processes can address it. The effective configuration needs headroom and should be recorded at handoff.

Should I run Windows or Linux?

Choose from the required software. Windows fits Windows applications and backends documented for Windows. Linux offers the broader native ROCm and serving path, but the exact distribution, kernel and framework must match AMD’s current matrix. There is no automatic parity.

Can I use CUDA or TensorRT on Radeon 8060S?

Not as the native AMD acceleration path. CUDA and TensorRT are NVIDIA technologies. Use software with documented ROCm, HIP, Vulkan or CPU support, or choose an NVIDIA system when the application requires CUDA.

Why not publish one permanent chassis specification?

Because storage, ports, network interfaces, cooling, adapter and firmware are system-vendor properties. Copying one configuration onto every Ryzen AI Max+ 395 computer would be inaccurate. D-Central identifies the actual computer in the transaction record.

Can D-Central configure an offline system?

An offline handoff can be scoped. The order must define how drivers, dependencies, containers and licensed model files are transferred, how users authenticate and who owns future updates. Third-party license and activation requirements still apply.

What should I send before asking for configuration?

Send the exact model or repository, quantization, context target, simultaneous-user target, preferred runtime, required OS applications, online/offline policy, storage needs, network environment and any reproducible acceptance test. Those inputs are more useful than a parameter count alone.

Sources and review: AMD Ryzen AI Max+ 395 specification and Windows VGM documentation; AMD ROCm RDNA 3.5 GPUVM and system optimization, Linux installation and shared-memory configuration, Linux support matrix, Windows support matrix and Ryzen limitations. Reviewed 25 August 2026. Because software support changes, recheck the current matrices for the exact deployment.