最近在 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系统可用内存只剩 32GBWindows 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 以最高效率访问的区域。此外还有一块叫 GTTGraphics 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 预留基本够用。常用模型参考模型规格常见量化文件大小建议显存分配7BQ4_K_M约 4.5GB8GB 至 16GB13BQ4_K_M约 8GB16GB32BQ4_K_M约 20GB32GB70BQ4_K_M约 42GB64GB123BQ4_K_M约 73GB96GB 或 112GB这个表只是起步参考实际还要看你的上下文长度和 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 路径上。再往上调到 64GB32B 模型的性能没有继续提升速度依然在 55 token/s 上下波动。这说明 32GB 分配已经喂饱了 32B 模型再多分配显存不会带来直接收益。4.3 70B 模型64GB 起步会更合适70B 模型是另一个量级。我把它放进分配 64GB 的环境下测试Llama-3.1-70B 文件约 42GB加上 KV cache 和运行缓冲64GB 分配刚好够用但余地不大。4K 上下文的实测速度在 18 到 22 token/s这个速度做对话是够用的。如果把分配调到 96GB70B 模型跑起来更从容因为留给 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% 余量的那个档位。我整理成一张汇总表方便对照UMA 分配32B Q4 速度70B Q4 速度系统可用适合场景16GB12 至 18 tok/s无法完整加载112GB轻量模型、日常使用32GB50 至 58 tok/s无法完整加载96GB32B 以下模型主力档64GB约 55 tok/s18 至 22 tok/s64GB70B 模型甜点档96GB约 55 tok/s16 至 20 tok/s长上下文更稳32GB120B/DeepSeek-R1 大模型专用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 8192Ollama 可以通过环境变量或模型设置控制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。这个逐级试探的过程比任何推荐配置都更符合你自己的实际需求。