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 驱动不匹配。从那以后我养成了一个习惯装好环境之后立刻锁定内核版本不让它自动升级。下面这张表是我整理的一个大致对应关系注意具体版本号会随时间变化这里给的是思路组件选择原则注意事项操作系统Ubuntu LTS 版本用官方长期支持版别追新内核与 ROCm 官方文档一致装完锁定禁止自动升级ROCm选官方标注 stable 的版本别用最新预览版PyTorch用 ROCm 官方预编译包别自己从源码编除非必要Python3.10 或 3.11太新太旧都容易出问题提示每次动版本之前先用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 [archamd64] 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_VERSION11.0.0 # 某些不被官方支持的卡需要这个 export PYTORCH_HIP_ALLOC_CONFexpandable_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_HIPBLASON -DAMDGPU_TARGETSgfx1100 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 --ipchost \ -v /path/to/models:/models \ rocm/vllm:latestvLLM 在 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 框架选型对照表框架适合场景ROCm 成熟度上手难度llama.cpp单机推理、GGUF 模型高低vLLM服务化、高吞吐中高中ONNX Runtime跨平台、ONNX 模型中中PyTorch 原生微调、自定义中高MLC-LLM端侧部署中中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 问题速查表现象可能原因解决方向rocm-smi 无输出驱动/权限/架构不支持查驱动、加组、设 GFX 变量PyTorch 用不了 GPU装了 CPU 版 torch重装 ROCm 版模型加载 OOM显存分配不足调 BIOS 显存推理极慢模型没上 GPU检查 offload 日志编译报错架构代号填错查正确 gfx 代号内核升级后失效DKMS 没跟上锁定内核版本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 生态确实不如另一家成熟但它的进步速度肉眼可见。现在遇到的很多坑过半年可能官方就修了。保持耐心遇到问题多搜多问这个平台的潜力是实打实的。