单张 AMD MI300X 跑 DeepSeek V4 Flash：一份可直接抄的生产部署方案

原文来源：GitHub - ryanzhou/deepseek-v4-flash-mi300x — 在单张 AMD MI300X 上生产级运行 DeepSeek V4 Flash 的完整配置：digest 锁定的 vLLM ROCm 镜像、SHA-256 校验的补丁文件、AITER 调优表，实测 168.6 tok/s 解码吞吐。

DeepSeek V4 Flash 是 304B 参数的 MoE 模型，官方 vLLM 推荐配置主要面向 NVIDIA 和较新的 AMD 硬件。但 MI300X 有个独特的优势：192GB 的 HBM3 显存（是 H100 SXM5 的 2.4 倍），标价大约只要 H100 的一半。对 304B 的 checkpoint 来说，这个容量让"单卡部署"成为可能——整个模型直接放进显存，不需要 PCIe 权重流式传输，也不需要层卸载。

问题在于，要把模型在 MI300X 上"跑得对、跑得快"，需要解决一串只有踩过坑才知道的问题。GitHub 用户 ryanzhou 把自己生产环境的整套配置开源了，本文把它拆解成可以直接照抄的步骤。

为什么 MI300X 上跑 V4 Flash 有坑

先理解要解决的障碍，才知道这份配置的价值：

• FP8 格式不兼容：MI300X（CDNA3 架构）实现的是 AMD/Graphcore 的 FNUZ 变体 E4M3，而 MI325X 及更新硬件用的是 OCP 标准 FP8。假设 OCP 语义的 kernel 跑在 MI300X 上，scale 域可能差两倍。所以正确性优先于性能。
• 官方 recipe 未覆盖：vLLM 官方配方覆盖 NVIDIA 和 MI325X/MI355X，但没有针对 0731 checkpoint 的单 MI300X 生产配置。
• 缺失的 kernel 快路径：AITER 对 gfx942 的某些 GEMM 形状缺少调优表，稀疏 MLA 解码还有 HIP-graph 风险，MoE 高并发路由有 bug，CPU-KV 加载路径缺跨流同步（上游 issue #47282 记录了，修复 PR #47291 一直没合并）。

这个仓库做的就是把这些修复收集起来、锁定版本、逐字节验证。

实测性能

在锁定的技术栈上（vLLM ROCm nightly 0.26.1rc1.dev229+g124154a88.rocm723、AITER 0.1.19）：

权重按原样运行（as shipped），不需要额外量化。混合 KV 策略：20GB GPU 上的 fp8_ds_mla 缓存 + 96GiB CPU 原生卸载层，用于被逐出的前缀缓存条目。

部署步骤

1. 主机前置条件：一张 MI300X（gfx942，304 CUs，约 192GiB HBM）、可用的 AMD 内核驱动、较新的 Docker Compose、约 235GiB RAM（给 CPU KV 层用）、约 500GB 磁盘（模型缓存就约 156GB）。

2. 拉取锁定的运行时和模型。镜像用 digest 锁定（确保每次拉到的都是同一个镜像），模型也锁定 revision：

VLLM_IMAGE='vllm/vllm-openai-rocm@sha256:e68d18b2ba50298661bfc49baf01158fbf036645c2362cccf3e8a7a79fe6c69a'
MODEL='deepseek-ai/DeepSeek-V4-Flash-0731'
REVISION='7872f01b1d1fe23eabc4c98b48bffcef5a386062'
 
docker pull "$VLLM_IMAGE"
docker run --rm --entrypoint hf \
  -v /root/.cache/huggingface:/root/.cache/huggingface \
  "$VLLM_IMAGE" download "$MODEL" --revision "$REVISION"

3. 准备文件：

cp Caddyfile.example Caddyfile   # 设置 hostname、email、远程 IP CIDR
mkdir -p aiter-cache crash-dumps
chmod +x vllm-entrypoint.sh
sha256sum -c SHA256SUMS        # 首次启动前校验所有补丁文件

4. 启动：用仓库里的 compose.yaml 起服务。运行配置要点：--trust-remote-code 加 DeepSeek V4 的 tokenizer/reasoning/tool parser；fp8_ds_mla KV 缓存（UE8M0 块缩放 FP8，256 token 块）；VLLM_ROCM_USE_AITER=1 + --moe-backend triton（Triton OGS 处理分组 MXFP4 专家，AITER 处理 attention 和 dense 线性层）；DSpark-7 投机解码（概率性起草 + 块拒绝）；2048 token 调度预算和 1024 token 长 prefill 上限，防止冷 prompt 卡住其他流。Caddy 做 IP 白名单的 HTTPS 反代。

5. 验证正确性：不要只看吞吐。验证套件包含两轮工具调用 fixtures、BFCL 子集（74-76/90 精确调用）、OpenCode tool-schema 检查、380K token 的 needle recall（原生和 DSpark 两条路径都测）。冷 prefill 和缓存 prefill 可能走不同的浮点路径，所以要都测。

仓库结构速览

.
├── compose.yaml         # 生产栈（vLLM ROCm + Caddy），digest 锁定
├── Caddyfile.example
├── vllm-entrypoint.sh   # 启动前清理 /dev/shm 里过期的 CPU-KV mmap
├── SHA256SUMS           # 每个运行时工件的 SHA-256 校验
├── patches/             # 逐字节一致的生产补丁 + 与上游的 diff
└── tuning/              # gfx942 的 AITER A8W8 blockscale 调优表

给你的实操建议

• 镜像和模型都锁 revision：digest 锁定保证复现性，这是生产环境最重要的习惯。
• SHA-256 校验所有补丁：一行命令，杜绝"文件被改过但没人知道"。
• 先验证正确性再调性能：这个仓库的哲学是 FP8 正确性第一，性能调优在其后——顺序反了会得到"快但错"的结果。
• 没有 MI300X 也能抄思路：镜像锁定 + 补丁管理 + 校验和的部署模式，适用于任何 GPU 推理服务的生产化。

这个方案的定位很明确：给有 AMD 单卡（或想用 MI300X 省一半硬件成本）的团队一套"开箱即用、可复现"的生产配置。模型本身 MIT 许可，仓库 Apache-2.0，配置、补丁、调优表全部可审计。