Strix Halo显存分配实战：统一内存如何影响大模型推理性能

最近在 AMD Ryzen AI MAX+ 395（也就是 Strix Halo）这颗处理器上折腾本地大模型推理，我在 Windows 11 下把 BIOS 里的显存分配反复改了好几轮，发现一个很反直觉的现象：同一个 32B 模型，你给它分的专用显存是 16GB 还是 32GB，跑出来的速度能差两三倍，而且这个坑不是看 GPU 算力就能预测的。

这篇文章就把我这段时间的完整测试过程、BIOS 设置方法、Ollama/llama.cpp 的 offload 逻辑，以及踩过的各种坑整理出来，给已经入手或者准备入手 Ryzen AI MAX+ 395 这类统一内存平台的读者一个可以直接照抄的显存分配方案。

1. 为什么 Strix Halo 的显存分配这么关键

很多人刚拿到这台设备时想不通一个问题：明明有 128GB 统一内存，为什么还要关心"显存分配"？它不是想用多少就用多少吗？真实情况不是这样的。

1.1 一套内存通吃 CPU/GPU/NPU 的架构

Ryzen AI MAX+ 395 的核心卖点是全颗芯片共享同一片物理内存。CPU、GPU、NPU 都能访问系统里的 128GB LPDDR5X，内存控制器是 256bit 位宽，理论带宽在 256GB/s 左右。这个带宽指标放在移动平台非常夸张，因为它直接决定了本地大模型推理的吞吐上限。

传统独显笔记本是"显存归显存，内存归内存"，模型必须塞进那个固定大小的 VRAM 里，塞不下就只能扔一部分到系统内存，走 PCIe 通道来回搬运，性能断崖下跌。而 Strix Halo 没有这道墙，GPU 的内核单元理论上可以把整个 128GB 都当显存用，这是它能跑 70B 甚至 120B 级大模型的底气。

但这里有个关键前提：Windows 11 的 GPU 驱动体系并不完全认"理论上的统一内存"。操作系统和驱动仍然需要知道，到底划出多少内存作为 GPU 的"专用显存"。这块专用区域就是通过 BIOS 里的 UMA Frame Buffer Size 来决定的。

1.2 显存分配影响的不只是"能不能跑"

我在实际操作里最明显的感受是：显存分配决定了模型推理时的"主场"在哪里。

如果你把专用显存设成 16GB，然后去跑一个量化后权重就有 20GB 的 32B 模型，那么 llama.cpp 的 Vulkan 后端或者 Ollama 就没办法把全部层都加载到 GPU。推理时一部分层在 GPU 上算，一部分层退回到 CPU 用系统内存算，这两部分的通信开销非常大。实测下来，这种情况下的生成速度可能只有全 GPU 推理的三分之一甚至更低。

反过来，如果你直接把显存拉到 96GB，系统可用内存只剩 32GB，Windows 11 自身的缓存、后台服务、浏览器标签页全都变得紧巴巴。一旦出现内存提交不足，系统会疯狂写入页面文件，这时候模型推理虽然还在跑，但整体响应会卡顿，甚至出现莫名其妙的掉速。

所以显存分配对于统一内存平台来说，本质上是"给 GPU 划定一个高效率工作区间"。分配过大过小都不行，必须精确匹配你常跑的模型规格。

2. Windows 11 下显存分配机制与 BIOS 实操

2.1 先搞清楚：UMA Frame Buffer Size 到底是什么

AMD 的 BIOS 里这个选项通常叫 UMA Frame Buffer Size，有的主板上显示为 GFX Frame Buffer 或者 VRAM Size，本质上是一回事。它代表系统启动时预留给 GPU 的那一部分物理内存，Windows 设备管理器里会认成"专用 GPU 内存"。

这里要特别区分两个概念。UMA Frame Buffer Size 是"专用"部分，是驱动层面保证 GPU 以最高效率访问的区域。此外还有一块叫 GTT（Graphics Translation Table）的共享区域，GPU 也可以通过驱动访问系统剩余内存，但路径和效率不太一样，软件调用起来也更多限制。

在 Strix Halo 上，很多工具（比如 LM Studio）会同时显示"专用 VRAM"和"共享内存"两部分。如果你没有在 BIOS 里设置足够的 UMA Frame Buffer，模型可能会被塞进共享区域，虽然也能跑，但性能表现不如专用区域稳定。

2.2 操作步骤：从 BIOS 到系统确认

我手头这台设备的 BIOS 路径是这样的：开机时按 DEL 或者 F2 进入 BIOS 设置，到 Advanced 菜单下找 NBIO Configuration 或 GFX Configuration，里面会有 UMA Frame Buffer Size。一般可选 Auto、3GB、8GB、16GB、32GB、64GB、96GB、112GB 这些档位，具体取决于设备厂商是否解锁了完整选项。

选择你想要的容量，保存退出。进系统后可以用 dxdiag 命令确认，打开命令行输入dxdiag，在"显示"选项卡里查看"显示内存"和"专用视频内存"。如果你的 BIOS 设置生效了，这里会显示对应的数值。也可以装 GPU-Z 看 Dedicated Memory 一栏，更加直观。

一个我踩过的坑：改完 BIOS 后如果只是重启进入 Windows，有时显存数值没有立刻更新。建议改完 UMA 后先关机，再冷启动一次，让硬件初始化彻底走一遍。另外一定要确认 BIOS 已经刷到最新版本，老版本固件对 96GB、112GB 这种大容量分配支持并不完善。

2.3 显存分配与系统内存的动态关系

很多新人以为 128GB 内存分配 64GB 给 GPU，系统就只剩 64GB。从 Windows 任务管理器的角度确实是这样，但实际使用中还会有一个动态缓冲机制。

分配 64GB 作为专用显存后，Windows 的资源管理器里可以看到"专用 GPU 内存"是 64GB，同时"共享 GPU 内存"也有一个很大的值。这表示 GPU 仍然可以借用部分系统内存。这种机制在为 GPU 划定安全区的同时保持灵活性，但依赖驱动调度。如果跑模型时显存溢出，驱动会把部分数据切到 GTT 区域，速度就会有损失。

所以我的建议是：不要为了榨干性能盲目设 112GB，除非你确定当前要跑的模型就是那种只能靠超大显存才能装下的巨型模型。大多数情况下，64GB 已经是非常好的甜点值。

3. 本地大模型推理工具链：怎么和显存分配配合

3.1 主选工具：Ollama、LM Studio、llama.cpp

在 Windows 11 下跑本地大模型，主流选择就三个：Ollama、LM Studio，或者说直接用 llama.cpp 的命令行版本。我个人测试下来，三个工具在 Strix Halo 上的性能差距不大，因为它们底层都调用了类似的 GPU 后端。

AMD 平台在 Windows 下的 GPU 推理后端，最省心的是 Vulkan。ROCm 在 Windows 上对 RDNA 3.5 的支持比较有限，配置起来麻烦而且经常碰到驱动兼容问题。Vulkan 后端则是开箱即用，Ollama 新版直接支持，LM Studio 默认就带，llama.cpp 只需要编译时开启 Vulkan 支持。

命令行的启动方式也简单，以 llama.cpp 为例：

llama-cli -m qwen2.5-32b-q4_k_m.gguf -ngl 99 -t 8 -c 8192

这里的-ngl 99表示尽可能把所有层都 offload 到 GPU。如果你只设置-ngl 40，那剩下的层就会在 CPU 上跑，效果差距立竿见影。

3.2 一个关键概念：GPU 层数与模型 offload

大模型推理时，神经网络是一层层执行的。每一层既可以在 GPU 上计算，也可以在 CPU 上计算。如果你没设置足够的 GPU 层数，模型就会有一部分层在 GPU 上跑完，再把中间结果传回 CPU，这种跨设备数据传输是本地推理最大的性能杀手。

判断一个模型当前是否完全跑在 GPU 上，要看工具日志。Ollama 启动时会输出类似"offload 72/72 layers to GPU"这样的信息，LM Studio 也会在加载模型时显示加载了多少层到 GPU，以及总共消耗的显存。如果日志显示被卸载到 CPU 的层数不为零，就说明你的显存分配或者工具设置还有问题。

还有一个容易被忽略的占用项是 KV cache。上下文长度设得越长，KV cache 占用越多。同样一个 32B 模型，8K 上下文和 32K 上下文的显存占用能差出好几 GB。所以当你觉得显存差一点点不够用时，先砍上下文长度试试，不一定非要动 BIOS。

3.3 用"模型显存需求公式"选分配值

我给一个通用的估算方法，适合所有量化模型：模型文件大小（GB）加上 KV cache 占用，再预留 2 到 4GB 的运行缓冲。

KV cache 的估算可以通过上下文长度乘以一个经验系数来近似，不同模型的系数不太一样。简单起见，7B 级别按 2GB 预留、32B 级别按 4GB 预留、70B 级别按 8GB 预留，基本够用。

常用模型参考：

这个表只是起步参考，实际还要看你的上下文长度和 Mac 层数。但整体上，把分配值定在"模型文件大小再上一个档位"是最稳妥的做法。例如跑 32B 就设 32GB，跑 70B 就设 64GB，不要为了省内存而卡在临界点上。

4. 实测：不同显存分配下的推理性能表现

4.1 测试环境说明

我手头的设备是 Ryzen AI MAX+ 395 处理器，128GB LPDDR5X 内存，BIOS 版本和相关驱动都更新到了当时的最新版。系统主力是 Windows 11 24H2，后来也刷过 Windows 11 27H2 的预览版本。这里多说一句，27H2 目前对 Strix Halo 的驱动兼容性还不是特别稳定，如果你不是为了用新版系统的新功能，建议先留在 24H2。

测试模型选了 Qwen2.5-32B-Instruct 的 Q4_K_M 量化版本，约 20GB 文件大小，以及 Llama-3.1-70B 的 Q4_K_M 量化版本，约 42GB。推理工具用 llama.cpp 的 Vulkan 后端，上下文长度固定在 4096，采样参数保持默认。

需要说明的是，不同驱动版本和不同厂商 BIOS 对 UMA 的调度策略存在差异，我的数据只是反映我手头这台设备的表现，但整体趋势在社区里是普遍一致的。

4.2 32B 模型在不同显存分配下的表现

我先测了 Qwen2.5-32B，因为它的体积正好横跨 16GB 到 64GB 的分配区间，最能暴露问题。

把 UMA Frame Buffer 设为 16GB 时，20GB 的模型文件放不进去，日志明确显示有 30 多层被卸载回 CPU。实际生成速度大概只有 12 到 18 token/s，而且明显能感觉到每次生成一个 token 都有卡顿，CPU 占用率很高。

切到 32GB 后，模型完整 offload 到 GPU，生成速度直接跳到 50 到 58 token/s。这个提升幅度远超我预期，也从侧面说明统一内存平台最怕的不是 GPU 算力不足，而是数据被切到 CPU 路径上。

再往上调到 64GB，32B 模型的性能没有继续提升，速度依然在 55 token/s 上下波动。这说明 32GB 分配已经喂饱了 32B 模型，再多分配显存不会带来直接收益。

4.3 70B 模型：64GB 起步会更合适

70B 模型是另一个量级。我把它放进分配 64GB 的环境下测试，Llama-3.1-70B 文件约 42GB，加上 KV cache 和运行缓冲，64GB 分配刚好够用但余地不大。4K 上下文的实测速度在 18 到 22 token/s，这个速度做对话是够用的。

如果把分配调到 96GB，70B 模型跑起来更从容，因为留给 KV cache 的空间变大了，我可以把上下文长度拉到 16K 甚至 32K 而不担心内存紧张。实测 16K 上下文时速度仍然能维持在 16 到 20 token/s，整体生成更稳定，没有出现 64GB 分配时偶尔的卡顿间歇。

但 96GB 分配的代价也很明显，系统可用内存只剩约 32GB。我的浏览器、开发工具、截图软件同时开着，已经能感觉到系统响应变慢。所以 96GB 分配更适合那种"一台机器专门做推理"的场景，不适合日常杂用。

4.4 结果解读：瓶颈到底在哪里

综合这些数据，Strix Halo 的统一内存架构决定了本地推理的瓶颈基本在内存带宽上，而不是 GPU 计算单元数量。RDNA 3.5 的 40CU 在 256GB/s 的内存带宽支撑下，能稳定跑出 50 到 60 token/s 的 32B 模型表现，已经相当能打。

真正决定你能不能用爽的，是 GPU 能否连续访问那片专用显存。分配过小时，模型一部分权重需要通过 CPU 中转，这会把带宽利用率拉得很低。分配过大时，系统内存不足导致页面交换，性能同样受限。所谓"最佳显存分配"，就是模型权重加上 KV cache 后，距离分配上限还有 10% 到 20% 余量的那个档位。

我整理成一张汇总表方便对照：

5. 常见问题与排查实录

5.1 软件不显示我为 GPU 分配的显存

有读者遇到过这个情况：BIOS 里明明设置了 64GB，进系统后 LM Studio 却只显示 40GB 或者更少的专用显存。这种情况首先要确认 Windows 系统是否正确识别了 UMA 区域，用 GPU-Z 查看 Dedicated Memory 一栏。

如果 GPU-Z 显示正确但 LM Studio 显示不对，问题多半出在软件对 AMD 平台的显存查询逻辑上。这类工具在 Windows 上读取显存信息时，可能只会读取某个特定报告值，而不会把所有 UMA 区域算进去。解决办法是看日志，LM Studio 加载模型时会打印模型层数和每层占用的显存，以日志为准。

另外，某些主板厂商会在 BIOS 里多一个"UMA Version"或者"GFX Table Version"选项，默认 Auto。我建议不要手动改，Auto 通常对应的报告方式最兼容。

5.2 推理中途崩溃或提示内存不足

这类问题我遇到最多的是在 64GB 分配下跑超长上下文。模型本身占 42GB，上下文拉到 32K 之后，KV cache 额外吃掉了十几 GB，这时候专用显存不够，llama.cpp 尝试通过共享内存继续分配，最终导致 buffer allocation 失败。

解决办法有两个。一是改工具参数，限制上下文长度。llama.cpp 里直接改-c 8192，Ollama 可以通过环境变量或模型设置控制num_ctx。另外也可以开启模型的量化 KV cache 功能，不少 GGUF 模型支持 KV cache 量化，显存占用能压缩一半左右。

还有一个容易被忽略的点：Windows 11 的桌面合成器 DWM 会占用一部分 GPU 资源。如果你开着高分辨率显示器加多屏扩展，DWM 可能分走几百 MB 到 1GB 的专用显存，在临界状态下这 1GB 可能就是压垮模型加载的最后一根稻草。

5.3 WSL2、Hyper-V、Docker 对显存分配的影响

很多人在 Windows 11 上装了 WSL2、Docker Desktop 或者 Hyper-V，用来跑 Linux 环境下的 AI 工具链，结果发现 GPU 推理性能变化很大。这是因为开启虚拟化平台后，Windows 的 GPU 调度会多一层虚拟化分区，同一时间 GPU 既要服务主机显示和推理，又要分配给虚拟机的图形调用。

在 Strix Halo 上，我建议纯推理场景用 Windows 原生工具就好，没必要开 WSL2 绕一圈。尤其当你只是想跑 Ollama 或 LM Studio 时，Vulkan 后端在 Windows 原生环境下的支持已经足够好。

如果你确确实实要跑 Linux 生态下的工具，比如某些只支持 ROCm 的框架，那再开启 WSL2 并安装对应的环境。此时要注意分配显存后，虚拟机和主机各自能看到的内存容量会互相挤压，尽量避免同时在 Windows 主机跑大模型和开虚拟机。

5.4 驱动与 BIOS 版本对 UMA 设置的坑

AMD Adrenalin 驱动的更新频率不低，但每次更新后我都会检查一下 UMA 设置是否仍然生效。有过一两次驱动更新后，Windows 报告的内存数值出现偏差，重启后恢复正常。这不是大问题，但如果遇到推理性能突然变化，先排查驱动版本。

BIOS 更新更要谨慎。一些厂商会在新 BIOS 里调整 UMA 选项的默认值，甚至更新后重置为 Auto。比如机械革命这类更激进的小厂设备，新 BIOS 可能加入 112GB 档位，也可能在更新后丢失自定义设置。所以升级 BIOS 后，第一件事就是回到 NBIO Configuration 重新检查一遍。

Windows 11 27H2 预览版用户还需要注意，新版系统对 WDDM 和内存报告机制有调整，某些版本下 112GB 分配不能被正确识别。如果遇到这种问题，先退回 24H2 或者等待厂商固件更新，不要在这上面浪费时间。

5.5 关于 WSL 安装、Docker Desktop 和 Hyper-V 的热门搜索词

写到这里，我顺手看了一下后台的搜索词，发现不少人在搜"Windows 11 安装 WSL"、"Windows 11 安装 Docker Desktop"、"Windows 11 安装 Hyper-V"这类关键词。这和本地大模型推理确实有关系，因为很多 AI 工具链的安装教程都是基于 Linux 容器写的，新手很容易被引导去装 Docker Desktop 或者 WSL2。

我的看法是：在 Strix Halo 设备上，如果你只是跑 GGUF 模型，可以完全绕开 Docker 和 WSL。Windows 原生版的 Ollama 和 LM Studio 已经是"双击即用"的程度，没必要为了跑一个模型去折腾虚拟机层。只有当你需要跑 SD WebUI 里某些 Linux 专属的 ROCm 优化、或者想用 vLLM / SGLang 这类服务化框架时，才值得投入时间配置 WSL2 + Docker 环境。

补充一点，如果你真的要在 Windows 11 上装 WSL2，顺便把 Windows 的"Hyper-V"和"虚拟机平台"功能打开，这会显著影响 GPU 的可用显存分配。建议安装完成后重新启动一次，确保虚拟化层完全初始化。

6. 避坑指南与最终设置建议

6.1 我的最终推荐配置

综合我跑过的模型和使用场景，给出一套直接照抄的配置方案。

日常混合使用（办公 + 偶尔跑 7B 到 13B 模型）：UMA 设 16GB。系统可用内存很充足，浏览器和 Office 都不受影响，7B 模型完全跑在 GPU 上没问题。

纯 32B 模型爱好者（Qwen2.5-32B、GLM-4-32B 等）：UMA 设 32GB。这个档位是最均衡的，系统剩余 96GB 给日常程序，GPU 又能吃满 32B 模型。

70B 模型玩家（Llama-3.1-70B、Qwen2.5-72B 等）：UMA 设 64GB。能完整跑 70B 的 Q4 量化，还留了十几 GB 给 KV cache，系统内存也还剩一半，算是甜点。

巨型模型党（123B、MoE 类大模型）：UMA 设 96GB 或 112GB。这已经是极限场景，建议整机只做推理，不要同时开一堆乱七八糟的程序，否则很容易触发系统内存不足。

6.2 几个比显存分配更重要的细节

第一，插电状态。LPDDR5X 在电池供电和插电模式下内存频率表现完全不同，跑大模型一定要插电。

第二，散热。Strix Halo 的 CPU 和 GPU 共享散热模块，如果你跑 70B 模型时 CPU 和 GPU 同时高负载，温度上来后两者都会降频，推理速度可能从 20 token/s 掉到 12 token/s。有条件的话开高性能电源计划，并用笔记本支架或者风扇辅助散热。

第三，确认内存频率。在 BIOS 里看 LPDDR5X 内存是否运行在 8000MT/s 这个标称频率上。有些设备开箱默认跑在较低频率，需要手动开启 EXPO/DOCP 或者等效的内存超频档位，否则带宽无法吃满。

6.3 写在最后

我实际用下来的体会是，Strix Halo 这台机器天生就是为本地大模型推理准备的跑分选手，但前提是你要理解并且手动控制它的显存分配策略。统一内存不是无所不能，它更像是一个需要精准调校的蓄水池，放太多水会淹了系统，放太少又喂不饱 GPU。

如果你刚拿到设备，我建议从 Auto 开始，跑一个自己常用的模型，看日志里 offload 了多少层。如果出现了 CPU 卸载层，再逐步上调用 UMA 档位，直到模型能完整加载到 GPU。这个逐级试探的过程，比任何"推荐配置"都更符合你自己的实际需求。