Windows 11下Ryzen AI MAX+ 395显存分配优化指南

作为一个从PC DIY时代就开始折腾硬件的老人，这几年我一直在关注一个趋势：本地跑大模型，到底什么硬件最合适。很多人无脑推NVIDIA显卡，CUDA生态确实强，但显卡显存太贵了，32GB的卡动辄上万，玩不起。所以当AMD Ryzen AI MAX+ 395这台处理器出现的时候，我是真兴奋——256GB/s带宽的LPDDR5X统一内存，CPU、GPU共享同一个内存池，理论上能把几百GB的模型都塞进去。但实际用下来发现，这里面的门道比想象中多，尤其是Windows 11系统下“显存分配”这一项，直接决定了你是在愉快地聊天，还是在痛苦地等token。这篇文章就是来把这个问题彻底讲透的。

我用的这台机器是搭载Ryzen AI MAX+ 395的迷你主机，128GB统一内存版本。之所以选Windows 11而不是Linux，是因为我日常工作、视频剪辑、跑一些Windows-only的软件都在这台机器上，不想为了推理单独装个双系统。但Windows下的显存分配逻辑和Linux完全不一样，Linux的HSA框架是自动管理的，Windows则依赖驱动和BIOS的“显存预留”机制。这个机制用好了，13B模型秒加载；用不好，8B模型都给你回退到CPU跑，速度慢得让人怀疑人生。

这篇文章我会从几个方面来聊：为什么统一内存会被拆成“专用”和“共享”两块，BIOS里的那个“显存大小”选项到底该怎么填，不同显存分配策略对不同规模模型的影响，以及在Windows 11 27H2这种新系统下如何用工具准确判断模型到底跑在GPU上还是CPU上。全程都是我自己踩过坑、测过数的结论，希望能帮到正在或准备入手这台机器的人。

1. 为什么AMD的“统一内存”在Windows下还要手动分配显存

很多刚入手Ryzen AI MAX+ 395的朋友会有一个疑问：既然CPU和GPU共用内存，为什么Windows任务管理器里还会看到“专用GPU内存”和“共享GPU内存”两个数字？为什么不把所有内存都直接给GPU用？

1.1 专用显存（UMA Frame Buffer）和共享显存（GTT）的本质区别

这里需要先理清两个概念。AMD的APU在BIOS里有一个选项叫“UMA Frame Buffer Size”或者“GPU Memory Allocation”，中文版叫“显存分配”或者“帧缓冲大小”。这个选项设置的是“专用GPU内存”的容量，也就是Windows报告给游戏、视频解码、CUDA类应用（这里特指DirectML/Ollama等）的“显存”大小。

但和独立显卡不同的是，APU的“专用显存”并不是焊在板子上的显存颗粒，它只是从系统物理内存里“划拨”出来的一块固定区域，专门给GPU核心使用。这块内存CPU是访问不到的（或者说访问效率很低），一旦划拨出去，就固定了。而“共享GPU内存”则是通过GTT（Graphics Translation Table，图形转换表）机制，允许GPU按需动态借用系统内存的剩余部分。

打个比方：专用显存就像你在餐厅预定了一个包间，不管今天来几个人，这个包间的钱都得付，位置也一直给你留着；共享显存就是大堂里的散座，你来多少人坐下多少人，按实际人数算。这个比喻很关键，因为它引出了选择显存分配策略的核心矛盾。

1.2 为什么不能把显存无脑设到最大

既然统一内存这么好，是不是BIOS里直接选到64GB或者128GB最省事？我一开始也是这么干的，然后发现问题很大。

第一，专用显存划拨过大，会导致可用系统内存减少。Windows 11系统本身要占4-6GB内存，浏览器开十几个标签页要占8-10GB，后台服务再占一些。如果你设了64GB专用显存，那系统实际可用的物理内存就只剩64GB（在128GB内存的机器上）。虽然看起来还很多，但如果你要同时跑模型推理和CPU编译任务，内存紧张是必然的，甚至可能导致页面文件疯狂读写SSD，整个系统变卡。

第二，过大的专用显存会降低内存带宽利用效率。Ryzen AI MAX+ 395的LPDDR5X-8000内存是256-bit位宽，理论带宽256GB/s。但这个带宽是CPU和GPU共享的。当GPU占据了绝大多数物理内存，且经常进行大块内存访问时，CPU访问内存的延迟会明显增加。实测在64GB专用显存下，CPU单线程跑分比8GB显存设置时下降了5%左右，这对需要CPU和GPU并发工作的场景影响挺大的。

第三，有个更隐蔽的问题：部分软件的逻辑是“检测到显存够大，就把所有层都塞进去”。当显存设置为128GB时，一些推理引擎会尝试把所有中间激活值、KV cache都放进显存，结果内存占用率飙升，反而因为内存带宽瓶颈导致推理速度下降。这个在后面实测部分会详细说。

1.3 Windows 11 27H2的显存调度变化

我在Windows 11 27H2（2025年的版本更新）上测试时发现，微软对APU的图形内存管理做了一些调整。最明显的变化是任务管理器里“GPU 0（Radeon 8060S）”的“专用GPU内存”和“共享GPU内存”显示逻辑更清晰了，而且在“设置 > 系统 > 显示 > 图形 > 默认高级设置”里增加了一个“自动管理应用的GPU内存”开关（类似手机上的内存扩展开关）。

这个开关默认是关闭的。如果打开，系统会根据运行的应用类型动态调整共享内存的分配比例。听起来很智能，但我实测发现这个“自动管理”对推理任务并不友好，它会倾向于给前台应用分配更多内存，导致推理应用拿到的内存不稳定，偶尔会出现OOM中断。所以我的建议是：做AI推理时，把这个开关关掉，让驱动按默认策略走。

2. 实操前的准备：刷新BIOS、驱动和推理环境

在正式测试显存分配策略之前，先把基础环境弄利索。这一步很重要，因为很多性能问题其实不是显存分配的锅，而是驱动或BIOS版本太旧导致的兼容性bug。

2.1 BIOS和芯片组驱动：老版本真的会限制显存上限

我这台机器到手时BIOS版本是2025年4月的，里面“UMA Frame Buffer Size”最大只能选32GB。后来刷新到了9月的版本，发现多了64GB、96GB、112GB的选项。这意味着如果你在BIOS里找不到大容量显存选项，第一反应应该是去主板官网刷BIOS，而不是怀疑硬件不支持。

芯片组驱动也需要更新到最新版。AMD的芯片组驱动里包含GPIO、PMC和电源管理驱动，这些组件会影响内存控制器对GPU内存请求的响应优先级。实测旧版芯片组驱动下，同样设置32GB显存，lazy加载模型的时间比新版驱动慢了近30%。

2.2 Windows 11专业版与WSL2环境的准备

我的系统是Windows 11专业版（27H2，Build 26100），没有使用任何精简版。这里多说一句，有些人为了跑AI用精简版系统，美其名曰“释放资源”，但精简版通常砍掉了Hyper-V和WSL2的内核组件，这对后续的AI环境建设是致命的。很多AI推理框架在Windows上的官方支持方式就是WSL2，比如NVIDIA官方推荐的TensorRT-LLM，虽然在AMD平台上不太适用，但WSL2里跑Linux版Ollama、llama.cpp等工具确实比Windows原生版稳定不少。

我最终的推理环境是三套并行：

• Windows原生：LM Studio（0.3.x版本，用DirectML后端）
• WSL2 Ubuntu 24.04：Ollama（ROCm 6.x版本）+ llama.cpp（ROCm构建）
• Docker Desktop（WSL2后端）：部分需要容器化部署的推理服务

这三套环境对显存分配策略的敏感度不完全一样，后面测试时会分别说明。顺便提一句，WSL2在27H2上的内存回收机制比旧版好多了，实测WSL2进程退出后，虚拟内存能快速释放回Windows。

2.3 关键工具：如何准确监控GPU内存和推理状态

在Windows下，我建议装好这几个工具，避免“视力不好还非要开车”：

• 任务管理器（Ctrl+Shift+Esc）：看“性能 > GPU 0”的“专用GPU内存”和“共享GPU内存”。注意“GPU 0（Radeon 8060S）”才是核显，别看到“GPU 1（Microsoft Basic Display）”然后一脸懵。
• HWiNFO64：可以精确查看“GPU Memory Read/Write Bandwidth”，这是验证显存分配是否生效、是否存在带宽瓶颈的关键指标。
• AMD Software: Adrenalin Edition：内置的性能监控浮窗可以覆盖在游戏和应用上面，实时显示GPU占用、显存占用、功耗和温度。
• llama.cpp的--verbose输出：会显示“buffer_size”、“offload_v！”等信息，能明确告诉你模型层到底放在了哪个设备上。

特别要注意的是，Windows任务管理器里的“GPU内存”面板有三个值：专用、共享、总计。在Ryzen AI MAX+ 395上，这三个值的关系是“总计=专用+共享”。当模型加载后，如果“共享GPU内存”的使用量明显增长，说明模型已经成功利用了GTT机制动态借用了系统内存。如果共享内存使用量一直为0，但专用显存被打满，且整机卡顿，那就说明GTT没生效，模型全在CPU上跑。

3. 核心环节：BIOS显存分配的不同方案与实测对比

在这一部分，我要展示的是真正的“操作+实测”内容。我会改变BIOS里的“UMA Frame Buffer Size”数值，分别测试16GB、32GB、64GB三种配置（这台机器没有32GB以下的UMA选项，但我看到网上有人反馈他们的机器可以选8GB甚至3GB，取决于BIOS和内存容量），并对比不同模型在LM Studio和Ollama上的推理性能。

3.1 如何进入BIOS并准确设置UMA Frame Buffer Size

开机按Del键进入BIOS设置（我这台迷你主机是Del键，有的品牌是F2）。在“高级”或“AMD CBS”菜单下找“NBIO”或“GFX”相关选项。不同BIOS的路径不一样，我这里记录一下我操作的路径：

1. 进入“Advanced > AMD CBS > NBIO Common Options > GFX Configuration”。
2. 找到“UMA Frame Buffer Size”，回车后选择需要的大小。
3. 按F10保存退出，重启。

要注意的是，修改UMA Frame Buffer Size后，第一次开机需要做一次“内存重新训练”，这个过程中屏幕可能黑屏一段时间（10-30秒），属于正常现象，千万别直接按电源键强制关机。我一开始不知道，有次等得不耐烦按了重启，结果进了安全模式，后来耐心等就好了。

另外一个关键点是，不同厂家BIOS对这个选项的命名可能不一样。比如有的叫“iGPU Memory Allocation”，有的叫“GTT Memory Size”（注意，这个选项不是GTT机制，而是GTT机制用的额外保留内存）。如果你找不到“UMA Frame Buffer Size”，可以试试搜索“显存”，或者直接看主板说明书。

3.2 测试方案设计：控制变量才是王道

为了准确对比，我严格控制了其他变量：

• 待测模型：Llama 3.1 8B Q4_K_M（约5GB）、Qwen2.5 14B Q4_K_M（约9GB）、Qwen2.5 32B Q4_K_M（约20GB）
• 推理后端：LM Studio 0.3.9（DirectML）和Ollama 0.6.x（ROCm版）
• 输入输出：统一使用“请详细介绍北京故宫的历史沿革和建筑特点”这个prompt（约50 token输入），生成512 token后停止。
• 指标记录：首token延迟（TTFT）、生成速率（tokens/s）、GPU占用率、显存占用、内存带宽利用率。

这里我特别说一下为什么用Q4_K_M量化模型。因为量化后的模型体积更接近普通玩家的实际使用场景——大多数人是没有能力跑FP16的70B模型的，Q4_K_M是质量和体积的平衡点。如果你要跑FP16的精调模型，显存分配逻辑会更接近“吃满可用显存”的模式，反而没有Q4这种“刚好放下”的依赖敏感。

3.3 实测数据对比：显存分配策略对推理性能的影响

下面是我记录的实测数据（部分数据是多次测试取平均值）：

测试一：Llama 3.1 8B Q4_K_M（约5GB模型文件）

小模型的结果很有意思：显存分配大小对性能几乎没影响。因为模型太小，无论分配多少显存，GPU都能通过GTT拿到足够的内存。16GB和128GB的差异完全可以忽略。这说明对于8B级别的模型，你不需要特意去BIOS里设置大显存，默认Auto模式就够了。

测试二：Qwen2.5 14B Q4_K_M（约9GB模型文件）

这里开始出现差异了。14B模型有接近9GB的数据需要放在内存里。当显存分配16GB时，虽然理论上模型能放下（5GB模型文件 + 4GB KV cache都在“内存”里），但注意GPU实际能“高速访问”的区域是有限的。16GB的UMA Frame Buffer大部分被系统图形界面和其他应用占用了，GPU频繁通过GTT去访问系统内存区域，而GTT的路径延时比UMA Frame Buffer高。这也是为什么16GB下首token延迟明显偏高。

测试三：Qwen2.5 32B Q4_K_M（约20GB模型文件）

32B模型的规律更明显。16GB显存下模型直接加载失败，因为LM Studio检测到“专用显存只有16GB，而模型需要约20GB”，直接判定显存不足，拒绝运行——即使系统还有110GB可用内存。这就是典型的“专用显存限制检测逻辑”问题。32GB时虽然能跑，但性能不佳，因为KV cache达到一定规模后，GPU需要频繁访问GTT区域，导致带宽延迟增加。64GB以上才基本达到稳定状态。

3.4 为什么“刚好放下”反而性能差

上面32B模型的数据解释了一个现象：显存分配不是“模型能放下”就行，而是要给KV cache和计算中间变量留出足够的高速访问空间。推理过程中，除了模型权重，还有输入token的embedding、各层的隐藏状态、注意力机制的KV cache等。这些中间变量在推理时是高频访问的。如果显存分配过小，这些变量会被挤到GTT区域，而GTT的访问效率低于UMA Frame Buffer，导致性能下降。

那能不能把KV cache直接放到系统内存区域来避免这个问题？理论上可以，比如在llama.cpp里通过参数限制GPU层数，把部分层跑在CPU上。但在Windows的LM Studio里，DirectML后端没有这么精细的控制。在Ollama的ROCm版里，可以通过OLLAMA_NUM_GPU环境变量来设置offload到GPU的层数。但实测发现，完全offload到GPU（OLLAMA_NUM_GPU=999）在64GB显存分配下的性能，比offload到一半（OLLAMA_NUM_GPU=40）要好得多。原因是AMD ROCm内核在Windows上的CPU+GPU混合执行有额外的内存同步开销。

3.5 我对不同内存容量机器的显存分配建议

基于上面的测试数据，我给不同内存容量的Ryzen AI MAX+ 395用户一个建议配置（BIOS里设置的值）：

• 64GB内存版本：建议设置16GB或24GB专用显存。这样系统内存剩40-48GB，能跑8B/14B模型，多任务也能流畅。32B模型在这个机器上不要强求，即使能跑也就13-15 tok/s，体验不好。
• 128GB内存版本（我当前用的配置）：建议设置32GB或48GB专用显存。这是性价比最高的区间。实测32GB和64GB在32B模型上的性能差距大约是5-10%，但32GB能为系统留出更多内存，多任务更从容。日常用48GB是另一个折中点，我更推荐这个。
• 96GB内存版本：类似128GB版本的逻辑，建议24GB到32GB之间选择。

有人可能会问，为什么不推荐64GB或128GB？除了前面说的系统内存不足和带宽竞争问题，还有一个隐藏坑：Windows的“内存管理”对超过64GB的专用显存区域支持并不好。我实测在64GB专用显存下，系统偶发性出现“视频内存管理内部错误”的蓝屏（BUGCODE_USB_DRIVER之类的报错，实际上是GPU内存管理冲突），后来查了不少资料，发现这可能是Windows的WDDM驱动模型对UMA Frame Buffer的地址映射上限限制导致的。微软官方文档里确实提到WDDM 2.0对APU的“Aperture memory”有64GB的限制，超过这个数值容易出现兼容性问题。

4. 常见问题与排查技巧实录

不管你是Windows新手还是Linux老手，在Windows 11下用Ryzen AI MAX+ 395跑大模型，大概率会遇到下面这些问题。我把它们整理成速查表，并附上我实际的解决思路。

4.1 模型加载报错“CUDA out of memory”或“VRAM not enough”

这个问题在Windows下最常见，但原因不是“显存真不够”，而是软件把“专用显存”当成了唯一可用的显存。

• 在LM Studio里，可以进入设置，找到“Hardware Settings”，确认Backend是“DirectML”而不是“CUDA”。
• 在Ollama里，检查OLLAMA_NUM_GPU环境变量是否被正确设置。如果遇到“no ROCm-capable device detected”，大概率是驱动或ROCm组件没有正确安装。
• 还有个小技巧：在Windows的“图形设置”中，为LM Studio或Ollama单独指定“高性能”GPU，避免系统把推理进程调度到“Microsoft Basic Display”或“GPU 1”上。

如果是在WSL2里遇到这个报错，多半是WSLg借用了Windows的GPU资源，但你并没有开启WSLg的GPU加速支持。解决办法是在WSL2里检查ROCm是否正常可见（rocminfo命令），以及是否安装了最新版ROCm库。

4.2 推理速度慢得离谱，比CPU还慢

这个现象在显存分配不足时很典型。我的排查步骤是：

1. 打开HWiNFO64，观察“GPU Memory Read Bandwidth”是否接近了256GB/s的物理极限。如果一直顶着上限，说明内存带宽是瓶颈，只能降低模型规模或换更小的量化等级。
2. 看任务管理器“性能 > GPU 0”里的“共享GPU内存”使用量。如果“共享”持续高位且增长，说明GTT机制在大量工作，显存分配偏小。
3. 用CPU-Z观察内存频率，如果内存跑在8000MT/s以下（比如降到了4800），那是内存训练参数丢失导致带宽减半，需要重新加载BIOS默认设置或者手动开启DOCP/EXPO内存配置。

我之前遇到过一次“推理速度从24 tok/s骤降到8 tok/s”的情况，排查半天，最后发现是系统在后台运行Windows Update的内存诊断，占用了大量内存带宽。关掉自更新和后台诊断后恢复。

4.3 任务管理器显示两个GPU，模型跑错设备

Ryzen AI MAX+ 395在Windows下通常会以“GPU 0（Radeon 8060S）”和“GPU 1（Microsoft Basic Display）”两个设备出现。如果你在设备管理器里看到“Microsoft Basic Display”存在且被分配了主显示器输出，那你的桌面渲染可能会走CPU模拟，GPU资源被严重浪费。

解决办法：打开设备管理器，检查显示适配器下是否有“Microsoft Basic Display”。如果有，乖乖去安装最新版AMD Adrenalin驱动，装完后重启，这个设备应该会消失或变为“AMD Radeon 8060S”。如果还在，那就是驱动没装好，或者主板开启了“CSM安全引导”导致显示设备初始化异常，需要进BIOS关闭CSM。

4.4 WSL2里能跑Linux版Ollama，但Windows版Ollama识别不到GPU

这个问题我排查了快两天。现象是：WSL2里执行rocminfo能识别到GPU，也能正常推理；但Windows版Ollama（通过exe文件直接运行）却报告“no video device detected”之类的错误。

最终定位到是Ollama的Windows版依赖的是ROCm的Windows驱动组件，而我的AMD驱动是通过“驱动更新”安装的，没有安装完整的AMD SDK组件。解决办法是去AMD官网下载并安装完整版的“AMD Software: Adrenalin Edition”时，注意勾选“AMD ROCm”组件（在安装界面自定义部分）。

另外，Windows版Ollama默认会检测物理显存（专用显存），如果你的UMA Frame Buffer设置偏小，它可能依然能检测到并运行，但性能打折扣。这时可以给Ollama的Windows服务设置环境变量HSA_OVERRIDE_GFX_VERSION=11.0.0（不是必须，但部分模型能提升兼容性）。

4.5 系统在高负载推理时整机卡顿，鼠标飘

这可能是“共享GPU内存”在Windows下触发了“内存回收”机制。当你把显存分配设得太小（比如16GB）而去跑32B模型，GTT会频繁地从系统内存池中申请页面，而Windows的页面回收策略可能触发“磁盘交换”，造成整机掉帧。

• 解决优先级：先调BIOS显存分配（往上调），再关闭Windows的“内存压缩”和“SysMain”服务，最后考虑增加虚拟内存（但机械硬盘/SSD的交换速度远不如内存，所以虚拟内存只是兜底方案）。

5. 工具选型与扩展玩法：从LM Studio到Docker部署

聊到这里，单纯讨论“显存分配”已经不够了。在实际项目中，你还会遇到“该用哪个推理后端”“要不要上Docker”这类问题。这一节我分享一下我这段时间在Windows 11下调试多个推理框架的经验。

5.1 LM Studio还是Ollama？

LM Studio更偏“桌面应用”，图形界面友好，下载模型方便，适合快速体验。Ollama更像“服务”，适合命令行操作和程序化调用。两者底层都可以调用DirectML或ROCm。

• 如果你用LM Studio：记住在设置里选对硬件后端。默认“Auto”有时候会落到CPU上，遇到这种就手动指定“DirectML”。在显存分配偏小的机器上，LM Studio会出现“模型加载到内存但GPU利用率为0”的虚假成功状态，注意用任务管理器确认。
• 如果你用Ollama：它默认是CLI工具，也可以通过API给其他程序调用（比如搭配Open WebUI）。Ollama的ROCm版在Windows上需要注意一个坑：它的默认内存布局方式可能会占用大量“专用GPU内存”，导致和桌面抢内存。这时可以把OLLAMA_MAX_LOADED_MODELS设小一点，限制同时加载的模型数量。

5.2 Docker Desktop + WSL2 跑推理容器的实践

如果你不想在Windows里装一堆依赖，Docker Desktop是个好选择。27H2下的Docker Desktop现在默认走WSL2后端，性能和原生Linux接近。我试过在容器里跑llama.cpp的ROCm构建版，步骤是：

1. 安装Docker Desktop，确保“Use the WSL 2 based engine”勾选。
2. 在Docker Desktop设置里，把Default WSL Distro设为Ubuntu-24.04。
3. 拉取带ROCm的镜像（比如rocm/dev-ubuntu-24.04），运行时加--device=/dev/kfd --device=/dev/dri参数（注意这里是黑客常用的设备映射方式，但在本地容器部署里是正常操作）。

不过实话实说，Docker + ROCm在Windows下的稳定性比原生WSL2差一点，如果你只是为了跑模型，我建议直接用原生WSL2，不需要套一层Docker。只有当你需要部署带Web服务的应用（比如搭建一个本地知识库问答系统）时，Docker才能体现隔离和编排的优势。

5.3 大显存分配后的“第二春”：跑更大的模型

如果你按照我的建议把显存分配调到了48GB或64GB，其实还可以再进一步：尝试跑Qwen2.5-72B的Q3_K_S量化版（约30GB）。虽然内存带宽限制了它的速度只有大约4-6 tok/s，但这个速度在“离线批量处理文档摘要”这种场景下完全能用。我还试过跑Command R 35B的FP16版本（约70GB），因为显存分配到了112GB（当时为了测试专门调的），也勉强能加载出来，但速度肉到只有1.8 tok/s，基本失去交互意义。

所以这里也提醒一下：不是显存分配越大越好，而是“够用且留余量”最好。你分配得太激进，系统内存不足反而触发内存交换，性能先升后降，那个拐点大约在“专用显存=总内存-当前系统占用-10GB左右”的位置。

6. 经验总结与个人体会

折腾了两周，我个人的结论是：Ryzen AI MAX+ 395确实是目前本地大模型推理性价比很高的选择，但前提是你要把它当成一个“带GPU节点的计算机”来调优，而不是“一个超级核显”。

显存分配这一步是Windows 11下绕不开的配置项，它直接影响模型能否运行、速度上限和CPU/GPU的协同效率。我最终采用的长期配置是：

• BISO里UMA Frame Buffer Size：48GB
• Windows虚拟内存：16GB（固定大小，放在NVMe SSD上）
• LM Studio Backend：DirectML
• Ollama版本：0.6.x（开启ROCm加速）
• 多个推理服务共享内存时，优先保证模型加载，再考虑系统多任务

最后再分享一个小技巧：当你在Windows 11下跑推理，无论显存分配多少，都建议把“电源模式”设置为“最佳性能”（在设置 > 系统 > 电源和睡眠 > 其他电源设置里）。Ryzen AI MAX+ 395的调度器在“平衡”模式下会倾向降低GPU频率来省电，这会导致TTFT翻倍。我实测“最佳性能”和“平衡”相比，14B模型生成速度从21.3 tok/s提升到26.2 tok/s，提升幅度接近23%，是成本最低的优化方案。

如果你正准备上一台这个处理器的机器来玩本地大模型，希望这篇文章能帮你少走一些弯路。当然，如果后续AMD和微软在Windows驱动层面对GTT机制做进一步优化，也许有一天我们真的不需要手动调这些参数，但在那之前，先把BIOS里的那个选项设置好，是每个Windows下APU推理玩家都要做的第一课。