AI Max 395 跑 ROCm：UMA 显存分配与常见排错指南

如果你正拿着一台 AMD AI Max 395 的准系统或者 128GB 内存的旗舰笔记本想跑 ROCm，那你大概率已经体会过什么叫“硬件很性感，软件很骨感”。这颗 APU 在端侧设备里确实是异类，CPU、GPU、NPU 共用同一块内存，理论上可以在一台笔记本里加载几十 GB 的大模型权重。但真正想让它跑起来，你得把 BIOS 里的显存分配、Linux 驱动、用户组权限、ROCm 版本全部对齐，哪一步没对上，表现就是各种“设备不存在”和“OOM”。这篇文章不打算写成一个超长教程，而是把我这段时间折腾下来最值得收藏的资源入口、安装路径和排错经验汇总出来，给同样在用 AI Max 395 + ROCm 的人省点时间。

1. 为什么是 AI Max 395？先想清楚你在折腾什么

1.1 这不是普通核显本，统一内存决定了玩法上限

AI Max 395 的宣传工作做得很足，但很多人在装 ROCm 之前并没有认真想过它和独显机器的本质区别。它的 CPU 部分最多 16 个 Zen 5 核心，GPU 部分是 40CU 规模的集成显卡，NPU 宣称有 50 TOPS 的 AI 算力，三者共享一片最高 128GB 的 LPDDR5x 统一内存，总线宽度 256-bit，理论带宽大概在 256GB/s 左右。

这个形态和传统笔记本最大的不同在于：显卡没有自己的独立显存颗粒，GPU 访问的是整个系统内存池。权重不需要从内存反复搬运到显存，CPU 写进去，GPU 就能直接读。跑 70B 级别的量化模型时，如果你把一半以上内存划给 GPU，那内存容量就是“显存容量”，这是任何同价位独显本都很难做到的。

但代价也很明显——内存带宽是共享的。GPU 运算时 CPU 再去读写内存，两者会互相挤占通道。ROCm 下的很多性能问题，最后查来查去都会落回“带宽被吃满”这个物理瓶颈。

1.2 ROCm 在这里的边界在哪里

ROCm 是 AMD 的 GPU 计算软件栈，对标的就是 CUDA。对 AI Max 395 来说，ROCm 能够把集成 GPU 当作一个计算设备来用，跑 HIP、PyTorch、vLLM 这些下游框架。但要注意，AMD 官方对 Strix Halo 平台的支持策略是以原生 Linux 为主的，Windows 侧虽然能用 HIP SDK 做部分开发，但很多 GPU 计算场景的兼容性明显不如 Linux 稳定。

所以，如果你买这台机器是为了本地跑大模型、做 RAG、调 diffusion，建议现在就把主力工作环境放到 Ubuntu 24.04 这类官方优先覆盖的发行版上。Windows 可以留着日常办公和游戏，但别指望所有 ROCm 例子都能在 Windows 下开箱即跑。

2. 统一内存和显存分配：一切资源问题的根源

2.1 UMA Frame Buffer 到底是什么

UMA（Unified Memory Architecture）帧缓冲是 BIOS/UEFI 里的一个设置项，常见名称有 UMA Frame Buffer Size、GFX Memory Size、VRAM Size，单位是 MB 或 GB。这个值决定了系统会从总内存里划出多大一块，作为“GPU 专用内存”预留给图形和计算使用。

AI Max 395 可调节的档位要看主板或整机厂商开放到什么程度。有的机器能一路调到 112GB，有的最高只开放到 32GB。分配之后，Windows 的任务管理器里会显示为“GPU 专用内存”，Linux 下 rocm-smi 或 amdgpu 驱动的 VRAM 读数也以这个池子为基准。

这里有个很容易绕晕的点：即使不调整 UMA，GPU 也能通过 GTT（Graphics Translation Table）访问系统剩余内存，但性能和地址映射方式不一样。预留给 GPU 的那部分内存，驱动可以像显存一样直接管理；而 GTT 方式本质是让 GPU 借道系统内存，延迟和分配效率都不如前者稳定。

2.2 128GB 内存到底能不能当成 128GB 显存

理论上可以，因为 UMA 上限可以设置为 128GB，但实操中没人会真的全划给 GPU。原因很简单：CPU 侧的操作系统、运行时、模型前后处理都要吃内存。如果全部划给 GPU，系统可能在开机阶段就 OOM，更别提用 llama.cpp 同时做 CPU offload 的混排方案了。

以 128GB 版为例，我个人建议的分配策略是这样的：

这个表格不是绝对标准，只是一个比较稳的起点。实际调优时我会先看模型权重和 KV Cache 的总占用，再决定 GPU 池子切多大。分配得好，后续 ROCm 的稳定性会高很多；分配得不好，跑大模型很容易出现系统内存先被清空、然后整个桌面卡死的状态。

2.3 为什么 ROCm 应用总报显存不足

很多人在 AI Max 395 上第一次跑 PyTorch，看到torch.cuda.OutOfMemoryError或 ROCm 的HSA_OUT_OF_RESOURCES就懵了：自己明明是 128GB 内存，怎么还会显存不足？

问题就出在 UMA 分配上。ROCm 应用能够被 GPU 直接使用的内存量，首先取决于 UMA 帧缓冲设置，其次取决于驱动是否允许动态使用 GTT。如果你在 BIOS 里只给了 512MB，那 ROCm 看到的就是一张“只有 512MB 显存”的显卡。写代码的人当然会直接报 OOM。

所以，遇到显存不足，第一反应不是去看代码或者模型，而是先进 BIOS 检查 UMA 分配。这个顺序搞反了，后面所有排查都会白费。

3. 官方资源入口：按优先级排序的一次性清单

3.1 文档：以 rocm.docs.amd.com 为准

ROCm 的官方文档入口是 https://rocm.docs.amd.com ，这个站点整合了安装说明、平台支持矩阵、API 参考和 Release Notes。对于 AI Max 395 用户，我建议先看两个页面：一是 Supported Platforms 页面，确认你用的 Ubuntu 22.04/24.04 内核版本在支持列表里；二是 Installation 页面，找到 amdgpu-install 包的下载链接。

不要从搜索引擎随意下载 ROCm 安装包，那边版本太杂，很多是旧版残留，装上之后会和新内核打架。官方文档页面里的仓库地址才是唯一靠谱来源。

3.2 驱动安装包与 Auto-Detect 工具

Windows 用户找驱动可以去 AMD 官方支持页下载，或者用 Auto-Detect and Install Tool 自动识别显卡并安装最新驱动。这个工具对普通用户很友好，但装完驱动后，它不会帮你装 ROCm 软件栈——ROCm 的绝大多数运行库和编译器依赖 Linux 包管理流程，Windows 下的支持情况要看 ROCm 官方文档里的 Windows 章节。

Linux 用户的核心动作是找到amdgpu-install这个 deb 包，它通常会放在 AMD 的包仓库目录结构里，例如 Ubuntu 24.04 对应的目录下面。文件名会带具体版本号和日期，建议你从官方安装文档当天给出的链接为准，不要收藏某个固定的 alpha 版本号然后用一年，ROCm 更新太快，旧包很容易和新内核不兼容。

3.3 GitHub 仓库清单

除了官方文档，GitHub 是另一个需要高频访问的地方：

• ROCm/ROCm：ROCm 软件栈的总体仓库，里面有发布计划、组件说明和版本号对应关系。
• ROCm/rocm-smi：对应 rocm-smi 命令行工具，查询 GPU 状态、温度、功耗。
• ROCm/hip：HIP 运行时和编译工具链，涉及 hipcc 的版本行为。
• ROCm/MIOpen：MIOpen 深度学习算子库，跑 CNN 或部分 PyTorch 算子时会被调用。

另外，遇到 ROCm 具体报错时，直接在 GitHub Issues 搜索关键词往往比文档更快。因为 AI Max 395 属于比较新的平台，大量问题在正式发布前并不存在，只有用户开始踩了坑，Issue 里才有真实反馈。

3.4 验证工具别漏了

资源清单纯文档和 GitHub 还不够，实际装机后你还需要几个验证工具：rocminfo、rocm-smi、rocm-bandwidth-test、hipcc。这些通常在rocm-libs或hip-examples等软件包里，安装后可以直接跑。

4. Ubuntu 24.04 上把 ROCm 跑起来：我的实操记录

4.1 安装前先把系统和固件对齐

我强烈建议在安装 ROCm 之前把系统更新到最新，因为 AI Max 395 的图形侧需要比较新的内核 DRM 驱动和 amdgpu 固件。如果内核太旧，即使 ROCm 安装成功，设备节点也可能生成不了。

第一步是装好内核头文件与内核模块扩展包：

sudo apt update sudo apt upgrade sudo apt install linux-headers-$(uname -r) linux-modules-extra-$(uname -r)

如果是在刚装完的 Ubuntu 24.04 上操作，uname -r输出的版本可能不是最新，升级后建议重启一次，等系统加载新内核再做后续步骤。很多“lspci 无反应”“renderD128 不存在”的问题，其实在重启之后就被治愈了。

4.2 安装 amdgpu-install 的细节

接下来从 ROCm 官方安装文档找到 amdgpu-install 的 deb 包。大致流程是：

wget <rocm-docs里提供的amdgpu-install下载链接> sudo apt install ./amdgpu-install_*.deb sudo amdgpu-install --usecase=rocm

--usecase=rocm是核心，它只安装 ROCm 计算栈，不会把一堆图形驱动选项带进来。如果你还需要跑一些同时依赖 OpenGL/Vulkan 的开发，可以考虑再加--usecase=rocm,graphics，但普通推理和模型加载不推荐装太多无关组件。

安装过程会拉取大量依赖，耗时十几分钟到半小时不等。如果你的网络环境比较慢，不要反复中断重试，容易留下半装状态的 dpkg 锁，后续会非常难受。

4.3 权限组和重启：最容易忽略的一步

安装命令跑完后，当前用户默认是没有权限访问 GPU 设备的。需要把自己加入render和video两个组：

sudo usermod -a -G render,video $USER

然后重启，或者至少重登一次。很多人在这一步跳过了重启，然后 rocm-smi 怎么敲都看不到 GPU，最后才发现是会话权限没刷新。

重启后先跑两行最基础的验证命令：

rocminfo rocm-smi

如果rocm-smi能显示你的集成 GPU 型号，比如 Radeon 8060S/8050S 或者 Strix Halo 相关设备名，那说明驱动和运行时已经基本打通。如果只看到系统里的其他 AMD 设备或者空列表，就要进入下面的排错环节。

4.4 用带宽测试确认性能是否正常

很多人验证完 rocminfo 就算了，但我会建议再跑一次带宽测试，因为 AI Max 395 的性能上限主要由内存带宽决定，提前测出带宽异常能省掉后面排查“为什么这么慢”的时间。

rocm-bandwidth-test

这个工具会测 device-to-device、host-to-device 等几种传输路径。在 Strix Halo 这种统一内存架构上，数值通常和 LPDDR5x 标称带宽有差距，但不会差得离谱。如果你发现读写带宽只有标称的一半，先检查是不是散热限制功耗，再检查 UMA 框是否开太小导致 GTT 频繁参与。

5. 初次上手最容易踩的四个坑，附排查思路

5.1 lspci 一点 AMD 都搜不到

很多人习惯用lspci | grep -i amd看显卡是否被系统识别，如果完全没有输出就慌了。这一步要注意：lspci列出的 PCI 设备可能不包含集成显卡，或者显卡被放到不显眼的分类里。更靠谱的查法是：

sudo lspci -nnk | grep -iA3 -B3 vga ls -l /dev/dri/

如果/dev/dri下没有renderD128，那说明内核的 amdgpu 驱动没有成功绑定设备。先去 BIOS 确认 iGPU 有没有被禁用，然后看dmesg | grep -i amdgpu里是否报了固件缺失。

5.2 /dev/dri/renderD128 不存在，多半是固件问题

AMD 显卡在内核驱动起来时需要 microcode 固件，这些固件在linux-firmware包里。如果更新内核后没同步更新固件，设备节点就不会生成。解决办法：

sudo apt install --reinstall linux-firmware sudo reboot

我自己遇到过一次很诡异的情况：刚装完 Ubuntu 24.04 时一切正常，后来手动升级内核到 HWE 版本后才出现 renderD128 消失。最后排查下来就是新内核和旧 linux-firmware 不匹配，更新固件就好了。

5.3 rocm-smi 正常，但应用找不到设备

这一条坑得最多，特别是刚接触 HIP 的人。系统层面rocm-smi能看到 GPU，但跑 PyTorch 或 vLLM 时却说找不到设备。原因通常是应用读取的是另一套可见性变量，默认枚举不到设备。

可以手动指定：

export HIP_VISIBLE_DEVICES=0 export ROCR_VISIBLE_DEVICES=0

如果是多设备环境，用rocminfo看到的逻辑序号不一定和设备位置一致，先用rocm-smi确认好实际逻辑编号再设置环境变量。

5.4 跑大模型时系统内存突然告急

在 128GB 机器上跑大模型，最怕的不是算力不够，而是显存池和系统内存互相抢。即使 UMA 只划了 64GB，ROCm 在某些情况下仍然可能通过 GTT 把更多内存映射给 GPU，结果就是模型在跑，系统侧不断触发 OOM，最后整个图形界面都卡死。

避免办法有两个：一是给 GPU 分配足够大的 UMA，让它尽量少走 GTT；二是在启动推理服务时用容器或控制组限制内存配额，不要让进程无限制膨胀。另外，不要为了追求高频去 BIOS 里乱关电流限制和功耗墙，Strix Halo 的内存控制器对温度和供电很敏感，强行解锁短期看不出问题，长期跑负载很容易不稳定。

6. 社区资源和性能参照：跑 LLM 之前先看这些

6.1 主流框架对 Strix Halo 的支持要看最新 Release

Ollama、vLLM、llama.cpp 对 AI Max 390/395 这类新设备的支持是持续变动的。如果你在某个教程里看到“叉烧包不兼容”，那大概率是几个版本前的旧结论。我的习惯是去每个项目的 GitHub Release Notes 里搜 Strix Halo 或 Radeon 8060S 关键词，确认当前版本是否有针对性的修复。

AMD 自己也会维护一些针对 ROCm 的分支和示例仓库，尤其是大模型推理方向，官方会不定期放出针对特定 API 的优化版本。这些仓库通常命名比较直接，搜索关键词可以用“ROCm vLLM”“ROCm ollama”“ROCm llama.cpp”加上“strix halo”过滤。

6.2 128GB 统一内存对量化模型的实际意义

以一个 70B 参数模型为例，Q4_K_M 量化后的权重大约在 40GB 上下，加上 KV Cache 和推理中间张量，一个会话轻松吃掉 45GB 以上。在传统 24GB 显卡上，这基本没戏；但在 AI Max 395 的 128GB 版本上，只要给 GPU 划 96GB，系统和权重都能舒服地放下。

这也是我为什么推荐至少分 64GB 给 GPU 的原因。16GB 或 32GB 的版本虽然也能玩，但可跑的模型范围会窄很多，性价比完全不如买顶配内存版。

6.3 社区实测数据和 Benchmark 去哪找

性能数据优先看三个地方：ROCm 官方文档里的平台说明、GitHub Issue 里用户贴出的测试截图、以及 Hugging Face 相关模型卡片的讨论区。很多玩 Strix Halo 的玩家会分享自己的 token/s、带宽测试结果和 BIOS 设置。注意采集基准时确认对方的 UMA 分配和散热条件，不然数字没有可比性。

从我自己和身边朋友跑下来的经验看，AI Max 395 在 ROCm 下的算力吞吐确实已经能接近入门级独显，但真实瓶颈永远是内存带宽。跑小 batch 推理时差距不大，一上大 batch 或长上下文，带宽直接决定天花板。

7. Windows 侧：显存分配和右键菜单两个小事

7.1 用 Auto-Detect 工具更新驱动，但别把 ROCm 希望寄托在 Windows

Windows 下的驱动更新建议直接用 AMD Auto-Detect and Install Tool，它会自动识别你的 CPU/GPU 组合并安装匹配版本。装完之后，AMD Software: Adrenalin Edition 也会一起进来，日常游戏和应用没有大问题。

但我要再强调一遍：ROCm 的完整功能支持在 Windows 上目前还比较有限。如果你只是想在 Windows 上偶尔跑个小推理 demo，那没问题；如果要正经做开发或者跑长任务，老老实实回 Linux 原生环境。两边切换的成本其实不高，Ubuntu 24.04 装好 ROCm 之后稳定得很。

7.2 右键菜单里的 AMD Software 入口怎么去掉

很多人被右键菜单里的“AMD Software: Adrenalin Edition”困扰。新版驱动里可以在 AMD Software 设置中找到“右键菜单”相关选项并关闭，路径一般在设置-首选项里，不同版本措辞略有差异。

如果你的驱动版本没有这个开关，也可以通过注册表清理：

Win+R -> regedit 备份后定位到 HKEY_CLASSES_ROOT\Directory\Background\shell\ACE 删除整个 ACE 项

操作前务必先导出备份。这个分支就是资源管理器右键菜单里 AMD Software 入口的注册项，删掉后一般不需要重启，刷新一下就能看到效果。按这个思路，你还可以顺手清理其他想要去掉的显卡工具右键项，只要先看 shell 下面有哪些名字对应的菜单项，再决定删哪个。我自己更倾向于直接关掉这类右键项，文件管理器菜单清爽一点，日常操作顺心很多，依赖菜单入口的机会本来就不多。