在 AMD MI300X 上运行 DeepSeek-V4-Flash

# 在 AMD MI300X 上运行 DeepSeek-V4-Flash 原文: https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/ 在Doubleword (https://app.doubleword.ai/)，我们正在构建一个面向大规模推理的云服务。要做到这一点，我们必须应对日益严重的计算资源短缺。 AMD 的 MI300X 于 2023 年 12 月在AMD 的“Advancing AI”活动 (https://www.amd.com/en/newsroom/press-releases/2023-11-15-amd-announces-amd-instinct-mi300-accelerator-launc.html)上发布，是 AMD 对标 NVIDIA H100 的产品，与 H200 属于同一代。它在高端 AI 加速器领域是个异类。当 H100 价格攀升（一年期租赁价格五个月内上涨 40%，所有主要 NVIDIA 部件的按需容量均已售罄SemiAnalysis,《GPU 大短缺：租赁容量》 (https://newsletter.semianalysis.com/p/the-great-gpu-shortage-rental-capacity)，2026 年 4月。)，MI300X 或许仍被低估。每张卡 192GB HBM3，对比 H100 的 80GB，FP8 算力相当，标价大约只有一半。然而，你今天就可以按需租用一台（例如从Hotaisle (https://www.hotaisle.ai/)），价格明显低于同等 NVIDIA 容量。 原因在于软件。在 AMD 上运行 AI 工作负载的问题已在其他文章 (https://newsletter.semianalysis.com/p/mi300x-vs-h100-vs-h200-benchmark-part-1-training)中被详尽讨论，并且有迹象表明，在 AMD 较新的芯片上，差距正在缩小SemiAnalysis 的InferenceX 控制面板 (https://inferencex.semianalysis.com/inference)追踪了最新的 AMD 部件（MI350X, MI355X）与当前的 NVIDIA 代际对比。。但这种对软件的新关注并未惠及旧款部件。截至 2026 年 5 月初，在 MI300X 上使用 vLLM 运行 DeepSeek-V4-Flash 就是行不通。 理论上，MI300X 是一款出色的加速器。我们希望它能够工作。这篇文章是一份工作日志，记录了我们在尝试让其正常运行时遇到的所有棘手问题和曲折路径。 ## FP8 方言§ (https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/#fp8-dialect) MI300X 属于开启低比特率潮流的那一代加速器。LLM 权重，以及在较小程度上的激活值和 KV 缓存，对数值不精确性的敏感度低于典型的 HPC 工作负载，因此 Hopper 代的 NVIDIA 芯片和第一代 Instinct 芯片首次增加了对低于 16 位精度的硬件支持。结果是，工作负载在传输数据量减半的同时，获得了双倍的 FLOPs。 问题在于，对于如何构建 FP8 数据类型存在分歧。Graphcore 和 AMD 在 2022 年的一份预印本 (https://arxiv.org/pdf/2206.02915)中提议了一种标准 (https://www.graphcore.ai/posts/graphcore-and-amd-propose-8-bit-fp-ai-standard-with-qualcomm-support)，并得到了高通的支持。Arm、Intel 和 NVIDIA 则通过 Open Compute Project 提出了另一种标准 (https://www.opencompute.org/documents/ocp-8-bit-floating-point-specification-ofp8-revision-1-0-2023-12-01-pdf-1)。这重演了当年导致 IEEE 754 标准制定的分叉路况（对 William Kahan 的采访 (https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html)生动讲述了算术标准是如何实际制定的，包括哪些论点胜出，哪些被遗忘。），不同的提供商构建了不同且互不兼容的行为。 也许毫不奇怪，考虑到各方的支持者名单，AMD/Graphcore 的标准未能胜出。AMD 较新的 MI325、MI350 和 MI355X 芯片都已转向 OCP 标准的 FP8。但 MI300X 仍然只支持 `fnuz` 方言（`fnuz` 代表“有限数、NaNs、无符号零”，即没有 `-0` 也没有 `inf`。在范围很小、每比特都很重要的小浮点 AI 工作负载中，去掉这些似乎是合理的做法，但这种方言并未流行起来，后来的 AMD 代际又回到了更常见的 FP8。），因此最初为 AMD 适配 DeepSeek 所做的 vLLM 工作实际上无法让 DeepSeek 在 MI300X 上运行。 许多 vLLM 的 FP8 路径能够感知 `e4m3` 与 `e5m2` 的区别，但无法区分 `fnuz` 与 OCP。两者的位布局相同，但指数偏置相差 1，因此同样的字节如果用错方言读取，结果会正好差两倍。MI300X 是实际中这种区别唯一重要的主流加速器（在本文中，我们会标注出自我们为此文准备的公开 vLLM 仓库中的演示 PR 的相关提交。`236de4e64` 提交 (https://github.com/doublewordai/vllm-amd-blog-doubleword/commit/236de4e64) 使 DeepSeek v4 压缩器以及融合压缩/量化/缓存写入使用平台 FP8 数据类型，以便缩放因子和缓存字节一致；`bd06e5d87` 提交 (https://github.com/doublewordai/vllm-amd-blog-doubleword/commit/bd06e5d87) 将滑动窗口 K 缓存路由到一个感知 fnuz 的融合量化和插入辅助函数中。）。 ## 缺失的注意力快速路径§ (https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/#missing-attention-fast-paths) DeepSeek v4 的注意力是稀疏的 (https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro)。每个查询只关注由学习到的索引器选出的 KV 缓存的一个 top-k 子集，滑动窗口上下文则单独处理。 它有很多活动部件：KV 压缩、索引器、滑动窗口路径、以及为每个部件提供数据的 FP8 缓存。在生产部署中为了获得最大性能，每个部件都需要以调优内核的形式得到特别关注（无双关意）。 AMD 上调优内核的来源是AITER (https://github.com/rocm/aiter)。AITER 是 AMD 的调优内核库，大致相当于 NVIDIA 用户从 cuBLAS、cuDNN、FlashAttention 和 Transformer Engine 组合中获得的功能。当 AITER 对特定形状没有合适的路径时，vLLM 会回退到通用的 Triton，而通用 Triton 注意力的速度比调优内核慢好几倍。AITER 对 DSV4 的覆盖并不均衡，而且现有的覆盖往往针对较新的 AMD 部件 (CDNA4) 而非 MI300X 中的 CDNA3 (gfx942) 核心。 这导致的后果有两种形式。有些部件在 gfx942 上完全缺少 AITER 路径：分页 MQA logits、稀疏 MLA prefill、稀疏 MLA decode。对于每个这样的部件，我们需要加入一个特定于 ROCm 的辅助函数，在 AITER 存在时调用它，否则就回退到 Triton 实现。有些部件虽有 AITER 路径，但在 gfx942 上会出问题：AITER prefill MQA logits 和 AITER sparse prefill logits 都属于这种情况。修复方法是，当 `current_platform` 报告为 gfx942 时，拒绝分发到这些路径，而是让 Triton 回退处理该调用。参见 `cb8a18556` 提交 (https://github.com/doublewordai/vllm-amd-blog-doubleword/commit/cb8a18556)：分页 MQA 和稀疏 MLA 回退，gfx942 上的 AITER 防护，以及正确性覆盖。 ## HIP 图§ (https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/#hip-graphs) HIP 图是 AMD 对 CUDA 图的模拟，语义基本相同：在预热时记录一次操作流，然后在后续每一步重放记录好的图。好处是消除了 decode 循环中每次启动的 Python 开销，这在每 token 启动数百个小内核时非常重要。由于 DeepSeek v4 有这么多活动部件，如果不利用图，内核启动次数会非常多。 代价是捕获的区域必须是其设备输入的纯函数。任何读取主机、分配依赖于实时批次的形状不规则的张量、或在捕获区域内同步的操作，都会被记录为预热时的值，然后永远重放。 AITER 调优内核天生就与此组成。AITER 内核是 C++ 启动，接受设备指针和大小；它们不会从 Python 分配不规则的临时存储，也不会在流中间读取主机标量。编写一个不能很好配合的 Triton 内核是很容易的，我们就犯过几次 `22cc02230` 提交 (https://github.com/doublewordai/vllm-amd-blog-doubleword/commit/22cc02230) 将稀疏 MLA decode 元数据重建为静态的、捕获安全的张量：没有动态的不规则分配，也没有在捕获期间进行主机到设备的标量写入。 ## 未解决的问题§ (https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/#loose-ends) 我们还遇到了一些较小的问题： - 一个 MoE 路由错误，其中专家掩码的形状是根据是否全局启用了 ROCm AITER 来决定的，而不是根据即将被调用的矩阵乘法是否实际上由 AITER 提供。当 AITER 全局启用但 MXFP4 回退到模拟后端时，内核得到了错误的掩码，导致 token 被路由到错误的专家。`8b5f7aa2c` 提交 (https://github.com/doublewordai/vllm-amd-blog-doubleword/commit/8b5f7aa2c) - 一个 Triton 内核根据全局张量边界而非逻辑块大小来屏蔽填充路径。在高并发下，填充路径会覆盖 MoE 路由位矩阵。`c32932bb9` 提交 (https://github.com/doublewordai/vllm-amd-blog-doubleword/commit/c32932bb9) ## 调优§ (https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/#tuning-it-up) 解决了正确性问题后，我们可以进行一些基本的优化。 在 MI300X 上工作的 DSV4-Flash 的首次性能分析显示，最耗时的层是稀疏 MLA 路径和 MXFP4 MoE 路径。这很好——如果不是这样，我们就真的麻烦了。 然而，在首次启动后，有相当一部分时间并不在矩阵乘法本身，而是在它们周围的簿记和调优上（稀疏 MLA decode 每一步都会重建不规则元数据。decode 内核写入一个临时张量，然后复制到调用者的输出缓冲区。bf16 投影权重在每一步 decode 时都被物化，而不是被缓存。一个静态的 Triton 启动形状同时覆盖了小批次斜坡和饱和服务。MXFP4 OGS 瓦片形状同样是一个单一静态选择，跨越了完全不同的加载阶段。`doublewordai/vllm\-amd\-blog\-doubleword\#2` (https://github.com/doublewordai/vllm-amd-blog-doubleword/pull/2)。）。 在我们简单的基准测试中，这将单张 GPU 的输出 token 速率从 2485 tok/s 提升到了 2699 tok/s，大约提高了 +8.6%。 ## 值得吗？§ (https://fergusfinn.com/blog/deepseek-v4-flash-mi300x/#was-it-worth-it) 在完成模型的适配、优化和测试后，我们得到了相当不错的数据： 这是一个胜利：MI300X 的租赁价格大约是其竞争对手 NVIDIA 容量的一半，每张卡拥有两倍以上的 HBM，并且现在就可以按需获取，而 H100 和 H200 的交货时间正在延长。我们还没有通过计算证明可以在每美元 token 数上胜过 NVIDIA 硬件，但我们已经证明，通过努力，我们可以接近到足以使其有用的程度。 造成困难的大部分因素都是暂时的。FP8 方言问题是 CDNA3 特有的：MI325、MI350 和 MI355X 都已转向 OCP 标准的 FP8，因此在新部件上不存在那个差两倍的陷阱。AITER 覆盖的缺口将随着 AMD 的内核工作赶上自身硬件而逐渐填补。而且，自从我们完成这项工作以来，即使在我们准备开源它的过程中，vLLM 在该模型上的性能和稳定性也得到了改善。 AMD 的硬件已经很好了有一段时间了。软件差距终于开始缩小的原因，一方面是 AMD 自身的关注，另一方面是从事这类工作的成本（本文中的所有修复都作为演示 PR 存放在我们为此准备的公开 vLLM 仓库 (https://github.com/doublewordai/vllm-amd-blog-doubleword)中；提交链接内联在文中。我们打算将那些对大家都有用的部分上游合并。）随着智能体编码的兴起而大幅下降。由于这两个因素，如果你将 DeepSeek-V4-Flash 请求发送到 Doubleword API (https://app.doubleword.ai/)，响应很可能就是由 AMD 驱动的。