DeepSeek V4 Flash 在单个 AMD MI300X 上运行——性能、修复与部署指南

TL;DR

DeepSeek V4 Flash 在单个 AMD MI300X GPU 上以 168 个 token/s 的中位解码速度（单流）和 约 8K token/s 的预填充速度 运行，使用完整的 3040 亿参数检查点，无需权重量化或卸载。性能通过应用一系列 ROCm 补丁、AITER GEMM 调优表以及混合 GPU-CPU KV 缓存策略实现。

---

为什么 MI300X 至关重要

Instinct MI300X 提供 192 GB 的 HBM3 和 5.3 TB/s 的内存带宽，约为 NVIDIA H100 SXM5 的 2.4 倍 HBM 容量。这一内存优势使得整个 156.7 GB 的 DeepSeek V4 Flash 检查点可完全驻留在 GPU 内存中，无需通过 PCIe 流式传输权重或分层卸载。大型 KV 缓存池（20 GB GPU + 96 GB CPU 层）支持 2–8 个典型并发流，以及高达 64 个流的突发负载。

"MI300X 拥有 192 GB 的 HBM3 和 5.3 TB/s 带宽，成本约为同等 NVIDIA 硬件的一半。" – AMD 产品页面

该仓库的新增内容

GitHub 仓库 ryanzhou/deepseek-v4-flash-mi300x 在先前工作（Fergus Finn 的 MI300X 启动和 Doubleword 的演示）基础上，提供了四项关键贡献：

1. 正确性补丁 适用于 ROCm 夜间版（vLLM ROCm 0.26.1rc1.dev229+g124154a88.rocm723），修复了 FP8 格式处理、MoE 路由、推测性验证和 CPU-KV 同步问题。
2. 已验证的推理配置，包含 DSpark-7 推测草稿、块拒绝机制、静态 K=7、2048 token 调度预算和 1024 token 长预填充上限。
3. AITER GEMM 调优表，针对 gfx942（MI300X）架构缺失的形状，以及 MXFP4 专家的 OGS 几何覆盖。
4. 混合 KV 策略：20 GB GPU fp8_ds_mla 缓存 + 96 GB 原生 CPU 卸载，配合 vLLM 问题 #47282 中记录的路径防护修复。

仓库结构（自包含概览）

.
├─ compose.yaml            # 生产级 Docker-Compose 堆栈（vLLM ROCm + Caddy）
├─ Caddyfile.example      # HTTPS 代理模板
├─ vllm-entrypoint.sh      # 启动前清理旧的 CPU-KV mmap 文件
├─ SHA256SUMS              # 所有运行时工件的 SHA-256 锁定值
├─ patches/
│  ├─ *.py                # 只读挂载的完整文件补丁
│  ├─ diffs/*.patch       # 与上游基线的统一补丁差异
│  └─ README.md           # 来源与再生说明
└─ tuning/
   └─ *.csv               # gfx942 的 AITER A8W8 块级调优表

关键性能数据（vLLM ROCm 夜间版 0.26.1rc1.dev229+g124154a88.rocm723，AITER 0.1.19）

指标	结果
单流解码（中位数）	168.6 tok/s
使用调优内核的预填充	≈ 7.9–8.5 K tok/s（新提示下 6988–7019 tok/s）
8 个并发流	总吞吐 542 tok/s，每流中位数 90.3 tok/s
64 流突发	总吞吐 830 tok/s，无 OOM 或引擎错误
上下文窗口	256K token 已验证（架构支持最高 1M）
权重在 HBM 中	156.67 GiB（无额外量化或卸载）

两项关键正确性修复

MXFP4 路由错误

MoE 位矩阵内核将块列填充至 Triton 块大小，但使用全局张量边界进行掩码，导致高负载下路由损坏。补丁将掩码替换为：

mask = (offs_local < BLOCK_SIZE) & (offs_global < nonzero_indx_size)

同时为分组 MXFP4 专家添加了融合 SiLU 和快速 DeepSeek 路由。

FP8 格式不匹配

DeepSeek V4 Flash 的 Lightning Indexer 缓存以 AMD 的 FNUZ E4M3 布局（16×16 块打乱）写入 FP8，而上游 AITER 期望的是 OCP E4M3 布局。补丁强制使用 float8e4b8 并设置 FP8_MAX=224.0，应用所需打乱，防止 MI300X 上出现两倍缩放错误。

推测性解码配置

该堆栈使用 概率草稿 + 块拒绝（DSpark-7）。两个 Gumbel 噪声补丁确保草稿提议噪声与拒绝/恢复噪声相互独立，仅在 draft_sample_method=probabilistic 时需要。

生产级调优细节

优化项	观察效果
为 gfx942 调优 21 个重复的 A8W8 GEMM 形状	单流/双流解码吞吐提升 42–62%
融合 SiLU + 快速路由 + 批次敏感专家块	原生 C1 解码从 34.5 提升至 56.6 tok/s（+64%）
BLOCK_H=64 的稀疏预填充块	预填充 7.9–8.5 K tok/s；稀疏注意力追踪从 317 ms 降至 142 ms/请求
静态 K=7 + 块拒绝 + 因果验证	单流 119.5 tok/s，输出正确
2048 token 预算 + 1024 token 长预填充上限	短请求在 52K 冷预填充后 TTFT 从 8.2s 降至 0.5s
混合 KV（20 GB GPU + 96 GB CPU）	1.93M token 长度等效容量，可容纳七个 256K 请求

并发性测试（不同 ~400 字提示，temperature=1.0，top_p=0.95）

流数	总吞吐 tok/s	每流中位解码	p50 TTFT
1	126.2	168.6 tok/s	1.026 s
2	145.4	152.7 tok/s	0.939 s
4	316.8	108.6 tok/s	0.369 s
8	542.3	90.3 tok/s	1.027 s
64	830.2	16.4 tok/s	2.190 s

注意： DSpark 接受率随提示内容变化；这些数据反映此特定 Docker 镜像与配置，非通用模型基准。

部署检查清单

1. 硬件 – 一个 MI300X（gfx942，304 CU，192 GiB HBM），AMD 驱动，Docker Compose，235 GiB 内存，~500 GB 磁盘。
2. 拉取锁定的运行时 – 使用摘要锁定镜像 vllm/vllm-openai-rocm@sha256:e68d18b2… 并下载模型版本 7872f01b1d…。
3. 验证补丁 – 首次启动前运行 sha256sum -c SHA256SUMS。
4. 启动堆栈 – docker compose up -d；观察日志中成功启动消息（模型加载、KV 缓存大小、CUDA 图捕获）。
5. 预热内核 – 执行一次未缓存的预填充（约 8K token）以初始化内核；后续请求将更快。
6. 烟雾测试 – 通过 Caddy 代理的 /v1/completions 端点发起简单完成请求。

生产注意事项

• HBM 空间紧张 – 热水位可达 ~204.5 GB（共 205.8 GB）。将 --kv-cache-memory-bytes 提高至 20 GB 以上可能在图捕获期间触发 HSA_STATUS_ERROR_OUT_OF_RESOURCES。
• CPU KV 层仅存储缓存条目 – --kv-offloading-size 96 --kv-offloading-backend native 在 /dev/shm 中映射约 103 GB 用于被驱逐的前缀缓存条目；入口脚本在崩溃后清理旧映射。
• 调度器警告 – 1664 token 的调度器警告是预期的，因为 DSpark-7 从 2048 token 预算中预留了草稿槽位。
• 预热延迟 – 重启后首次预填充耗时约 5.3 秒（8.9K token）；后续预填充降至约 1.7 秒。
• 正确性测试 – 仓库包含验证套件，覆盖工具调用、模式检查，以及原生和 DSpark 路径的 380K token 针对性召回测试。

许可与来源

堆栈、文档和 vLLM 衍生补丁采用 Apache-2.0 许可；AITER 补丁保留其 MIT 头部。DeepSeek V4 Flash 模型本身在 Hugging Face 上采用 MIT 许可。

---

Hacker News 社区洞察

• 有用户指出，DwarfStar 可用更少内存运行相同模型，可能使用了量化，但该仓库刻意避免量化以保留全权重推理。
• 另一评论澄清，MI300X 通常以 8 GPU OAM 机箱形式销售（约 25 万欧元），而非单卡。
• 部分参与者将吞吐与 NVIDIA H800 结果（≈ 15K tok/s/gpu）进行比较，并建议仍有进一步优化空间。
• 有贡献者提到，MI350P PCIe 变体（144 GB HBM）也可托管 DeepSeek V4 Flash，因使用 MXFP4 量化后模型可容纳于 144 GB 内。
• 更广泛的问题被提出：在不使用量化的情况下，能否对拥有数千亿参数的前沿模型进行推理？DeepSeek V4 Flash（304B）表明，单个高 HBM GPU 可处理亚万亿参数模型。