Ryzen AI Max 395 本地 AI 推理实战：ROCm 环境搭建与框架适配资源清单

1. 为什么这套组合值得单独整理一份资源清单

AMD 这两年在本地 AI 推理这条线上动作不小，尤其是 Ryzen AI Max 395 这颗 APU 出来之后，很多人的第一反应是"这玩意儿到底能不能跑大模型"。我一开始也是抱着怀疑态度去折腾的，毕竟过去几年本地推理基本被某家生态垄断，换平台意味着大量踩坑。但实际用下来，Ryzen AI Max 395 配合 ROCm 这套组合，在特定场景下确实有它独特的价值，尤其是统一内存架构带来的大显存优势，是很多独立显卡方案给不了的。

这篇内容主要面向三类人：一是手里已经有或者准备入手 Ryzen AI Max 395 设备，想搞清楚它能干什么的；二是想从零搭建本地 AI 推理环境，但预算和功耗敏感的个人开发者；三是已经在用 ROCm，但被各种版本兼容问题折磨得够呛，想找一份相对完整资源索引的老玩家。我会把硬件特性、ROCm 安装、推理框架适配、常见坑这几个维度都过一遍，尽量把散落在各处的信息汇总成一份能直接照着做的清单。

需要先说明一点，AMD 的 AI 软件栈迭代速度非常快，ROCm 的版本号几个月就跳一次，很多教程过两个月就失效了。所以我在整理的时候，会更侧重"思路"和"排查方法"，而不是死记某个具体命令。你把底层逻辑搞明白了，版本变了也能自己推出来该怎么做。

2. Ryzen AI Max 395 硬件底子到底强在哪

2.1 统一内存架构才是真正的杀手锏

Ryzen AI Max 395 最核心的卖点不是 CPU 核心数，也不是 GPU 的算力峰值，而是它的统一内存架构。传统独显方案里，显存是独立的一块，比如 16GB 显存就只能跑 16GB 以内的模型，超了就 OOM。而 Ryzen AI Max 395 允许系统把一部分内存划给 GPU 当显存用，最高可以做到 96GB 甚至更多的显存分配（取决于整机内存容量和 BIOS 设置）。

这意味着什么？你可以在一台功耗几十瓦的小机器上，跑一个 70B 级别的量化模型。虽然推理速度比不上高端独显，但"能跑起来"和"跑不起来"是质的区别。我实测下来，用 4bit 量化的 70B 模型，在 128GB 内存的 Ryzen AI Max 395 设备上，显存分配调到 96GB，是可以完整加载的，token 生成速度大概在每秒几个 token 的水平，做离线批处理或者个人助手完全够用。

这里有个关键点很多人会忽略：显存分配是在 BIOS 里设置的，不是操作系统层面动态调整的。你买机器的时候如果只配了 64GB 内存，那能分给 GPU 的上限就有限。所以选购设备时，内存容量比 CPU 型号更值得关注。我的建议是至少 64GB 起步，想跑大模型直接上 128GB。

2.2 算力定位要摆正预期

Ryzen AI Max 395 的 GPU 部分是基于 RDNA 3.5 架构的集成显卡，算力大概在几十 TFLOPS 的级别（FP16）。这个数字放在独显里不算突出，但考虑到它的功耗和体积，性价比是成立的。你要拿它去和高端独显比训练速度，那肯定不现实；但做推理、做微调、做本地 RAG，它是能胜任的。

我个人的经验是，把这颗芯片定位成"低功耗本地推理工作站"最合适。它的优势场景是：7x24 小时常开、功耗敏感、需要大显存、对延迟不极端敏感。比如家里放一台做私人知识库问答，或者做批量文档处理，这种场景它比独显方案更合适，因为独显方案要么显存不够，要么功耗和噪音上去了。

2.3 内存带宽是隐藏的瓶颈

有一点必须提前打预防针：统一内存架构虽然解决了容量问题，但内存带宽是共享的。CPU 和 GPU 抢同一块内存的带宽，实际推理速度会受内存频率和通道数影响。LPDDR5X 的带宽虽然不低，但和独显的 GDDR6/GDDR7 比起来还是有差距。所以你会看到一个现象：同样的模型，Ryzen AI Max 395 能加载，但生成速度明显慢于同显存容量的独显。

这不是缺陷，是架构取舍。你要的是"能跑大模型"还是"跑得飞快"，得先想清楚。想清楚之后，很多预期落差就不会有了。

3. ROCm 环境搭建的完整路径

3.1 先搞清楚 ROCm 是什么、不是什么

ROCm 是 AMD 的开放计算平台，对标的是另一家的 CUDA。它包含运行时、编译器、数学库、通信库这一整套东西。很多人第一次接触会以为装个 ROCm 就万事大吉了，其实不是——ROCm 只是底层，上面还要有 PyTorch、ONNX Runtime 这些框架的支持才能跑模型。

这里有个认知误区要纠正：ROCm 不是驱动。驱动是内核层面的东西，ROCm 是用户态的软件栈。你装 ROCm 之前，系统驱动得先到位。在 Linux 上，通常通过发行版的包管理器或者 AMD 官方源来装驱动和 ROCm；在 Windows 上，情况更复杂一些，官方支持一直在推进，但成熟度不如 Linux。

我的建议很直接：想认真玩 ROCm，就用 Linux。Ubuntu 或者 Fedora 都行，Ubuntu 的社区资料更多，遇到问题好搜。Windows 上虽然也能跑，但坑多，而且很多推理框架的 ROCm 后端在 Windows 上支持不完整。

3.2 版本匹配是最大的坑

ROCm 生态最让人头疼的就是版本匹配。ROCm 版本、PyTorch 版本、Python 版本、内核版本，这四个东西之间有一张隐形的兼容性矩阵。你随便升级其中一个，可能整个环境就崩了。

我踩过最典型的一次坑：系统自动更新把内核升了，结果 ROCm 的 DKMS 模块没跟上，GPU 直接识别不到。排查了半天才发现是内核版本和 ROCm 驱动不匹配。从那以后我养成了一个习惯：装好环境之后立刻锁定内核版本，不让它自动升级。

下面这张表是我整理的一个大致对应关系，注意具体版本号会随时间变化，这里给的是思路：

提示：每次动版本之前，先用rocm-smi确认当前环境是好的，改完之后再确认一次。这样出问题能快速定位是哪一步引入的。

3.3 安装步骤的实操记录

我以 Ubuntu 为例，把大致流程走一遍。注意具体命令里的版本号你要根据当时官方文档替换。

第一步是装驱动和 ROCm 仓库。AMD 官方提供了一个 amdgpu-install 脚本，但我不太推荐直接用那个一键脚本，因为它会装一堆你可能用不到的东西。更干净的做法是手动添加官方 apt 源，然后按需安装。

# 添加 AMD 官方 GPG key 和源（版本号按官方文档替换） wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | sudo apt-key add - echo 'deb [arch=amd64] https://repo.radeon.com/rocm/apt/6.x/ ubuntu main' | sudo tee /etc/apt/sources.list.d/rocm.list sudo apt update

第二步是安装核心包。这里我建议只装必要的，别贪多：

sudo apt install rocm-hip-sdk rocm-opencl-sdk

装完之后把当前用户加入 render 和 video 组，否则权限会有问题：

sudo usermod -aG render,video $USER

然后重启，重启之后用rocm-smi验证。如果能看到 GPU 信息，说明底层通了。

第三步是装 PyTorch 的 ROCm 版本。这一步千万别用pip install torch，那样装的是 CPU 版或者 CUDA 版。要去 PyTorch 官网找 ROCm 对应的安装命令，通常是这样的形式：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.x

装完之后进 Python 验证：

import torch print(torch.cuda.is_available()) # ROCm 环境下这个也返回 True print(torch.cuda.get_device_name(0))

如果这两行能正常输出，恭喜你，最难的坎已经过了。

3.4 环境变量别漏了

有几个环境变量在 ROCm 环境下经常需要手动设置，尤其是跑多卡或者特定框架的时候：

export HSA_OVERRIDE_GFX_VERSION=11.0.0 # 某些不被官方支持的卡需要这个 export PYTORCH_HIP_ALLOC_CONF=expandable_segments:True # 缓解显存碎片

HSA_OVERRIDE_GFX_VERSION这个变量特别重要。Ryzen AI Max 395 的核显有时候不在 ROCm 官方支持列表里，通过这个变量可以"伪装"成受支持的架构，让 ROCm 认它。具体填什么值取决于你的 GPU 架构代号，这个得查资料确认，填错了会直接崩。

4. 推理框架的适配与选型

4.1 llama.cpp 的 ROCm 后端

如果你主要跑 GGUF 格式的量化模型，llama.cpp 是最省心的选择。它对 ROCm 的支持比较成熟，编译的时候开启 HIP 后端就行。

编译命令大致是这样：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_HIPBLAS=ON -DAMDGPU_TARGETS=gfx1100 cmake --build build --config Release -j$(nproc)

这里的AMDGPU_TARGETS要填你实际的架构代号。Ryzen AI Max 395 对应的代号需要查一下，填错了编译能过但跑起来会报错。

编译完之后跑模型：

./build/bin/llama-cli -m model.gguf -ngl 999 -p "你的提示词"

-ngl 999的意思是尽可能多的层放到 GPU 上。因为统一内存架构显存大，这个值可以设得很高，让模型尽量跑在 GPU 上。

我实测下来，llama.cpp 在 ROCm 上的稳定性不错，但首次加载模型会比较慢，因为要编译 kernel。第二次加载就快了。所以别以为第一次卡住是出问题了，耐心等。

4.2 vLLM 的 ROCm 支持

vLLM 是另一个主流选择，优势是吞吐量高，适合做服务化部署。它对 ROCm 的支持这几年进步很大，但配置起来比 llama.cpp 麻烦。

装 vLLM 的 ROCm 版本，通常要用官方提供的 Docker 镜像，因为自己编译依赖太多。用 Docker 的话，记得把 GPU 设备映射进去：

docker run -it --device=/dev/kfd --device=/dev/dri \ --group-add video --ipc=host \ -v /path/to/models:/models \ rocm/vllm:latest

vLLM 在 Ryzen AI Max 395 上跑，要注意显存分配和 batch size 的平衡。因为内存带宽有限，batch size 开太大反而会拖慢速度。我的经验是从小 batch 开始试，逐步往上加，找到吞吐量的拐点。

4.3 ONNX Runtime 和其他选择

如果你跑的是 ONNX 格式的模型，ONNX Runtime 有 ROCm 的执行提供器。这个在 Windows 上支持相对好一些，适合不想折腾 Linux 的人。但生态没有 PyTorch 那么丰富，模型转换有时候会丢精度。

还有像 MLC-LLM、ExLlamaV2 这些，对 ROCm 的支持程度不一。我的建议是优先选社区活跃、ROCm 相关 issue 多的框架，因为遇到问题能搜到答案。冷门框架在 ROCm 上出问题，基本只能自己啃源码。

4.4 框架选型对照表

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

5.1 GPU 识别不到怎么办

这是最高频的问题。rocm-smi报 "No GPU found" 或者 PyTorch 里cuda.is_available()返回 False，排查顺序是这样的：

先确认内核模块加载了没有，lsmod | grep amdgpu看有没有输出。没有的话说明驱动没装好，回去检查驱动安装步骤。有输出但 rocm-smi 还是找不到，大概率是权限问题，确认用户在 render 和 video 组里，而且改完组之后要重新登录才生效，光重启服务不够。

如果权限没问题还是找不到，那就是架构不被支持，需要设HSA_OVERRIDE_GFX_VERSION。这个值怎么确定？去查你的 GPU 架构代号，然后找一个 ROCm 官方支持列表里同架构的值填进去。

5.2 显存分配不够怎么调

前面说过显存是在 BIOS 里分的。如果你发现模型加载到一半 OOM，但系统内存明明还有富余，那就是 BIOS 里给 GPU 分少了。重启进 BIOS，找类似 "UMA Frame Buffer Size" 或者 "GPU Memory Allocation" 的选项，调大。

不同厂商的 BIOS 叫法不一样，有的藏在高级设置里。调完之后进系统用rocm-smi --showmeminfo vram确认实际可用显存。

注意：显存分多了，系统可用内存就少了。128GB 内存分 96GB 给 GPU，系统只剩 32GB，跑大模型加载的时候系统本身也要占内存，别分得太极限，留点余量。

5.3 推理速度慢的优化思路

速度慢先别急着换硬件，按这个顺序排查：

第一，确认模型真的跑在 GPU 上。llama.cpp 里看日志有没有 "offloaded X layers to GPU"，如果全是 CPU 在跑，那当然慢。第二，检查内存频率，BIOS 里内存是不是跑在标称频率上，有时候默认是降频跑的。第三，看是不是内存带宽打满了，用rocm-smi监控 GPU 利用率，如果利用率不高但速度慢，瓶颈可能在内存带宽或者 CPU 侧的数据搬运。

优化手段上，量化等级是影响最大的。Q4 比 Q8 快很多，精度损失在可接受范围内。另外 context length 别设太大，KV cache 占显存也占带宽。

5.4 问题速查表

5.5 几个我踩过的坑

第一个坑是盲目追新。看到 ROCm 出新版本就升，结果新版本对老框架支持不好，折腾半天回滚。现在我都是等新版本出来一两个月，社区反馈稳定了再升。

第二个坑是Docker 里跑 ROCm 忘了映射设备。容器里 rocm-smi 找不到 GPU，查了半天才发现是--device参数没加。这个错误很隐蔽，因为容器能起来，只是用不了 GPU。

第三个坑是内存超频导致不稳定。为了追求带宽把内存频率拉高，结果跑大模型的时候随机崩溃。后来降回默认频率，稳定性立刻好了。本地推理场景，稳定性比那点性能提升重要得多。

6. 资源汇总与后续扩展方向

6.1 值得收藏的资源类型

折腾 ROCm 这段时间，我总结出几类必须常备的资源。第一是 AMD 官方的 ROCm 文档，尤其是 compatibility matrix 那一页，装环境之前必看。第二是各个推理框架的 GitHub issue 区，搜 "ROCm" 加你的报错信息，大概率有人遇到过。第三是社区论坛里关于 Ryzen AI Max 的讨论帖，硬件层面的坑那里最全。

模型资源方面，GGUF 格式的量化模型在 Hugging Face 上很丰富，选的时候注意看有没有人反馈在 ROCm 上跑过。有些模型转换的时候用了 CUDA 特有的算子，在 ROCm 上会报错，这种要避开。

6.2 这套组合还能怎么扩展

Ryzen AI Max 395 加 ROCm 的玩法不止推理。往上可以搭本地 RAG 系统，用向量数据库加嵌入模型，做一个完全离线的知识库。嵌入模型对算力要求不高，这颗芯片跑起来很轻松。再往上可以做模型微调，LoRA 这种轻量微调在统一内存架构上是有可行性的，因为显存够大，能放下更大的 batch。

另一个方向是多机协作。如果你有两台这样的设备，可以通过分布式推理框架把模型拆开跑，突破单机内存上限。这个我还没深入折腾，但思路是通的，值得后续研究。

6.3 给新手的最后几句实在话

如果你刚入手 Ryzen AI Max 395，别一上来就想着跑最大的模型。先用小模型把环境跑通，确认 ROCm、PyTorch、推理框架这条链路是通的，再逐步加大模型。环境不通的时候去调大模型，你根本分不清是环境问题还是模型问题。

还有就是做好版本管理。把能跑通的环境配置记下来，包括 ROCm 版本、内核版本、框架版本、环境变量。下次环境崩了，照着记录回滚，比重新排查快得多。我自己是维护了一个脚本，一键恢复环境，省了很多事。

ROCm 生态确实不如另一家成熟，但它的进步速度肉眼可见。现在遇到的很多坑，过半年可能官方就修了。保持耐心，遇到问题多搜多问，这个平台的潜力是实打实的。