在 AMD MI300X 上部署 DeepSeek-V4-Flash：一次硬核的技术复盘

背景

在 Doubleword，我们致力于构建一个专为高吞吐量推理设计的云平台。为了在当前的算力短缺环境中生存并发展，我们必须直面严峻的现实：高端 AI 加速器的供应极度紧张。

AMD 的 MI300X 于 2023 年 12 月 6 日在 AMD “Advancing AI” 活动上发布，作为对 NVIDIA H100 的回应，它与 H200 同属一代产品。在高端 AI 加速器领域，MI300X 显得颇为独特。当 H100 的价格在过去五个月内飙升了 40%（根据 SemiAnalysis 2026 年 4 月的报告，按需容量在各大主要 NVIDIA 芯片上已售罄）时，MI300X 的价值似乎仍未被充分认知。

MI300X 拥有每张卡 192GB 的 HBM3 显存，远超 H100 的 80GB；其 FP8 算力相当，但列表价格仅为 H100 的一半左右。然而，尽管硬件参数亮眼，MI300X 在软件生态上却面临巨大挑战。截至 2026 年 5 月初，在 MI300X 上使用 vLLM 运行 DeepSeek-V4-Flash 依然无法正常工作。尽管 AMD 在新芯片（如 MI350X、MI355X）上正在缩小软件差距，但这种关注尚未完全回溯到旧型号上。

本文旨在记录我们在尝试让 DeepSeek-V4-Flash 在 MI300X 上运行起来的过程中，所遇到的所有技术障碍、曲折路径及解决方案。

核心内容

FP8 数据类型的方言冲突

MI300X 是开启低比特精度计算时代的加速器之一。由于大语言模型（LLM）的权重、激活值和 KV 缓存对数值不精确性的敏感度低于典型的高性能计算（HPC）工作负载，NVIDIA 的 Hopper 架构和初代 Instinct 芯片首次引入了硬件对 16 位以下精度的支持。这意味着在传输数据量减半的情况下，可应用的 FLOPS 翻倍。

然而，FP8 数据类型的构建标准存在分歧：

• AMD / Graphcore 标准：由 AMD 和 Graphcore 在 2022 年的预印本中提出，并得到 Qualcomm 支持。
• OCP 标准：由 Arm、Intel 和 NVIDIA 通过开放计算项目（Open Compute Project）提出。

由于缺乏统一标准，各厂商实现了互不兼容的行为。正如 IEEE 754 浮点标准制定过程中的历史重演，AMD/Graphcore 的标准未能成为主流。AMD 后续的 MI325、MI350 和 MI355X 芯片均已转向 OCP 标准的 FP8，但 MI300X 仍仅支持 fnuz 方言。

fnuz 代表 “finite, nans, unsigned zero”（有限值、非数字、无符号零），即不支持 -0 和 inf。这种设计在小浮点范围且每位都至关重要的 AI 工作负载中看似合理，但并未广泛普及。

技术痛点： vLLM 的大多数 FP8 路径能够区分 e4m3 和 e5m2，却无法区分 fnuz 和 OCP 标准。尽管两者位布局相同，但指数偏差相差 1。这意味着如果以错误的方言读取相同的字节，结果会恰好偏差两倍。MI300X 是唯一一个在实际应用中因这一区别而产生显著影响的重大加速器。

解决方案： 我们需要修改 vLLM 的代码，使其在 MI300X 上正确识别 fnuz 格式。具体包括让 DeepSeek v4 的压缩器和融合压缩/量化/缓存写入使用平台特定的 FP8 数据类型，确保缩放因子和缓存字节一致，并将滑动窗口 K-cache 路由到感知 fnuz 的融合量化辅助函数中。

缺失的注意力快速路径

DeepSeek v4 的注意力机制是稀疏的。每个查询仅关注由学习索引器选定的 KV 缓存的子集（top-k），滑动窗口上下文则单独处理。这一架构包含多个组件：KV 压缩、索引器、滑动窗口路径以及支持这些操作的 FP8 缓存。

为了在部署中实现最大性能，每个组件都需要经过调优的内核支持。在 AMD 平台上，调优内核的来源是 AITER（AMD 的调优内核库，相当于 NVIDIA 的 cuBLAS、cuDNN、FlashAttention 和 Transformer Engine 的组合）。如果 AITER 没有针对特定形状的路径，vLLM 会回退到通用的 Triton 内核，而通用 Triton 注意力的速度比调优内核慢数倍。

问题现状： AITER 对 DeepSeek V4 (DSV4) 的支持不均匀，且现有支持往往针对较新的 AMD 部件（CDNA4 架构），而非 MI300X 使用的 CDNA3 (gfx942) 核心。

具体故障点：

1. 完全缺失的路径：在 gfx942 上，paged MQA logits、稀疏 MLA 预填充（prefill）、稀疏 MLA 解码（decode）完全缺失 AITER 路径。
   • 对策：为每个缺失部分添加 ROCm 特定的辅助函数，在 AITER 存在时调用它，否则回退到 Triton 实现。
2. 存在但崩溃的路径：AITER 预填充 MQA logits 和 AITER 稀疏预填充 logits 在 gfx942 上会出错。
   • 对策：当 current_platform 报告为 gfx942 时，拒绝分发到这些 AITER 路径，转而由 Triton 回退处理。

HIP Graphs 的限制

HIP Graphs 是 AMD 对标 CUDA Graphs 的技术，语义基本相同：在预热阶段记录一次操作流，然后在后续每一步中重放记录好的图。其优势在于消除了解码循环中每次启动内核的 Python 开销，这对于每个 token 启动数百个小内核的场景至关重要。由于 DeepSeek v4 组件众多，如果不利用 Graphs，内核启动次数将非常庞大。

限制条件： 捕获区域内的代码必须是其设备输入的纯函数。任何从主机读取、分配依赖于实时批次形状的稀疏张量，或在捕获区域内同步的操作，都会以预热时的值被记录并永久重放，导致错误。

适配挑战： AITER 调优内核天然符合这一要求，因为它们是接受设备指针和大小的 C++ 启动，不会从 Python 分配稀疏暂存内存，也不会在中途读取主机标量。然而，编写不兼容的 Triton 内核很容易。

解决方案： 我们需要重构稀疏 MLA 解码元数据，将其重建为静态、捕获安全的张量，避免动态稀疏分配和在捕获期间向设备写入主机标量。

其他遗留问题（Loose Ends）

除了上述主要障碍，我们还解决了一些较小的问题：

1. MoE 路由 Bug：专家掩码（expert-mask）的形状判断逻辑错误地依赖于全局是否启用了 ROCm AITER，而非即将调用的矩阵乘法是否实际使用 AITER。当全局启用 AITER 但 MXFP4 回退到模拟后端时，内核获取了错误的掩码，导致 token 被路由到错误的专家。
2. Triton 内核掩码错误：某个 Triton 内核在掩码填充通道时，错误地使用了全局张量边界而非逻辑块大小。在高并发下，填充通道会破坏 MoE 路由位矩阵。

关键要点

• 硬件性价比与软件生态的错位：MI300X 拥有 192GB HBM3 显存和极具竞争力的价格，但在软件栈成熟度上落后于 NVIDIA。截至 2026 年中，直接运行主流模型（如 DeepSeek-V4-Flash）仍存在严重兼容性障碍。