FuTransformer 在 Hopper 上实现 FP8 prefill …
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载prefill 与 decode 的不…
论文指出，Transformer 的 prefill 阶段会在多个 token 之间复用权重，因此主要受矩阵乘法和激活数据搬运制约；而单 token 的 decode 阶段复用有限，瓶颈落在权重读取与 KV-cache 读取上。FuTransformer 针对这两种负载分别设计：prefill 走 FP8 路径，decode 走 INT4 路径。实现上沿用了 CODA 的 GEMM 加 epilogue 思路，并加入 KV-cache 直接放置、把固定的 RMSNorm 增益折进权重、用延迟缩放直接写出 FP8 输出，以及支持无 padding 的 prefill。
INT4 decode 的量化做法
decode 阶段使用 INT4 投影权重和一份 INT4 的 KV-cache 副本。权重与 key 按 Tensor Core 的 fragment 布局存放，可直接反量化成 MMA 操作数，无需生成完整的中间 tile。缓存量化误差方面，采用块对角 Hadamard 变换来压低离群通道带来的影响。这些做法共同支撑了论文报告的 decode 加速比。
实测加速与精度代价
在单张 H100 上，prefill 比编译版 PyTorch FP8 快至多 1.48 倍，达到 1.29 PFLOP/s；8B 形状下带 SwiGLU 的 gate/up 投影，BF16 路径比 CODA 快 1.13 倍，FP8 路径比所评估的 BF16 CODA 路径快 2.02 至 2.18 倍。decode 在 8B 与 70B 形状、batch 1 至 32 范围内，比 PyTorch BF16 与 INT4 块中较快者快 1.3 至 2.4 倍，比编译并加 CUDA graph 的 BF16 快 2.1 至 3.3 倍，比使用 PyTorch INT4 投影核的同一块快 1.3 至 6.3 倍，后者面向单查询行且在 batch 32 时输给 BF16。精度上，全部 WikiText-2 token 走 INT4 权重路径时，困惑度从 6.24 变为 7.23（round-to-nearest）或 6.99（GPTQ），旋转 INT4 缓存再增加 0.20，各 kernel 与量化参考计算的困惑度差距在 0.001 以内。
为什么值得看
给出 prefill 与 decode 分别量化的具体加速比和精度代价，做 Llama 推理部署的工程师可直接对照评估。
信源1 家
关键事实
FuTransformer 是面向 NVIDIA Hopper GPU 的 Llama 风格 Transformer 块 CUDA 实现，prefill 用 FP8、decode 用 INT4[1]
单张 H100 上 prefill 比编译版 PyTorch FP8 快至多 1.48 倍，达到 1.29 PFLOP/s[1]
8B 与 70B 形状、batch 1 至 32 下，INT4 decode 比 PyTorch BF16 与 INT4 块中较快者快 1.3 至 2.4 倍，比自身 FP8 路径快 31% 至 51%[1]
完整 Llama-3.1-8B 在 batch 为 1 时单步 decode 耗时 2.8 ms，编译版 transformers 为 8.1 ms[1]
INT4 权重路径使 WikiText-2 困惑度从 6.24 升至 7.23 或 6.99，旋转 INT4 缓存再增加 0.20[1]
相关 · 论文
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。