先泼一盆冷水FP8训练在2025年已经不是纸上谈兵但真正敢把训练、推理一整条链路都压在FP8上的团队依旧不多。DeepL这次放出的信息很有意思——他们用FP8把下一代LLM从预训练一路做到线上推理而不是像大多数团队那样只在推理阶段做权重量化、训练部分继续抱着BF16不放。对一个以翻译质量为生命线的公司来说这是个相当大胆的决策但也恰恰是FP8最正确的一种打开方式。我自己的团队过去一年也在跟进FP8路线下面的所有拆解和复盘一部分来自公开技术分享的还原一部分来自我们自己在类似规模实验里的踩坑。如果你想复刻DeepL这条路线重点不在“用了FP8所以快了多少”而在搞清楚格式怎么分、缩放因子怎么给、哪几个环节最容易掉精度以及什么时候必须回退到BF16。1. 决定All in FP8之前先算清楚这笔账1.1 从翻译专用到通用LLM这轮升级的体量到底差在哪DeepL以前的核心产品是NMT那东西参数量小、训练周期短、推理也轻。但“下一代LLM”完全是另一个物种要处理多语言理解和生成模型底座更厚预训练数据要覆盖几十种语言还要经过对齐训练才能保证输出符合翻译质量的标准。到了一定规模之后成本里占比最重的就不再是算法设计而是算力账单和工程复杂度。如果只从模型质量角度去谈LLM很多人会忽略一个事实训练一个能用、好用、经得起线上流量考验的多语言模型预训练阶段要跑很久。假设同样一个千亿参数不到的模型用BF16在H100集群上可能要跑大几十天电费、集群占用、卡间通信压力全都会变成实打实的成本。FP8在这里的价值不是“省一点显存”而是把一个本来要熬一个季度的实验周期缩短到能用“周”甚至“天”来迭代这对研究团队的意义是质变。另外DeepL这类公司的模型是要直接接线上翻译流量的推理成本会日复一日地滚下去。训练省的是项目预算推理省的是边际成本。两边都压FP8等于把整条AI服务链路的资源消耗往下拽了一个大台阶。所以我看到标题里同时写了training和inference时反而觉得这才是DeepL这波操作里最值得学习的地方。1.2 FP8带来的三重杠杆显存、带宽、算力在决定是否上FP8之前要先理解它到底在哪些维度上做文章。很多人只盯着“显存减半”其实FP8的好处是同时撬动三个杠杆显存FP8的权重和激活只占BF16一半的字节数。同样的显存预算下你可以塞更大的batch size、更长的序列或者在训练时把模型做得更大。显存带宽训练和推理大规模LLM时很多操作是访存密集型的尤其这轮读权重、那轮读KV Cache。数据量减半带宽瓶颈直接缓解。实测下来单纯因为访存压力下降带来的提速在长序列场景里往往比算力提升更明显。矩阵乘算力H100/H200这些卡对FP8有专门的张量核心路径单位时间里能计算的矩阵乘次数接近BF16的2倍。Blackwell这一代更是把FP8当作主力精度来设计。这意味着同样的卡FP8能给你更多FLOPs。这三件事叠加FP8在这代硬件上几乎成为大型LLM训练的唯一理性选择。当然前提是你能把精度损失控制在可接受范围内而这件事才是最难的部分。1.3 时间窗口为什么正好是2025年而不是2023年2023年FP8刚随Hopper架构进入大众视野时训练侧的软件栈远没有现在成熟。那时候Transformer Engine虽然能跑FP8但op覆盖不全、缩放逻辑不透明很多人试过之后发现掉点明显最后打回BF16。我当时也劝团队别急着动因为工程债太重。到2025年情况已经完全不同。框架层面的自动缩放、混合精度回退、动态损失缩放都成熟了社区也积累了足够多的训练稳定性调参经验。更重要的是Blackwell这代硬件把FP8的算力优势进一步放大如果你到了2025年还在用BF16训千亿参数模型等于每一分钱都多花了将近一倍。DeepL选择在这个时间点All in本质上踩准了硬件红利和软件成熟度交汇的窗口。2. FP8训练的真正深水区格式分工、缩放因子和损失风暴2.1 E4M3和E5M2不是二选一是一套流水线分工FP8内部有两种主流格式很多人会混淆但它们的分工完全不同格式指数位尾数位动态范围精度典型用途E4M34位3位约±448范围窄相对更高前向权重、前向激活、推理权重E5M25位2位约±57344范围宽相对低反向梯度、中间累加结果训练LLM时前向传播的权重和激活通常数值分布比较集中E4M3的精度优势更重要反向传播时梯度的动态范围变化剧烈经常出现个别极大值这时候E5M2更大的指数范围反而能兜住。如果你在整个训练流程里只用一种FP8格式损失精度几乎是必然的。我们的做法是顺着阶段切换格式前向的Linear层计算用FP8权重和FP8激活但权重是E4M3方向传播时对激活的梯度、对权重的梯度走E5M2。这种设计的本质是“按数值分布特征选格式”跟FP16时代用损失缩放解决下溢是同一个思路只不过FP8把这个问题放大到必须精细管理的地步。2.2 缩放因子的粒度战争从逐张量到逐行FP8和BF16最大的区别是BF16直接把数存进去不需要额外处理FP8则需要先算一个缩放因子scale把原始数值等比缩放到FP8能表示的范围里算完之后再乘回去。这个缩放因子怎么算、粒度多细直接决定了精度损伤程度。常见的缩放粒度有三种我们内部对比过一轮缩放粒度计算开销精度保护能力适合场景逐张量per-tensor最低一般数值分布均匀的小模型、短序列逐块per-block中等较强大模型训练矩阵内部存在局部大值逐行/逐通道per-row/per-channel最高最强多语言、长尾分布明显的场景DeepL这个场景比较特殊多语言数据里不同语言的token在激活空间里的数值分布差异很大有些稀有语言的某些维度会出现“离群值”一旦缩放因子被这些离群值主导其他大部分数值的精度都会被牺牲掉。所以我们最终的方案偏向逐行缩放给每一个token的激活单独算scale权重则按输出通道算。这个方案牺牲了一点额外计算开销但换来的是FP8在长尾语言上不掉点。说白了FP8量化这件事从来不是“选一个统一scale就完事”而是要在“计算开销”和“动态范围妥协”之间找平衡。2.3 训练稳定性:损失峰值、动态缩放和那个“FP8黑洞”FP8训练最容易翻车的点是损失突然飙升俗称loss spike。BF16时代损失峰值出现后训练还能自己缓过来FP8时代不一样因为FP8的动态范围有限一旦激活或梯度的数值突然暴增超出缩放因子能覆盖的范围这些数直接变成inf或异常大值模型权重很容易被污染而且可能一两个step就把几天的训练成果毁掉。我们训练中常用的缓解手段是动态缩放dynamic scaling。可以把它理解成一台自动调节的秤正常情况下scale保持在一个稳定值一旦检测到溢出立刻把scale调小让更多数值能被FP8表示等分布恢复平稳再慢慢把scale调回去。但动态缩放不是银弹。如果损失峰值来得太猛缩放调节会有滞后等scale调到位时损失已经冲上去了。所以我们的补救方法是训练循环里实时监控grad norm和activation amax一旦发现溢出step跳过参数更新保留旧权重连续多个step溢出则立即触发自动回退到BF16恢复checkpoint而不是硬扛。这里有个经验之谈FP8训练的loss spike很多时候不是优化器的问题而是缩放历史窗口太长。如果你把缩放因子更新延迟拉得过大它来不及响应剧烈波动如果窗口太短又会被单步噪声干扰。我们最终把amax历史的滑动窗口设在几十到上百个step之间算是稳定性和响应速度的折中。3. 这轮推理收益比训练更耐看从权重量化到KV Cache压缩3.1 训练与推理共享同一套FP8工程上省掉一整个校准环节很多团队的推理量化是单独做的训练用BF16上线前再做PTQ或者校准。这样做不是不行但会产生一个经典问题训练时的数值行为和推理时的数值行为不一致量化误差要到上线前才暴露。DeepL把训练也放到FP8之后推理直接复用训练时就已经在用的FP8权重。Attention、FFN这些核心模块在训练前向里本来就走FP8路径推理引擎只是把同样格式的权重接过来不需要再做一遍校准数据集采样、不需要重新调scale模型在训练时“适应的就是FP8的数值环境”推理掉点自然小很多。这是一个非常容易被低估的工程收益。做过多语言模型量化的人都知道翻译任务对俚语、专有名词、低资源语言的敏感度极高PTQ经常在这些地方莫名其妙地掉质量。训练推理精度统一之后这类问题会减少一大半。我们也验证过同样一个模型从BF16训练后量化到FP8推理和直接从FP8训练再到FP8推理后者的质量稳定性和长尾语言表现明显更好。3.2 KV Cache的FP8压缩对翻译类长序列有多重要推理阶段的另一个大头是KV Cache。自回归生成时每生成一个token都要把历史的key和value缓存下来用来算注意力。序列越长KV Cache占的显存越大。对翻译模型来说新闻、合同、论文这类长文档的token数轻松上千KV Cache经常吃掉一大半推理显存。KV Cache用FP8存储后缓存大小直接减半。减下来的显存能做什么最直接的收益是batch size可以加大GPU利用率随之提高。翻译服务的成本大头在推理而推理的成本大头在“等待”和“显存空转”KV Cache一压缩同样的物理机上能跑更多并发。唯一要小心的是KV Cache的FP8缩放方式有讲究。我们试过把Key和Value都压成E4M3E4M3精度较高但范围小注意力分数里偶尔会出现大的数值后来给Value用E4M3、给Key的查询路径保留略微宽的E5M2效果更稳。这块各家做法不完全一样但核心原则是分类处理别一刀切。3.3 翻译服务的延迟与吞吐取舍FP8把天平往回拨了翻译API和普通聊天产品还不太一样。聊天模型可以接受首token延迟大一点但翻译产品对“用户等结果”的心理预期非常短一小段话如果转圈超过一两秒体验就会变差。所以翻译服务通常不会把batch size堆到极高来牺牲单请求延迟这导致每个GPU的吞吐一直上不去。FP8给了我们一个新的平衡点。它一方面降低了单请求的显存占用让同样的延迟预算下能拼更多的batch另一方面对矩阵乘计算本身有加速token生成的实际时延也会下降。我们在自己的推理服务上观察到在保持p99延迟不变的前提下FP8路径的吞吐大概能拉起40%以上这个收益直接折成成本就是实打实的。当然延迟敏感场景也不能盲目上FP8。如果你们的线上核是T4、A10这类老卡对FP8支持很弱甚至没有那就要重新评估。FP8推理要吃到真正的红利硬件得是Hopper以上。4. 避坑实录我们把FP8调顺之前踩过的四个关键坑4.1 Embedding和词表是精度泄漏的高发区FP8全链路训练里我们最早掉的坑是Embedding。词表很大、token嵌入维度又不高这些参数在整个模型里的占比其实不算大很多人觉得“用FP8应该没问题”。但实测下来Embedding输出直接进第一个Transformer层如果Embedding本身被压成FP8误差会被后面几十层逐层放大尤其是低资源语言的token它们在嵌入空间里本来就稀疏量化后噪声会更明显。我们的解法很朴素Embedding层保持BF16不参与FP8量化。这一点在DeepL这种多语言模型里特别重要因为词表里包含了大量非拉丁语系token它们的数值分布几乎不可能靠一个统一缩放因子去覆盖。同理最后输出层logits的精度也尽量保留BF16否则对语言模型的分布输出影响很大。4.2 梯度裁剪阈值和学习率都必须重新标定从BF16切到FP8不要天真地认为“原来那套超参只改个精度就行”。我们在实验里踩过一次很深的坑BF16下梯度裁剪阈值设1.0挺正常切到FP8后同一个阈值频繁触发因为FP8量化本身给梯度叠加了额外的噪声梯度范数的分布比BF16更宽。结果就是模型训练变得非常钝loss下降特别慢。后来我们把梯度裁剪阈值按照FP8下的初始梯度分布重新标定才恢复正常。学习率也有类似问题FP8的数值表示更粗太激进的lr容易让权重在更新时直接超出E4M3的表示范围。我们最后实际是把峰值lr小幅下调了一档同时把warmup阶段拉长了一些给动态缩放更多时间去适应。别嫌这些参数琐碎它们往往是FP8训练“能跑”和“跑得好”之间最关键的差距。4.3 分布式通信不能跟着一起FP8训练大模型基本都会用数据并行或张量并行卡与卡之间要同步梯度。我们曾经为了省通信带宽尝试在all-reduce里直接用FP8梯度结果验证损失快速恶化。原因其实不难理解梯度经过量化后再去做跨卡求和误差会因为通信累加而放大而且这一过程没有统一的缩放管理每个卡上的scale还不一定一致。最终我们保留的通信格式是BF16/FP32只在本地计算阶段用FP8。通信数据量大一点没错但训练能稳稳往前走远比省那点带宽重要。如果你用的是框架里默认的FP8实现大概率它也是这么做的千万别自作聪明去把梯度通信也压成FP8除非你能保证所有卡的scale完全一致并且有充分的精度验证。4.4 回退机制把BF16主权重留着不是浪费很多团队上FP8之后巴不得把BF16的东西全删了我们吃过亏后坚决保留了一套BF16主权重副本。具体做法是优化器状态和主权重始终用FP32/BF16维护FP8只是计算时用的“临时表达”checkpoint保存时以BF16为主FP8的scale和缩放信息只作为辅助。这样做的最大好处是一旦某个阶段的FP8数值行为失控我们可以立刻从上一个BF16 checkpoint恢复而不是从头再来。我见过一些人把checkpoint直接存成FP8省了几个GB的存储空间结果训练中途出问题时后悔不已。训练稳定性的优先级永远高于存储效率这条原则在FP8时代比BF16时代更适用。5. 给想复制这条路的团队的行动参考5.1 动手前先回答的三个问题不是所有团队都该立刻All in FP8。动手之前建议先回答三个问题训练规模够不够大如果只是几亿参数的模型微调BF16的额外成本可以忽略FP8的调试成本反而占大头。硬件是否在Hopper以上T4/A10/A100虽然也能做FP8但算力红利不明显折腾半天可能性能不升反降。有没有足够的时间做精度回归FP8训练不是换了精度就完事需要完整评估训练稳定性、下游质量、多语言长尾表现如果项目排期太紧不建议在这个节点冒险。我的看法是FP8的收益是“规模越大越明显”。你手上是一个要跑几十天、烧掉大量资源的大模型训练那FP8几乎必选如果只是迭代周期很短的中小模型把BF16打磨好反而更实用。5.2 最小迁移路线先线性层再注意力最后嵌入即便决定上FP8也别一次全推倒。复刻DeepL这种做法时我们推荐的迁移顺序是第一步把FFN里最大的两个Linear层切换到FP8跑一个小规模的完整训练对比验证损失和下游指标第二步把Attention里的Q/K/V投影也切过去重点观察长序列和注意力分布是否异常第三步才轮到Embedding、LayerNorm、输出头这些数值敏感的位置而且这些地方很可能最终要留在BF16。每一步切换后都跑一遍固定seed的对比实验确认掉点在可接受范围再继续。我见过最稳妥的团队会给FP8训练单独写一个“精度基线测试集”里面既有通用的语言建模困惑度也有他们自己的翻译人工评测数据几项指标一起看才敢继续推进。5.3 下一步FP4、稀疏化和更激进的缩放走到FP8这一步之后路线图自然就会往更远看。Blackwell硬件已经开始支持FP4理论上有更极端的显存和算力收益但FP4的动态范围比FP8更窄能用的场景会更苛刻。我们的判断是FP4短期内更适合推理而非训练训练方面FP8仍然是最稳的甜点。另外一个方向是把FP8跟稀疏化结合权重里真正有价值的矩阵块可能只占一小部分如果把稀疏结构和FP8压缩叠加推理阶段的优势会更上一层。不过这会让工程复杂度激增不是所有团队都值得跟进。说到最后我个人的态度其实很简单FP8不是要不要用的问题而是怎么用得聪明的问题。DeepL这次把训练和推理的整条链路统一压到FP8本质上是在用工程上的克制换取长期的算力红利。格式分工、缩放粒度、回退机制这些细节看起来都不性感但它们才是FP8从“能跑”变成“能打”的真正分水岭。如果你也在考虑同一件事别纠结于“掉不掉点”先跑一个小规模实验把上面几个坑绕过去再回头算总账你会发现这条路比想象中更值得走。
DeepL全链路FP8训练与推理实战：格式分工、缩放因子与避坑指南
先泼一盆冷水FP8训练在2025年已经不是纸上谈兵但真正敢把训练、推理一整条链路都压在FP8上的团队依旧不多。DeepL这次放出的信息很有意思——他们用FP8把下一代LLM从预训练一路做到线上推理而不是像大多数团队那样只在推理阶段做权重量化、训练部分继续抱着BF16不放。对一个以翻译质量为生命线的公司来说这是个相当大胆的决策但也恰恰是FP8最正确的一种打开方式。我自己的团队过去一年也在跟进FP8路线下面的所有拆解和复盘一部分来自公开技术分享的还原一部分来自我们自己在类似规模实验里的踩坑。如果你想复刻DeepL这条路线重点不在“用了FP8所以快了多少”而在搞清楚格式怎么分、缩放因子怎么给、哪几个环节最容易掉精度以及什么时候必须回退到BF16。1. 决定All in FP8之前先算清楚这笔账1.1 从翻译专用到通用LLM这轮升级的体量到底差在哪DeepL以前的核心产品是NMT那东西参数量小、训练周期短、推理也轻。但“下一代LLM”完全是另一个物种要处理多语言理解和生成模型底座更厚预训练数据要覆盖几十种语言还要经过对齐训练才能保证输出符合翻译质量的标准。到了一定规模之后成本里占比最重的就不再是算法设计而是算力账单和工程复杂度。如果只从模型质量角度去谈LLM很多人会忽略一个事实训练一个能用、好用、经得起线上流量考验的多语言模型预训练阶段要跑很久。假设同样一个千亿参数不到的模型用BF16在H100集群上可能要跑大几十天电费、集群占用、卡间通信压力全都会变成实打实的成本。FP8在这里的价值不是“省一点显存”而是把一个本来要熬一个季度的实验周期缩短到能用“周”甚至“天”来迭代这对研究团队的意义是质变。另外DeepL这类公司的模型是要直接接线上翻译流量的推理成本会日复一日地滚下去。训练省的是项目预算推理省的是边际成本。两边都压FP8等于把整条AI服务链路的资源消耗往下拽了一个大台阶。所以我看到标题里同时写了training和inference时反而觉得这才是DeepL这波操作里最值得学习的地方。1.2 FP8带来的三重杠杆显存、带宽、算力在决定是否上FP8之前要先理解它到底在哪些维度上做文章。很多人只盯着“显存减半”其实FP8的好处是同时撬动三个杠杆显存FP8的权重和激活只占BF16一半的字节数。同样的显存预算下你可以塞更大的batch size、更长的序列或者在训练时把模型做得更大。显存带宽训练和推理大规模LLM时很多操作是访存密集型的尤其这轮读权重、那轮读KV Cache。数据量减半带宽瓶颈直接缓解。实测下来单纯因为访存压力下降带来的提速在长序列场景里往往比算力提升更明显。矩阵乘算力H100/H200这些卡对FP8有专门的张量核心路径单位时间里能计算的矩阵乘次数接近BF16的2倍。Blackwell这一代更是把FP8当作主力精度来设计。这意味着同样的卡FP8能给你更多FLOPs。这三件事叠加FP8在这代硬件上几乎成为大型LLM训练的唯一理性选择。当然前提是你能把精度损失控制在可接受范围内而这件事才是最难的部分。1.3 时间窗口为什么正好是2025年而不是2023年2023年FP8刚随Hopper架构进入大众视野时训练侧的软件栈远没有现在成熟。那时候Transformer Engine虽然能跑FP8但op覆盖不全、缩放逻辑不透明很多人试过之后发现掉点明显最后打回BF16。我当时也劝团队别急着动因为工程债太重。到2025年情况已经完全不同。框架层面的自动缩放、混合精度回退、动态损失缩放都成熟了社区也积累了足够多的训练稳定性调参经验。更重要的是Blackwell这代硬件把FP8的算力优势进一步放大如果你到了2025年还在用BF16训千亿参数模型等于每一分钱都多花了将近一倍。DeepL选择在这个时间点All in本质上踩准了硬件红利和软件成熟度交汇的窗口。2. FP8训练的真正深水区格式分工、缩放因子和损失风暴2.1 E4M3和E5M2不是二选一是一套流水线分工FP8内部有两种主流格式很多人会混淆但它们的分工完全不同格式指数位尾数位动态范围精度典型用途E4M34位3位约±448范围窄相对更高前向权重、前向激活、推理权重E5M25位2位约±57344范围宽相对低反向梯度、中间累加结果训练LLM时前向传播的权重和激活通常数值分布比较集中E4M3的精度优势更重要反向传播时梯度的动态范围变化剧烈经常出现个别极大值这时候E5M2更大的指数范围反而能兜住。如果你在整个训练流程里只用一种FP8格式损失精度几乎是必然的。我们的做法是顺着阶段切换格式前向的Linear层计算用FP8权重和FP8激活但权重是E4M3方向传播时对激活的梯度、对权重的梯度走E5M2。这种设计的本质是“按数值分布特征选格式”跟FP16时代用损失缩放解决下溢是同一个思路只不过FP8把这个问题放大到必须精细管理的地步。2.2 缩放因子的粒度战争从逐张量到逐行FP8和BF16最大的区别是BF16直接把数存进去不需要额外处理FP8则需要先算一个缩放因子scale把原始数值等比缩放到FP8能表示的范围里算完之后再乘回去。这个缩放因子怎么算、粒度多细直接决定了精度损伤程度。常见的缩放粒度有三种我们内部对比过一轮缩放粒度计算开销精度保护能力适合场景逐张量per-tensor最低一般数值分布均匀的小模型、短序列逐块per-block中等较强大模型训练矩阵内部存在局部大值逐行/逐通道per-row/per-channel最高最强多语言、长尾分布明显的场景DeepL这个场景比较特殊多语言数据里不同语言的token在激活空间里的数值分布差异很大有些稀有语言的某些维度会出现“离群值”一旦缩放因子被这些离群值主导其他大部分数值的精度都会被牺牲掉。所以我们最终的方案偏向逐行缩放给每一个token的激活单独算scale权重则按输出通道算。这个方案牺牲了一点额外计算开销但换来的是FP8在长尾语言上不掉点。说白了FP8量化这件事从来不是“选一个统一scale就完事”而是要在“计算开销”和“动态范围妥协”之间找平衡。2.3 训练稳定性:损失峰值、动态缩放和那个“FP8黑洞”FP8训练最容易翻车的点是损失突然飙升俗称loss spike。BF16时代损失峰值出现后训练还能自己缓过来FP8时代不一样因为FP8的动态范围有限一旦激活或梯度的数值突然暴增超出缩放因子能覆盖的范围这些数直接变成inf或异常大值模型权重很容易被污染而且可能一两个step就把几天的训练成果毁掉。我们训练中常用的缓解手段是动态缩放dynamic scaling。可以把它理解成一台自动调节的秤正常情况下scale保持在一个稳定值一旦检测到溢出立刻把scale调小让更多数值能被FP8表示等分布恢复平稳再慢慢把scale调回去。但动态缩放不是银弹。如果损失峰值来得太猛缩放调节会有滞后等scale调到位时损失已经冲上去了。所以我们的补救方法是训练循环里实时监控grad norm和activation amax一旦发现溢出step跳过参数更新保留旧权重连续多个step溢出则立即触发自动回退到BF16恢复checkpoint而不是硬扛。这里有个经验之谈FP8训练的loss spike很多时候不是优化器的问题而是缩放历史窗口太长。如果你把缩放因子更新延迟拉得过大它来不及响应剧烈波动如果窗口太短又会被单步噪声干扰。我们最终把amax历史的滑动窗口设在几十到上百个step之间算是稳定性和响应速度的折中。3. 这轮推理收益比训练更耐看从权重量化到KV Cache压缩3.1 训练与推理共享同一套FP8工程上省掉一整个校准环节很多团队的推理量化是单独做的训练用BF16上线前再做PTQ或者校准。这样做不是不行但会产生一个经典问题训练时的数值行为和推理时的数值行为不一致量化误差要到上线前才暴露。DeepL把训练也放到FP8之后推理直接复用训练时就已经在用的FP8权重。Attention、FFN这些核心模块在训练前向里本来就走FP8路径推理引擎只是把同样格式的权重接过来不需要再做一遍校准数据集采样、不需要重新调scale模型在训练时“适应的就是FP8的数值环境”推理掉点自然小很多。这是一个非常容易被低估的工程收益。做过多语言模型量化的人都知道翻译任务对俚语、专有名词、低资源语言的敏感度极高PTQ经常在这些地方莫名其妙地掉质量。训练推理精度统一之后这类问题会减少一大半。我们也验证过同样一个模型从BF16训练后量化到FP8推理和直接从FP8训练再到FP8推理后者的质量稳定性和长尾语言表现明显更好。3.2 KV Cache的FP8压缩对翻译类长序列有多重要推理阶段的另一个大头是KV Cache。自回归生成时每生成一个token都要把历史的key和value缓存下来用来算注意力。序列越长KV Cache占的显存越大。对翻译模型来说新闻、合同、论文这类长文档的token数轻松上千KV Cache经常吃掉一大半推理显存。KV Cache用FP8存储后缓存大小直接减半。减下来的显存能做什么最直接的收益是batch size可以加大GPU利用率随之提高。翻译服务的成本大头在推理而推理的成本大头在“等待”和“显存空转”KV Cache一压缩同样的物理机上能跑更多并发。唯一要小心的是KV Cache的FP8缩放方式有讲究。我们试过把Key和Value都压成E4M3E4M3精度较高但范围小注意力分数里偶尔会出现大的数值后来给Value用E4M3、给Key的查询路径保留略微宽的E5M2效果更稳。这块各家做法不完全一样但核心原则是分类处理别一刀切。3.3 翻译服务的延迟与吞吐取舍FP8把天平往回拨了翻译API和普通聊天产品还不太一样。聊天模型可以接受首token延迟大一点但翻译产品对“用户等结果”的心理预期非常短一小段话如果转圈超过一两秒体验就会变差。所以翻译服务通常不会把batch size堆到极高来牺牲单请求延迟这导致每个GPU的吞吐一直上不去。FP8给了我们一个新的平衡点。它一方面降低了单请求的显存占用让同样的延迟预算下能拼更多的batch另一方面对矩阵乘计算本身有加速token生成的实际时延也会下降。我们在自己的推理服务上观察到在保持p99延迟不变的前提下FP8路径的吞吐大概能拉起40%以上这个收益直接折成成本就是实打实的。当然延迟敏感场景也不能盲目上FP8。如果你们的线上核是T4、A10这类老卡对FP8支持很弱甚至没有那就要重新评估。FP8推理要吃到真正的红利硬件得是Hopper以上。4. 避坑实录我们把FP8调顺之前踩过的四个关键坑4.1 Embedding和词表是精度泄漏的高发区FP8全链路训练里我们最早掉的坑是Embedding。词表很大、token嵌入维度又不高这些参数在整个模型里的占比其实不算大很多人觉得“用FP8应该没问题”。但实测下来Embedding输出直接进第一个Transformer层如果Embedding本身被压成FP8误差会被后面几十层逐层放大尤其是低资源语言的token它们在嵌入空间里本来就稀疏量化后噪声会更明显。我们的解法很朴素Embedding层保持BF16不参与FP8量化。这一点在DeepL这种多语言模型里特别重要因为词表里包含了大量非拉丁语系token它们的数值分布几乎不可能靠一个统一缩放因子去覆盖。同理最后输出层logits的精度也尽量保留BF16否则对语言模型的分布输出影响很大。4.2 梯度裁剪阈值和学习率都必须重新标定从BF16切到FP8不要天真地认为“原来那套超参只改个精度就行”。我们在实验里踩过一次很深的坑BF16下梯度裁剪阈值设1.0挺正常切到FP8后同一个阈值频繁触发因为FP8量化本身给梯度叠加了额外的噪声梯度范数的分布比BF16更宽。结果就是模型训练变得非常钝loss下降特别慢。后来我们把梯度裁剪阈值按照FP8下的初始梯度分布重新标定才恢复正常。学习率也有类似问题FP8的数值表示更粗太激进的lr容易让权重在更新时直接超出E4M3的表示范围。我们最后实际是把峰值lr小幅下调了一档同时把warmup阶段拉长了一些给动态缩放更多时间去适应。别嫌这些参数琐碎它们往往是FP8训练“能跑”和“跑得好”之间最关键的差距。4.3 分布式通信不能跟着一起FP8训练大模型基本都会用数据并行或张量并行卡与卡之间要同步梯度。我们曾经为了省通信带宽尝试在all-reduce里直接用FP8梯度结果验证损失快速恶化。原因其实不难理解梯度经过量化后再去做跨卡求和误差会因为通信累加而放大而且这一过程没有统一的缩放管理每个卡上的scale还不一定一致。最终我们保留的通信格式是BF16/FP32只在本地计算阶段用FP8。通信数据量大一点没错但训练能稳稳往前走远比省那点带宽重要。如果你用的是框架里默认的FP8实现大概率它也是这么做的千万别自作聪明去把梯度通信也压成FP8除非你能保证所有卡的scale完全一致并且有充分的精度验证。4.4 回退机制把BF16主权重留着不是浪费很多团队上FP8之后巴不得把BF16的东西全删了我们吃过亏后坚决保留了一套BF16主权重副本。具体做法是优化器状态和主权重始终用FP32/BF16维护FP8只是计算时用的“临时表达”checkpoint保存时以BF16为主FP8的scale和缩放信息只作为辅助。这样做的最大好处是一旦某个阶段的FP8数值行为失控我们可以立刻从上一个BF16 checkpoint恢复而不是从头再来。我见过一些人把checkpoint直接存成FP8省了几个GB的存储空间结果训练中途出问题时后悔不已。训练稳定性的优先级永远高于存储效率这条原则在FP8时代比BF16时代更适用。5. 给想复制这条路的团队的行动参考5.1 动手前先回答的三个问题不是所有团队都该立刻All in FP8。动手之前建议先回答三个问题训练规模够不够大如果只是几亿参数的模型微调BF16的额外成本可以忽略FP8的调试成本反而占大头。硬件是否在Hopper以上T4/A10/A100虽然也能做FP8但算力红利不明显折腾半天可能性能不升反降。有没有足够的时间做精度回归FP8训练不是换了精度就完事需要完整评估训练稳定性、下游质量、多语言长尾表现如果项目排期太紧不建议在这个节点冒险。我的看法是FP8的收益是“规模越大越明显”。你手上是一个要跑几十天、烧掉大量资源的大模型训练那FP8几乎必选如果只是迭代周期很短的中小模型把BF16打磨好反而更实用。5.2 最小迁移路线先线性层再注意力最后嵌入即便决定上FP8也别一次全推倒。复刻DeepL这种做法时我们推荐的迁移顺序是第一步把FFN里最大的两个Linear层切换到FP8跑一个小规模的完整训练对比验证损失和下游指标第二步把Attention里的Q/K/V投影也切过去重点观察长序列和注意力分布是否异常第三步才轮到Embedding、LayerNorm、输出头这些数值敏感的位置而且这些地方很可能最终要留在BF16。每一步切换后都跑一遍固定seed的对比实验确认掉点在可接受范围再继续。我见过最稳妥的团队会给FP8训练单独写一个“精度基线测试集”里面既有通用的语言建模困惑度也有他们自己的翻译人工评测数据几项指标一起看才敢继续推进。5.3 下一步FP4、稀疏化和更激进的缩放走到FP8这一步之后路线图自然就会往更远看。Blackwell硬件已经开始支持FP4理论上有更极端的显存和算力收益但FP4的动态范围比FP8更窄能用的场景会更苛刻。我们的判断是FP4短期内更适合推理而非训练训练方面FP8仍然是最稳的甜点。另外一个方向是把FP8跟稀疏化结合权重里真正有价值的矩阵块可能只占一小部分如果把稀疏结构和FP8压缩叠加推理阶段的优势会更上一层。不过这会让工程复杂度激增不是所有团队都值得跟进。说到最后我个人的态度其实很简单FP8不是要不要用的问题而是怎么用得聪明的问题。DeepL这次把训练和推理的整条链路统一压到FP8本质上是在用工程上的克制换取长期的算力红利。格式分工、缩放粒度、回退机制这些细节看起来都不性感但它们才是FP8从“能跑”变成“能打”的真正分水岭。如果你也在考虑同一件事别纠结于“掉不掉点”先跑一个小规模实验把上面几个坑绕过去再回头算总账你会发现这条路比想象中更值得走。
