把AMD Ryzen AI MAX+ 395这套平台翻来覆去测了将近一个月，折腾最多的就是Windows 11底下的显存分配问题。这机器跟传统PC有个本质区别——CPU和GPU共享一整块内存，理论上你拨96GB给显卡当显存用都行，这在以前的笔记本和迷你主机上根本不敢想。玩本地大模型的人应该都清楚，显存就是硬通货，模型参数、KV Cache全得往里塞，显存不够，哪怕CPU再强也只能看个寂寞。NVIDIA那边大显存卡的价格能劝退一大半玩家，而Ryzen AI MAX+ 395这种统一内存方案，确实把门槛砸低了不少。
这篇文章想记录的东西其实很聚焦：同一台128GB内存的Ryzen AI MAX+ 395机器，在Windows 11下把BIOS里的显存分配分别设成6GB、16GB、32GB、96GB，跑一组常见的本地大模型，看看加载能力、生成速度到底差多少。同时把显存分配背后的原理、BIOS设置步骤、实测数据和踩过的坑一并说清楚。适合手上有这台机器、或者正在纠结要不要入手这类大内存APU设备的本地AI玩家、程序开发者和硬件爱好者参考。
1. 统一内存与本地大模型的适配逻辑
1.1 为什么大显存是本地大模型的硬门槛
本地大模型的加载逻辑其实没有太多神秘感：模型权重必须完整放进显存，推理的时候GPU才能按需读取。拿目前主流的一些量化模型来算笔账，Llama 3.1 8B用Q4_K_M量化，权重大概4.5GB到5GB；Qwen2.5 14B量化后大约8.5GB到9GB；Qwen2.5 32B量化后接近20GB；Llama 3.3 70B量化后更是冲到40GB上下。这还只是权重本身，还没算KV Cache，上下文一拉长，几个GB的显存又被吃掉了。
所以你会发现一个尴尬的事实：NVIDIA的RTX 4060、RTX 5060这种主流卡，显存只有8GB到16GB，跑7B、8B的小模型绰绰有余，但想碰32B以上的模型就是痴人说梦。要么加钱上48GB、96GB的专业卡，要么走多卡并行、模型切片之类的复杂路线，成本和折腾程度都不是普通玩家愿意承担的。本地模型社区里，大家最核心的需求始终是“在预算范围内搞到更大的可用显存”。
Ryzen AI MAX+ 395正好卡在这个需求点上。它的统一内存架构允许GPU借用大容量系统内存当显存，内存插满128GB的版本，理论上可以划走96GB给GPU。这个显存规模已经超过了市面上绝大多数消费级显卡，也是很多人盯上它的根本原因。跑大模型的第一道门槛是“装不装得下”，这机器至少把容量门槛大幅向下拉了。
1.2 Ryzen AI MAX+ 395 的硬件底子与瓶颈
简单过一遍硬件底子。Ryzen AI MAX+ 395用的是Zen 5架构，16核32线程，集成显卡是Radeon 8060S，40个RDNA 3.5 CU单元，从纸面规格看图形性能相当于一块中端独显。但真正让它在一众APU里脱颖而出的，是内存子系统：LPDDR5X-8000，256-bit位宽，最高支持128GB容量，理论带宽大概256GB/s。
这个带宽数据需要特别拎出来讲。NVIDIA RTX 4090的显存带宽超过1TB/s，RTX 3060也有360GB/s，而Ryzen AI MAX+ 395只有约256GB/s，比很多独立显卡都低。但它赢在容量上，一个能放70B模型的“超大仓库”，配合256GB/s的“传送带”,这在本地大模型场景下是能接受的组合。
打个不严谨但好理解的比方：显存大小是仓库面积，内存带宽是仓库和加工车间之间的传送带速度。独显是“仓库小但传送带飞快的车间”，Ryzen AI MAX+ 395则是“仓库极大但传送带中等偏上”。你能把70B模型这个庞然大物放进仓库，但每秒钟从仓库搬出来的货是有限度的，这个限度最终决定了token生成速度的上限。
1.3 显存分配到底在分配什么
在深入实测之前，必须先搞明白Windows 11下“显存分配”这个动作的实际含义。对Ryzen AI MAX+ 395这类APU来说，BIOS里有个很关键的选项，通常叫UMA Frame Buffer Size，也有厂商叫Dedicated Graphics Memory或者VRAM Allocation。设置这个值，本质上是告诉系统：我从物理内存里固定保留多大一块区域，专供GPU使用。
这块被保留的内存，进入Windows之后会显示成GPU的“专用GPU内存”。比如你在BIOS里分配了16GB，那么任务管理器里Radeon 8060S这一项通常就会显示专用GPU内存为16GB，而系统总可用内存会相应减少约16GB。这一点和NVIDIA独显的逻辑完全不同，独显的显存是物理独立的，怎么分配都不影响系统内存；而APU是“同一个池子，你多舀一瓢，系统就少一瓢”。
还有一个容易忽略的细节。在统一内存架构下，即使专用GPU内存用完了，驱动通常还会允许GPU去申请“共享GPU内存”，也就是临时借用剩余的系统内存。这部分内存在WDDM驱动模型下是可以用的，但它的性能和稳定性远不如固定保留的专用内存，在大模型这种持续高强度读写的场景里，一旦模型权重被挤到共享内存区域，速度下降会非常明显，甚至直接卡死。这也是为什么“显存分配够不够”会直接影响能不能流畅跑模型，而不是只看总内存容量。
2. Windows 11下的显存分配实操设置
2.1 第一步：找到BIOS入口与分配选项
不同品牌的Ryzen AI MAX+ 395设备，BIOS界面和菜单路径会有差异，但大方向是一致的。我这台机器用的是迷你主机形态，开机按Del键进BIOS，在Advanced或者Chipset菜单下找到NB Configuration（北桥配置），里面就有UMA Frame Buffer Size这个选项。如果你的是笔记本或者另一种品牌的迷你主机，入口可能叫GFX Configuration、Memory Configuration或者Display Configuration，耐心翻一翻Advanced菜单，基本都能找到。
有个经验之谈，某些厂商的BIOS默认是简易模式，UMA Frame Buffer这类高级选项被藏起来了。这时候需要先切换到高级模式，通常是按F7或者右上角有切换按钮。还有些机器更狠，把高级内存设置藏得很深，需要同时按住特定组合键，比如某些型号在BIOS首页按Ctrl+Shift+F1之类。如果找不到，优先去官网看有没有对应机型的BIOS高级菜单解锁说明，或者问问同型号机友。
2.2 分档逻辑：不同模型该配多大显存
找到了选项之后，接下来就是选多大。Ryzen AI MAX+ 395的BIOS选项一般覆盖3GB、6GB、8GB、16GB、32GB、48GB、64GB以及96GB这些档位，部分机器还有AUTO档。我的建议是：不要依赖AUTO，手动指定更靠谱，因为AUTO在某些固件版本下会给出非常保守的值，导致大模型加载失败。
按照实际模型需求来分档，大致逻辑如下。
| 目标模型场景 | 建议显存分配 | 说明 |
|---|---|---|
| 只跑7B~8B量化模型 | 16GB | 权重约5GB，剩余留给KV Cache |
| 跑14B量化模型 | 32GB | 权重约9GB，长上下文需要额外空间 |
| 跑32B量化模型 | 48GB~64GB | 权重约20GB，推荐64GB更从容 |
| 跑70B量化模型 | 96GB | 权重约40GB，只有大分配才能容纳 |
| 日常办公+偶尔跑模型 | 32GB | 兼顾系统内存与模型运行 |
这个表格不是绝对的，但方向是对的。大模型推理不能只看权重体积，上下文长度、批量大小、框架本身的显存开销都要算进去。保守起见，我会在模型权重大小基础上再留至少4GB到8GB的余量，这样长上下文的时候不容易OOM。另外还要考虑操作系统本身，Windows 11加浏览器加开发工具，日常占用轻松超过8GB，分配完显存之后如果系统内存只剩十几GB，体验会非常难受。
2.3 验证与避坑：改完不生效怎么办
BIOS里设置完毕，保存退出，进入Windows之后不要急着开跑，先验证一下分配是否真的生效。最快的办法是打开任务管理器，切到“性能”标签，点GPU那一项，查看“专用GPU内存”这一栏，如果显示的数字和你BIOS里设置的一致，那就说明系统已经识别到了。另外一个验证途径是运行dxdiag，在“显示”选项卡里能看到“显示内存”和“共享内存”，前者基本对应专用显存。
这里有个特别容易踩的坑：在某些主板上，改了UMA Frame Buffer之后如果只是点“重启”，内存控制器可能没有完全重新初始化，进系统后会发现显存分配没变，还是老样子。解决方案是：改完BIOS设置，保存退出，先把机器完全关机，等几秒，再开机。第一次开机时内存training可能比较慢，显示器黑屏时间长一点是正常的，千万别中途强行断电。另外，如果你用的是独立显卡副卡或者老版本驱动，Windows对APU显存的识别也可能出现延迟，建议装最新版AMD显卡驱动再验证。
3. 实测：不同显存分配档位的推理性能对比
3.1 测试环境与模型清单
为了控制变量，整个测试全程在同一个系统环境里完成。平台是128GB内存版本的Ryzen AI MAX+ 395迷你主机，系统为Windows 11 24H2，显卡驱动更新到AMD官网提供的最新版本。推理框架以Ollama for Windows的DirectML后端为主，个别模型用llama.cpp的Vulkan版本复测过，避免单一框架的调度差异干扰结论。
测试模型选了四个档位，覆盖从轻到重：Llama 3.1 8B Q4_K_M、Qwen2.5 14B Q4_K_M、Qwen2.5 32B Q4_K_M、Llama 3.3 70B Q4_K_M。上下文长度统一设置为4096，关闭流式输出之外的额外功能，每个模型跑一轮固定的中文问答，取稳定后的生成速度。这里不看首token时间，重点看稳定生成期的tok/s，因为那才是长文本生成时用户真正感知到的速度。每档显存分配下，我都让系统重启后静置两分钟再测试，把后台干扰降到最低。
3.2 四档分配的实测数据
整理一下四档分配下的实测结果。
| 显存分配 | 8B Q4模型 | 14B Q4模型 | 32B Q4模型 | 70B Q4模型 |
|---|---|---|---|---|
| 6GB | 可运行，约30~35 tok/s | 加载失败，OOM | 加载失败 | 加载失败 |
| 16GB | 约52~56 tok/s | 约26~28 tok/s | 加载失败 | 加载失败 |
| 32GB | 约53~56 tok/s | 约27~29 tok/s | 约13~15 tok/s | 加载失败 |
| 96GB | 约53~56 tok/s | 约27~29 tok/s | 约14~15 tok/s | 约4.8~5.5 tok/s |
这里面最值得聊的有两点。第一，6GB分配档位下，8B模型虽然勉强能跑，但速度比16GB档位明显慢了一截，而且生成过程中GPU占用率波动很大，这就是前面提到的模型有一部分被挤到了共享内存区域，GPU要跨过驱动层去读写那些未固定保留的内存，效率自然下降。第二，16GB档位和32GB档位在跑8B、14B模型时，速度几乎没有区别。这充分说明在显存容量够用的情况下，再加大分配并不会带来额外速度提升。
还有一点，70B Q4模型在96GB分配下大约只能跑到4.8到5.5 tok/s，这个速度放在NVIDIA高端卡上确实不够看，但在本地设备上能稳定跑完全文不报错，已经是很强的实用性了。如果你愿意把上下文缩短、或者换GTPQ等更激进的量化方式，速度还能再往上提一点，但这是另一个话题了。
3.3 性能瓶颈解剖：分配容量与带宽的关系
为什么会出现“够用之后加量不加价”？这要从推理的物理过程找答案。自回归生成时，模型每生成一个token，都需要把权重从头到尾读一遍。假设一个Q4量化模型的权重是20GB，内存带宽是256GB/s，那么理论上每秒最多只能全量读取12.8次，对应token生成速度上限大约就是12.8 tok/s。实际还要考虑KV Cache读写、算子调度、访存效率损耗，所以实测值低于理论值很正常。
由此可以推出一个很实用的公式感认知：token生成速度约等于内存带宽除以模型权重体积，再乘一个七八折的损耗系数。8B模型权重约5GB，256除以5约等于51，再打点折正好落在实测的50多tok/s；32B模型权重约20GB，256除以20约等于12.8，实测13到15tok/s，已经很接近上限；70B模型权重约40GB，理论上限是6.4tok/s，实测能到5左右，说明走了不少针对性的访存优化。理解了这条规律，就不会再纠结“把显存从32G调到96G会不会让32B模型变快”这种问题了。
真正能影响生成速度的变量是模型量化等级、上下文长度和推理框架的算子优化，而不是你已经给足了容量的显存分配。显存分配更像一个开关，分配小了直接给你断电，分配够了它就退居幕后，剩下交给带宽和模型大小去决定。
4. 推理框架选型与Windows 11环境配置
4.1 Windows原生方案：Ollama与LM Studio
对于不想折腾环境的普通用户，我强烈建议从Ollama for Windows或者LM Studio起步。Ollama在Windows下有原生安装包，装完之后底层会自动走DirectML路径，能够直接识别AMD的GPU。它的一大优势是命令行体验顺畅，模型下载、加载、API调用一步到位，很多开发工具也直接跟它的API对接。LM Studio则更适合喜欢图形界面的用户，模型管理、参数调节、聊天窗口都在一个界面里搞定，底层可以用Vulkan或者OpenCL，对Radeon显卡的兼容性也不错。
不过Windows原生方案也有它的短板。DirectML路径相比CUDA或者ROCm，在算子覆盖面和极端性能优化上还是有差距，尤其是在大模型推理这种算子相对集中的场景下，差距可能表现为几个百分点的速度损失，但多数情况下感知不明显。另外Windows原生方案对显存的管理相对“黑盒”，你不太容易精确控制模型权重和KV Cache分别落在哪块内存上，好在大部分情况下它会优先使用专用GPU内存，行为已经足够稳定。
4.2 WSL2 + ROCm方案
如果你不只是跑聊天模型，还想用PyTorch跑一些微调脚本、或者部署vLLM这类重型推理框架，那么WSL2 + Ubuntu + ROCm这套组合更合适。Windows 11对WSL2的支持已经很成熟，一条wsl --install命令就能把环境搭起来，然后在Linux侧安装AMD的ROCm驱动以及ROCm版PyTorch，就可以获得接近Linux原生的体验。
AMD在Windows平台上对ROCm的支持以前一直比较谨慎，但到了Ryzen AI MAX这一代，情况改善了很多。Radeon 8060S这类RDNA 3.5核显在WSL2里被识别为ROCm设备后，跑PyTorch推理脚本的兼容性比Windows原生DirectML路径好不少。在WSL2里要注意内存分配的坑，默认配置下WSL可能只占用系统可用内存的一部分，也可能抢占太多。要在用户目录下建一个.wslconfig文件，手动设置memory上限，比如[memory] 或者memory=64GB，然后执行wsl --shutdown重启WSL，配置才会生效。
4.3 框架选择建议
结合我这些天的实际体验，可以给一个明确的选型建议。如果你主要需求是快速跑起一个本地聊天机器人，或者给现有工具接一个本地大模型API，Ollama for Windows是最省心的路径，五分钟就能跑通。如果你喜欢图形化管理模型，也愿意折腾一下Vulkan相关设置，LM Studio是更好的选择。如果你要做批量推理、模型微调或者需要精细控制Prompt处理逻辑，老老实实打开WSL2装ROCm环境，不要在Windows原生上死磕。
有人可能问，为什么Windows原生跑PyTorch对AMD支持还是不够好？原因在于Windows图形驱动走的是WDDM模型，GPU资源由系统统一调度，很多适合大模型推理的高效内存访问方式在WDDM下使不上劲。WSL2本质上是一个轻量虚拟机，Linux侧直接跑ROCm驱动，更接近AMD驱动团队优先优化的Linux路径，兼容性和性能都能拿到更好的结果。
5. 常见问题与避坑记录
5.1 显存分配不生效怎么办
这次测试里我头一回改UMA Frame Buffer就遇到了“改了好像没改”的情况。BIOS里明明设成32GB，进到Windows一看，任务管理器还是显示6GB。排查下来，根因就是保存后选了重启，而不是完全关机。AMD平台的固件在冷启动和重启时对内存控制器的初始化路径不一样，部分设置必须冷启动才能被正确读取。后来改成保存退出后强制关机，等待电源灯完全熄灭再开机，显存分配就正常识别了。
还有一个容易被忽略的点：Windows下的显卡驱动缓存。如果你刚换过驱动版本，或者系统刚从旧硬件迁移过来，任务管理器显示的专用GPU内存可能仍然来自旧的驱动报告。这时候去设备管理器把显示适配器里的显卡禁用再启用一次，或者干脆把AMD Software里恢复一下出厂设置，再重启，往往就能纠正。还是不行的话，检查BIOS固件版本，有些早期固件的UMA选项存在Bug，更新到最新版能解决。
5.2 出现OOM、速度慢、系统卡死
OOM是最常见也最好判断的问题。在6GB分配档位下加载14B模型，Ollama直接报内存分配失败，llama.cpp则会在加载权重时提示Can't allocate memory，这类错误指向很明确，就是显存分配不足，去BIOS调大即可。但有一种迷惑性很强的OOM：显存分配明明够，权重也快加载完了，最后一步突然报错。这种情况多半是上下文长度设置过大，KV Cache把剩余的显存挤爆了，把上下文从默认值调低就好。
速度慢分两种。一种是模型能跑，但速度只有个位数tok/s，比如6GB档位下跑8B模型掉到30多tok/s甚至更低，多半是权重被放到了共享内存区域。去任务管理器看一眼GPU的“共享GPU内存使用量”，如果数值很高，就说明专用显存已经满了。另一种是整体系统响应慢，浏览器切页面都卡，这种通常是显存分配过大，系统内存被挤到极限，Windows开始频繁换页。解决办法是调小分配档位，给系统留出至少16GB以上的可用内存。
5.3 个人使用体会与最终建议
这一个月折腾下来，我最大的体会是：显存分配这件事，本质上是在做容量规划，而不是性能调优。它对推理速度的影响是“阈值式”的——分配不够就彻底跑不了，分配够了之后，性能就交给内存带宽和模型大小去决定，你再怎么加码分配也没有额外收益。所以最合理的做法是先想清楚自己经常跑多大模型，再按模型权重加余量确定档位，别盲目往最高档调。
对我个人来说，128GB内存的机器，如果未来一段时间以跑32B和70B模型为主，我会长期放在96GB档位，因为系统还剩32GB左右，日常办公够用。如果只是跑7B、14B模型，我反而建议设成32GB甚至16GB，把更多内存留给系统缓存和开发环境，体验会更均衡。最后再分享一个小技巧：改完显存分配后，如果发现某个模型加载速度明显变慢，可以去检查一下Windows虚拟内存设置，手动给系统盘留一个足够大的页面文件，很多时候能把一些莫名其妙的启动缓慢问题解决掉。
