AMD AI Max 395 这颗 APU 出来之后我陆陆续续翻了不少官方文档和社区帖子。作为 Strix Halo 的旗舰型号它把 16 个 Zen 5 核心、40 个 RDNA 3.5 计算单元和一颗 XDNA2 NPU 塞进了同一个封装最高能配 128GB LPDDR5X 统一内存。关注它的人大多数都带着同一个问题ROCm 到底能不能在这颗芯片上折腾起来能不能真的把 70B 级别的模型拉到本地跑。这篇不是评测是我把目前能看到的官方资源、社区经验和实操细节筛过一遍之后的汇总顺便补上我自己跑环境时踩过的坑。无论你是想入手迷你主机还是攒一套端侧推理设备这份清单应该能帮你少绕点路。1. 先看清 AI Max 395 的硬件底色1.1 统一内存才是这个平台的灵魂很多人在聊这颗芯片时会习惯性叫它“核显 APU”其实有点低估了。传统 PC 里 CPU 和 GPU 各自守着独立内存数据搬运要经过 PCIe 总线显存一满就只能干瞪眼。AI Max 395 不一样CPU、GPU、NPU 共用一整块物理内存GPU 可以直接访问系统内存CPU 也能随手操作 GPU 分配的内存整机只存在“一块内存”没有独立显存这个概念。这意味着本地跑模型时显存不够的问题几乎被消除。举个例子Llama 3 70B 用 4bit 量化Q4_K_M大概要 40GB 空间放到 128GB 统一内存上剩余空间依然很多模型加载流程就和跑普通桌面应用一样不牵扯任何 VRAM 分流操作。这个体验非常像把 GPU 当成一张“无限显存”的卡唯一要服从的物理限制只有内存带宽。LPDDR5X 在这里能提供的带宽大约 256GB/s这是理解性能的关键数字。你可以把它类比成一张 256GB/s 带宽的显卡容量管够带宽并不夸张。后续所有推理速度的判断都必须拿这个数字去衡量。1.2 为什么是 RDNA 3.5而不是 CDNA 3另一个让人迷惑的点是架构选择。ROCm 生态真正被长期优化的对象是 CDNA 架构的 Instinct 加速卡而 AI Max 395 用的是 RDNA 3.5。这背后的考量有两个层面。一方面这款产品本质上是面向消费级和创作者市场RDNA 保留了完整的显示输出、视频编解码和图形渲染能力CDNA 完全不具备这些所以方向上肯定选 RDNA。另一方面从 ROCm 适配角度看RDNA 3.5 的指令集和 RDNA 3gfx11xx 系列非常接近很多现成的 RDNA 3 内核程序可以复用到这颗芯片上这为后续软件适配省了大功夫。当然接近不代表完全一致。AI Max 395 在 ROCm 体系里对应的是 gfx1151 目标标识而社区和官方在早期解决兼容问题时常常借助一个环境变量 HSA_OVERRIDE_GFX_VERSION 来让运行时把它“伪装”成 gfx1100以此加载已有的 RDNA3 Docker 内核。这种软硬件错位带来的问题我在后文会详细展开。2. ROCm 在这颗芯片上的真实支持状态2.1 从“强行能跑”到“逐步官方化”的版本演进AMD 对 RDNA 平台启用 ROCm 的方式比较保守基本遵循实验性支持到逐步成熟的路径。到了 AI Max 395 这里时间线大概分成两个阶段。早期阶段也就是 6.3.x 时代想在 Strix Halo 上跑 PyTorch 的 ROCm 版本普遍需要设置环境变量 HSA_OVERRIDE_GFX_VERSION11.5.1把 gfx1151 伪装成 gfx1100让 ROCm 运行时加载 RDNA3 的内核程序。这个方法社区已经验证过很多次能用但属于“哄着软件跑起来”的路线部分底层内核封装并不是专门为这颗芯片编译的性能上会打一些折扣。进入 6.4 之后情况明显好转。ROCm 6.4 以及后续小版本对 Strix Halo 的 gfx1151 目标补上了更完整的内核支持很多推理场景不再需要强行覆盖 GFX 版本直接在官方 PyTorch 容器里就能识别设备。我自己在 WSL2 里用 ROCm 6.4 的官方容器跑 llama.cpp设备识别、内核加载和显存分配都比 6.3 时代顺很多。我把当前阶段的状态整理成了一个表方便对照ROCm 版本AI Max 395 可用性备注6.3.x需要 HSA_OVERRIDE_GFX_VERSION11.5.1社区实践为主能跑但不完美6.4gfx1151 得到正式内核支持推荐使用的起点6.4.x 及以后持续修复稳定性与性能关注官方 Release Notes提示看任何 2025 年之前的 ROCm RDNA 教程时都要留个心眼版本差异太大可能直接误导你。以官方文档和当月的 Release Notes 为准。2.2 Windows WSL2 与 Linux 原生跑法怎么选AI Max 395 的 ROCm 开发环境目前有两条主路一条是 Windows 下的 WSL2另一条是原生 Linux。先说 WSL2。AMD 官方很多资料都建议走这条路原因很直接Windows 驱动帮你搞定 GPU 设备映射WSL2 内部直接跑 Ubuntu 24.04 容器环境省去了物理机装 Linux 驱动和双系统切换的麻烦。实际用下来只要 Windows 侧安装的是新版 AMD 显卡驱动自带 WSL 支持WSL2 里就可以直接拉 ROCm 官方的 Docker 镜像。注意一个反直觉点不需要在 WSL2 内部再装驱动因为 GPU 访问是通过 Windows 驱动转发进来的。这条路线适合大多数想在开发机上折腾的人。如果你要搭一台 7x24 小时跑训练或推理的服务节点原生 Linux 更省心。Ubuntu 22.04 或 24.04 下用 amdgpu-install 脚本装 ROCm稳定性更好容器和 Python 环境的兼容性也更可控。代价是你要处理系统内核、桌面环境和显卡驱动的各种耦合问题遇到问题排查链路更长。取舍就很清楚了场景推荐路线日常开发、写脚本、快速验证Windows WSL2跑长时间训练、稳定服务原生 Linux需要同时用 NPU 做语音/视觉任务Windows 下暂时更顺手2.3 框架兼容矩阵能用的到底有哪些这是很多人真正关心的问题。我根据自己的使用和社区反馈整理了目前 AI Max 395 上相对靠谱的框架清单。PyTorch 是主力框架官方 ROCm 版本通过 pip 或容器都能装。但注意不是所有算子都被优化适配像卷积、Attention 这类基础模块在 gfx1151 上表现正常部分偏门算子仍可能遇到编译失败或运行时报错。在你真正跑大模型推理之前先用简单的矩阵乘法和 attention 测试脚本验证一下环境。ONNX Runtime 的 ROCm 执行提供方ROCm EP也能用尤其适合导出 ONNX 之后再推理的场景。很多 LLM 工具链支持 ONNX 导出这条路径优点是可以脱离特定框架版本限制但同样需要确认算子兼容性最好准备一个 CPU EP 的 fallback 路径。llama.cpp 是我最推荐拿来干活的工具。它本身是多后端架构可以直接调用 ROCm HIP 后端针对大模型的量化内核支持非常完善而且对统一内存环境适应得比较好。在 AI Max 395 上跑各类开源模型llama.cpp 的体验基本是最稳的。vLLM 这类高并发推理引擎虽然在 ROCm 侧有支持但对 APU 这类平台的适配还不算成熟。想用它服务并发请求建议先拉官方 ROCm 容器实测不要在社区碎片化教程上浪费时间。还有一个小众选择是 tinygrad社区有人专门给 gfx1151 做了适配补丁。如果你喜欢写自定义 kernel这个项目会很有乐趣但一般用户不必为它投入额外精力。最后强调一个容易混淆的点NPU 不走 ROCm 路线。AI Max 395 的 XDNA2 NPU 需要单独用 AMD Ryzen AI 软件栈通过 ONNX Runtime IPU EP 或 Vitis 工具链去调用。所以如果你想处理语音唤醒之类的小模型可以交给 NPU但 NPU 和 ROCm 是两套完全独立的技术体系别把资源混在一起找。3. 值得收藏的资源清单与实操路线3.1 官方入口先认准这几个ROCm 主文档入口是 rocm.docs.amd.com所有版本说明、安装指南、支持矩阵都在这里。特别是 Release Notes每个版本的 GPU 支持列表都会更新AI Max 395 属于哪个阶段一看便知。PyTorch 官方的 AMD 支持页面也值得放进书签里面有对应 ROCm 版本的 pip 安装命令和容器标签。另外就是 AMD 的容器镜像仓库直接搜 rocm/pytorch 就能找到比本地编译省一万倍精力。官方还有一个 ROCm GitHub 组织里面放着 ROCm 主体代码库和各类示例代码遇到内核层面的问题翻 issues 比搜索引擎更容易找到答案。这里建议你常看两个具体页面ROCm 的 GPU 支持矩阵以及 ROCm 6.4 的 Release Notes。前者决定你的芯片在哪个版本能得到正式支持后者告诉你官方到底改了哪些相关模块。3.2 社区资源GitHub 和论坛里的宝藏社区资源这块我自己常逛的包括这些渠道ROCm 官方 GitHub 仓库找安装脚本、内核代码和已知问题列表llama.cpp 项目仓库搜索 gfx1151 或 strix halo 相关的 issue能看到很多人贴出实测参数和性能tinygrad 仓库的 AMD 后端补丁适合喜欢读代码和写 kernel 的玩家AMD 社区论坛的 Strix Halo 板块偏消费级问答但偶尔有官方工程师出来澄清支持状态Reddit 的 r/LocalLLaMA 和 r/Amd搜 “Strix Halo ROCm” 能刷出不少一手测试要提醒的是社区里的信息更新极快三个月前的帖子很可能就已经失效。遇到问题时优先看最近一个月的讨论其次再看官方文档千万不要照搬 2024 年甚至 2025 年年初的老教程。3.3 一条直接能抄的环境搭建路线我自己最常用的路线是在 WSL2 里拉官方 PyTorch 容器步骤如下# 1. 确保 Windows 侧 AMD 驱动已更新且开启了 WSL2 虚拟机平台 # 2. 进入 WSL2安装 Docker CE 后拉取官方镜像 docker pull rocm/pytorch:rocm6.4_ubuntu24.04_py3.11 # 3. 启动容器把 GPU 设备映射进去 docker run -it --device/dev/kfd --device/dev/dri --group-add video \ --shm-size16g rocm/pytorch:rocm6.4_ubuntu24.04_py3.11 # 4. 在容器内验证设备可见 rocm-smi如果是在 6.3 时代或者某些老旧容器里需要强制覆盖再追加一行export HSA_OVERRIDE_GFX_VERSION11.5.1这个变量的作用是告诉 ROCm 运行时“当前设备是 gfx1100”从而加载对应的 RDNA3 内核。它解决的是内核段匹配问题但等于放弃了针对 gfx1151 的专属优化。能升级就升级别长期依赖。权限问题也很常见。物理 Linux 下经常遇到 /dev/kfd 无权限的情况把当前用户加进 video 组即可sudo usermod -aG video $USER重启之后再执行 rocm-smi基本就能看到设备信息了。4. 实操体验与性能观察4.1 从 7B 到 70B本地推理的参考速度既然走 ROCm 路线大家最关心的还是推理速度。我基于自己测过和社区验证过的数据给出一个偏保守的参考范围模型规模Q4_K_M权重占用参考速度7B约 4.5GB35-45 token/s14B约 9GB20-30 token/s32B约 18GB12-18 token/s70B约 40GB8-12 token/s这个数字背后有个可以量化的逻辑。推理生成阶段每生成一个 token都要流式读取一遍模型权重。70B Q4 每 token 的权重流量大约 40GB在 256GB/s 的带宽上限下理论极限只有 6.4 token/s 上下。实际能跑到 8-12是因为缓存、批处理和内核优化带来了额外增益。所以判断 AI Max 395 的性能关键不是看它的 40CU 图形单元有多强而是看内存带宽能和模型规模之间如何匹配。7B 级别能跑得飞快70B 级别属于“能够用但不流畅”的状态这就是这颗芯片在推理场景下的真实画像。4.2 几个值得坚持的调优方向统一内存环境下的调优和独显很不一样。我总结了几条实际有效的方向。第一关注内存分配而不是显存监控。传统思维里“显存不足”的提示在 AI Max 395 上几乎消失真正会限制你的是整机物理内存余量。Windows 下图形驱动默认会把一部分内存当作“专用显存”预留如果你的内存是 64GB 版本建议在 BIOS UMA Frame Buffer 里适当调高分配比例否则内核加载可能遇到奇怪的分配失败。第二功耗曲线决定了持续性能。AI Max 395 支持几十瓦到 120W 的功耗档位短跑可以冲高功耗长跑训练建议压低功耗否则温度管理会让你损失不少频率。我在长时间跑 32B 模型时把功耗锁定在 90W 左右性能波动比全速档小很多。第三NPU 不要闲着。XDNA2 NPU 特别适合处理语音转录、简单分类这类小负载让 GPU 专心跑大模型。这种分工思路在传统独立显卡平台上根本不存在却是 AI Max 395 这类集成平台的核心优势。4.3 常见问题速查表我把折腾过程中遇到的和朋友问过的高频问题整理成了速查表基本覆盖了大多数人会卡的环节现象可能原因解法rocm-smi 找不到设备权限不足把用户加入 video 组或检查容器 --group-addPyTorch 提示 no kernel image is availableGFX 版本不匹配设 HSA_OVERRIDE_GFX_VERSION11.5.1或升级 ROCm 版本模型加载到一半报内存不足UMA Frame Buffer 分配过低BIOS 里调高帧缓冲或检查其他进程内存占用WSL2 里速度异常Windows 驱动不是最新版装最新 AMD 驱动重启 WSLllama.cpp 构建时找不到 HIP源码构建参数问题直接用官方容器或查 llama.cpp README 的 ROCm 构建说明容器内 printf 一行输出乱码终端编码无关多为内核态警告忽略即可不影响推理注意如果你在容器里看到“device name not found”之类的报错先看一眼容器是否加了 --device/dev/kfd 和 /dev/dri。这俩设备节点是 ROCm 运行的命根子少了任何一个都会导致设备不可见。还有一个特别容易被忽略的问题官方 PyTorch 容器里 Python 版本和 pip 版本经常不是你熟悉的那套不要一上来就 pip install 一堆东西。先用容器自带的 torch 跑一个几秒钟的矩阵乘法确认 ROCm 后端真的在正常工作再继续搭建项目依赖。5. 关于这套组合我最后的几句实话5.1 哪些人值得入手哪些人可以再观望说了这么多回到最现实的问题AI Max 395 ROCm 这套组合适合谁我个人的判断是如果你是做 LLM 应用原型的比如给 70B 级别模型写 Agent 应用、做私有化知识库、在数据不出本机的前提下跑批量推理这颗芯片非常合适。128GB 统一内存带来的安全感是任何消费级独显都很难替代的。它让你不再纠结“这个模型量化到多少才能塞进显存”而是直接考虑“这个模型对我的场景够不够聪明”。但如果你想做大规模模型训练或者重度依赖科学计算流程建议谨慎。ROCm 的 RDNA 支持和 CDNA 正式支持之间仍有差距部分训练算子会遇到兼容或性能瓶颈训练场景远不如推理场景顺畅。另外256GB/s 的带宽在训练场景下也是一个肉眼可见的短板。同类场景下对比一台 4090 整机AI Max 395 的成本、体积和功耗都更低但绝对性能上限也更低。这不是谁优于谁的问题而是两类完全不同的使用哲学一个是高带宽、小显存的传统独显路线一个是容量为王、带宽均衡的统一内存路线。5.2 接下来还能怎么折腾从资源汇总的角度我想再提醒你关注几个后续方向。一是 ROCm 相关版本迭代尤其是 6.4 之后的山猫更新gfx1151 的优化会越来越多。二是 llama.cpp 和 vLLM 这类推理项目对 APU 的适配这个是最容易直接吃到红利的。三是 AMD 的 Ryzen AI 软件栈NPU 生态虽然和 ROCm 不是一回事但作为 AI Max 395 的差异化功能值得在后续项目里单独拓展。我个人现在最常干的组合操作是让 NPU 负责麦克风阵列的实时语音识别同时让 GPU 通过 ROCm 跑本地大模型对话生成。这种“小模型走 NPU、大模型走 ROCm iGPU”的协作模式是传统独显平台做不出来的体验也把 AI Max 395 的硬件价值吃得很透。说到底AI Max 395 和 ROCm 的组合还处在一个“硬件先跑起来软件逐步跟上”的甜蜜期。愿意折腾的人现在入手能体验到比别人早半年的 70B 本地部署不想折腾的人也可以再等几个版本等官方支持再成熟一档。这个时间点没有标准答案只有你对“本地大模型”这件事有多执着。