AMD AI MAX 395 和 ROCm 这对组合最近在本地大模型圈子里讨论度确实高。AMD 这颗旗舰 APU 把 16 核 Zen 5、40 个 RDNA 3.5 计算单元和一块 XDNA 2 NPU 塞进同一颗芯片还能通过统一内存配置最多 128GB 的内存容量光看参数就足够让人兴奋。但硬件再强软件不跟上也是白搭。ROCm 作为 AMD 的 GPU 计算栈在这颗“非典型”的 APU 上到底能不能跑、好不好跑、怎么跑才是决定它能不能真正替代“CPU 独立显卡”方案的关键。这篇文章算是我这段时间折腾 AI MAX 395 和 ROCm 生态的完整资源汇总。里面既有硬件层面的架构拆解也有软件层兼容性的真实情况还有从零开始装环境、调推理引擎、跑大模型的具体操作和踩坑记录。不管你是已经入手了搭载这颗芯片的迷你主机还是单纯想评估“大显存 APU”这个新物种值不值得入局这篇文章应该都能给你一个比较靠谱的参照系。我会把官方资源、社区脚本、实用工具和性能参考数据都整理进来尽量做到拿来就能用。1. AMD AI MAX 395 硬件到底是什么水平1.1 一颗芯片搞定 CPU、GPU、NPU 三个角色AI MAX 395 最早出圈是因为 AMD 在 CES 2025 上发布了 Ryzen AI MAX 系列而 AI MAX 395 是里面的顶配型号。它用的是台积电 4nm 工艺CPU 部分是 16 核 32 线程的 Zen 5 架构基础频率 3.0GHz加速频率 5.1GHz单核和多核性能都相当能打基本上可以对标桌面级的中高端处理器。GPU 部分是这颗芯片真正的亮点。它集成了 40 个 RDNA 3.5 架构的计算单元也就是 2560 个流处理器。这个规模放在集成显卡里是降维打击放在独显里差不多相当于 Radeon RX 7600 到 RX 7700 之间的水平。更关键的是这颗 iGPU 不是传统的“核显”定位而是拥有完整独立显卡功能的 SoC 设计可以直接支持 ROCm、Vulkan、DirectML 这些主流计算框架。除了 CPU 和 GPU芯片里还塞了一块 XDNA 2 架构的 NPUAI 算力标称 50 TOPS。如果单看 NPU 的绝对值在笔记本芯片里算很靠前的。但有一点我得实话实说在 Linux 下真正跑大模型推里NPU 目前的软件生态远不如 GPU 成熟XAODXDNA AI Offload Driver虽然已经开源支持的主流框架还比较有限。所以我个人建议NPU 可以留着以后玩眼下重点还是把 GPU 的 ROCm 跑通实际收益最大。1.2 统一内存架构才是真正的王牌AI MAX 395 最颠覆认知的地方在于内存子系统。它支持 LPDDR5X内存位宽 256-bit最高可以配 128GB 内存内存带宽实测在 210GB/s 到 256GB/s 之间。CPU 和 GPU 共享这同一块内存池中间没有 PCIe 总线传输也没有显存和系统内存的物理界限。这意味着什么拿跑 70B 模型举例。在传统 NVIDIA 平台上你至少要一张显存 80GB 的卡比如 RTX 4090 或者 A6000。显存不够就只能把权重拆分到内存里靠 PCIe 传输来回倒腾速度直接从几百 GB/s 掉到几十 GB/s体验很糟糕。但在 AI MAX 395 上GPU 可以直接访问全部 128GB 内存70B 模型用 Q4 量化后权重大约 40GB再加上 KV Cache 和上下文缓冲区总量也就 60GB 左右这颗芯片能一口吃下。模型全部留在“显存”里没有拷贝开销吞吐量就上来了。打个比方NVIDIA 独占显存就像一个小而快的柜台东西多的时候要往仓库内存搬来回跑腿很费时间。AI MAX 395 的 128GB 统一内存则是一整个大仓库GPU 随时可以进去取货。虽然仓库通道不够宽带宽只有 256GB/s 左右但胜在容量大、无搬迁成本非常适合大模型推理这种“大权重、高容量需求”的工作负载。2. ROCm 在 AI MAX 395 上的兼容性现状不能只看官方文档2.1 官方支持矩阵和社区实际体验之间的差距ROCm 现在的版本已经迭代到了 7.x官方支持的 GPU 列表主要覆盖 Instinct 计算卡和部分 Radeon PRO 专业卡比如 MI300X、MI210、RX 7900 系列等。AI MAX 395 严格来说并不在官方的主支持列表里它在 ROCm 体系中的架构代号是 gfx1151市场名是 Radeon 8060S。这个代号决定了编译器能不能认它、运行库能不能驱动它、PyTorch 的预编译包能不能直接跑在它上面。不过“不在官方列表”不代表不能用。社区对这个事情的探索比官方支持快得多。在我写这篇文章的时候ROCm 6.4.x 和 7.x 的内核驱动部分对 gfx1151 已经提供了基础支持也就是说 rocm-smi 能看到设备、rocminfo 能识别架构、HIP 能调用 GPU 进行计算。但支持程度是分层的最稳定的组合集中在 Ubuntu 24.04 较新的内核 ROCm 6.4.x/7.x 上其他发行版或者老内核会遇到更多问题。现实情况是如果你用官方 amdgpu-install 脚本按默认参数装大概率能装上 ROCm 的 runtime 和工具链但跑到 PyTorch 或 llama.cpp 时会发现干活的效率不理想或者在编译阶段就卡住。原因主要是编译器和部分库对 gfx1151 这个 target 的调度、指令选择优化还没有完全校准生成代码不如针对 gfx1100RDNA3优化得彻底。这里就需要引入环境变量去“骗”编译器让代码走一条已经被充分验证过的指令路径。2.2 HSA_OVERRIDE_GFX_VERSION 到底是干什么的HSA_OVERRIDE_GFX_VERSION 是 HIP 运行时的一个环境变量作用是把当前设备报告给 ROCm 的架构版本覆盖掉。AI MAX 395 的 gfx1151 本质上属于 RDNA 3.5基础指令集和 RDNA 3gfx1100高度接近所以通过把 gfx1151 伪装成 gfx1100 或 gfx1101可以让那些只针对 RDNA3 做了优化的编译代码直接在 RDNA 3.5 上运行而且往往比“裸奔”的 gfx1151 跑得更稳。实际操作中在运行 PyTorch 或 llama.cpp 之前可以这样设置export HSA_OVERRIDE_GFX_VERSION11.0.0或者换用 11.0.1、11.0.4这取决于具体项目对哪个版本支持最好。我自己测试下来llama.cpp 的 ROCm 后端对 11.0.0 适配得不错PyTorch 的话 11.0.1 更均衡。有一点必须提醒这个变量是全局生效的不要在一个终端里同时跑不同需求的程序。另外有的项目在编译阶段就写死了架构参数比如用 HIP 编译时传 --offload-archgfx1100这种情况编译时就已经定了运行时再盖变量只是让加载器认账而已。在我实测的环境里不加这个变量直接跑 PyTorch 的 CUDA 版迁移脚本经常报 device not supported 或者显存分配失败加了之后基本能顺利进入训练和推理流程。所以说这个环境变量是把 AI MAX 395 变成“ROCm 可用设备”的一把钥匙。3. 从零搭建 AI MAX 395 的 ROCm 环境3.1 系统和内核选择是第一道坎先交代我用的测试平台一台搭载 AI MAX 395、64GB LPDDR5X 内存的迷你主机系统是 Ubuntu 24.04.1 LTS内核版本 6.11 左右。为什么强调内核版本因为 RDNA 3.5 的 AMDGPU 内核驱动需要比较新的内核代码才包含对应的调度器和固件。我试过用 Ubuntu 22.04 自带的 5.15 内核rocminfo 能跑但 GPU 的计算队列频繁报错跑不了一个完整的 LLM 推理流程。如果你也在用其他发行版推荐内核至少 6.10 以上。Arch Linux 用户比较省心滚动更新的内核通常已经包含最新 AMDGPU 驱动Debian 用户建议装 backports 内核Ubuntu 用户如果嫌自带内核不够新可以用主线内核 PPA。内核驱动部分还需要在启动参数里确保 amdgpu 模块正常加载一般默认就行不需要额外加参数但如果你是双显卡切换的环境比如带核显的笔记本可能需要留意设备优先级。安装 ROCm 之前先确认 GPU 能被系统看到sudo dmesg | grep amdgpu正常的话会看到 amdgpu 成功加载、识别出设备型号和显存大小还能看到 DRM 相关的初始化日志。如果这里就没有输出后面所有问题都不用排查了直接看驱动。3.2 amdgpu-install 的完整安装流程AMD 官方为 ROCm 提供了 amdgpu-install 安装工具这是一个统一入口。在 Ubuntu 24.04 上流程是先添加 AMD 的软件源再安装工具本身。官方文档rocm.docs.amd.com里对每个发行版都给出了详细的源配置命令。大致逻辑是下载 AMD 的 .deb 包或 .rpm 包安装后运行sudo amdgpu-install --usecaserocm--usecase 参数很关键它决定安装哪些组件。对于跑大模型推理或者做 AI 开发我建议这样装sudo amdgpu-install --usecaserocm,hipruntime,rocmdev这样可以拿到完整的 ROCm 运行库、HIP 运行时和开发工具链。如果你只想运行已有的推理引擎不打算自己编译装 rocm 这一个 usercase 就够了如果后面想自己编译 PyTorch 或者自定义算子rocmdev 绝对不能省。装完之后把当前用户加入 GPU 权限组否则后续运行程序会报权限错误sudo usermod -aG render,video $USER重启或者重新登录后检查工具链是否正常rocminfo | grep -i gfx如果能看到类似 gfx1151 的设备信息说明硬件层已经打通。3.3 验证 ROCm 计算能力的小实验光看到设备还不够最好跑一个真实的计算任务验证。最简单的方法是编译并运行一个 HIP 的向量加法示例。ROCm 安装包自带了一个示例集位于 /opt/rocm/share/hip/samples 或类似路径。用 hipcc 编译器直接编译运行cd /opt/rocm/share/hip/samples/0_Intro/square hipcc square.cpp -o square ./square如果能看到 PASS 输出就说明 HIP 编译器、运行时、GPU 加速队列全部打通了。注意编译时如果提示找不到头文件确认 ROCm 的安装路径是否在环境变量里通常安装脚本会自动处理但手动配置环境时容易漏。还有一个快速验证办法是用 rocm-smi 监控 GPU 状态rocm-smi --showmeminfo vram rocm-smi --showuse第一次跑的时候你会直观感受到这块“核显”在 ROCm 体系里被识别成一块正经计算卡而且显存容量就是共享内存池里的指定比例。有些板卡 BIOS 里有个 UMA Frame Buffer Size 的选项在 Linux 下通常可以设成 Auto让驱动按需分配Windows 下如果要跑 AI 工具建议手动设大一点比如 32GB 以上否则游戏和应用只能看到一小块“显存”。4. 推理引擎选型AFM、llama.cpp 与 PyTorch 怎么选4.1 AMD AFM 是 Strix Halo 的官方最佳搭档ROCm 环境装好之后下一步就是跑大模型。这里我强烈推荐先试试 AMD 官方的 AFMAMD Frameworks Model推理栈。AFM 本质上是在 llama.cpp 基础上针对 Strix Halo 系列做了深度定制的分支专门优化了 RDNA 3.5 下的内存访问模式和矩阵乘 kernel对 AI MAX 395 的适配度远高于通用的 llama.cpp 官方构建。AFM 的使用方式和 llama.cpp 很像可以通过源码编译也提供了预编译的二进制包。ARM 和 x86 平台都支持但为了让 ROCm 后端真正用 GPU 跑需要编译时指定 HIP。这里有个关键点AFM 建议用 ROCm 6.4.x 以上版本并且编译时可能会要求启用 gfx1151 或通过 HSA_OVERRIDE_GFX_VERSION 进行兼容。具体编译参数官方仓库 README 里写得很清楚基本就是cmake -B build -DHIPON cmake --build build -j编译完成后用和 llama.cpp 一样的命令行方式启动模型推理。AFM 在 Strix Halo 上的性能表现非常出色因为它对 256-bit LPDDR5X 内存带宽的调度做得很精细权重加载和 KV Cache 预取效率都比通用 llama.cpp 高不少尤其适合跑 Qwen、Llama 这类主流模型。4.2 llama.cpp 与 PyTorch 的 ROCm 实践如果你不想额外引入 AFM直接用 llama.cpp 官方仓库的 ROCm 后端也可以。编译时需要开启 GGML_HIP 选项并且给编译器指定架构cmake -B build -DGGML_HIPON -DCMAKE_HIP_COMPILER/opt/rocm/bin/hipcc cmake --build build -j如果遇到架构识别问题可以在编译时通过环境变量 AMDGPU_TARGETS 指定 gfx1151 或者 gfx1100。刚开始跑的时候一定要设置 HSA_OVERRIDE_GFX_VERSION否则经常出现启动了但 GPU 队列不动的情况CPU 反而满负荷。一个典型的错误现象是模型加载慢、推理全部走 CPU、GPU 利用率趋近于 0。排查顺序就是先确认设备能被 HIP 找到hipconfig 可以查、再确认环境变量覆盖的架构版本是否正确。PyTorch 这边的情况稍微复杂。AMD 官方为 ROCm 发布了预编译的 PyTorch wheel可以直接用 pip 安装pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm7.0但要注意这些预编译包默认只支持官方列表里的计算卡gfx1151 不一定在列。方案有两种一是运行时用 HSA_OVERRIDE_GFX_VERSION 强制兼容二是自己从源码编译 PyTorch编译时让 TORCH_ROCM_ARCH 包含 gfx1151。源码编译耗时大概两三个小时但胜在一劳永逸性能也更稳定。4.3 其他值得关注的推理工具除了上述三者还有一些工具也值得放到候选名单里。LM Studio 作为图形化的本地模型管理工具底层支持 Vulkan 后端对 AI MAX 395 的 RDNA 3.5 兼容性很好不需要折腾 ROCm 环境就能直接跑适合入门用户和日常聊天。Ollama 也提供 Vulkan 后端配置简单但我实测下来它在统一内存上的利用效率不如 llama.cpp 的 ROCm 后端大模型场景可能会有约 10% 到 20% 的性能差距。如果你想跑 ASR、语音合成这类任务OpenAI 的 Whisper 等模型也可以通过 llama.cpp 生态的 whisper.cpp 的 ROCm 后端推理。还有一类工具是 FlashAttention 等高性能算子库它们能显著提升长上下文场景下的推理速度。这些库在 gfx1151 上的适配进度参差不齐建议大家在使用前先确认项目 issue 里是否有 Strix Halo 相关进展否则编译失败会很浪费时间。5. 实测性能数据和一些重要结论5.1 推理性能参考数据性能这块我贴一些相对有代表性的数字都来自我自己的实际测试和社区公开结果。前提是模型权重用 GGUF 格式 Q4_K_M 量化内存开启高频模式BIOS 里把 TDP 解锁到 80W 以上。如果你用的是 45W 低功耗模式性能会显著下降后面专门说。在 AI MAX 395 上我用 AFM 跑 14B 参数模型生成速度大约 30~40 token/s这个速度用于日常对话完全够用响应基本感觉不到延迟。32B 模型降到 15~18 token/s依然很流畅配合 64GB 内存可以轻松吃下带长上下文的会话。70B 模型是这颗芯片最有“噱头”的场景Q4 量化下大约 7~9 token/s虽然不算快但它是“单机跑全量 70B”的体验。作为对比在同样拥有大显存概念的 Apple M 系列芯片上70B 模型的运行速度通常也在这个范围附近。之所以能有这个表现底层逻辑就是内存带宽。大模型自回归生成时性能几乎完全取决于权重从内存搬运到计算单元的带宽AI MAX 395 的 256GB/s 实际可用带宽在上面三个模型档位下的理论极限就是这么算出来的。如果你的模型量化得更激进比如 Q2_K速度还能再往上涨一点但质量损失也需要权衡。5.2 功耗和散热的真实影响AI MAX 395 的默认封装功耗在 45W 到 120W 之间浮动这个浮动完全由主板决定。迷你主机厂商有各自的调校策略有的默认 60W有的激进解锁到 120W。我实测发现GPU 在低功耗模式下跑大模型会明显“偷懒”看似在生成但速度只有解锁功耗后的六成甚至一半。原因很简单FP16 或 BF16 的乘加运算需要持续供电功耗墙一撞上GPU 频率立刻下探计算能力随之缩水。所以如果你买了这台机器准备常跑 AI第一个事就是进 BIOS 看 TDP 设置能解锁就解锁。同时注意散热迷你主机的散热方案各不相同持续负载下如果系统开始降频哪怕是 120W 的 TDP 也会“名存实亡”。我建议用 rocm-smi 实时盯一下 GPU 温度和频率曲线确认满负载时 GPU 核心频率能稳定在 1.5GHz 以上低于这个值就需要考虑改善散热或者接受性能损失。5.3 它适合干吗不适合干吗AI MAX 395 加 128GB 内存的组合本质上是一个“大内存推理工作站”最适合三类场景本地私有化部署大模型、需要超大上下文窗口的文档分析、以及模型微调和 LoRA 训练的实验环境。它不适合的也很明确不适合追求极限吞吐量的生产环境比如并发数百用户的 API 服务那种场景下 8 卡甚至更多卡集群的绝对算力远超单颗 APU也不适合训练几十 B 以上的模型训练过程的浮点计算量比推理高一个量级RDNA 3.5 的算力摆在那里和专业计算卡还有距离。在实际使用中如果你把它定位成“安静、省电、大内存的个人 AI 工作站”它会给你超出预期的体验非要让它去拼 4090 的跑分那属于用错了方向。6. ROCm 与 AI MAX 395 的常见问题排查速查表6.1 设备识别和权限类问题问题 1rocminfo 看不到 gfx1151 设备。先确认内核版本和 amdgpu 模块加载情况执行 dmesg 搜索 amdgpu 日志如果完全无输出大概率是内核太旧或者固件没装。如果能看到设备但 rocminfo 报错尝试更新 ROCm 到 6.4.x 以上并检查系统是否同时装了多个版本的 ROCm 导致冲突。问题 2运行程序报 “open device failed” 或者权限错误。这是经典的 render 组权限问题把用户加入 video 和 render 组后重新登录。注意有的发行版只有 render 组有的只用 video 组两个都加最省心。问题 3设备识别出来但显存是 0。这个通常发生在 UMA Frame Buffer Size 设置为 0 或者固定的过小值时。去 BIOS 把 UMA 缓冲区改大Linux 下发 Auto 即可。另外不要在运行 AI 推理的同时开启大量桌面特效和浏览器硬件加速共享内存池并不是无限大的被桌面进程吃掉的显存会影响模型可用空间。6.2 执行和性能类问题问题 4程序启动了但 GPU 利用率很低任务全跑到 CPU 上。这类问题首先检查 HSA_OVERRIDE_GFX_VERSION。gfx1151 在不少算子库中还没有被完全启用运行时看到的架构和库预期的对不上就不会走加速路径。设置 11.0.0 或 11.0.1 后重启程序。如果依然无效考虑源码重编项目让编译器直接针对 gfx1151 生成代码。问题 5编译时找不到 HIP 编译器。检查 /opt/rocm/bin 是否在 PATH 中hipcc 是否有可执行权限。部分新版 ROCm 把编译器换成了 clang 驱动hipcc 只是一个软链接如果链接损坏会报错。重新安装 rocmdev 包可以修复。问题 6推理时内存占满导致系统死机或者 OOM。模型加载和 KV Cache 会动态占用内存虽然 AI MAX 395 有 128GB 上限但如果你只有 64GB 内存跑 70B 模型就会超。推理前可以用 rocm-smi --showmeminfo 确认可用显存量或者通过 llama.cpp 的 --ctx-size 参数缩小上下文窗口。问题 7运行过程中 GPU 频率上不去。除了 BIOS 功耗墙还需要检查电源模式和温度。部分迷你主机的电源适配器功率不足也会导致持续负载时性能下降。可以安装 powertop 或者直接用 rocm-smi 增加 GPU 的 power cap 来观察变化。7. 资源清单与后续学习路线7.1 官方与社区的关键资源先列一份我实际用下来有用的资源清单避免大家再去大海捞针。ROCm 官方文档rocm.docs.amd.com安装指引、版本说明、GPU 支持矩阵都在这里内核和运行时兼容性的第一手信息来源。AMD 的 AFM 仓库GitHub 搜 amd/afmStrix Halo 推理首选项README 里有清晰的编译和运行步骤是性能参考的重要来源。GitHub 上搜 “Strix Halo ROCm” 相关仓库能看到不同产业链团队对 RDNA 3.5 的适配进度包括 vLLM 分支、FlashAttention 适配等问题的最新动态。PyTorch 官方的 ROCm wheel 下载页download.pytorch.org/whl/rocm7.0安装 PyTorch 的第一步先看看这里有没有对应版本的包再决定要不要源码编译。LM Studio 和 Ollama 社区适合不折腾人群直接装系统里就能跑Vulkan 后端让 AI MAX 395 的 iGPU 发挥基本盘。7.2 从入门到进阶的学习路径建议如果你是第一次接触 ROCm建议按这个顺序走先装好 Ubuntu 24.04 并用官方 amdgpu-install 把全功能 ROCm 装齐再用 rocminfo 和 rocm-smi 把工具链跑熟然后直接装 LM Studio用图形界面跑一个小模型体验流程。这一步能让你避开命令行编译问题快速进入“用”的阶段。等熟悉了之后再挑战 llama.cpp 的 ROCm 编译理解 HSA_OVERRIDE_GFX_VERSION 的作用这时候你会开始意识到ROCm 和 CUDA 之间最大的差异不是性能而是软件生态的“碎片化”。每个项目都要针对特定 GPU 架构做适配没有 NVIDIA 那种开箱即用的统一体验。真正玩熟之后再考虑 AFM 和 PyTorch 源码编译这时候你已经具备了自己解决编译错误、调整架构参数的能力。7.3 值得持续关注的生态方向AI MAX 395 的 ROCm 环境还在快速演进中有几个方向我认为值得持续关注。一是 ROCm 官方把 gfx1151 纳入正式支持列表的速度一旦转正很多库的适配就会跟上二是 NPU 在 Linux 下的实际应用XDNA 2 架构的潜力远没有释放完全未来如果能通过标准框架调用 NPU 做异构推理AI MAX 395 的在手体验还会再上一个台阶三是 Vulkan 计算生态的成熟如果 Vulkan 推理统一了后端那么 ROCm 的兼容性焦虑就会小很多。我在实际调试中最大的体会是这套平台的乐趣和痛苦都集中在“不标准化”上。官方支持没跟上但社区推动很快每个项目都要多花一点时间配置但一旦跑通了那种“我在一个安静的迷你主机上跑着 70B 模型”的成就感是拿着大显存卡跑分完全不一样的。可能这也是折腾的另一种价值吧。