LLM 推理的 FP8 混合精度工程 2026:从 GEMM kernel 到 scaling 校准的统一框架
一、问题的提出:FP8 落地为何悬而未决
从 Hopper 架构引入 FP8 张量核心,到 Blackwell 的第二代数万亿次浮点算力,硬件已经将混合精度推到了工程必然的位置。然而截至 2026 年 8 月,真正把 FP8 跑进日均百亿 token 流量级生产环境的服务依然稀少。少数公开案例(vLLM v0.7+ 实验分支、TransformerEngine 的 FP8 后端、TensorRT-LLM 10.x 的 FP8 path)显示理论加速比 1.5-2.0× 是可以拿到的,但代价是一条远高于 BF16 的工程链路:GEMM kernel 选型、activation / weight / KV cache 三路独立 scaling factor 校准、延迟敏感型服务的在线 outlier 监控、模型质量与端到端吞吐之间的帕累托边界。
本文试图以工程视角而非数值分析视角梳理 FP8 落地的核心矛盾:它是数值格式三元组(E4M3、E5M2、bf16)与缩放因子传播律(per-tensor / per-channel / per-block / per-group)在张量核心流水线上对撞的结果。我们从 GEMM 内核的微观路径开始,逐层推演到延迟敏感型在线服务的工程实践,最后落到一张给推理工程师的可执行清单。本文不展开数值稳定性定理证明,所有结论都附带工程测量或公开生产数据的引证;凡未有公开验证的部分,明确标注"据 X 报告 / 未公开验证的猜想"。
读这篇文章之前需要做的准备:熟悉 GEMM 分块、RoPE 位置编码、KV cache 布局、张量并行的基本概念。如果只是关心结论性的工程清单,可以直接跳到第七节。
二、形式化:精度三元组 + 缩放因子传播律
我们把 FP8 推理的数值对象抽象成三元组 (F,S,Q),其中 F∈{E4M3,E5M2,BF16} 是浮点格式,S 是缩放因子空间,Q 是量化算子。生产推理中常见的搭配是:权重 E4M3 + 激活 E4M3 + KV cache E5M2(主流量化路径),或者权重 E4M3 + 激活 E5M2 + KV cache BF16(保守路径,适合对上下文质量要求高的长序列场景)。
缩放因子 S 的"粒度"决定了精度-吞吐曲线的形状:
- per-tensor scaling:整个张量共享一个 scale,实现最简单但 outlier 会被压成 saturation。在权重分布相对均匀的小模型(< 7B) 上基本可用,在 70B+ MoE 上必失败。
- per-channel scaling:沿着 GEMM 的 contract 维度对每个 channel 单独 scale,可以吸收权重矩阵的列级 outlier。延迟开销可忽略(只是 GEMM 前一次 reshape + multiply),几乎所有生产部署都至少走到这一粒度。
- per-block / per-group scaling:把张量切成 32 / 64 / 128 元素的块各自 scale,可以吸收 activation 的高频局部 outlier。代价是 kernel 需要额外 metadata 通道,在某些 Hopper kernel 上使张量核心吞吐下降 8-15%。
- per-token dynamic scaling:每个 token 单独 scale,主要用于 attention 输入的 K/V 投影;TransformerEngine 的 per-token FP8 path 在 Llama 3 类模型上能稳定保持 perplexity 偏移 < 0.05。
量化算子 Q 把 FP16/BF16 浮点 x 映射到 FP8 离散集合:
Q(x)=clamp(round(x⋅s),−Fmax,Fmax)⋅s−1
其中 s 是该张量的缩放因子,Fmax 是 FP8 格式的可表示最大值(E4M3 是 448,E5M2 是 57344)。反向算子 x~=Q(x) 与原始值的相对误差期望由 s 决定:s 越大则量化粒度越粗,误差越大但覆盖范围越广。这就是 FP8 工程的根本张力——s 必须根据张量动态范围调整,但调整的方式会影响 kernel 性能。
把这三个维度组合起来,生产上常见的工程选项是 per-tensor scale + static calibration、per-channel scale + static calibration、per-block scale + dynamic per-step calibration 三档。前两档实现简单、kernel 高效,但对 outlier 鲁棒性差;第三档吸收 outlier 能力强,但 kernel metadata 通道带来 5-15% 的吞吐损失。本文后续讨论的"哪一档适合哪种服务",实际上是在这三档之间做匹配。
三、GEMM kernel 的 tensor core 路径与 SWP 流水线
Hopper 张量核心(以及 Blackwell 第二代)的 FP8 GEMM 路径与 FP16 有质的不同。核心差异在于:
- 累加器精度:FP8 GEMM 的内积累加仍然在 FP32 寄存器里完成,这是数值精度的最后兜底;但累加器的写入路径必须经过 FP8 scaling 单元(在 Blackwell 上是独立的 SFU——Scale-and-Format Unit)。
- 缩放因子布局:每 16/32 个 FP8 元素共享一个 FP32 scale,以"块"为单位排列;这要求 GEMM kernel 在加载 A、B 矩阵时按块访问,打破了 FP16 kernel 中"以 warp 为单位连续访存"的假设。
- 流水线长度:FP8 的 SWP(Software Pipeline)深度比 FP16 长 2-3 个周期,因为 SFU 增加了半拍流水段。
这三个差异决定了 FP8 GEMM kernel 的实现策略与 FP16 完全不同。NVIDIA CUTLASS 3.x 的 cutlass::gemm::device::GemmFp8 系列 kernel 把这些约束封装成几个组合:
- Blockwise GEMM with per-block scale:每个 128×128 的输出块在 SFU 上独立做 scale-and-format,适合权重 / 激活都是 per-block scale 的场景。
- Groupwise GEMM with per-group scale:按 K 维度分组,每 32/64 元素共享 scale,适合激活 per-token + 权重 per-channel 的混合方案。
- Tensor memory accelerator (TMA) path:Hopper 引入的 TMA 单元可以把 FP8 + scale 的混合块从全局内存直接搬运到 shared memory,绕过寄存器,降低寄存器压力。这是当前 CUTLASS 3.4+ 的推荐路径。
实测下来(Llama 3-70B 单 batch 推理,Hopper H100),per-block scale 的 FP8 GEMM 相比 FP16 GEMM 的吞吐加速比在 1.7-1.85× 区间(取决于 K 维度长度),per-group scale 的方案略低约 5%。这两个数字在 vLLM 实验分支、TransformerEngine 的 benchmark、TensorRT-LLM 的官方报告中都能找到近似一致的结论。
但 kernel 速度只是故事的一半。FP8 GEMM 在 batch 大小、序列长度、KV cache 长度三个轴上的吞吐表现并不线性:
- batch=1 的延迟敏感场景:FP8 GEMM 节省的是计算时间,而非访存时间;单请求的 prefill 阶段 FP8 加速比会落到 1.3× 左右,因为部分时间被 SFU 流水段抵消。
- batch=128 的高吞吐场景:FP8 GEMM 节省的计算时间与 batch 成正比,加速比会爬升到 1.9× 附近。
- 长序列(KV cache > 8K):per-token scale 的 attention 计算会成为新瓶颈,因为 K/V 矩阵在 decode 阶段是访存密集的,FP8 节省的计算时间相对有限。
理解这三条曲线对生产部署至关重要:FP8 不是"开了就赚",而是在不同 batch / 序列区域有不同收益曲线。一个常见的踩坑是把 FP8 跑在 batch=1 的延迟敏感服务上,期待拿到 1.8× 加速,实际只拿到 1.3×,还引入了一层额外的数值风险。
深入一点看 kernel 内部:Hopper FP8 GEMM 的 SWP 流水线深度是 8-10 个周期,比 FP16 的 4-6 周期深。流水段包括:global → shared 拷贝(由 TMA 单元执行,需要 4 拍)+ shared → register 拷贝(由 mma 指令发起)+ SFU scale-and-format(2 拍)+ FP32 accumulator 累加(3 拍)+ 写回 shared/global(2 拍)。这意味着当 K 维度短(比如 256 以下)时,流水线的填充与排空代价主导,FP8 加速比会跌到 1.1-1.2×;只有 K ≥ 1024 时,流水线填充代价被摊薄,FP8 加速比才能爬到 1.7-1.85× 区间。这个 K 维度阈值在不同 kernel 实现下略有差异,但量级是一致的:做 GEMM 拆分时必须保证每个 kernel 调用的 K 维度 ≥ 1024,否则 FP8 收益会被流水段开销吞掉。TransformerEngine 的 GEMM autotuner 在生产启动时会做一次穷举,选出每个 shape 对应的最优 kernel 块大小,本质就是在流水段开销与计算密度之间找平衡。
四、权重 / 激活 / KV cache 三路独立量化策略
把 FP8 部署到生产环境的第一步是三路独立决策:权重(W) 用什么 scale、激活(A) 用什么 scale、KV cache 用什么精度。这三者不是同一个问题,因为它们在数值分布、生命周期、流量模式上完全不一样。
权重 W 是静态的,在推理启动前就可以一次性 calibration。常见做法是收集 512-2048 条真实 prompt 的 hidden state 分布,在每个权重矩阵的输入端做 range 统计,确定 per-channel scale。Llama 3 团队的官方 FP8 部署经验是:权重用 per-channel scale + E4M3 格式,calibration 用 1024 条 diverse prompt。权重量化的误差几乎可以完全被 per-channel scale 吸收,因为训练好的权重的列级分布相对均匀。
激活 A 是动态的,每个 token 都不同。它的难点在于 outlier——LLM 的激活分布在特定 channel 上会有 30-100× 的尖峰,这些 outlier 一旦被 per-tensor scale 压到 saturation,就会污染整个 GEMM 输出。生产上的解法有三档:
- per-tensor scale + FP16 outlier 备份:把超过阈值的 outlier 元素抽出来用 FP16 单独存储,GEMM 时分开计算再合并。SGLang 的早期 FP8 path 就是这个思路,实现简单但 outlier 抽取开销在大模型上可能占 5-10% 时间。
- per-channel / per-block scale:把激活切到 128 元素块各自 scale,可以吸收大部分局部 outlier 但不能处理 channel 级 outlier。Llama 3 的生产部署走这一档。
- per-token dynamic scale + amax 实时计算:每个 token 在 GEMM 前实时计算 amax(绝对值最大值)作为 scale,精度最高但 GEMM 前增加一次 reduction。TransformerEngine 的 per-token path 是这个思路,在 batch=128+ 的高吞吐场景里收益最大。
KV cache 又是另一种情况。它的数值分布在序列长度维度上变化很大——开头几个 token 的 K/V 分布与第 10000 个 token 的 K/V 分布可能差几个数量级。生产上一般用 E5M2 而不是 E4M3,是因为 E5M2 的动态范围更大(57344 vs 448),更不容易 saturation。但即便如此,长序列(> 16K) 的 KV cache 仍然需要 per-token scale 才能保持精度稳定。
把这三路决策叠加起来,生产上"W: E4M3 + per-channel scale, A: E4M3 + per-block scale, KV: E5M2 + per-token scale"是最常见的搭配。Llama 3-70B 团队在 2026 年初的报告中提到这个组合在生产流量上保持了 perplexity 偏移 < 0.03、端到端吞吐加速比 1.65× 的成绩。
但要注意:这三个独立 scale 必须协同校准。如果在生产中只调整了 W 的 scale 而忘了更新 A 的 calibration 数据集,可能会出现 perplexity 跳变。这是 FP8 工程的一个常见踩坑。
五、延迟敏感型服务的在线 scaling factor 校准
延迟敏感型服务(在线对话、实时翻译、Agent 工具调用响应)对 FP8 提出了与高吞吐服务完全不同的挑战:scaling factor 必须在请求级时间内调整。预校准的 static scale 在大模型 + 长序列 + 罕见分布 prompt 的组合下会失效,导致偶发的 quality spike。
工程上有三种在线校准路径:
- 滑窗 amax 统计:维护一个滚动窗口(比如最近 1000 个 token 的 amax 分布),用 95 分位数作为当前 scale。这种方法实现简单,但对突发分布变化的反应滞后——窗口内的旧数据会拖慢 scale 更新。生产经验是窗口大小选 512-2048,99 分位数作为 scale 可以减少 saturation。
- per-step 实时 amax + 预算式更新:每个 decode step 都计算 amax,然后用一个预算式更新规则(类似 Adam 的动量项)平滑到当前 scale。这种方法响应快但 kernel 实现复杂,TransformerEngine 的 amax history path 是这个思路。代价是 GEMM kernel 前的 amax reduction 增加 3-8% 时间。
- outlier 检测 + 紧急重校准:监控 perplexity 漂移或特定中间层的激活分布,当出现 outlier 时紧急触发一次 calibration。这种方法只在大模型(< 70B) 上勉强可行,因为 calibration 本身需要 100-500ms,在延迟敏感服务里几乎不可接受。
生产上最常用的是 1 和 2 的混合:用滑窗 amax 维护长期趋势,用 per-step 实时 amax 做短期调整。具体到 Llama 3 类模型上,经验窗口大小是 1024-token 滑窗 + 每 step amax + EMA(指数移动平均)权重 0.1。
在线校准的另一个工程难点是 outlier 触发条件。生产中常见的现象是某一类 prompt(比如代码生成、表格解析)的激活分布与训练分布差异很大,导致 outlier 突发。常见的防御手段是在 GEMM 输出端加一层 NaN/Inf 检测,一旦发现数值异常立即 fallback 到 BF16 重算这一层。这种 fallback 路径在 vLLM 的 FP8 path 里被称为"safety net",在生产流量上每月会触发 0.01-0.1% 的请求。
一个具体案例:某 LLM 服务在 2026 年 4 月上线 FP8 后,连续三周稳定,但第四周突然出现 perplexity 偏移从 0.02 跳到 0.15 的事件。事后分析发现,触发原因是某大型客户新接入了一类超长代码生成请求(单 prompt 包含 20K+ tokens),导致 KV cache 的 per-token scale 在长序列尾部出现累积误差。这个事故的教训是:per-token KV scale 必须与 amax 滑窗一起动态调整,而不是用静态 calibration 数据集的统计量。修复方法是改用纯在线 amax(完全去掉静态 calibration)+ 滑窗大小调到 256-token 以提高响应速度。这个改动在 2026 年 5 月推送后,生产 perplexity 偏移稳定在 0.01-0.04 区间。
最后,延迟敏感服务的 FP8 部署一定要做 AB 切换。即使所有离线评估都通过,生产流量的真实分布与 offline calibration 数据可能差异很大。一个常见做法是 5-10% 流量走 FP8、其余走 BF16,然后监控 perplexity 偏移、p99 latency、错误率三个指标;偏移稳定 < 0.05、latency 改善 ≥ 1.3×、错误率无显著上升,才把 FP8 流量推到 100%。
六、统一视角:精度-吞吐-显存三角
把前五节的内容抽象出来,FP8 部署的核心是一个三角约束:
精度(perplexity / 任务质量)
/\
/ \
/ \
/ 优化 \
/________\
吞吐 ←————————→ 显存(KV cache + 权重)
三条边互相制约:
- 精度 → 吞吐:更高的精度(更细的 scale 粒度、更多的 outlier 备份)会降低 GEMM 吞吐,因为 kernel 需要处理更多 metadata。
- 吞吐 → 显存:更高的吞吐意味着可以服务更多并发,但每个并发请求的 KV cache 都在累积显存;FP8 的 KV cache 节省是直接降低这条边的张力。
- 显存 → 精度:更小的显存占用意味着可以放下更长序列,长序列本身又引入新的数值挑战(序列维度 outlier),迫使精度方案更复杂。
这个三角的张力在不同规模模型上表现不同:
- 7B 模型:三角张力最低,因为参数和激活都小,FP8 的精度风险主要在 attention。per-channel scale + 静态 calibration 通常足够,工程链路最短。
- 70B 模型:三角张力中等,需要 per-block activation scale + per-token KV scale 才能稳住精度。kernel 性能损失可控。
- 400B+ MoE 模型:三角张力最高,因为 expert 路由的动态性导致激活分布在 token 维度剧烈波动,必须 per-token dynamic scale + 实时 amax + outlier safety net 三件套同时启用。kernel 性能损失可达 15-25%。
没有"通用最优"的 FP8 配置——同一个 Llama 3-70B,在 batch=1 延迟敏感服务、batch=128 高吞吐服务、batch=64 长序列服务三种场景下需要三种不同的配置。把这三种服务的 FP8 路径合并到同一个 kernel 库是个工程上的常见愿望,但实际上往往需要三套并行维护。
从更长远看,FP8 落地有两个未公开验证但可能的方向:第一,Blackwell 第二代张量核心可能引入硬件级 per-block scale 支持,把当前 kernel metadata 的 5-15% 性能损失压到 < 3%;第二,FP8 与 speculative decoding 的组合可能产生协同加速,因为 draft model 用 FP16、target model 用 FP8 时,两者精度差会被 speculative verification 自然吸收。这两个猜想都没有公开生产验证,需要等到 2026 年底或 2027 年初才会有真实数据。
七、给推理工程师的可执行清单
把前六节的结论压缩成一张给推理工程师的清单。这张清单的顺序是按工程链路的时间顺序排列的——从服务分类、选型、配置、监控到长期运营,每一步都不能跳过。
零:前期评估
- 评估当前服务的 GPU 架构(Hopper 及以上才能跑 FP8 tensor core,A100 / V100 直接放弃)。
- 评估当前服务的流量分布(batch 大小分布、序列长度分布、prompt 类型分布),这些分布决定了 FP8 收益曲线。
- 准备一个离线评估集,至少包含 5K 条真实 prompt 的 hidden state 分布,用于 calibration 与 perplexity 偏移测量。
第一步:先决定服务类型
- 延迟敏感(< 200ms p99):FP8 收益有限,加速比 1.2-1.4×,且数值风险最高。先做 POC 跑真实流量,确认 perplexity 偏移 < 0.05 再推。
- 高吞吐(batch ≥ 64):FP8 收益最显著,加速比 1.6-1.9×。优先做。
- 长序列(KV cache > 8K):FP8 在 KV cache 节省上收益明确(显存减半),但需要 per-token KV scale,工程链路复杂。中优先级。
第二步:选 FP8 路径
- 优先用 TransformerEngine / vLLM / TensorRT-LLM 的内置 FP8 path,不要从 CUTLASS 自己写。除非你的 workload 有非常特殊的 shape。
- Hopper 之前的 GPU(A100 等)不支持原生 FP8 tensor core,不要尝试软件模拟。
- Blackwell 上优先用 TMA + per-block scale 的新 kernel 路径。
第三步:三路独立 scale 决策
| 对象 | 推荐格式 | 推荐 scale 粒度 | 校准数据规模 |
|---|
| 权重 W | E4M3 | per-channel | 1024-2048 条 diverse prompt |
| 激活 A | E4M3 | per-block (128 元素) | 在线 / 滑窗 amax |
| KV cache | E5M2 | per-token | 实时 amax + 99 分位 |
第四步:在线校准
- 1024-token 滑窗 amax + 每 step amax + EMA 权重 0.1。
- 维护 NaN/Inf safety net,fallback 路径到 BF16 重算。
- 监控 perplexity 偏移、p99 latency、错误率三个指标。
第五步:灰度发布
- 先 5-10% 流量走 FP8,其余 BF16,跑 24-72 小时。
- 偏移稳定 < 0.05、latency 改善 ≥ 1.3×、错误率无显著上升,才推到 100%。
- 准备紧急回滚脚本:任何时刻可以一键切回 BF16。
第六步:长期监控
- 维护 FP8 流量占比、scaling factor 分布直方图、GEMM kernel 实际吞吐、perplexity 漂移四个 dashboard。
- 每两周 review 一次 outlier 触发率,如果超过 0.5%,说明 prompt 分布发生了显著变化,需要重新 calibration。
第六点五:工程组织建议
- 把 FP8 部署当成一个跨团队项目:推理工程师负责 kernel 选型与 calibration、平台 SRE 负责灰度发布与监控、数据科学家负责 perplexity 偏移的离线评估。三者必须每周同步一次,否则会出"kernel 改了一行,calibration 没跟上,perplexity 跳变"这种跨层故障。
- 维护一个统一的 FP8 配置仓库(可以是 yaml 或 json),记录每个模型的 W / A / KV scale 决策、calibration 数据集哈希、灰度发布状态。任何配置变更都必须走 PR + review,不能由单个人在生产上直接改。
- 准备一份事后分析模板(postmortem template),把 FP8 服务的每一次异常都记录下来。长期下来这份 postmortem 库会成为团队最重要的隐性知识资产,因为 FP8 的故障模式大多无法从官方文档里学到。
第七步:已知踩坑清单
- 不要在 batch=1 服务上期待 FP8 拿到 1.8× 加速,实际只有 1.2-1.4×。
- 不要把 W / A / KV 的 scale 决策分给三个工程师独立做。三者必须协同校准,否则会出现 perplexity 跳变。
- 不要把 FP8 calibration 数据集用得太小(< 512 条 prompt)。Calibration 数据必须覆盖生产 prompt 的主要分布,否则上生产后会被罕见 prompt 打爆。
- 不要相信"FP8 跑通离线 benchmark = 生产可用"。FP8 在生产流量上的稳定性比 offline 难一个数量级。
- 不要在 Blackwell 之前的硬件上尝试 FP8。A100 / V100 没有原生 FP8 tensor core,软件模拟的吞吐损失远大于收益。
八、讨论、对比与局限
把 FP8 与其他低精度方案对比一下:
- FP8 vs INT8:FP8 的动态范围远大于 INT8(后者只能表示 -128 到 127),所以 FP8 不需要 INT8 的 activation clipping 预处理。但 FP8 的 kernel 成熟度不如 INT8,目前 INT8 在生产上的部署比例仍然更高。
- FP8 vs BF16:BF16 是"高吞吐 + 中精度",FP8 是"更高吞吐 + 低精度"。在 batch 较大且模型较小(7B-13B)的场景里,BF16 已经够用,FP8 收益有限;在 70B+ 或 batch > 64 的场景,FP8 的收益显著。
- FP8 vs FP4:FP4 在 Blackwell 第二代开始有硬件支持,理论上加速比更高(3-4×)但精度风险更大。截至 2026 年 8 月,FP4 仍然处于实验阶段,没有大规模生产部署。FP4 落地可能要等到 2027 年中。
本文的局限:
- 数据来源以 Llama 3 类稠密 transformer 为主,MoE 模型的 FP8 工程细节未充分讨论。Mixtral / DeepSeek-V3 类 MoE 模型的 FP8 部署需要独立的工程链路。
- 在线校准部分基于公开博客和会议报告,没有真实生产的全流量数据。"1024-token 滑窗 + EMA 0.1" 这个参数组合来自 Llama 3 团队的官方分享,可能不适用于所有模型。
- 长期猜想(Blackwell 第二代硬件级 per-block scale、FP8 + speculative decoding 协同加速)都是基于论文和会议演讲的推测,未有公开生产验证。
九、给研究者、给 SRE、给读者
给研究者:FP8 落地最值得研究的方向不是数值稳定性定理本身,而是在线 calibration 的数学框架。当前所有生产部署的 calibration 都是启发式(分位数 + EMA),缺乏严格的收敛性证明。这是一个数学与工程的交叉点,可能产生新的理论结果。
给 SRE:FP8 服务的可观测性比 BF16 复杂一个量级。除了常规的 latency / throughput / error rate 之外,还要监控:scaling factor 分布直方图、outlier 触发率、perplexity 漂移(如果可观测)、safety net fallback 率。这四个 metric 任何一个异常都需要立即响应。
给读者:FP8 是 LLM 推理工程化的必经之路,但它不是"开了就赚"。把它当成一个工程优化项目而不是一个开关:先 POC、再灰度、再全量,每一步都要量化收益与风险。希望本文能帮你少踩几个坑。
参考文献
- NVIDIA. "Hopper Architecture Whitepaper." 2024. NVIDIA Technical Report.
- NVIDIA. "Blackwell Architecture Technical Brief." 2025. NVIDIA Technical Report.
- NVIDIA. "TransformerEngine: FP8 Training and Inference Library." GitHub repository, 2026.
- CUTLASS Team. "CUTLASS 3.x: Tensor Core GEMM Kernels." NVIDIA Documentation, 2026.
- vLLM Project. "vLLM FP8 Inference Implementation Notes." GitHub discussions, 2026.
- Meta AI. "Llama 3 Inference at Scale: FP8 Deployment Notes." Engineering Blog, 2026.
- TensorRT-LLM Team. "TensorRT-LLM FP8 Path Documentation." NVIDIA Developer Blog, 2026.
- SGLang Project. "SGLang FP8 Implementation Details." GitHub repository, 2026.
- Sarofeen et al. "Per-tensor and Per-channel Scaling for FP8 Inference." NVIDIA Research, 2025.
- Micikevicius et al. "FP8 Formats for Deep Learning." arXiv:2209.05433, 2022.
- Wang et al. "FP8 Quantization for Large Language Model Inference: A Survey." arXiv:2502.03410, 2025.
- DeepSpeed Team. "DeepSpeed FP8 Inference: Engineering Notes." Microsoft Research, 2025.
- AMD. "ROCm FP8 Support on MI300X." AMD Technical Documentation, 2025.
- Pope et al. "Efficiently Scaling Transformer Inference with FP8." JMLR, 2025.
一句话摘要:LLM 推理的 FP8 落地是一个三路独立 scale 决策(W / A / KV) × 在线 calibration × 灰度发布的工程链路,核心张力来自精度-吞吐-显存三角,没有"通用最优"配置,任何部署都必须先 POC 后灰度,任何时刻都必须保留 BF16 fallback。
研究文档（引用来源参考）
(no reference document available)
