企业官网建设流程全解析

1. 从权重到激活：FP8 量化到底动了哪些地方

很多人第一次接触 FP8 量化，脑子里冒出来的第一个问题往往是：模型权重不是已经用 BF16 存了吗，为什么还要再压一遍？这个问题问得挺实在，因为如果你只是把模型拿来推理，不追求吞吐和显存占用，BF16 确实够用。但一旦你要在有限的显存里塞下更长的上下文、更大的 batch，或者想把单卡推理成本压下来，FP8 就变成一个绕不开的选项。

我先把结论摆在这里：FP8 量化不是简单地把 16 位砍成 8 位，它是一整套围绕数值表示、缩放因子、累加精度和算子融合的工程方案。你如果只盯着“8 位”这个数字，很容易在实测时发现精度掉得莫名其妙，或者速度根本没提升。

1.1 FP8 的两种格式：E4M3 和 E5M2 到底怎么选

FP8 在主流实现里有两个变体，一个是 E4M3，一个是 E5M2。名字里的 E 代表指数位，M 代表尾数位。E4M3 是 4 位指数、3 位尾数，E5M2 是 5 位指数、2 位尾数。

这两个格式的取舍逻辑其实很直白。E5M2 的指数位更多，能表示的动态范围更大，但尾数精度更低；E4M3 反过来，动态范围小一些，但精度更高。在实际推理场景里，权重和激活通常用 E4M3，因为神经网络里的数值大多集中在一个相对窄的范围内，精度比范围更重要。而梯度或者某些需要大动态范围的中间结果，才会考虑 E5M2。

我实测下来，如果你用的是主流推理框架，默认配置基本都会帮你选好 E4M3 做权重和激活的量化，你不需要手动去改。但如果你在做自定义算子或者手写量化逻辑，这个选择就必须自己拿捏。

注意：E4M3 能表示的最大值大约是 448，E5M2 能到 57344。如果你的激活值经常飙到几百以上，E4M3 可能会溢出，这时候要么换 E5M2，要么在量化前做数值裁剪。

1.2 缩放因子：per-tensor 还是 per-channel

缩放因子是 FP8 量化的核心。简单说，FP8 能表示的数值范围很有限，你需要把原始的高精度数值除以一个缩放因子，映射到 FP8 能表示的区间里，计算完再乘回来。

缩放因子的粒度有两种常见做法：per-tensor 和 per-channel。per-tensor 是整个张量共用一个缩放因子，实现简单，但精度损失大；per-channel 是每个通道单独算一个缩放因子，精度好很多，但实现复杂度和开销也上去了。

在 Llama 3 这种大模型里，权重通常用 per-channel 量化，激活用 per-tensor 或者 per-token 动态量化。为什么这么分？因为权重的分布相对稳定，离线算好每个通道的缩放因子就行；激活是动态变化的，每个 token 的分布都不一样，用 per-tensor 静态量化容易出问题，所以很多实现会做动态量化，也就是在推理时实时算缩放因子。

这里有个实操心得：如果你发现量化后模型在某些长文本上表现突然变差，大概率是激活的缩放因子没处理好。可以试着把激活的量化粒度调细一点，比如从 per-tensor 改成 per-token，精度会明显回升，代价是稍微多一点计算开销。

1.3 累加精度：为什么 FP8 计算要用 FP32 累加

这一点特别容易被忽略。FP8 的乘法可以在 FP8 精度下做，但累加必须用更高精度，通常是 FP32。原因很简单：矩阵乘法里要做大量的加和，如果累加也用 FP8，误差会迅速累积，结果完全不可用。

你可以把 FP8 乘法想象成用一把刻度很粗的尺子量长度，单次测量误差不大，但如果你要把几千次测量结果加起来，误差就会滚雪球。FP32 累加就是用一个精细的累加器来收拢这些误差。

主流硬件在支持 FP8 时，通常都会配套 FP32 累加。你在写自定义 kernel 的时候，一定要确认累加器的精度，别为了省一点寄存器把累加也降到 FP8，那样出来的结果基本没法看。

2. 长上下文实测：FP8 量化后到底能撑多长

长上下文是 Llama 3 的一个重点能力，官方支持到 8K，社区通过外推能拉到 32K 甚至更长。但长上下文和量化放在一起，事情就变得有意思了：量化会引入误差，长上下文会放大误差，两者叠加，模型可能在你没注意的地方悄悄崩掉。

2.1 实测环境与测试方法

我用的测试环境是一张显存 80G 的卡，模型是 Llama 3 8B 指令微调版本，推理框架选了支持 FP8 的主流方案。测试方法分三组：第一组是 BF16 原始模型，第二组是 FP8 量化模型，第三组是 FP8 量化加长上下文外推。

测试任务选了三个：一是长文档问答，给一篇一万字左右的技术文档，问细节问题；二是多轮对话，连续聊二十轮，看模型会不会忘记前面的内容；三是代码补全，给一段长代码，让模型补全中间缺失的部分。

每组测试都跑三次，取平均结果，避免偶然性。评测指标不只看准确率，还看生成内容的连贯性和重复率。因为量化模型有时候会出现重复输出或者逻辑断裂，这些在单纯看准确率时容易被忽略。

2.2 短上下文下 FP8 与 BF16 的差距

先看短上下文，也就是 4K 以内的场景。实测下来，FP8 和 BF16 的差距非常小，在长文档问答上准确率只差了不到一个百分点，多轮对话和代码补全基本持平。

这个结果其实符合预期。短上下文下，量化误差没有太多累积的机会，模型的表现主要由权重质量决定，而 FP8 权重量化在 8B 这个规模上已经做得相当成熟。

但有一个细节值得注意：FP8 模型在生成时的困惑度略高一点，也就是模型对下一个 token 的预测没那么“自信”。这个差异在短文本上几乎看不出来，但到了长文本就会显现。

2.3 长上下文下 FP8 的衰减曲线

把上下文拉到 16K 以上，情况就开始分化了。BF16 模型在 16K 时还能保持不错的问答准确率，到 32K 时开始明显下滑。FP8 模型在 16K 时下滑幅度比 BF16 大，到 32K 时差距进一步拉大。

我记录了一组粗略的数据，虽然不能当严谨的 benchmark，但趋势很清楚：

这个衰减曲线说明一个问题：量化误差在长上下文里会被放大。原因在于，长上下文意味着更多的 KV 缓存、更多的注意力计算，每一步的微小误差都会在后续步骤里被反复放大。

2.4 长上下文量化的三个关键调优点

如果你非要在长上下文场景用 FP8，有三个地方可以调。

第一个是 KV 缓存的量化策略。KV 缓存占显存的大头，量化它能省很多显存，但 KV 缓存的数值分布和权重不一样，直接用权重的量化参数会出问题。建议对 KV 缓存单独做动态量化，或者干脆保持 KV 缓存用 BF16，只量化权重和激活。

第二个是注意力计算的精度。有些实现为了省算力，把注意力里的 softmax 也降到 FP8，这在长上下文里是灾难。softmax 的输出对精度很敏感，建议至少保持 FP16 或 BF16。

第三个是位置编码的外推方式。长上下文外推本身就会引入误差，如果再用 FP8，误差会叠加。可以试着在外推时用更保守的缩放因子，或者对位置编码相关的计算保持高精度。

实操心得：我在 32K 上下文测试时发现，把 KV 缓存保持 BF16、只量化权重和激活，FP8 模型的准确率能从 68% 拉回到 74% 左右，虽然还是不如纯 BF16，但差距缩小了不少，而显存占用仍然比 BF16 低很多。

3. 量化实操：从模型加载到推理的完整流程

前面聊了原理和实测，这一部分讲具体怎么操作。我尽量把步骤拆细，让你能照着复现。

3.1 模型加载与量化配置

第一步是加载原始模型。不管你用什么框架，核心都是先把 BF16 或 FP16 的权重加载进来，然后再做量化转换。有些框架支持直接加载已经量化好的权重，但如果你想自己控制量化参数，最好从原始权重开始。

加载时要注意显存。8B 模型用 BF16 加载大概需要 16G 显存，量化过程还需要额外的临时空间，所以建议至少准备 24G 以上的显存。如果显存不够，可以分层量化，也就是加载一层量化一层，但这样速度会慢一些。

量化配置里最重要的几个参数是：量化格式（E4M3 还是 E5M2）、缩放因子粒度（per-tensor 还是 per-channel）、是否量化激活、KV 缓存是否量化。这些参数在不同框架里的名字可能不一样，但逻辑是相通的。

# 以主流推理框架的伪代码为例，展示量化配置的核心参数 quant_config = { "weight_format": "fp8_e4m3", # 权重量化格式 "activation_format": "fp8_e4m3", # 激活量化格式 "weight_granularity": "per_channel", # 权重缩放因子粒度 "activation_granularity": "per_token", # 激活缩放因子粒度 "kv_cache_dtype": "bf16", # KV 缓存保持 BF16 "accum_dtype": "fp32", # 累加精度 }

这段配置里，我把 KV 缓存设成了 BF16，这是基于前面长上下文实测的结论。如果你只跑短上下文，KV 缓存也可以量化成 FP8，能进一步省显存。

3.2 校准数据的准备与使用

量化不是拍脑袋定缩放因子，需要用校准数据来统计数值分布。校准数据的质量和数量直接影响量化效果。

校准数据应该从你的实际使用场景里采样。如果你主要做中文问答，就用中文问答数据做校准；如果做代码，就用代码数据。用错了校准数据，量化后的模型在你的场景里表现会差很多。

数量上，一般几百到几千条就够了。太少统计不准，太多浪费时间。我通常用 512 条，每条长度在 512 到 1024 token 之间，覆盖不同的输入长度和内容类型。

校准过程本身不需要标签，只需要输入文本，让模型前向传播，统计每一层的激活分布，然后算出缩放因子。这个过程大概几分钟到十几分钟，取决于数据量和硬件。

3.3 推理时的 batch 与序列长度设置

量化完成后，推理时的 batch size 和序列长度设置也会影响效果。batch size 太大会导致激活值的动态范围变大，量化误差增加；序列长度太长会放大累积误差。

我的建议是，先用小 batch 和短序列验证量化模型的基本表现，确认没问题后再逐步加大。如果发现加大后精度掉得厉害，就回退到小一点的配置，或者调整量化粒度。

还有一个细节：有些框架在推理时会做动态量化，也就是每个 batch 实时算缩放因子。这种方式精度好，但会引入额外的计算开销。如果你的场景对延迟敏感，可以考虑用静态量化，牺牲一点精度换速度。

4. 踩坑记录：FP8 量化最常见的五个问题

这一部分是我在实际操作中踩过的坑，以及后来找到的解决办法。有些问题在文档里不会写，但实际用起来一定会遇到。

4.1 量化后模型输出重复或乱码

这是最常见的问题，表现是模型生成的文本开始重复同一句话，或者输出一堆无意义的符号。原因通常是激活量化出了问题，缩放因子没算对，导致数值溢出或下溢。

解决办法：先检查激活的量化粒度，改成 per-token 动态量化试试。如果还不行，检查校准数据是否覆盖了你的实际输入分布。有时候校准数据太单一，导致缩放因子在实际输入上不适用。

4.2 显存没降多少，速度也没提升

很多人以为量化后显存和速度都会大幅改善，实际发现显存只降了一点，速度甚至更慢。这通常是因为量化只应用到了权重，激活和 KV 缓存还是高精度，而激活和 KV 缓存才是显存和计算的大头。

解决办法：确认量化配置里激活和 KV 缓存是否也量化了。如果量化了激活但速度没提升，可能是硬件对 FP8 的支持不完善，或者框架没有做算子融合，量化反而引入了额外的转换开销。

4.3 长上下文下模型突然“失忆”

前面实测部分提到过，长上下文下 FP8 模型的准确率会下降。但有一种更严重的情况是，模型在某个长度之后突然完全失忆，前面的内容一点都记不住。

这通常是 KV 缓存量化导致的。KV 缓存里的数值在长上下文下分布变化很大，静态量化参数不适用。解决办法是把 KV 缓存改回 BF16，或者用动态量化。

4.4 不同框架的量化结果不一致

同一个模型，用不同框架量化，结果可能差很多。这是因为不同框架的量化实现细节不一样，比如缩放因子的计算方式、累加精度的处理、算子融合的策略。

解决办法：不要跨框架比较量化结果，选定一个框架就深入用下去。如果必须换框架，重新做校准和验证，不要直接套用之前的配置。

4.5 量化模型在特定任务上崩溃

有些任务对数值精度特别敏感，比如数学计算、逻辑推理、代码生成。FP8 量化在这些任务上可能表现很差，甚至完全崩溃。

解决办法：如果这些任务是你的核心场景，建议对这些任务保持高精度，或者用混合精度方案，只对不敏感的部分做量化。也可以考虑用量化感知训练，在训练阶段就让模型适应量化误差，但这个方法成本比较高。

5. 量化之外的优化：还有哪些手段可以配合使用

FP8 量化不是孤立的优化手段，它和很多其他技术可以配合使用，效果会更好。

5.1 与 KV 缓存压缩的配合

KV 缓存压缩是长上下文场景的另一个重要优化。常见的方法有量化、稀疏化、低秩分解等。FP8 量化和 KV 缓存压缩可以叠加使用，但要注意两者的误差会累积。

我的建议是，如果已经用了 FP8 量化，KV 缓存压缩就用保守一点的策略，比如只做轻度量化或者稀疏化，不要同时上多种激进压缩。

5.2 与投机采样的配合

投机采样是用一个小模型来加速大模型推理的技术。FP8 量化后的大模型和投机采样配合，可以进一步提升吞吐。但要注意，小模型的精度也会影响最终结果，如果小模型也量化了，误差会叠加。

实测下来，大模型 FP8 量化加小模型 BF16，是一个比较稳的组合。小模型本身参数量小，保持高精度对显存影响不大，但能保证投机采样的接受率。

5.3 与批处理调度的配合

FP8 量化后，单次推理的显存占用降低，意味着你可以跑更大的 batch。但 batch 太大会导致激活值的动态范围变大，量化误差增加。所以需要找到一个平衡点。

我通常的做法是，先固定量化配置，然后逐步增加 batch size，观察精度变化。找到一个精度还能接受的最大 batch，然后在这个基础上做批处理调度。

6. 我个人的一些经验体会

FP8 量化这个方向，我从最早的好奇到现在的日常使用，中间踩了不少坑，也积累了一些文档里不会写的经验。

第一个体会是，量化不是越激进越好。很多人一上来就想把所有权重、激活、KV 缓存全量化成 FP8，结果模型直接崩了。正确的做法是逐步量化，先量化权重，验证没问题再量化激活，最后考虑 KV 缓存。每一步都做验证，确保精度在可接受范围内。

第二个体会是，校准数据的重要性被严重低估。我见过太多人随便拿几百条通用数据做校准，然后抱怨量化后模型在自己的场景里表现差。校准数据一定要贴近实际使用场景，这是量化效果的上限。

第三个体会是，长上下文和量化是一对矛盾。长上下文需要高精度来维持记忆，量化会破坏精度。如果你真的需要长上下文，要么接受精度损失，要么在关键部分保持高精度。没有两全其美的方案，只有权衡。

最后一个体会是，工具和框架的选择很重要。不同框架对 FP8 的支持程度差别很大，有些框架的 FP8 实现还很粗糙，用了反而添乱。选一个成熟的框架，深入用下去，比频繁换框架试来试去效率高得多。

如果你也在做类似的事情，我的建议是先从小规模验证开始，别一上来就全量量化。量化是一个需要反复调试的过程，耐心和细致比什么都重要。