How to Unlock the Full 128GB as VRAM on a Ryzen AI Max+ 395 (Strix Halo): BIOS + Linux GTT Guide

Quick answer: On a 128GB Ryzen AI Max+ 395 ("Strix Halo"), Windows caps GPU-allocatable memory at 96GB through the BIOS UMA frame buffer (set it there, then enable AMD Adrenalin's "Variable Graphics Memory"). Linux goes further: with the amdttm.pages_limit and amdttm.page_pool_size GTT kernel parameters on kernel 6.16.9 or newer, the Radeon 8060S iGPU reaches roughly 110–120GB. The counterintuitive best practice is to set the BIOS graphics allocation to its 512MB minimum and let GTT manage the pool dynamically. Convert any GB target to the page count these params need with (size_GB × 1024 × 1024) / 4.096 — 110GB is 28,160,000 pages.

Why 128GB soldered ≠ 128GB the GPU can use

This is the misconception that sends every new Strix Halo owner to a forum thread. You bought a box advertised with 128GB of unified memory, loaded a 70B model, and your inference runtime reported an out-of-memory error at ~16GB. Nothing is broken. You just hit the default carve-out.

Unified memory means the CPU and the Radeon 8060S iGPU share one physical pool of LPDDR5X — but the GPU still needs memory assigned to it before it can use it. There are two mechanisms for that assignment:

• UMA (the fixed carve-out): The BIOS reserves a static slice of RAM as a dedicated GPU frame buffer at boot. It's simple and universal, but it's fixed — whatever you set is walled off from the CPU whether the GPU uses it or not. This is the "16GB" most boxes ship with.
• GTT — Graphics Translation Table (the dynamic pool): The GPU addresses ordinary system memory on demand through the kernel's memory manager. No fixed wall; the GPU pins pages as it needs them. This is the mechanism Linux exposes to reach the highest ceilings.

If the architecture itself is new to you, our Ryzen AI Max+ 395 explainer covers what the chip is and why AMD bet on a big unified pool over a fast-but-small GPU. The short version relevant here: the silicon supports assigning most of the 128GB to the GPU — the software just has to be told to do it, and how you tell it differs sharply between Windows and Linux.

The Windows path: BIOS UMA + Adrenalin Variable Graphics Memory

Windows is the simpler path and the one most boxes ship on — the HP Z2 Mini G1a and GMKtec EVO-X2 both default to it. The ceiling here is a hard 96GB. There's no supported way past it on Windows; the AMD driver stack simply won't allocate more than 96GB of the 128GB pool to the GPU.

Two settings get you there:

1. BIOS UMA Frame Buffer. Enter your box's BIOS/UEFI and find the graphics memory setting — labeled "UMA Frame Buffer Size," "iGPU Memory," or similar. To target the full ceiling, set a large fixed carve-out. Framework's community documentation and the jdhodges Adrenalin guide both confirm the 96GB wall applies regardless of box vendor, because it's a driver-level limit, not a per-BIOS one.
2. AMD Adrenalin "Variable Graphics Memory." In the Adrenalin control panel (Performance → Tuning, on recent driver builds) there's a Variable Graphics Memory toggle that lets the GPU dynamically claim additional system RAM on top of the UMA carve-out — up to the same 96GB total. jdhodges' "How to Allocate VRAM on Strix Halo: AMD Adrenalin Guide" walks the exact toggle location.

For a business or Prime-logistics buyer who wants the box working with the least fiddling, the Windows-default HP Z2 Mini G1a (vPro, ECC, 3-year warranty) or the flagship GMKtec EVO-X2 are the natural picks — you set the UMA buffer once, flip the Adrenalin toggle, and 96GB is available. If 96GB fits your largest model (it holds a 4-bit 70B with context comfortably), Windows is genuinely the path of least resistance.

The Linux path: the GTT trick that beats Windows

This is the money section. If you want more than 96GB — or you simply want the most VRAM per dollar out of the box you already paid for — Linux is the answer, and the Framework Desktop (open firmware, standard mini-ITX board, best Linux/tinkerer story) is the box built for it.

The method comes from Jeff Geerling's write-up "Increasing the VRAM allocation on AMD AI APUs under Linux" and the technigmaai GitHub wiki's step-by-step for Ubuntu 24.04. Here's the counterintuitive core, and it trips people up every time:

"On a 128GB Ryzen AI Max+ 395 (Strix Halo), Windows caps GPU-allocatable memory at 96GB through the BIOS UMA frame buffer, but Linux — with the amdttm.pages_limit and amdttm.page_pool_size GTT kernel parameters on kernel 6.16.9 or newer — unlocks roughly 110–120GB; the counterintuitive best practice is to set the BIOS graphics allocation to its 512MB minimum and let GTT manage the pool dynamically."

Step 1 — Set the BIOS UMA to 512MB, not maximum

On Windows you raise the UMA buffer. On Linux you do the opposite: set it to the 512MB minimum. Why? Because a large fixed UMA carve-out is dead weight — it's walled off from GTT. By shrinking UMA to the floor, you hand nearly the entire 128GB pool to GTT, which then allocates dynamically. CraftRigs frames the math cleanly: a small BIOS carve-out plus GTT reaching into the pool is how you land around ~108GB usable (their "~96GB + ~12GB GTT = ~108GB" example), with well-tuned setups reaching 110–120GB.

Step 2 — Confirm kernel 6.16.9 or newer

Run uname -r. This is non-negotiable: on kernels older than 6.16.9, ROCm can report only ~15.5GB of VRAM no matter what your GTT parameters say — a documented bug discussed in the Framework community and AMD GitHub threads, fixed at 6.16.9. If you're below that floor, upgrade the kernel before touching anything else, or you'll chase a ghost.

Step 3 — Do the page-count math

The amdttm parameters take a page count, not gigabytes. Each page is 4KB, so the conversion is:

pages = (size_GB × 1024 × 1024) / 4.096

Worked examples (keep this exact — a wrong formula is worse than none):

Step 4 — Add the kernel parameters and reboot

Edit /etc/default/grub and append both parameters to GRUB_CMDLINE_LINUX_DEFAULT, using your page count from Step 3 for both values:

amdttm.pages_limit=28160000 amdttm.page_pool_size=28160000

Then rebuild the boot config and reboot:

sudo update-grub   # or grub2-mkconfig on Fedora-family distros
sudo reboot

After reboot, confirm with rocm-smi or your inference runtime's VRAM readout. You should see ~110GB available instead of the default carve-out. That's the whole trick — a 512MB BIOS floor, a modern kernel, and two kernel parameters.

How much should you actually allocate? (the safety knob)

Just because you can hand the GPU 120GB doesn't mean you should. This is a calibration knob, not a fixed number — and over-tightening it has a real cost. The tuning rule:

allocate ≈ 75% of total RAM − ~12GB OS reserve

On a 128GB box that lands you around 96–108GB for the GPU, leaving enough headroom for the OS, your inference server's own overhead, and anything else running. Push past that and you invite the failure mode that's worse than a smaller allocation: the kernel starts swapping model weights to disk. Disk is orders of magnitude slower than LPDDR5X — a model that "fits" but spills to swap will crawl far worse than one that was sized to stay resident. The right number depends on your OS overhead and background load, so start conservative (say 96GB), confirm your model loads and stays resident, then raise it if you have headroom. Treat the first boot as a measurement, not a final answer.

What the extra VRAM unlocks (model-size table)

The whole point of this exercise is fitting a bigger model. Here's the 4-bit rule of thumb that ties your allocation ceiling to what will actually load — capacity decides whether a model runs; bandwidth (a separate ~215 GB/s ceiling on this chip) decides how fast:

The headline payoff: a Strix Halo box holds a 4-bit 70B with room to spare on either OS, and the Linux GTT ceiling gives long-context and larger-MoE workloads meaningful extra headroom. For the concrete 120B walkthrough, see how to run GPT-OSS 120B locally on a mini PC. And once your model fits, the next question is speed — our real tokens-per-second breakdown explains why a dense 70B crawls at ~5 tok/s while a 30B MoE model flies at 70–100 tok/s on the same silicon. Fitting the model and racing it are two different problems; this guide solves the first, that one covers the second.

Box-by-box notes: which make this easy vs fiddly

The silicon is identical across every Strix Halo box — same Ryzen AI Max+ 395, same Radeon 8060S, same 128GB pool. What differs is BIOS UX and OS support, which is exactly what matters for this task:

• Framework Desktop — the easiest Linux/GTT box. Open firmware, standard mini-ITX board, and the best community documentation for the amdttm method. If your plan is the 110–120GB Linux route, this is the natural pick.
• GMKtec EVO-X2 — the flagship, Windows-default. Its spec sheet explicitly lists "up to 96GB GPU-allocatable," so the Windows 96GB path is turnkey; the Linux route works too but you're on your own for BIOS quirks.
• Beelink GTR9 Pro — dual 10GbE for pulling models off a fast NAS or clustering boxes. One caveat worth knowing before you commit: ServeTheHome documented 10GbE NIC instability under sustained heavy GPU load (a driver-dependent crash) — relevant precisely because a maxed-out VRAM allocation means a maxed-out GPU.
• HP Z2 Mini G1a — the business path: vPro, ECC, Windows-default, and StorageReview ran GPT-OSS 120B on it with no discrete GPU. Best for a buyer who wants the 96GB Windows path and brand-backed support over squeezing out the last few GB.
• Minisforum MS-S1 Max — enthusiast I/O (dual 10GbE, dual USB4 v2, PCIe x16, 2U-rack option). The pick if the box is going into a rack-mounted multi-box cluster where the extra Linux VRAM per node compounds.

Prices on all five have been moving with the 2026 DRAM shortage — verify the current price at the retailer before buying rather than trusting any figure you saw last week. If you're still choosing a box, our best mini PC for local LLMs guide ranks them by budget and model size, and the GMKtec EVO-X2 review covers the flagship in depth.

Cheat sheet / verdict

The whole guide, condensed to a copy-paste block:

• Linux GTT params (110GB example): amdttm.pages_limit=28160000 amdttm.page_pool_size=28160000
• Page-count formula: (size_GB × 1024 × 1024) / 4.096
• Kernel floor: 6.16.9+ (older kernels can cap ROCm at ~15.5GB)
• Safe allocation: ~75% of RAM minus ~12GB — start at 96GB, raise if headroom allows, never so high the kernel swaps to disk.

Verdict: If 96GB fits your largest model, stay on Windows — it's two settings and done. If you want every usable GB out of the box you paid a small fortune for during the DRAM spike, go Linux, drop the BIOS UMA to 512MB, add the amdttm GTT params on kernel 6.16.9+, and you'll be running around 110GB of VRAM on an iGPU — something that was science fiction two years ago.