1. AI Max 395 是什么定位为什么值得折腾最近不少跑本地模型的群友都在聊 AMD AI Max 395微博、B站、X 上也经常刷到 Strix Halo 的测试图。作为已经实机用了一段时间的人我先把这台机器的定位说清楚它本质上是一颗把高性能 CPU、大规模 GPU、NPU 打包进同一个 chip 的旗舰级 APU而配套的软件生态主力就是 ROCm——AMD 对标的 CUDA 开源计算平台。所以这篇资源汇总核心围绕两件事展开AI Max 395 的硬件到底强在哪以及 ROCm 上怎么把它变成一台能跑大模型的工作站。为什么大家盯着它因为过去玩本地 AI要么需要一块昂贵的独立显卡要么选择苹果的统一内存 Mac。AI Max 395 把两者思路揉在一起CPU、GPU 共享同一片高带宽内存整机功耗又比传统 CPU独显方案低不少。这意味着你花一份预算就能获得一台既能编译代码、又能跑 32B 甚至更大参数量模型的单机设备。当然光有硬件还不行ROCm 生态近几年追上来了不少PyTorch、vLLM、llama.cpp 这些主流组件在 gfx1151 这个架构上有官方或半官方支持这才是它能进入我得力工具箱的真正原因。这篇文章适合三类人看第一类已经下单但还没装好环境的 AI Max 395 用户这里给了完整启动路径第二类在挑选板子和迷你主机时犹豫“AMD 能不能跑 AI”的观望者这里能帮你判断软件栈的实际成熟度第三类熟悉 CUDA 但没碰过 ROCm 的开发者不少命令行和报错在两种平台下完全不同看完能少走很多弯路。1.1 一颗芯片上的三件套CPU、GPU、NPU 都是什么水平AI Max 395 的规格简单概括是“堆料不眨眼”。CPU 部分是 16 核 32 线程的 Zen 5 架构基础频率 3.1GHz加速频率能到 4.3GHz 左右日常当工作主机用完全够。GPU 部分更夸张内置 40 个 RDNA 3.5 计算单元对应到独显大约就是 Radeon 8060S 这个级别桌面小主机外接一台显示器做图形输出、做渲染加速都足够。另有一块基于 XDNA 2 的 NPU本地吞吐大约 50 TOPS当前主要给 Windows 上的 AI 应用调用Linux 下主要靠 GPU 跑模型。但真正让 395 区别于普通 APU 的地方是它最高支持 128GB 的 LPDDR5X 内存内存位宽 256-bit峰值带宽在早期测试中稳定在 250GB/s 上下。这是什么概念对比一下桌面级 DDR5 双通道一般是 60GB/s 左右主流独立显卡配的 GDDR6 显存是 300GB/s 到 600GB/s 级别AI Max 395 的内存带宽比传统桌面内存高出四五倍又比独显低一个档次正好落在“能装大模型”和“能喂饱 GPU 计算单元”之间的甜点上。所以我特别建议把 AI Max 395 理解成一个“带宽约束的系统”而不是传统意义上的“有独显的电脑”。你在上面跑 AI 时GPU 计算单元往往还有余力但每一条指令都受制于内存能吐出多少数据。这个特质直接决定了模型选型、量化格式、推理框架的取舍后面实操段落我会专门展开。1.2 统一内存才是杀手锏传统独显的写代码流程是显存 24GB模型放不下就换成更小量化如果主机内存 64GB也没法把模型塞进显存里跑。AI Max 395 和苹果 M 系列一样GPU 和 CPU 之间没有严格物理上的“显存/内存”隔离PyTorch、llama.cpp 之类的框架都能默认把整个统一内存空间当成可用显存活来用。这一点带来的实际好处非常直接假如你机器配了 64GB那 20GB 左右的 30B 级模型、28GB 左右的双模态模型都能塞进去跑配到 128GB 后单机跑带量化的大参数模型成为可能。虽然带宽不如 HBM但容量和价格优势太明显了一个 ITX 主机就能干过去需要整台 A6000 工作站的事。更别提系统里同时挂着浏览器、IDE、编译任务统一内存不会把显存和系统内存切死资源利用率更高。1.3 和谁对比别用 RTX 4090 的思路看待 AI Max 395很多人习惯问“AI Max 395 能打 RTX 4090 吗”。我的看法是这个问法本身就失真。RTX 4090 计算吞吐确实高出一截显存带宽也多出不少但 24GB 显存容量摆在那跑不动 40B 以上的模型就是跑不动。AI Max 395 优势在“容量换带宽”、在“一颗处理器搞定全部”劣势也很清楚跑小模型、高并发负载时吞吐比不过一块中高端独显。更现实的参照是苹果 M4 Max、M4 Pro 这类统一内存平台。AI Max 395 的优点是开放生态可以自己装 Linux、随意跑容器、用标准 ROCm 工具链缺点是软件兼容性仍需要时间沉淀不是所有 CUDA 时代的工具都能开箱即用。拿它做推理、调参、跑本地 Agent 是非常合适的做大规模训练或超长上下文高性能服务建议还是考虑真正的专业级方案。2. ROCm 支持现状gfx1151 到能跑 PyTorch中间差了点啥讲完硬件该讲软件了。AMD 的 ROCm 是个开源计算栈架构分几层底层有内核驱动amdgpu往上是一组运行时库如rocm-smi、libamdhip64再往上就是 HIP 编程模型和 ROCm 生态库。PyTorch 现在官方分发 ROCm 版本vLLM 也有原生编译包llama.cpp 通过 HIP 后端支持 Radeon 全系列。但每个套件对架构的适配进度不一样这也是大家查资料最容易乱的地方。2.1 ROCm 和 CUDA 生态的差异先建立心理预期如果你之前只碰过 CUDA刚上手 ROCm 会有两个不舒服的地方。第一CUDA 是英伟达一家维护驱动、库、框架版本经常是一套整体对应而 ROCm 的各个组件升级节奏不同内核模块版本、HIP 版本、PyTorch wheel 里捆绑的 ROCm 版本时不时会错开需要多一点耐心看好支持矩阵。第二启动参数和报错信息不同GPU 架构 ID 叫 gfx1151部分老工具会不识别需要手动设置HSA_OVERRIDE_GFX_VERSION之类环境变量这个后面会专门讲。有了这两个心理预期后面遇到问题就不容易慌。实际上现在的 ROCm 已经比两三年前成熟太多PyTorch 官方轮子能做到“装完即用”绝大多数普通用户不需要自己从源码编译 HIP 库。只做推理的话一部分用户甚至能绕开传统 ROCm 全量安装直接跑 llama.cpp 的 HIP 版或 vLLM 的预编译包省时省力。2.2 gfx1151 支持时间线哪些版本值得记牢AI Max 395 对应的 GPU 架构代号是 gfx1151完整名字叫 RDNA 3.5 的集显变体。ROCm 正式支持这个 ID 是从 ROCm 6.4.x 开始在 6.5、6.6 系列里持续完善。也就是说如果你下载一个 6.3 甚至更老的 ROCm 安装包系统大概率会拒绝识别这块 GPU或者在rocminfo中看到一堆空白。这是很多刚入手二手的兄弟最容易踩的坑驱动装了一晚上最后发现版本太老。ROCm 6.3.x 及之前不原生支持 gfx1151不建议浪费时间折腾ROCm 6.4.x首次提供正式支持可用 PyTorch 推理但部分工具不稳定ROCm 6.5.x目前我用下来最稳的组合vLLM、llama.cpp 构建都能跑ROCm 6.6.x / 6.7 RC更新了编译器、算子库容器也升级可以尝鲜但注意回滚路径记住这个时间线你在选择 Docker 镜像、PyTorch wheel、vLLM release 时就有依据了。我的原则很简单这些组件都往 6.5 或 6.6 靠拢不要混用版本太散的包。2.3 官网支持矩阵怎么读别只盯着 GPU 列表ROCm 官网有个 compatibility matrix里面列出了受支持的 GPU、操作系统、内核组合。但拿 AI Max 395 去对照时你会发现列表主线还是 MI 系列和 Radeon 独显APU 和部分移动端 GPU 的显示逻辑不太一样。这时候就要看“是否标了 gfx1151”或者发行说明里有没有 Strix Halo 字样而不是傻傻地搜“395”。另外要留意 ROCm 对 Linux 内核版本的最低要求。新版驱动模块跟较老的内核容易出现头文件不匹配所以 Ubuntu 24.04、Fedora 41 这些相对新一点的系统是更顺滑的选择。Windows 侧ROCm 近两年也开始了原生移植计划但普通用户暂时还是建议用 WSL2 或干脆装双系统Linux 下跑 AI 的省心程度目前依然远超 Windows。3. 资源汇总官方、社区、镜像一篇拿齐这部分是纯干货列表我把接触过的资源按照用途分了个类。每个类别里我都标注了哪些是必看的、哪些是备胎、哪些适合进阶用户。3.1 官方文档与发布入口ROCm 官方文档中心这是第一站包含安装、库介绍、内核驱动说明本质上的“最全地图”。地址不复杂直接搜 ROCm docs 就能出来强烈建议装完驱动后把“ROCm Installation”那一章通读一遍PYTorch 官方安装页它生产标准命令我们敲pip install torch --index-url ...装 ROCm 版 PyTorch 时用的链接就是它生成的HuggingFace / ONNX Runtime 等上游框架文档ONNX Runtime 对 ROCm 的支持文档其实写得不错推荐作为阅读补充3.2 PyTorch ROCm wheel 和安装命令PyTorch 官方从 ROCm 5.x 时代就开始发布预编译 wheel现在的命令大概长这样具体 index-url 以官方页面为准pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.5注意几个容易出错的地方第一Python 版本兼容性PyTorch 官方 wheel 一般需要 Python 3.9 到 3.12社区反馈 3.11 或 3.12 最稳定第二需要先把系统里现有的 torch 卸干净否则 pip 会保留旧版本导致冲突第三ROCm 环境变量如果对不上哪怕装上了也会在导入时提示找不到 HIP 库。更省事的方式是用uv或者 Conda 建独立环境至少避免搞坏系统 Python。3.3 vLLM 与推理框架vLLM 是当前服务化推理的主流选择滚动批处理、PagedAttention 这些特性对吞吐提升明显。它支持 ROCm但安装时得确认你选的 release 是否编入了 gfx1151。官方 GitHub 的 release 说明里会写rocm相关的预编译包如果找不到对应版本就老老实实从源码编译一次。llama.cpp 是另一个方向适合快速跑单机量化模型。它的 HIP 编译目前是社区维护的热门路径只要环境里有 ROCm 工具链编译参数指向-DGGML_HIPON再指定AMDGPU_TARGETSgfx1151即可。跑起来以后可以用llama-bench做快速性能测试这个比看评测文章直观得多。3.4 容器镜像汇总容器化对新手最友好因为所有库和依赖已经打包好可以绕开大部分依赖地狱。我常用的镜像来源rocm/pytorch 系列官方维护标签里有 ROCm 版本和 PyTorch 版本组合拉下来基本能直接跑vllm/vllm-openai 的 ROCm tag官方推荐有对应 ROCm 版本的镜像社群镜像Reddit 的 r/LocalLLaMA 和 AMD 开发者社区里经常有人分享自己打好的镜像最适合拿来当“黑盒”快速试用镜像虽好用但要注意一点容器内组件版本对应宿主机内核模块。通常 Docker 容器只装用户态库内核驱动还是依赖宿主机的amdgpu所以宿主机 ROCm 版本太老容器里新的软件栈照样跑不起来。这个“内核驱动在宿主、用户态库在容器”的心智模型最好先建立起来。3.5 社区站点与讨论专区搞 AI 绕不开社区ROCm 相关的活跃阵地包括AMD ROCm GitHub 仓库不是只看代码issue 区有很多真实用户的踩坑记录搜索 gfx1151 能找到大量一手经验Reddit 的 r/LocalLLaMA、r/ROCm测速帖、装机帖密度很高尤其是 Strix Halo 刚出的那几周很多关键结论都出自这里AMD 社区论坛官方工程师偶尔出没一些兼容性问题的最终回复会比普通社区准确我的经验是遇到报错先去 GitHub issue 搜报错原文十有八九能找到别人提交过的解决方案搜不到再发帖提问提问时附上rocm-smi和rocminfo的输出别人更容易帮你精准定位。3.6 工具链和调优能力如果只是跑跑现成模型装个 PyTorch 就够。一旦开始做量化、微调、实验新算子就得补上这些底层工具ROCm 编译器工具链hipcc、hipify、rocm-smi 等常见命令所在的包rocm-smi查看 GPU 状态的核心工具类似于nvidia-smi可以用rocm-smi --showuse --showtemp实时观察核心占用率和温度rocBLAS / hipBLASLt / MIOpen矩阵运算、卷积运算的底层库PyTorch 调用的就是它们。碰到算子报错时需要确认这些库是否已随 ROCm 安装AMD 的内存大页 HugePage 工具对内存密集型推理有帮助一般不需要普通用户干预这部分我平时不是全装而是哪个需求出现了再装哪个。但rocm-smi和rocminfo建议第一批就装它们是诊断一切问题的起点。4. 从零搭建在 AI Max 395 上跑通 Llama 的实操记录光有资源清单不够我把自己从全新系统到跑出第一个 token 的完整过程整理出来你照着走一遍应该能省下好几个小时。4.1 硬件与系统准备我用的是一台 AMD AI Max 395 平台的 mini PC配了 128GB LPDDR5X 内存系统盘是一块 2TB NVMe。系统装的 Ubuntu 24.04.2 LTS内核版本 6.8 往上。为什么不选 22.04因为 ROCm 6.5 官方对 24.04 的覆盖完整Linux 内核也新USB4、Wi-Fi 这类周边设备的兼容性也好很多。到手第一步先进 BIOS 确认几项内存频率是否识别到 8000MT/s 左右、启用 SVMAMD 的虚拟化相关选项后面跑容器有用、电源管理模式别选省电档。因为 AI Max 395 的内存带宽直接决定推理速度如果你发现内存被设成了低功耗 5600MT/s跑模型的性能会差一大截。4.2 安装驱动和运行时Ubuntu 下最保险的方式是用 AMD 源安装 ROCm。大致流程是# 添加 ROCm 官方 apt 源以 6.5 为例具体以官网为准 wget https://repo.radeon.com/rocm/6.5.1/ubuntu/... # 或者用官方的一键脚本 sudo apt update sudo apt install rocm装完必须用这两条命令验证rocm-smi # 应该看到 4 个卡其实是 1 个 GPU 的 4 个调度分区或者 1 个 device rocminfo # 搜索 gfx1151确认被识别新手最大的困惑点在这里AI Max 395 的核显在 ROCm 视角下可能会显示成几个不同的agent代表不同功能块。忽略额外信息你只需要关心 gfx1151 的那一行是否正常出现以及rocm-smi能不能读到温度、功耗。apt 装完再把当前用户加入render或video组否则普通用户访问 GPU 设备节点会权限不足sudo usermod -aG render $USER sudo usermod -aG video $USER改完注销重登再测权限问题在 ROCm 里非常常见几乎每个人都会遇到一次。4.3 安装 PyTorch ROCm 并自检然后建一个干净的虚拟环境装 PyTorchpython -m venv ~/envs/rocm_env source ~/envs/rocm_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/rocm6.5如果只想快速测试可以先跑一段最小的 GPU 张量运算看能否调用 HIPimport torch x torch.randn(1024, 1024, devicecuda) y x x.T print(torch.cuda.is_available()) # 返回 True 才说明 PyTorch 已经识别到 GPU这里有个 ROCm 生态特有的“迷惑行为”PyTorch 的devicecuda字符串在 ROCm 版本里也继续沿用所以torch.cuda.is_available()返回 True 不代表你在用 NVIDIA 硬件它只是兼容层实际调的是 HIP。很多新用户不知道这一点看到cuda字眼就会误判。如果要确认算力真的在跑看rocm-smi --showuse里的 GPU 利用率是否涨上来再配合watch -n 1 rocm-smi --showtemp观察温度曲线。如果遇到 HIP 相关的段错误或找不到库文件多半是LD_LIBRARY_PATH的问题把 ROCm 安装路径下的lib目录加进去再试。4.4 跑 Llama 的实际命令与预期性能我用 llama.cpp 做说明因为编译和运行最透明。先克隆仓库再按 ROCm 配置编译git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_HIPON -DAMDGPU_TARGETSgfx1151 cmake --build . --config Release -j 16编译时间可能会比较长耐心等待。跑一个 8B 模型的命令大概是./llama-cli -m /models/llama-3.1-8b-instruct.Q4_K_M.gguf -p 介绍一下合肥 -n 128如果你不想源码编译其实也可以下载官方编译的普通版 llama.cpp 跑 CPU但那样没法调用 GPU。协作开发时的建议是直接在构建目录里跑llama-bench它会把不同 block size 下的 prompt 处理速度和 token 生成速度一次性列出来比手动测准确得多。关于性能预期我给出一个基于实测的粗略参考区间受温度和电源策略影响会浮动8B 模型 Q4 量化prompt 处理约 800~1200 token/s生成约 40~55 token/s14B 模型 Q4 量化生成约 25~35 token/s32B 模型 Q4 量化生成约 15~25 token/s70B 模型 Q4 量化生成约 8~12 token/s勉强可用此时 128GB 内存能装下但带宽已经吃满这个成绩放到 128GB 统一内存平台上最大的意义是让“大模型常驻内存”成为可能。你不会有“显存不够先把其他程序关掉”的焦虑模型加载一次后面整个对话、任务调度都在几十毫秒级完成。4.5 服务化部署vLLM 与 OpenAI 兼容接口单机命令行爽完了接下来大概率想接一个服务端口给各种客户端用。vLLM 是更工业级的选择安装时如果不想从源码编译先看看是否已有匹配 ROCm 6.5 的预编译轮子。跑起来的命令类似python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-32B-Instruct \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85--gpu-memory-utilization这个参数在统一内存平台上要格外小心。它表示允许 vLLM 使用多少比例的可用内存但 AI Max 395 上没有独立的显存GPU 会动态占用系统内存。官方推荐的 0.9 往往会让系统没内存跑推理进程我实测 0.75 到 0.85 之间的体验比较稳。服务起来以后用标准 OpenAI SDK 就能调用和跑在 CUDA 机器上的接口风格完全一致。如果你更偏好轻量方案也可以选择 LLaMA.cpp 自带的 HTTP serverllama-server同样提供 OpenAI 兼容 API适合个人知识库或内部小工具部署简单依赖也少。5. 我实际踩过的坑和不建议做的操作这部分是血泪合集。环境搭多了以后我最大的体会是 ROCm 相关的报错大部分不是死解不了的难题而是版本不匹配的变体。5.1 驱动和内核版本暗坑我在 Ubuntu 24.04 上曾经把内核手动升级到 6.9结果 ROCm 模块编译失败启动时直接黑屏。后来查到 AMD 官方支持矩阵里对内核版本有明确验证范围新内核不一定更好。正确的做法是官方支持什么内核就用什么不要手贱升级。另一个高频坑是同时装了amdgpu-dkms和发行版自带的amdgpu模块冲突后rocminfo直接看不到设备。我后来的习惯是安装 ROCm 之前先把系统里各种 fglrx、旧版驱动清除干净装完再重启。如果你已经遇到画面崩坏、开机卡死进 recovery mode 卸载刚装的 ROCm 包即可恢复。5.2 环境变量和 Python 环境匹配PyTorch wheel 和LD_LIBRARY_PATH有着奇妙的耦合关系。我给自己定了几条规矩用 venv 或 conda 管理 Python 环境不在系统 Python 全局装库每个项目单独建环境避免 torch 和 vllm 互相覆盖遇到 ImportError 先检查rocminfo是否能正常输出再检查LD_LIBRARY_PATH是否指到正确的 ROCm lib 目录跑 vLLM 时减少不必要的环境变量多变量叠加反而会干扰这四条规矩说起来平凡却帮我避开过至少七八次“为什么我装的 PyTorch 看不到 GPU”的崩溃瞬间。5.3 内存、HugePages 和大模型加载统一内存平台的“内存即显存”模式有一个隐藏问题系统默认的内存页管理会干扰大块分配。推理超过 30B 模型时llama.cpp 或 vLLM 可能会提示分配失败或性能异常这时可以考虑启用 HugePages把模型驻留的内存取成 2MB 大页减少 TLB miss。不过这需要修改内核参数和系统配置普通用户可以先不开等真遇到性能瓶颈再调。另外AI Max 395 的内存带宽虽高但 LPDDR5X 和 HBM 的延迟特性不同。实测超过 70B 级别的模型时长上下文的 prefill 阶段会变得很慢这个物理瓶颈暂时无解。所以模型规模在上限边缘时别期望它能像 H100 那样飞起合理预期更重要。5.4 编译源码时目标架构写错的教训我第一次编译 llama.cpp 时没写AMDGPU_TARGETSgfx1151导致 GGML 编译时只包含了通用目标码GPU 完全没跑起来CPU 烧了半天也慢如老牛。后来才意识到ROCm 编译工具会根据目标架构生成特定 ISA架构没写对等于白编译。vLLM 从源码编译更讲究官方文档会要求指定ROCM_TARGETgfx1151或类似参数并且需要较新版本的 ROCm 编译器否则会在生成 miopen_kernels 时直接报错。这些细节在官方文档的AMD installation from source章节里都有只是字体不大、容易被跳过。我的建议是所有源码编译任务都集中固定在“ROCm 6.5 允许目标架构 gfx1151”的组合能省很多无谓的时间。5.5 不建议做的三件事结合群友的反馈我额外列出三件不建议做的事第一不建议一上来就跑去改装内核参数做 ROCm 性能调优比如强行改 GPU 频率上限容易导致整机不稳定。先把自带配置跑通再逐步调。第二不建议在 Windows 上硬跑 ROCm 原生推理。虽然 AMD 一直在推进 Windows 支持但生态完善度、算子覆盖、容器兼容都远不如 Linux折腾的性价比很低。第三不建议拿 128GB 内存去一次性并发跑很多个 70B 模型。容量虽够但带宽会迅速耗尽多个模型同时 prefill 时系统的响应延迟会指数级恶化还不如排队逐个推理。6. 资源速查表与后续路线建议最后把高频资源收拢成一张表方便你存下来慢慢查。我没有列密密麻麻的 URL更建议按“功能目标”去记忆这些位置因为网址会随着版本调整而变动。资源用途获取方式ROCm 官方文档安装说明、兼容矩阵、API 参考搜rocm docs amdPyTorch 官方安装页生成 pip 安装命令打开 pytorch.org 的 get-started 页面选 ROCmROCm GitHub 组织源码、issue、社区修复方案GitHub 搜ROCm组织rocm/pytorch 镜像Docker 快速启动环境Docker Hub 搜rocm/pytorchvLLM 官方文档服务化部署、源码编译指引搜vllm amd installationllama.cpp 仓库GGUF 模型推理、benchmarkGitHub 搜llama.cppAMD 社区论坛遇到疑难杂症时求助搜AMD community ROCmr/LocalLLaMA性能测试、模型推荐、使用分享Reddit 对应分区6.1 如果打算搭建我建议的路线第一步确定系统。优先 Ubuntu 24.04 或 Fedora 41内核保持官方默认。第二步按官方文档装好 ROCm 6.5 系列跑通rocminfo。第三步建 Python 虚拟环境装 PyTorch ROCm wheel跑一个矩阵乘法确认算力可用。第四步从 Hugging Face 下载一个 8B 量化模型用 llama.cpp 或 loader 跑通生成。第五步如果要做服务安装 vLLM 或 llama-server 启动 OpenAI 兼容接口。这条路线循序渐进每个阶段都有明确的验证点不会让你陷入“装了一堆东西但不知道是不是真的成功”的迷茫。整体时间大约半天到一天有一个懂 Linux 的朋友在旁边的话速度会再快一点。6.2 后续还能扩展哪些玩法把基础推理跑通之后AI Max 395 可以继续往几个方向深耕本地 RAG 知识库用嵌入模型 向量库 LLM 组成、多模态模型推理、基于 vLLM 给局域网内其他设备提供 API 服务、甚至用 ROCm 做小规模微调和 LoRA 实验。这些方向的共同点都是依赖统一内存的容量优势而缺点则集中在带宽对 prefill 阶段的限制。眼下 AI Max 395 还很新ROCm 的每个版本发布都会带来新的算子支持和性能优化。如果你像我一样打算长线使用我建议把 ROCm 版本固定在某个稳定序列同时对 releases 页面保持关注看到明显性能提升的新版本再系统性升级不要每次发布都冲到最前线。毕竟这套东西的乐趣在于把本地 AI 变成真正能日常使用的生产力工具稳定压倒一切。 AI Max 395与ROCm实战：本地大模型推理的资源与搭建指南
1. AI Max 395 是什么定位为什么值得折腾最近不少跑本地模型的群友都在聊 AMD AI Max 395微博、B站、X 上也经常刷到 Strix Halo 的测试图。作为已经实机用了一段时间的人我先把这台机器的定位说清楚它本质上是一颗把高性能 CPU、大规模 GPU、NPU 打包进同一个 chip 的旗舰级 APU而配套的软件生态主力就是 ROCm——AMD 对标的 CUDA 开源计算平台。所以这篇资源汇总核心围绕两件事展开AI Max 395 的硬件到底强在哪以及 ROCm 上怎么把它变成一台能跑大模型的工作站。为什么大家盯着它因为过去玩本地 AI要么需要一块昂贵的独立显卡要么选择苹果的统一内存 Mac。AI Max 395 把两者思路揉在一起CPU、GPU 共享同一片高带宽内存整机功耗又比传统 CPU独显方案低不少。这意味着你花一份预算就能获得一台既能编译代码、又能跑 32B 甚至更大参数量模型的单机设备。当然光有硬件还不行ROCm 生态近几年追上来了不少PyTorch、vLLM、llama.cpp 这些主流组件在 gfx1151 这个架构上有官方或半官方支持这才是它能进入我得力工具箱的真正原因。这篇文章适合三类人看第一类已经下单但还没装好环境的 AI Max 395 用户这里给了完整启动路径第二类在挑选板子和迷你主机时犹豫“AMD 能不能跑 AI”的观望者这里能帮你判断软件栈的实际成熟度第三类熟悉 CUDA 但没碰过 ROCm 的开发者不少命令行和报错在两种平台下完全不同看完能少走很多弯路。1.1 一颗芯片上的三件套CPU、GPU、NPU 都是什么水平AI Max 395 的规格简单概括是“堆料不眨眼”。CPU 部分是 16 核 32 线程的 Zen 5 架构基础频率 3.1GHz加速频率能到 4.3GHz 左右日常当工作主机用完全够。GPU 部分更夸张内置 40 个 RDNA 3.5 计算单元对应到独显大约就是 Radeon 8060S 这个级别桌面小主机外接一台显示器做图形输出、做渲染加速都足够。另有一块基于 XDNA 2 的 NPU本地吞吐大约 50 TOPS当前主要给 Windows 上的 AI 应用调用Linux 下主要靠 GPU 跑模型。但真正让 395 区别于普通 APU 的地方是它最高支持 128GB 的 LPDDR5X 内存内存位宽 256-bit峰值带宽在早期测试中稳定在 250GB/s 上下。这是什么概念对比一下桌面级 DDR5 双通道一般是 60GB/s 左右主流独立显卡配的 GDDR6 显存是 300GB/s 到 600GB/s 级别AI Max 395 的内存带宽比传统桌面内存高出四五倍又比独显低一个档次正好落在“能装大模型”和“能喂饱 GPU 计算单元”之间的甜点上。所以我特别建议把 AI Max 395 理解成一个“带宽约束的系统”而不是传统意义上的“有独显的电脑”。你在上面跑 AI 时GPU 计算单元往往还有余力但每一条指令都受制于内存能吐出多少数据。这个特质直接决定了模型选型、量化格式、推理框架的取舍后面实操段落我会专门展开。1.2 统一内存才是杀手锏传统独显的写代码流程是显存 24GB模型放不下就换成更小量化如果主机内存 64GB也没法把模型塞进显存里跑。AI Max 395 和苹果 M 系列一样GPU 和 CPU 之间没有严格物理上的“显存/内存”隔离PyTorch、llama.cpp 之类的框架都能默认把整个统一内存空间当成可用显存活来用。这一点带来的实际好处非常直接假如你机器配了 64GB那 20GB 左右的 30B 级模型、28GB 左右的双模态模型都能塞进去跑配到 128GB 后单机跑带量化的大参数模型成为可能。虽然带宽不如 HBM但容量和价格优势太明显了一个 ITX 主机就能干过去需要整台 A6000 工作站的事。更别提系统里同时挂着浏览器、IDE、编译任务统一内存不会把显存和系统内存切死资源利用率更高。1.3 和谁对比别用 RTX 4090 的思路看待 AI Max 395很多人习惯问“AI Max 395 能打 RTX 4090 吗”。我的看法是这个问法本身就失真。RTX 4090 计算吞吐确实高出一截显存带宽也多出不少但 24GB 显存容量摆在那跑不动 40B 以上的模型就是跑不动。AI Max 395 优势在“容量换带宽”、在“一颗处理器搞定全部”劣势也很清楚跑小模型、高并发负载时吞吐比不过一块中高端独显。更现实的参照是苹果 M4 Max、M4 Pro 这类统一内存平台。AI Max 395 的优点是开放生态可以自己装 Linux、随意跑容器、用标准 ROCm 工具链缺点是软件兼容性仍需要时间沉淀不是所有 CUDA 时代的工具都能开箱即用。拿它做推理、调参、跑本地 Agent 是非常合适的做大规模训练或超长上下文高性能服务建议还是考虑真正的专业级方案。2. ROCm 支持现状gfx1151 到能跑 PyTorch中间差了点啥讲完硬件该讲软件了。AMD 的 ROCm 是个开源计算栈架构分几层底层有内核驱动amdgpu往上是一组运行时库如rocm-smi、libamdhip64再往上就是 HIP 编程模型和 ROCm 生态库。PyTorch 现在官方分发 ROCm 版本vLLM 也有原生编译包llama.cpp 通过 HIP 后端支持 Radeon 全系列。但每个套件对架构的适配进度不一样这也是大家查资料最容易乱的地方。2.1 ROCm 和 CUDA 生态的差异先建立心理预期如果你之前只碰过 CUDA刚上手 ROCm 会有两个不舒服的地方。第一CUDA 是英伟达一家维护驱动、库、框架版本经常是一套整体对应而 ROCm 的各个组件升级节奏不同内核模块版本、HIP 版本、PyTorch wheel 里捆绑的 ROCm 版本时不时会错开需要多一点耐心看好支持矩阵。第二启动参数和报错信息不同GPU 架构 ID 叫 gfx1151部分老工具会不识别需要手动设置HSA_OVERRIDE_GFX_VERSION之类环境变量这个后面会专门讲。有了这两个心理预期后面遇到问题就不容易慌。实际上现在的 ROCm 已经比两三年前成熟太多PyTorch 官方轮子能做到“装完即用”绝大多数普通用户不需要自己从源码编译 HIP 库。只做推理的话一部分用户甚至能绕开传统 ROCm 全量安装直接跑 llama.cpp 的 HIP 版或 vLLM 的预编译包省时省力。2.2 gfx1151 支持时间线哪些版本值得记牢AI Max 395 对应的 GPU 架构代号是 gfx1151完整名字叫 RDNA 3.5 的集显变体。ROCm 正式支持这个 ID 是从 ROCm 6.4.x 开始在 6.5、6.6 系列里持续完善。也就是说如果你下载一个 6.3 甚至更老的 ROCm 安装包系统大概率会拒绝识别这块 GPU或者在rocminfo中看到一堆空白。这是很多刚入手二手的兄弟最容易踩的坑驱动装了一晚上最后发现版本太老。ROCm 6.3.x 及之前不原生支持 gfx1151不建议浪费时间折腾ROCm 6.4.x首次提供正式支持可用 PyTorch 推理但部分工具不稳定ROCm 6.5.x目前我用下来最稳的组合vLLM、llama.cpp 构建都能跑ROCm 6.6.x / 6.7 RC更新了编译器、算子库容器也升级可以尝鲜但注意回滚路径记住这个时间线你在选择 Docker 镜像、PyTorch wheel、vLLM release 时就有依据了。我的原则很简单这些组件都往 6.5 或 6.6 靠拢不要混用版本太散的包。2.3 官网支持矩阵怎么读别只盯着 GPU 列表ROCm 官网有个 compatibility matrix里面列出了受支持的 GPU、操作系统、内核组合。但拿 AI Max 395 去对照时你会发现列表主线还是 MI 系列和 Radeon 独显APU 和部分移动端 GPU 的显示逻辑不太一样。这时候就要看“是否标了 gfx1151”或者发行说明里有没有 Strix Halo 字样而不是傻傻地搜“395”。另外要留意 ROCm 对 Linux 内核版本的最低要求。新版驱动模块跟较老的内核容易出现头文件不匹配所以 Ubuntu 24.04、Fedora 41 这些相对新一点的系统是更顺滑的选择。Windows 侧ROCm 近两年也开始了原生移植计划但普通用户暂时还是建议用 WSL2 或干脆装双系统Linux 下跑 AI 的省心程度目前依然远超 Windows。3. 资源汇总官方、社区、镜像一篇拿齐这部分是纯干货列表我把接触过的资源按照用途分了个类。每个类别里我都标注了哪些是必看的、哪些是备胎、哪些适合进阶用户。3.1 官方文档与发布入口ROCm 官方文档中心这是第一站包含安装、库介绍、内核驱动说明本质上的“最全地图”。地址不复杂直接搜 ROCm docs 就能出来强烈建议装完驱动后把“ROCm Installation”那一章通读一遍PYTorch 官方安装页它生产标准命令我们敲pip install torch --index-url ...装 ROCm 版 PyTorch 时用的链接就是它生成的HuggingFace / ONNX Runtime 等上游框架文档ONNX Runtime 对 ROCm 的支持文档其实写得不错推荐作为阅读补充3.2 PyTorch ROCm wheel 和安装命令PyTorch 官方从 ROCm 5.x 时代就开始发布预编译 wheel现在的命令大概长这样具体 index-url 以官方页面为准pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.5注意几个容易出错的地方第一Python 版本兼容性PyTorch 官方 wheel 一般需要 Python 3.9 到 3.12社区反馈 3.11 或 3.12 最稳定第二需要先把系统里现有的 torch 卸干净否则 pip 会保留旧版本导致冲突第三ROCm 环境变量如果对不上哪怕装上了也会在导入时提示找不到 HIP 库。更省事的方式是用uv或者 Conda 建独立环境至少避免搞坏系统 Python。3.3 vLLM 与推理框架vLLM 是当前服务化推理的主流选择滚动批处理、PagedAttention 这些特性对吞吐提升明显。它支持 ROCm但安装时得确认你选的 release 是否编入了 gfx1151。官方 GitHub 的 release 说明里会写rocm相关的预编译包如果找不到对应版本就老老实实从源码编译一次。llama.cpp 是另一个方向适合快速跑单机量化模型。它的 HIP 编译目前是社区维护的热门路径只要环境里有 ROCm 工具链编译参数指向-DGGML_HIPON再指定AMDGPU_TARGETSgfx1151即可。跑起来以后可以用llama-bench做快速性能测试这个比看评测文章直观得多。3.4 容器镜像汇总容器化对新手最友好因为所有库和依赖已经打包好可以绕开大部分依赖地狱。我常用的镜像来源rocm/pytorch 系列官方维护标签里有 ROCm 版本和 PyTorch 版本组合拉下来基本能直接跑vllm/vllm-openai 的 ROCm tag官方推荐有对应 ROCm 版本的镜像社群镜像Reddit 的 r/LocalLLaMA 和 AMD 开发者社区里经常有人分享自己打好的镜像最适合拿来当“黑盒”快速试用镜像虽好用但要注意一点容器内组件版本对应宿主机内核模块。通常 Docker 容器只装用户态库内核驱动还是依赖宿主机的amdgpu所以宿主机 ROCm 版本太老容器里新的软件栈照样跑不起来。这个“内核驱动在宿主、用户态库在容器”的心智模型最好先建立起来。3.5 社区站点与讨论专区搞 AI 绕不开社区ROCm 相关的活跃阵地包括AMD ROCm GitHub 仓库不是只看代码issue 区有很多真实用户的踩坑记录搜索 gfx1151 能找到大量一手经验Reddit 的 r/LocalLLaMA、r/ROCm测速帖、装机帖密度很高尤其是 Strix Halo 刚出的那几周很多关键结论都出自这里AMD 社区论坛官方工程师偶尔出没一些兼容性问题的最终回复会比普通社区准确我的经验是遇到报错先去 GitHub issue 搜报错原文十有八九能找到别人提交过的解决方案搜不到再发帖提问提问时附上rocm-smi和rocminfo的输出别人更容易帮你精准定位。3.6 工具链和调优能力如果只是跑跑现成模型装个 PyTorch 就够。一旦开始做量化、微调、实验新算子就得补上这些底层工具ROCm 编译器工具链hipcc、hipify、rocm-smi 等常见命令所在的包rocm-smi查看 GPU 状态的核心工具类似于nvidia-smi可以用rocm-smi --showuse --showtemp实时观察核心占用率和温度rocBLAS / hipBLASLt / MIOpen矩阵运算、卷积运算的底层库PyTorch 调用的就是它们。碰到算子报错时需要确认这些库是否已随 ROCm 安装AMD 的内存大页 HugePage 工具对内存密集型推理有帮助一般不需要普通用户干预这部分我平时不是全装而是哪个需求出现了再装哪个。但rocm-smi和rocminfo建议第一批就装它们是诊断一切问题的起点。4. 从零搭建在 AI Max 395 上跑通 Llama 的实操记录光有资源清单不够我把自己从全新系统到跑出第一个 token 的完整过程整理出来你照着走一遍应该能省下好几个小时。4.1 硬件与系统准备我用的是一台 AMD AI Max 395 平台的 mini PC配了 128GB LPDDR5X 内存系统盘是一块 2TB NVMe。系统装的 Ubuntu 24.04.2 LTS内核版本 6.8 往上。为什么不选 22.04因为 ROCm 6.5 官方对 24.04 的覆盖完整Linux 内核也新USB4、Wi-Fi 这类周边设备的兼容性也好很多。到手第一步先进 BIOS 确认几项内存频率是否识别到 8000MT/s 左右、启用 SVMAMD 的虚拟化相关选项后面跑容器有用、电源管理模式别选省电档。因为 AI Max 395 的内存带宽直接决定推理速度如果你发现内存被设成了低功耗 5600MT/s跑模型的性能会差一大截。4.2 安装驱动和运行时Ubuntu 下最保险的方式是用 AMD 源安装 ROCm。大致流程是# 添加 ROCm 官方 apt 源以 6.5 为例具体以官网为准 wget https://repo.radeon.com/rocm/6.5.1/ubuntu/... # 或者用官方的一键脚本 sudo apt update sudo apt install rocm装完必须用这两条命令验证rocm-smi # 应该看到 4 个卡其实是 1 个 GPU 的 4 个调度分区或者 1 个 device rocminfo # 搜索 gfx1151确认被识别新手最大的困惑点在这里AI Max 395 的核显在 ROCm 视角下可能会显示成几个不同的agent代表不同功能块。忽略额外信息你只需要关心 gfx1151 的那一行是否正常出现以及rocm-smi能不能读到温度、功耗。apt 装完再把当前用户加入render或video组否则普通用户访问 GPU 设备节点会权限不足sudo usermod -aG render $USER sudo usermod -aG video $USER改完注销重登再测权限问题在 ROCm 里非常常见几乎每个人都会遇到一次。4.3 安装 PyTorch ROCm 并自检然后建一个干净的虚拟环境装 PyTorchpython -m venv ~/envs/rocm_env source ~/envs/rocm_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/rocm6.5如果只想快速测试可以先跑一段最小的 GPU 张量运算看能否调用 HIPimport torch x torch.randn(1024, 1024, devicecuda) y x x.T print(torch.cuda.is_available()) # 返回 True 才说明 PyTorch 已经识别到 GPU这里有个 ROCm 生态特有的“迷惑行为”PyTorch 的devicecuda字符串在 ROCm 版本里也继续沿用所以torch.cuda.is_available()返回 True 不代表你在用 NVIDIA 硬件它只是兼容层实际调的是 HIP。很多新用户不知道这一点看到cuda字眼就会误判。如果要确认算力真的在跑看rocm-smi --showuse里的 GPU 利用率是否涨上来再配合watch -n 1 rocm-smi --showtemp观察温度曲线。如果遇到 HIP 相关的段错误或找不到库文件多半是LD_LIBRARY_PATH的问题把 ROCm 安装路径下的lib目录加进去再试。4.4 跑 Llama 的实际命令与预期性能我用 llama.cpp 做说明因为编译和运行最透明。先克隆仓库再按 ROCm 配置编译git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_HIPON -DAMDGPU_TARGETSgfx1151 cmake --build . --config Release -j 16编译时间可能会比较长耐心等待。跑一个 8B 模型的命令大概是./llama-cli -m /models/llama-3.1-8b-instruct.Q4_K_M.gguf -p 介绍一下合肥 -n 128如果你不想源码编译其实也可以下载官方编译的普通版 llama.cpp 跑 CPU但那样没法调用 GPU。协作开发时的建议是直接在构建目录里跑llama-bench它会把不同 block size 下的 prompt 处理速度和 token 生成速度一次性列出来比手动测准确得多。关于性能预期我给出一个基于实测的粗略参考区间受温度和电源策略影响会浮动8B 模型 Q4 量化prompt 处理约 800~1200 token/s生成约 40~55 token/s14B 模型 Q4 量化生成约 25~35 token/s32B 模型 Q4 量化生成约 15~25 token/s70B 模型 Q4 量化生成约 8~12 token/s勉强可用此时 128GB 内存能装下但带宽已经吃满这个成绩放到 128GB 统一内存平台上最大的意义是让“大模型常驻内存”成为可能。你不会有“显存不够先把其他程序关掉”的焦虑模型加载一次后面整个对话、任务调度都在几十毫秒级完成。4.5 服务化部署vLLM 与 OpenAI 兼容接口单机命令行爽完了接下来大概率想接一个服务端口给各种客户端用。vLLM 是更工业级的选择安装时如果不想从源码编译先看看是否已有匹配 ROCm 6.5 的预编译轮子。跑起来的命令类似python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-32B-Instruct \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85--gpu-memory-utilization这个参数在统一内存平台上要格外小心。它表示允许 vLLM 使用多少比例的可用内存但 AI Max 395 上没有独立的显存GPU 会动态占用系统内存。官方推荐的 0.9 往往会让系统没内存跑推理进程我实测 0.75 到 0.85 之间的体验比较稳。服务起来以后用标准 OpenAI SDK 就能调用和跑在 CUDA 机器上的接口风格完全一致。如果你更偏好轻量方案也可以选择 LLaMA.cpp 自带的 HTTP serverllama-server同样提供 OpenAI 兼容 API适合个人知识库或内部小工具部署简单依赖也少。5. 我实际踩过的坑和不建议做的操作这部分是血泪合集。环境搭多了以后我最大的体会是 ROCm 相关的报错大部分不是死解不了的难题而是版本不匹配的变体。5.1 驱动和内核版本暗坑我在 Ubuntu 24.04 上曾经把内核手动升级到 6.9结果 ROCm 模块编译失败启动时直接黑屏。后来查到 AMD 官方支持矩阵里对内核版本有明确验证范围新内核不一定更好。正确的做法是官方支持什么内核就用什么不要手贱升级。另一个高频坑是同时装了amdgpu-dkms和发行版自带的amdgpu模块冲突后rocminfo直接看不到设备。我后来的习惯是安装 ROCm 之前先把系统里各种 fglrx、旧版驱动清除干净装完再重启。如果你已经遇到画面崩坏、开机卡死进 recovery mode 卸载刚装的 ROCm 包即可恢复。5.2 环境变量和 Python 环境匹配PyTorch wheel 和LD_LIBRARY_PATH有着奇妙的耦合关系。我给自己定了几条规矩用 venv 或 conda 管理 Python 环境不在系统 Python 全局装库每个项目单独建环境避免 torch 和 vllm 互相覆盖遇到 ImportError 先检查rocminfo是否能正常输出再检查LD_LIBRARY_PATH是否指到正确的 ROCm lib 目录跑 vLLM 时减少不必要的环境变量多变量叠加反而会干扰这四条规矩说起来平凡却帮我避开过至少七八次“为什么我装的 PyTorch 看不到 GPU”的崩溃瞬间。5.3 内存、HugePages 和大模型加载统一内存平台的“内存即显存”模式有一个隐藏问题系统默认的内存页管理会干扰大块分配。推理超过 30B 模型时llama.cpp 或 vLLM 可能会提示分配失败或性能异常这时可以考虑启用 HugePages把模型驻留的内存取成 2MB 大页减少 TLB miss。不过这需要修改内核参数和系统配置普通用户可以先不开等真遇到性能瓶颈再调。另外AI Max 395 的内存带宽虽高但 LPDDR5X 和 HBM 的延迟特性不同。实测超过 70B 级别的模型时长上下文的 prefill 阶段会变得很慢这个物理瓶颈暂时无解。所以模型规模在上限边缘时别期望它能像 H100 那样飞起合理预期更重要。5.4 编译源码时目标架构写错的教训我第一次编译 llama.cpp 时没写AMDGPU_TARGETSgfx1151导致 GGML 编译时只包含了通用目标码GPU 完全没跑起来CPU 烧了半天也慢如老牛。后来才意识到ROCm 编译工具会根据目标架构生成特定 ISA架构没写对等于白编译。vLLM 从源码编译更讲究官方文档会要求指定ROCM_TARGETgfx1151或类似参数并且需要较新版本的 ROCm 编译器否则会在生成 miopen_kernels 时直接报错。这些细节在官方文档的AMD installation from source章节里都有只是字体不大、容易被跳过。我的建议是所有源码编译任务都集中固定在“ROCm 6.5 允许目标架构 gfx1151”的组合能省很多无谓的时间。5.5 不建议做的三件事结合群友的反馈我额外列出三件不建议做的事第一不建议一上来就跑去改装内核参数做 ROCm 性能调优比如强行改 GPU 频率上限容易导致整机不稳定。先把自带配置跑通再逐步调。第二不建议在 Windows 上硬跑 ROCm 原生推理。虽然 AMD 一直在推进 Windows 支持但生态完善度、算子覆盖、容器兼容都远不如 Linux折腾的性价比很低。第三不建议拿 128GB 内存去一次性并发跑很多个 70B 模型。容量虽够但带宽会迅速耗尽多个模型同时 prefill 时系统的响应延迟会指数级恶化还不如排队逐个推理。6. 资源速查表与后续路线建议最后把高频资源收拢成一张表方便你存下来慢慢查。我没有列密密麻麻的 URL更建议按“功能目标”去记忆这些位置因为网址会随着版本调整而变动。资源用途获取方式ROCm 官方文档安装说明、兼容矩阵、API 参考搜rocm docs amdPyTorch 官方安装页生成 pip 安装命令打开 pytorch.org 的 get-started 页面选 ROCmROCm GitHub 组织源码、issue、社区修复方案GitHub 搜ROCm组织rocm/pytorch 镜像Docker 快速启动环境Docker Hub 搜rocm/pytorchvLLM 官方文档服务化部署、源码编译指引搜vllm amd installationllama.cpp 仓库GGUF 模型推理、benchmarkGitHub 搜llama.cppAMD 社区论坛遇到疑难杂症时求助搜AMD community ROCmr/LocalLLaMA性能测试、模型推荐、使用分享Reddit 对应分区6.1 如果打算搭建我建议的路线第一步确定系统。优先 Ubuntu 24.04 或 Fedora 41内核保持官方默认。第二步按官方文档装好 ROCm 6.5 系列跑通rocminfo。第三步建 Python 虚拟环境装 PyTorch ROCm wheel跑一个矩阵乘法确认算力可用。第四步从 Hugging Face 下载一个 8B 量化模型用 llama.cpp 或 loader 跑通生成。第五步如果要做服务安装 vLLM 或 llama-server 启动 OpenAI 兼容接口。这条路线循序渐进每个阶段都有明确的验证点不会让你陷入“装了一堆东西但不知道是不是真的成功”的迷茫。整体时间大约半天到一天有一个懂 Linux 的朋友在旁边的话速度会再快一点。6.2 后续还能扩展哪些玩法把基础推理跑通之后AI Max 395 可以继续往几个方向深耕本地 RAG 知识库用嵌入模型 向量库 LLM 组成、多模态模型推理、基于 vLLM 给局域网内其他设备提供 API 服务、甚至用 ROCm 做小规模微调和 LoRA 实验。这些方向的共同点都是依赖统一内存的容量优势而缺点则集中在带宽对 prefill 阶段的限制。眼下 AI Max 395 还很新ROCm 的每个版本发布都会带来新的算子支持和性能优化。如果你像我一样打算长线使用我建议把 ROCm 版本固定在某个稳定序列同时对 releases 页面保持关注看到明显性能提升的新版本再系统性升级不要每次发布都冲到最前线。毕竟这套东西的乐趣在于把本地 AI 变成真正能日常使用的生产力工具稳定压倒一切。