企业官网建设流程全解析

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 架构的 NPU，AI 算力标称 50 TOPS。如果单看 NPU 的绝对值，在笔记本芯片里算很靠前的。但有一点我得实话实说：在 Linux 下真正跑大模型推里，NPU 目前的软件生态远不如 GPU 成熟，XAOD（XDNA 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 的调度、指令选择优化还没有完全校准，生成代码不如针对 gfx1100（RDNA3）优化得彻底。这里就需要引入环境变量去“骗”编译器，让代码走一条已经被充分验证过的指令路径。

2.2 HSA_OVERRIDE_GFX_VERSION 到底是干什么的

HSA_OVERRIDE_GFX_VERSION 是 HIP 运行时的一个环境变量，作用是把当前设备报告给 ROCm 的架构版本覆盖掉。AI MAX 395 的 gfx1151 本质上属于 RDNA 3.5，基础指令集和 RDNA 3（gfx1100）高度接近，所以通过把 gfx1151 伪装成 gfx1100 或 gfx1101，可以让那些只针对 RDNA3 做了优化的编译代码直接在 RDNA 3.5 上运行，而且往往比“裸奔”的 gfx1151 跑得更稳。

实际操作中，在运行 PyTorch 或 llama.cpp 之前，可以这样设置：

export HSA_OVERRIDE_GFX_VERSION=11.0.0

或者换用 11.0.1、11.0.4，这取决于具体项目对哪个版本支持最好。我自己测试下来，llama.cpp 的 ROCm 后端对 11.0.0 适配得不错，PyTorch 的话 11.0.1 更均衡。有一点必须提醒：这个变量是全局生效的，不要在一个终端里同时跑不同需求的程序。另外，有的项目在编译阶段就写死了架构参数（比如用 HIP 编译时传 --offload-arch=gfx1100），这种情况编译时就已经定了，运行时再盖变量只是让加载器认账而已。

在我实测的环境里，不加这个变量直接跑 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 --usecase=rocm

--usecase 参数很关键，它决定安装哪些组件。对于跑大模型推理或者做 AI 开发，我建议这样装：

sudo amdgpu-install --usecase=rocm,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 官方的 AFM（AMD 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 -DHIP=ON 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_HIP=ON -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 设备识别和权限类问题

问题 1：rocminfo 看不到 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/afm）：Strix 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 模型”的成就感，是拿着大显存卡跑分完全不一样的。可能这也是折腾的另一种价值吧。