这份配置最近登上 Hacker News，作者 Ryan Zhou 把整套东西开源在 GitHub 上：一张 AMD MI300X 显卡，直接跑官方发布的 deepseek-ai/DeepSeek-V4-Flash-0731 权重，不做额外量化，也不做分层卸载，模型以出厂状态运行。仓库里包含 Docker Compose 部署栈、锁定哈希值的文件覆盖层、对照上游的差异补丁和调优参数表。

能塞下的原因是显存，不是算力

DeepSeek V4 Flash 是一个混合专家（MoE，指模型内部分成很多”专家”子网络，每个词只激活其中一小部分）架构的模型，基础设计 2840 亿参数、每个词激活 130 亿。0731 这一版额外附带了推测解码草稿模块，模型卡上标注的参数量因此是 3040 亿。它以 FP4 加 FP8 的混合精度发布——专家权重用四位、注意力和路由用八位——整个检查点在硬盘上约 149 GiB。

这个数字正是关键。它装不进 H100 的 80GB，也装不进 H200 的 141GB，所以官方推荐方案要么四张 H200，要么一整块 GB200 NVL4 托盘。而 MI300X 有 192GB 显存和 5.3 TB/s 带宽，容量是 H100 SXM5 的 2.4 倍，刚好装得下。

实际加载后，权重占 156.67 GiB，旁边还能放下 20GB 的键值缓存，另有 96 GiB 溢出到内存层，所以主机需要约 235 GiB 系统内存。显存峰值是 205.8GB 里的 204.5GB——余量不到一个 GB，非常紧。

性能数据

作者给出的实测结果如下：单条流解码中位数 168.6 词元/秒；调优后的预填充速度约 7.9 到 8.5K 词元/秒；八条并发流合计 542 词元/秒，每条中位 90.3；六十四条流突发时合计 830 词元/秒，没有显存溢出，也没有引擎报错；上下文验证到 256K，架构本身支持 100 万。

这些数字不是白来的。调优 21 个反复出现的矩阵乘形状，让单双流解码提升了 42% 到 62%，八到六十四流场景提升 10% 到 35%。融合 SiLU 激活加快速路由之后，原生解码从 34.5 提到 56.6 词元/秒，路由内核每层耗时从 42.6 微秒降到 11.9 微秒。还有一处很实用的调度改动：把调度预算设成 2048 词元、长预填充上限设成 1024 词元后，排在一个 5.2 万词元冷提示后面的短请求，首字延迟从 8.2 秒降到 0.5 秒。

代价是九个补丁

真正值得注意的是这套东西为什么需要九个补丁覆盖层。

一处是精度格式。MI300X 用的是 AMD 与 Graphcore 的 fnuz 变体八位浮点，而 MI325X 以及更新的卡用的是行业标准格式。一个假定标准格式的内核跑在 MI300X 上，缩放值可能直接差两倍。另一处更隐蔽：专家路由的位矩阵内核在填充块列时，掩码比对的是全局张量边界而不是逻辑块大小，高并发下填充通道会污染路由矩阵，表现出来是长提示下工具名字对不上、模式被遗忘——而这恰好是这个模型主打的智能体场景。修复只有一行。

软件侧的落差同样明显。vLLM 在 v0.21.0 的发布说明里声称支持 DeepSeek V4 的 ROCm 版本，但官方镜像在 AMD 硬件上启动就崩，报错指向一个只有英伟达 Hopper 架构才有的特性，与此同时官方配方仓库把所有 AMD 型号标为不支持。到 vLLM 0.25，官方配方验证了 MI325X，但只在张量并行度 1、4K 上下文下。MI300X——这张在 AMD 自家开发者云上 1.99 美元一小时就能租到的卡——至今不在官方支持矩阵里。

我的判断

AMD 那笔硬件账其实早就算得过来了：内存受限的混合专家推理场景，单卡显存容量才是硬约束，而 AMD 卖的就是更大的容量，MI325X 到了 256GB，MI355X 是 288GB。真正拖后腿的是硬件之下的那一层。

一个人花九个补丁、一套自建调优表填上的这段路，本该由芯片厂商自己走完。对准备用 AMD 卡做推理的团队来说，这份仓库是难得的参考；但它同时也是一份并不好看的进度报告。

你所在的团队评估过 AMD 卡做推理吗，卡在了哪一步？

来源：GitHub / ryanzhou 项目页，Hacker News