最近在整理 AMD AI Max 395 和 ROCm 的资料时，发现网上的信息散得离谱：官方文档讲架构，GitHub 仓库讲驱动，Reddit 讨论讲性能，中文社区大多在晒跑分截图，真正把“从买机器到跑通本地 AI”这条链路串起来的文章几乎没有。这篇东西就是我把自己翻过的资源、实际装过的环境、踩过的坑，以及从社区里捞出来的有效工具链路汇总到一起，给准备用 AI Max 395 玩 ROCm 的朋友做个参考。不管你是刚入手这台 APU 机器，还是正在纠结要不要上 ROCm，这篇文章都能省下你几个通宵。
1. 先搞清楚 AI Max 395 这颗芯片的脾气
1.1 核心规格速览：它不是一块普通 APU
AMD 给 Ryzen AI Max 395 的定位不是“带集显的 CPU”，而是把 Zen 5 架构 CPU、RDNA 3.5 架构 GPU、XDNA 2 架构 NPU 全部塞进一个封装里。CPU 部分最多 16 核，GPU 部分有 40 个计算单元，NPU 算力在 50 TOPS 上下。这些参数对跑分有意义，但真正影响 ROCm 体验的，是它的内存系统。
这颗芯片支持 LPDDR5X 统一内存池，最高可以配 128GB，内存总线带宽做到 256GB/s。这个数字得放在上下文里看：一块普通 RTX 4060 的显存带宽大概是 272GB/s，而 AI Max 395 在笔记本的功耗范围内做到了接近独显的带宽，同时让 CPU、GPU、NPU 共享同一块内存，这决定了它跑 AI 模型的上限不在“显存大小”，而在“带宽和功耗”。
规格参数可以参考下面这张表：
| 项目 | 典型配置 | 备注 |
|---|---|---|
| CPU | Zen 5 架构，最多 16 核 | 移动端旗舰水平 |
| GPU | RDNA 3.5，40 CU | ROCm 识别为 gfx1151 系列的 APU 图形核 |
| NPU | XDNA 2，约 50 TOPS | 主要用于端侧小模型和加速应用 |
| 内存 | LPDDR5X，最高 128GB | 统一内存架构，GPU 可直接寻址 |
| 内存带宽 | 最高 256GB/s | 对 ROCm 计算性能起决定性作用 |
| 默认美学 | 发热和功耗墙比较敏感 | 后续章节会展开讲 |
刚开始我在 Windows 底下折腾时，下意识把它当作“CPU 加一张小独显”来处理，结果后面很多问题都出在这个错误的认知上。ROCm 对这套架构的调度方式，和独立显卡完全不一样。
1.2 统一内存池：ROCm 最大的红利也是最大的麻烦
ROCm 的编程模型本来是为独立 GPU 设计的，显存是显存，内存是内存，数据要从 CPU 内存拷贝到 GPU 显存里。但 AI Max 395 的内存池是统一的，GPU 可以寻址整个系统内存。这带来一个听起来很美好的东西：零拷贝。从 CPU 读数据、GPU 算数据，不再需要显式的 memcpy，驱动层可以直接通过 GTT 路径访问内存。
好处是，你不需要为了跑一个大模型去精打细算“8GB 够不够”，直接给它 20GB 内存跑 14B 模型也不会立刻爆炸。
麻烦也在这里。统一内存意味着“显存压力”变成了“总内存压力”。系统要同时承担操作系统、浏览器，还要填进去模型权重、KV Cache、临时推理缓冲区。我在一台 64GB 内存的 AI Max 395 机器上跑 14B 模型时，系统内存占用一度超过 45GB，如果不是统一内存池，这根本不可能发生。但反过来，如果同时开着 Chrome、Electron 软件、编译任务，内存一满，模型推理速度会断崖式下降。
另外，不是所有 ROCm 应用都对统一内存优化到位。很多框架会默认认为显存和内存地址空间是分开的，虽然 HIP 能识别到 agent，但某些库的 allocator 还是会走显排除路径。这个要靠环境变量和框架本身的适配来绕，后面章节会讲。
1.3 别拿它和独显比：适合什么不适合什么
明确一点：AI Max 395 不是 RTX 4060 的替代品，也不是 MI 系列计算卡的平替。它的定位是轻量级本地 AI 工作站。
- 适合：本地推理 8B 到 14B 的大语言模型、跑 Stable Diffusion、做 RAG 知识库、小批量微调（LoRA 级别）、日常开发调试 ROCm/HIP 程序。
- 不太适合：大规模多卡训练、需要数千 GB/s 带宽的高性能计算任务、频繁做全参数微调的负载。
为什么？因为 256GB/s 的带宽摆在那里。做推理时，模型权重要从内存流进 CPU，带宽就是吞吐量的物理上限；而训练任务更在意持续算力和数据的反复搬运，这种 APU 的功耗限制会很快变成瓶颈。所以资源汇总的第一步，是先管理好你的预期：这台机器能让你在桌面环境下舒服地玩本地模型，但别指望它干 MI300X 的活。
2. ROCm 环境搭建：从系统检查到第一个矩阵跑通
2.1 安装之前先确认三件事
我踩过的最大的坑，是没检查环境就一股脑装驱动，结果报错后再回头查，浪费时间。AI Max 395 上装 ROCm，有三件事一定要提前确认。
第一，操作系统。我目前测试下来最稳的是 Ubuntu 24.04 LTS，其次是 22.04 LTS。不要用 Arch 或者刚发布的滚动发行版，除非你愿意每天处理依赖断裂问题。Windows 对 ROCm 的支持非常有限，虽然你可以通过 WSL2 跑，但底层还需要 Windows 驱动配合，稳定性远不如原生 Linux。
第二，内核版本。ROCm 对内存管理、KFD 驱动的依赖很强，内核太老或太新都会出问题。Ubuntu 24.04 自带的内核版本基本能直接支持，不用专门换主线内核。
第三，BIOS 设置。进入 BIOS 后找到 UMA Frame Buffer Size（不同厂商名字可能不一样，也可能叫 Dedicated Graphics Memory）。这个值默认可能是 512MB 或 1GB。别急着拉满，它只是给 GPU 预保留的固定内存，不是模型可用显存上限。真正跑 ROCm 的时候，GPU 会自主分配系统内存。UMA 值设得过高反而会吃掉可用内存，保持默认或者 1GB 就够。
2.2 驱动与 ROCm 安装：两条路线我建议怎么走
AMD 官方推荐的安装方式是下载amdgpu-install的 deb 安装包，用这个包同时安装驱动和 ROCm。不建议用 apt 直接搜rocm，因为仓库里的版本经常落后，而且缺少芯片适配补丁。
我自己用的步骤大致如下：
# 到 https://rocm.docs.amd.com 拿当前版本的 amdgpu-install 包 sudo apt update sudo apt install "linux-headers-$(uname -r)" "linux-modules-extra-$(uname -r)" sudo apt install ./amdgpu-install_*.deb sudo amdgpu-install --usecase=rocm --no-dkms注意--no-dkms这个参数。DKMS 的好处是当内核更新后会自动重编驱动，坏处是如果编译器版本不对，内核一更新驱动就挂掉。我在 24.04 上试过带 DKMS，重启后就遇到内核模块无法加载的问题。后来改用--no-dkms，只在当前内核上装驱动，目前稳定运行。
装完之后，把当前用户加入render和video组，否则跑 ROCm 应用会因权限不足失败：
sudo usermod -aG render,video $USER然后重启。这部分没有太多玄学，关键点在于：别为了“最新”去装 ROCm 的 nightly 版，除非你是专门做软件栈开发的。稳定版优先。
2.3 设备识别验证：lspci 看不到 AMD 设备的排查思路
有一个热词非常典型：lspci | grep -i amd 无反应。很多人装完驱动后执行这条命令，发现什么输出都没有，就慌得不行。先别慌，这大概率是正常的。
lspci是在 PCI 总线层面枚举设备，而 AI Max 395 的 GPU 核并不是一块插在 PCIe 插槽上的独立显卡，它和 CPU 在同一个 SoC 里。在 Linux 的 PCI 枚举中，很多 APU 的显示设备并不会在基本型号字符串里带AMD字样，而是显示类似VGA compatible controller [Vendor ID:1002]。如果你只 grepAMD，当然什么都搜不到。
更可靠的方法是直接看系统有没有加载对应的计算节点：
ls /dev/kfd /dev/dri如果能看到/dev/kfd和/dev/dri/renderD128，说明驱动已经加载，ROCm 的 Compute Agent 是可用的。再用：
rocminfo它会列出系统中所有 ROCm agent，包括 CPU Agent 和 GPU Agent。如果 GPU Agent 的类型显示GPU，并且 GFX 版本对应你的 APU，就说明驱动路径没问题。
2.4 跑第一个 PyTorch 矩阵验证
验证环境最简单的办法是装一个 PyTorch ROCm 版，然后跑矩阵乘法。这里有个细节：PyTorch ROCm 版本目前只能通过第三方索引安装，比如pip install torch --index-url https://download.pytorch.org/whl/rocm6.x。装完之后测试：
import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))有些朋友看到torch.cuda.is_available()返回False就以为没装好，其实在 ROCm 后端里，torch.cuda这个命名空间被保留了，只要你的安装包是对应 ROCm 版本，这个函数返回True就代表 HIP 后端可用。设备名应该能识别到你的 APU GPU 型号。
然后跑一个 4096x4096 的矩阵乘法，看看是否正常运行：
a = torch.randn(4096, 4096, device='cuda') b = torch.randn(4096, 4096, device='cuda') c = a @ b print(c.shape)如果顺利出结果，ROCm 核心链路就已经通了。这里不用管跑分，先确保计算图、内存分配和 Kernel Launch 都没问题。
3. 硬核资源清单：官方文档、代码仓库和命令行工具
3.1 官方文档入口，别走错门
ROCm 的官方文档现在都收敛在rocm.docs.amd.com，不要去老域名或者各种镜像站。我建议按顺序读这几个核心板块：
- Installation Guide：安装步骤和系统支持矩阵，别跳过。
- HIP Programming Guide：如果你要自己写 Kernel，这本必读，否则可以先放一放。
- ROCm Compatibility Matrix：查硬件和驱动版本对应关系。
另外重点提一下rocm-smi，它不是文档，是一个命令行工具，可以查看当前 GPU agent 的使用率、温度、功耗。在 AI Max 395 上，某些独显专属的显存占用项会显示为 0，这是正常的，因为统一内存的占用需要看umc相关指标或者直接看系统free -h。
推荐把官方下载页的 RSS 加上，ROCm 的版本更新非常快，一个月不出新版本都不正常。
3.2 GitHub 仓库：装机脚本和示例代码
资源不只是在文档里，真正的活跃内容在 GitHub。以下仓库我反复翻过：
| 仓库 | 用途 | 推荐度 |
|---|---|---|
ROCm/ROCm | 所有子模块的汇总和兼容信息 | 必看 |
ROCm/rocm-examples | 官方的 HIP/OpenMP 示例，跑通后能练手 | 高 |
ROCm/HIP | HIP 运行时和编程接口实现 | 排查疑难时用 |
ROCm/rocSPARSE等计算库 | 稀疏矩阵、FFT 等高性能库 | 按需 |
做资源汇总时，我还强烈推荐看ROCm/llvm-project的amd-stg-open分支。虽然它肯定不会给你开箱即用的东西，但遇到莫名其妙的内核崩溃或编译错误，PR 和 issues 里经常有人已经找到了临时解决办法。
对于 AI Max 395 这类新硬件，GitHub Issues 往往比官方文档更早反映问题。搜索关键词的时候用gfx1151或者Strix Halo，能被官方支持说明里的含糊措辞骗到的时间能缩短一半。
3.3 基准测试与监控工具
跑分不是必须的，但一套可复现的基准能帮你判断驱动版本变化和内核改动是变好还是变坏。我常用以下组合：
rocm-smi：快速看温度、功耗。rocprof：做 Kernel 级别的 Profiling，找瓶颈用。pyperf加一个 PyTorch 脚本：测量各类矩阵乘法和 Transformer 层的延迟。
如果想自己写小脚本，建议测三个项目：memcpy带宽、GEMM算力、MHSA层的运行时间。对于 AI Max 395，memcpy带宽这一项特别能反映统一内存的真实效率，直接在 ROCM 上用hipMemcpy测大块数据拷贝，如果发现带宽远低于 256GB/s，说明驱动或内存路由有问题，需要调 NUMA 相关参数。
网上很多人贴 Geekbench AI 或者 Procyon 分数，这类工具对 ROCm 的兼容性不稳定，跑出来的分只能看个乐，别当作决策依据。
3.4 推理框架怎么选：llama.cpp / Ollama / vLLM
这是大家最关心的部分。在 AI Max 395 上跑大模型，我的优先级是：
Ollama：新手最友好。它对 ROCm 的支持比较成熟，安装好后它会自动检测 HIP 设备。如果检测不到你的 APU，可以通过设置HSA_OVERRIDE_GFX_VERSION=11.0.0来临时强制兼容模式，但要注意这可能会引发性能和稳定性问题。我自己在 Ollama 上跑qwen3:8b是没问题的。
llama.cpp：自由度最高，性能天花板也最高。需要手动启用 HIP/ROCm 支持：
cmake -B build -DGGML_HIP_ROCm=ON -DAMDGPU_TARGETS=gfx1151 cmake --build build --config Release -j 8注意AMDGPU_TARGETS要根据你的芯片实际支持版本填。如果不填，默认目标列表很大，编译会慢。跑起来后用-ngl 999把所有层都放到 GPU 上，能榨干统一内存的带宽。
vLLM：适合做推理服务，但对 APU 的支持还在完善中，如果只是单机自己玩，不建议一开始就上。我踩过坑：vLLM 在启动时按 CUDA 思维假设了独立显存，结果内存池不够用，日志全是 allocation failure。如果你想跑服务，先把 vLLM 放到 Docker 里用 ROCm 镜像，再慢慢调。
4. 显存分配、功耗墙与常见驱动问题处理
4.1 手动分配显存：UMA 还是让驱动自己管
这个热词“ryzen ai max 395 如何手动分配显存”的搜索量一直很高，说明大家默认这是一张显卡，需要像 Windows 游戏那样设置“专用显存”。但 AI Max 395 是统一内存架构，答案有点反直觉：不需要手动分配，也不建议手动分配。
BIOS 里的 UMA Frame Buffer Size 设置，控制的是开机时预留给 GPU 编程接口的基本缓冲区，相当于给 GPU 一块“像显存的内存”来做显示输出和早期初始化的用。它不会决定你可以用多少内存跑 AI 模型。ROCm 的 HIP 运行时可以直接访问系统内存池，模型多大，它就会尝试分配多少，前提是系统内存有剩余。
如果你想对可用内存做“手动分配”，合理的方式不是在 BIOS 里砍内存，而是用容器限制内存大小，或者设置HIP_VISIBLE_DEVICES来指定计算设备，然后对进程做 cgroup 限流。比如用 systemd-run 限定某个推理服务只能使用 32GB 内存：
systemd-run --scope -p MemoryMax=32G ./llama-server ...这样既能防止 OOM 把桌面环境拖死，也能保住你“手动控制显存”的诉求。实际效果比动 UMA 安全得多。
4.2 功耗限制与 BPO：自动还是关
先声明一下，这里说的都是公开信息和我的实测，不涉及任何特殊工具。AI Max 395 的 TDP 控制在 BIOS/SoC 层面很激进，它会在你长时间满载时自动压低 CPU 和 GPU 的频率，保护散热系统。很多朋友看到电源管理相关设置里有“BPO”或类似选项，不知道应该“自动”还是“关闭”。
我的建议是：保持自动。除非你是极限玩家，愿意接受风扇噪音和潜在的不稳定，才去手动调整。BPO 这类选项影响的是基频提升和功耗分配策略，对 ROCm 计算的影响主要是“长稳性能”而不是“瞬间跑分”。
如果你发现跑推理跑久了速度变慢，先查温度，再查实际功率：
sudo rocm-smi --showtemp --showpower如果温度超过 90 度，重点不是改 BIOS，而是清理笔记本散热、垫高机器、调整风扇策略。软件层面硬改功耗限制风险不小，我一般不做。
4.3 驱动装不上的经典错误 2147942659
这是一个 Windows 下 AMD 显卡驱动的安装错误码，经常会出现在系统更新驱动、安装新版 Adrenalin 时。虽然它和 ROCm 没什么关系，但很多人看到“AMD 驱动错误”就以为是 ROCm 的问题，所以我还是把它放进来。
这个错误我用两个步骤解决了九成的情况：
- 下载 AMD Cleanup Utility，在安全模式下清理所有旧版驱动。
- 重启后关闭 Windows 的快速启动，用管理员权限重新安装驱动。
如果还不行，检查 Windows 更新有没有“可选更新”里的驱动组件。很多时候，错误 2147942659 是旧驱动残留和快速启动的锁文件冲突，跟硬件没什么关系。
真正要提醒的是：别在 Windows 上花太多时间解决这类问题。如果你想用 ROCm 跑 AI，直接装 Linux 或者开 WSL2，驱动问题会少一半。Windows 下的支持管线是为游戏显卡设计的，AI Max 395 的 ROCm 路径在 Linux 上才是正式主场。
4.4 右键菜单里的 AMD Software：怎么清理
热词里还有几个关于右键菜单的高频问题：怎么去掉 AMD Software 的右键条目，关闭 AMD Software: Adrenalin Edition 菜单。这是 AMD Adrenalin 软件更新之后一直存在的一个“烦人点”。它不是 bug，是产品选择，想关掉可以这样做：
打开 AMD Software: Adrenalin Edition，进入“设置” -> “偏好设置”，看一下有没有“在桌面快捷菜单中显示”“在上下文菜单中显示 Radeon”之类的开关，关掉即可。如果找不到这个开关，只能通过注册表或者 Windows 的“组策略”去隐藏，但不推荐给普通用户手改注册表。
既然到了这里，我再多说一句：这类右键菜单和驱动安装错误，本质上都是“用 Windows 驱动思维去对待 ROCm 平台”带来的困扰。真正想用 AI Max 395 干活，尽早切到 Linux 会舒服很多。
5. 信息甄别：别被名字听起来很牛的插件带偏
5.1 “DLSS5 插件 AMD 版”？先确认是不是 AI 幻觉
网络上经常有人搜“dlss5 插件 amd版下载”，这个词的搜索量高得离谱。严肃说一句：DLSS 是 NVIDIA 的超分辨率技术，有明确的硬件壁垒，它不存在官方“AMD 版”。AMD 自己的替代方案叫 FSR。
更麻烦的是，现在有些内容农场会用“DLSS5 插件 AMD版”这种关键词来吸引下载，实际给你的可能是恶意脚本或者旧版杂项工具。AI Max 395 玩 AI 绘画、游戏超分，应该关注 AMD 的 FSR 和 Ryzen AI 相关的 SDK，而不是 DLSS5 的“AMD 版”。
如果你真的想让 AMD 显卡跑 NVIDIA 生态里的模型，常见路径是用转换工具把 CUDA 模型转成 ONNX 或者直接用 PyTorch 的 ROCm 版，这不叫“DLSS5 插件”，而是通用的模型迁移。ROCm 自己也提供 HIPify 工具，可以把部分 CUDA 代码转成 HIP。
5.2 关于 AMD BPO、Auto-Tune 等热词的澄清
社区里很多词大家传着传着就变味了。比如“AMD BPO 是自动还是关”，其实在不同主板上它对应的选项含义不一样，甚至有主板品牌自己改过定义。我从经验角度说：这类设置对以 ROCm 为主力负载的用户影响不大，保持默认、维持系统稳定优先。
如果你看到某个 Twitch 或短视频博主说“关了 BPO 性能暴涨”，别立刻抄作业，先记录原版的 BIOS 设置，调整后跑测试对比，再决定要不要长期保留。电脑性能瓶颈在散热和内存带宽上的占比远大于电源管理选项。
5.3 资源获取的渠道优先级排序
最后把资源渠道排个序，这是我自己的信息获取优先级：
| 优先级 | 渠道 | 理由 |
|---|---|---|
| 1 | 官方文档和 Release Notes | 唯一权威，版本变化最清楚 |
| 2 | GitHub Issues 和 Pull Requests | 能反映最新 bug 和临时 workaround |
| 3 | AMD 社区论坛 / r/ROCm | 有大量一线用户实践，但需要甄别 |
| 4 | 中文博客和 B 站 / 短视频 | 方便入门，但很多已经过期 |
| 5 | 内容农场和下载站 | 尽量别碰，恶意风险高且信息滞后 |
ROCm 的生态不像 CUDA 那么“文档完备”，迭代快，很多方案三个月就过期。遇到问题先用英文搜，再用中文搜，能少走不少弯路。
说实话，我用 AI Max 395 跑 ROCm 这几个月，最大的体会是：这台机器的硬件底子非常好，统一内存架构让很多在低配 GPU 上跑不起来的模型终于能塞进笔记本里。但 ROCm 在 APU 上的成熟度确实还在追赶中，不能指望装了就能像 CUDA 那样顺手。如果你打算试，我建议从 Ollama 加 llama.cpp 入手，把官方文档链接和 GitHub 仓库先存好，遇到问题多查日志。驱动问题、权限问题、gfx 版本不匹配问题，八成都是环境配置的顺序问题，耐心做一次系统检查就能解决大半。希望这份资源汇总能帮你省下我当初踩坑时浪费的那些时间。
