AMD MI355X megakernel 实战：投机解码 + MXFP4 把单请求解码提速 3.3 倍
· 阅读需 3 分钟
「ROCm 推理不如 CUDA」是过去两年的默认叙事。AMD 这篇技术博客不打算辩解，直接甩出了三个数字：1100、1470、3.3 倍。
三项技术的组合拳
针对单请求解码（延迟敏感、吞吐不重要的高交互场景），AMD 在 Instinct MI355X 上组合了三项优化：
1. Megakernel（持久内核）
- 单个持久内核覆盖整个前向传播（Qwen3.8-27B、GPT-OSS-120B 验证），消除逐算子 launch 开销
- 用 FlyDSL（Python DSL，编译到 AMD GPU 代码）与 HIP C++ 编写——注意 FlyDSL 与 DeepSeek 昇腾版 TileLang 的路线同构，社区 DSL 正在成为非 CUDA 平台的共同选择
2. 投机解码（Speculative Decoding）
- Qwen3.8-27B 搭配 EAGLE3/DFlash2 起草模型，batch 1、GSM8K 实测约 1,100 tokens/s
- GPU graph capture 消除 CPU round-trip
3. MXFP4 量化
- Qwen3.8-Flash-Next + 完整 262K token KV cache 装进单颗 die，较基线约 3.3 倍加速
双 die 架构红利：数据放置即性能
MI355X 的两颗 die（DPX+NPS2 拓扑）本身就是优化空间：
- GPT-OSS-120B 实测 约 1,470 tokens/s
- 仅靠数据放置优化（data locality）就拿到 7.5–8% 的解码提升
- 分阶段 profiling：Q/K/V 交接快 25%、专家路由快 17%
这类「拓扑感知放置」的收益在双 die GPU（MI355X、Rubin）上会越来越重要——芯片拓扑从实现细节变成了编译器与调度层的优化输入。
与竞品的横向定位
- 场景限定：1.9–3.3 倍是单请求 decode 提速——高交互智能体、实时对话等 batch 1 场景；大 batch 吞吐场景另算
- 参照系：此前 SemiAnalysis AgentX 测试中，GB300 NVL72 在低交互区间仍保持领先（详见 CUDA 护城河一文）；AMD 的强项在高交互区间的性价比
- 生态接入：成果已可通过 ATOM、SGLang、vLLM 使用（GPT-OSS-120B 为 vLLM 预览）
结论
这篇博客的真正信号不是某个倍数，而是方法论的收敛：megakernel、投机解码、社区 DSL、拓扑感知放置——AMD 的优化清单与华为 TileLang、谷歌 TorchTPU 高度趋同。非 CUDA 阵营已经形成了一套可复制的「推理栈追赶剧本」，剩下的变量只是执行深度。对买家，MI355X 在高交互推理场景已值得进入选型池；对开发者，FlyDSL/TileLang 这类 Python DSL 的学习投入开始有了跨平台的复利。
数据来源与口径说明
- 全部性能数字：AMD ROCm 官方技术博客（2026-10-20 至 23 发布周期），AMD News Daily 摘要转述
- 1100/1470 tokens/s 为 batch 1 特定模型配置，不外推至其他负载
- FlyDSL 为 AMD 的 Python DSL 工具，与 TileLang 的类比来自 SemiAnalysis 对两者的并列表述