我们如何利用FP8构建DeepL新一代大型语言模型（LLM）的训练与推理系统
当DeepL部署我们当前配备544块NVIDIA H100张量核心GPU的NVIDIA DGX SuperPOD时，我们获得的不仅仅是计算能力的显著提升。H100还通过新一代张量核心实现了对8位浮点（FP8）数据类型的原生支持，使GPU能够以FP8精度执行矩阵乘法及其他张量运算。通过采用FP8精度进行矩阵乘法运算，我们能够提升大型语言模型（LLMs）的训练与部署吞吐量，因为现代LLMs涉及的大部分计算都以矩阵乘法形式呈现.
将计算精度从16位降至8位，对DeepL新一代大型语言模型的开发产生了重大影响。这使我们能够构建规模更大的语言人工智能模型，其参数数量大幅增加，经语言专家评估后质量显著修订，同时仍能在生产推理的相同延迟窗口内运行。这意味着翻译质量较我们之前的模型提升了1.4倍（针对欧洲语言）和1.7倍（针对英语和日语等更复杂的语言对），同时仍能高效快速地交付成果。这也意味着我们的模型能够处理更多功能和特性上的请求，同时不会影响用户体验。
换言之，FP8训练与推理在扩展DeepL语言人工智能方面发挥了核心作用。
本文旨在阐述我们为将FP8应用于训练与推理所经历的历程，分享支撑这一成果的核心工具与技术，并展示我们在训练与推理性能方面以训练与推理性能为术语生成的阶段性成果。
BF16和FP8格式有什么区别？
BFloat16（BF16）与FP8的区别简约来说在于：后者使用半数位数来表示数值。实际上，BF16将16个可用位置分配到两个字节中，每个字节包含8位。FP8仅使用一个字节。
可用的位数决定了在科学记数法中部署浮点数尾数和指数部分的精度。BF16包含1位符号位、8位指数位和7位尾数位。FP8的可用位数减半，包含1位符号位和7位有效位，其中7位有效位分别分配给指数部分和小数部分。因此，它的范围比BF16更小，精度也更低。它可以表示更窄的范围，以及该范围内的更少数量。
例如，假设我们想用十亿年为单位表示地球的年龄（约45.43亿年）。在BF16中，我们可以精确地将其表示为0100000010010001。
那么用FP8表示这个数如何？实际上，有两种FP8格式可供选择：E4M3 和 E5M2。此处的字母和数字代表位在指数（E）和尾数（M）之间的分配方式。用于表示指数的位数越多，可描述的数值范围就越大；用于表示尾数的位数越多，在该范围内可描述的数值就越多。
无论选择哪种FP8格式，实际上都无法精确表示4.543。若选择精度相对更高的E4M3，可获得最接近的值（4.5）。在E5M2中，你能达到的最近距离是5。
与这种精度和范围不足相对应的是，FP8能够实现更快的计算速度，且相较于BF16需要显著减少的内存。这对推理而言具有巨大价值，而采用正确的方法，它同样能极大提升训练速度。归根结底，问题在于大型语言模型（LLM）的训练究竟需要多大的范围和精度.你需要精确地表示地球的年龄吗？还是说接近4300万年已经足够接近了？如果你对整个宇宙感兴趣，那么第二级精度的数据应该就能满足你的需求。毕竟，舍入误差仅占宇宙年龄的约0.3%。
DeepL的发展历程证明，FP8能够满足高质量大型语言模型训练的需求，这为我们训练模型所能实现的功能以及实际部署方式开辟了新的可能性。
DeepL 大型语言模型的预训练
我们进行FP8训练和推理的旅程始于大型语言模型的预训练。预训练完成后，我们针对特定任务对模型进行微调，将大型模型蒸馏为小型模型，开展强化学习，并部署设置并行化策略，从而充分利用我们拥有的海量GPU资源。
应用FP8格式进行混合精度训练
我们利用NVIDIA Transformer Engine将现有训练代码从BF16转换为FP8。该工具是由NVIDIA提供的训练库，可加速变换器模型训练，并支持FP8格式。Transformer Engine 提供关键组件以支持混合精度训练，无缝管理 FP8 与 BF16 格式之间的转换，并处理缩放因子.
我们采用NVIDIA推荐的Transformer引擎默认配置，在训练阶段的前向传播中使用E4M3模型，而在反向传播中则采用E5M2模型。这实际上意味着：我们采用精度更高的格式来预测下一个令牌的概率分布，而在精度要求较低时，则使用精度较低但范围更广的格式来计算模型更新所需的梯度。我们根据两种格式的各自优势，为其最适合的任务分别选用。
在下图中，我们绘制了所有能够用E4M3格式表示的数字。如您所见，这些数值集中在零点附近，最大值不足500。事实上，FP8格式的可表示值数量可以用一张非常简短的表格来呈现。要使这种格式在训练中发挥作用，关键在于了解这些值的分布情况，并在其范围内进行操作.
这需要在FP8权重张量旁存储额外的缩放因子，以克服有限范围并防止溢出和下溢。在使用低精度张量进行计算时，还必须考虑缩放因子。例如，在对两个张量进行乘法运算时，你使用以下公式：(A_fp8 * A_scale) × (B_fp8 * B_scale)，其中 A_fp8 和 B_fp8 是 8 位张量，而缩放因子是 32 位标量。这些操作有专门的硬件支持。
FP8与BF16在训练性能上的对比
当我们谈论训练性能时，指的是在现有计算能力下模型能够多快完成训练。为比较FP8与BF16的训练性能，我们考察模型浮点运算利用率（MFU）。该指标反映模型每秒执行的浮点运算次数（FLOPS），以百分比形式呈现其相对于现有硬件技术可行FLOPS的占比。
在本次对比中，我们以BF16格式的浮点运算性能（FLOPS）作为统一基准进行比较，尽管从技术角度而言，采用FP8格式后可实现更高的浮点运算性能。这使我们能够评估从BF16转向FP8时，可用处理能力所能实现的增量提升。
如下图所示，采用FP8格式后，模型训练对可用计算能力的利用率从44.6%提升至67%，有效将模型训练速度提升了50%。
这本身就是一次令人印象深刻的性能提升。为实现这一目标，我们与英伟达合作优化了对Transformer Engine功能的使用。基于另一套训练方案，我们在15个月内逐步提升了训练性能25%，最终将MFU提升至80%。
FP8与BF16在大型语言模型训练质量上的对比
因此，FP8在训练性能方面的提升确实令人印象深刻。然而，作为DeepL，我们真正关注的输出是训练质量.与BF16精度相比，这种方法的训练质量如何？
为验证FP8提供的质量，我们测试了在两种格式下训练其中一个模型的情况。这使我们能够比较训练损失和下游质量。
我们利用三万亿个令牌训练了一个15亿参数的模型，随后对比了FP8训练与BF16训练的质量。此处的关键指标是训练损失，它指的是模型预测下一个词的能力.
如下方图表所示，我们发现BF16相较于FP8略具优势，这体现在FP8曲线始终略高于BF16曲线。然而，这种差异被两种格式在相邻训练步骤间更大幅度的训练损失波动所掩盖。在两种情况下，我们都观察到训练损失随时间推移呈现出相同的切实改善趋势。
FP8与BF16下游训练质量对比
随后，我们转向测试FP8与BF16训练在实际下游应用程序中呈现的质量表现。
在此情况下，我们测试了该模型在处理英语和德语时的表现。我们比较了验证困惑度，该指标量化了模型在预测序列中下一个词元时所经历的不确定性。再次强调，预期是困惑感会随着时间推移而降低。在此实际场景中，我们发现FP8训练与BF16相比并未出现质量下降。
从BF16转换到FP8的最终效果是：我们能够更快地训练模型，同时降低内存需求，并保持相同的训练质量——训练损失仅出现微小下降，验证困惑度也保持在可比水平。这实际上意味着DeepL能够通过最大限度地利用处理能力，构建更复杂的模型，从而处理更复杂的任务.这极大地拓展了我们利用大型语言模型训练所能实现的范围。
从FP8训练到推理
旅程的下一阶段涉及为大型语言模型（LLMs）进行生产推理的准备工作。在此，支持方面的重任由NVIDIA TensorRT-LLM承担，这是NVIDIA为可扩展大型语言模型推理提供的解决方案，并支持FP8浮点运算。它从训练中提取模型的权重，构建引擎以优化模型运算，使其尽可能高效。采用的优化技术包括：内核融合、优化C++/CUDA代码、键值缓存以及持续飞行中批处理。
FP8在推理中的优势
大型语言模型的推理过程始终涉及吞吐量（单位时间内可处理的令牌数量）与延迟之间的相互作用。毋庸置疑，提供最佳的客户体验的关键在于控制延迟。然而，吞吐量对DeepL同样至关重要，因为它决定了我们能在特定时间处理的请求数量，进而决定了模型在实际应用中的能力范围.
随着吞吐量的增加，延迟往往也会随之增加，这是不可避免的。批量处理多个请求可提升吞吐量，但代价是每个个人的延迟增加。这可能影响客户的体验。然而，FP8与BF16的推理性能显著变更了这种平衡状态，使我们占据优势.
如下图所示，对于大多数批处理规模，FP8能在与BF16相同的延迟水平下处理两倍的吞吐量。如果我们设置一个特定的延迟预算，该预算能为用户提供最佳体验，那么在实践中就能看到这种效果。实际上，FP8在术语吞吐量方面已将我们的大型语言模型的有效容量提升了一倍。
换言之，从BF16到FP8的演进不仅使我们能够为DeepL构建更强大、更复杂的大型语言模型。这也确保了我们能够有效应用这些大型语言模型，提供最佳的客户体验，并扩大我们语言人工智能在实际应用中的影响力。我们实现了更大规模模型的加速训练，这些模型在保持相同延迟参数的同时，能够处理两倍数量的请求.
接下来呢？我们最近部署了搭载NVIDIA DGX GB200系统的全新NVIDIA DGX SuperPOD，其计算能力实现了近乎指数级的飞跃。对我们而言真正有趣的是，这台机器将引入新一代张量核心，能够原生支持FP4张量运算，例如矩阵乘法。那时，我们的旅程才真正开始。在训练和推理过程中，看到单个字节能实现的功能，实在令人兴奋。敬请关注，见证半字节的无限可能。
关于作者
马库斯·施诺斯，高级研究高性能计算工程师
Markus Schnös 是 DeepL 的高级研究高性能计算工程师，专注于大规模语言模型（LLM）的训练与推理扩展.他对分布式训练和低精度浮点计算有着浓厚的兴趣。
www.linkedin.com/in/markus-schnoes-349300185
法比安·约斯维格，高级研究高性能计算工程师
法比安·约斯维格是DeepL的资深研究工程师，拥有机器学习、高性能计算和理论粒子物理学背景。他致力于为全球最精准的翻译器扩展人工智能模型与基础设施。