Zyphra ZYFA：AMD MI355X 上的 FP8 FlashAttention 提速 1.76 倍

AMD Instinct MI355X 上的注意力计算长期依赖 AMD 自家的 AITER 库，而 Zyphra 新发布的开源项目 ZYFA 给出了一个更具竞争力的选择。这套针对 MI355X 优化的 FP8 与 BF16 prefill attention kernel，在真实模型激活值上跑出了比 AITER 快 1.16 至 1.76 倍的成绩，同时在 head dimension 128 的场景下将误差降低了 62% 至 78%。对关注 AMD 生态推理性能的团队来说，这是一个值得评估的新变量。

为什么 prefill attention 值得单独优化

大模型推理分为 prefill 和 decode 两个阶段，两者的性能瓶颈截然不同。Decode 阶段受限于显存带宽，通常是 memory-bound；prefill 阶段则要一次性处理整段输入序列，计算密度高，属于 compute-bound。FlashAttention 系列工作正是围绕 prefill 场景的 IO 与计算效率做文章，而 FP8 进一步把矩阵乘法的吞吐潜力释放出来。

MI355X 作为 AMD 面向 AI 训练与推理的高端加速卡，硬件层面支持低精度格式，但软件栈能否把这份算力兑现，取决于 kernel 的实现质量。ZYFA 的切入点很明确：不做通用框架，而是把 prefill attention 这一个高频热点做到极致。这种单点突破的策略，在推理成本敏感的部署场景里往往比大而全的方案更容易见效。

FlashAttention 的核心思路是IO 感知（IO-aware）：GPU 的片上 SRAM（共享内存/寄存器）带宽远高于 HBM 显存带宽，而标准注意力实现需要把 Q、K、V 以及中间的 attention score 矩阵反复写入和读出 HBM。FlashAttention 通过分块（tiling）把 Q/K/V 切成小块载入片上内存完成计算，并用在线 softmax（online softmax）技巧在不保存完整 score 矩阵的前提下逐块累积结果，从而把显存读写量从 O(N²) 降到接近 O(N)。对 prefill 这种长序列、计算密集的场景，减少 HBM 往返往往比减少浮点运算更能提升端到端速度，这也是所有 prefill 注意力 kernel 优化的共同出发点。

ZYFA 的性能与精度数据

根据 Zyphra 公布的结果，ZYFA 的 FP8 kernel 在与 AMD AITER 的对比中取得了 1.16 至 1.76 倍的加速。加速比存在区间，说明收益与具体的序列长度、batch 配置和 head 维度相关，而非一个固定倍率。

更值得关注的是精度表现。在 head dimension 128 的设置下，ZYFA 相比 AITER 的误差降低了 62% 至 78%。低精度注意力最让人犹豫的就是数值稳定性，FP8 的尾数位有限，attention score 的动态范围又大，稍有不慎就会出现明显的精度损失。能把误差压到这个水平，意味着 ZYFA 在量化策略或累加路径上做了针对性设计，使其不只是"更快"，而是"快到可以用"。

需要注意，这组数字来自真实模型激活值而非合成基准，参考价值高于纯 microbenchmark。但公开信息没有披露具体的模型规模、序列长度分布和测试框架，横向对比时仍需在自己的负载上复现验证。

FP8 通常指 E4M3 与 E5M2 两种 8 位浮点格式：E4M3 用 4 位指数、3 位尾数，动态范围较小但精度更高，适合权重和激活；E5M2 用 5 位指数、2 位尾数，范围大但精度低，常用于梯度。相比 BF16（8 位指数、7 位尾数），FP8 的尾数位只有 3 位左右，意味着同样数值的相对表示误差放大约 16 倍。注意力计算中 QK^T 的 score 动态范围又特别宽，因此 FP8 注意力普遍需要**per-tensor 或 per-head 缩放因子（scaling factor）**把数值映射到可表示区间，并在 softmax 前做反量化或采用分块缩放。累加通常仍在 FP32 中进行，若累加也用低精度，误差会迅速累积。ZYFA 能在 head dimension 128 下显著降低误差，很可能就在缩放粒度、累加路径或 softmax 处理上做了更细的设计。

BF16 路径与开源策略的意义

ZYFA 同时提供 BF16 kernel，这一点容易被 FP8 的光环掩盖，但对实际落地很重要。并非所有模型和所有层都适合直接上 FP8，混合精度部署中 BF16 仍是安全基线。一个项目同时覆盖两种精度，意味着团队可以在同一套 kernel 体系内按层做取舍，而不必在多个库之间拼接。

选择开源则直接对准了 AMD 软件生态的痛点。相比 NVIDIA 的 CUDA 生态，AMD 的 ROCm 在注意力这类核心算子的优化库丰富度上仍有差距，第三方高质量 kernel 的补充能显著降低迁移门槛。Zyphra 把 ZYFA 开放出来，既是对自身工程能力的展示，也在为 AMD 推理栈积累可复用的基础设施。

AITER 是 AMD 官方维护的 AI Tensor Engine for ROCm，提供包括 attention、GEMM、MoE 等在内的高性能算子集合，是 MI300/MI350 系列上跑 vLLM、SGLang 等推理框架的默认后端之一。由于它直接调用 AMD 底层汇编与 Composable Kernel（CK）库，长期被视为 ROCm 上注意力的性能基线。ZYFA 选择以 AITER 作为对照对象，实际上是在官方基线之上做增量优化；这也解释了为什么它的加速比区间不算夸张——AITER 本身已经不是未优化的朴素实现，能在此基础上取得 1.16 至 1.76 倍提升，说明仍有可挖掘的调度或量化空间。评估时把 AITER 作为对照基准，比与 PyTorch 原生实现对比更有实际意义。

落地前需要确认的几件事

评估 ZYFA 时，加速比区间（1.16 至 1.76 倍）应当被视为上限参考而非预期值。真实业务中的序列长度分布往往长尾明显，短序列占比高时 kernel 启动开销会稀释收益。建议先用生产流量的采样输入做 A/B 对比，重点看 P99 延迟而非平均值。

精度方面，误差降低 62% 至 78% 是在 head dimension 128 下测得，其他 head 维度的表现需要单独验证。对于数学推理、长上下文检索这类对数值敏感的任务，建议在小流量上做输出一致性抽检，确认精度变化不会传导到最终效果。

生态成熟度也是现实因素。开源 kernel 的文档、issue 响应和版本兼容节奏，决定了它能否进入长期维护的技术栈。如果团队对 AMD 平台的依赖是长期的，把 ZYFA 纳入 benchmark 体系作为常规对照项，比一次性评估更有价值。

小结

ZYFA 的价值不在于某一个加速比数字，而在于它证明了 AMD MI355X 上的 FP8 注意力还有可挖掘的空间，并且这个空间可以由社区项目而非仅靠厂商库来填补。对正在评估 AMD 推理方案的团队，这是一个低成本、高信息量的试验对象：跑一轮自己的负载，就能知道它是否值得进入生产路径。