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_HIP=ON，再指定AMDGPU_TARGETS=gfx1151即可。跑起来以后可以用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 左右、启用 SVM（AMD 的虚拟化相关选项，后面跑容器有用）、电源管理模式别选省电档。因为 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 并自检
然后建一个干净的虚拟环境装 PyTorch：
python -m venv ~/envs/rocm_env source ~/envs/rocm_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/rocm6.5如果只想快速测试，可以先跑一段最小的 GPU 张量运算看能否调用 HIP：
import torch x = torch.randn(1024, 1024, device='cuda') y = x @ x.T print(torch.cuda.is_available()) # 返回 True 才说明 PyTorch 已经识别到 GPU这里有个 ROCm 生态特有的“迷惑行为”：PyTorch 的device='cuda'字符串在 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_HIP=ON -DAMDGPU_TARGETS=gfx1151 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/s
- 14B 模型 Q4 量化：生成约 25~35 token/s
- 32B 模型 Q4 量化：生成约 15~25 token/s
- 70B 模型 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 server，llama-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_TARGETS=gfx1151，导致 GGML 编译时只包含了通用目标码，GPU 完全没跑起来，CPU 烧了半天也慢如老牛。后来才意识到，ROCm 编译工具会根据目标架构生成特定 ISA，架构没写对等于白编译。
vLLM 从源码编译更讲究，官方文档会要求指定ROCM_TARGET=gfx1151或类似参数，并且需要较新版本的 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 amd |
| PyTorch 官方安装页 | 生成 pip 安装命令 | 打开 pytorch.org 的 get-started 页面选 ROCm |
| ROCm GitHub 组织 | 源码、issue、社区修复方案 | GitHub 搜ROCm组织 |
| rocm/pytorch 镜像 | Docker 快速启动环境 | Docker Hub 搜rocm/pytorch |
| vLLM 官方文档 | 服务化部署、源码编译指引 | 搜vllm amd installation |
| llama.cpp 仓库 | GGUF 模型推理、benchmark | GitHub 搜llama.cpp |
| AMD 社区论坛 | 遇到疑难杂症时求助 | 搜AMD community ROCm |
| r/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 变成真正能日常使用的生产力工具，稳定压倒一切。
