大模型预填充与解码的量化策略评测：为什么要分阶段设计

一、评测概述：一个模型，两种脾气

在评估大模型推理性能时，很多团队会习惯性地把“推理”当成一个整体指标来看待：吞吐多少、延迟多少、显存占用多少。但真正做过线上服务的人都会发现，同一个模型在不同请求形态下表现出的瓶颈截然不同。这种差异的根源，就在于大模型推理其实包含两个性质完全不同的阶段——预填充（Prefill）和解码（Decode）。

本文要评测的对象，不是某一个具体产品，而是一类技术思路：针对预填充与解码阶段采用不同量化策略的方案是否值得、如何评估、在什么条件下收益明显。这类思路常被称为“解耦量化”或“分阶段量化”。

适合阅读本文的读者包括：负责大模型推理服务部署的开发者、设计推理架构的架构师、关注推理成本与延迟的运维人员，以及需要为业务选择量化方案的技术负责人。本文不给出“某方案一定更好”的结论，而是提供一套可复用的评测框架，帮助读者在自己的业务场景下做出判断。

二、评测目标：要回答哪些问题

在动手评测之前，先要明确评测要回答的核心问题，否则很容易陷入“指标一大堆、结论说不清”的困境。建议围绕以下问题展开：

1. 预填充阶段与解码阶段的资源瓶颈是否真的不同？差异有多大？
2. 对两个阶段使用相同的量化位宽，是否会带来某一侧的浪费或损失？
3. 分阶段量化能否在保持输出质量的前提下，改善延迟、吞吐或显存占用？
4. 这种收益在什么规模、什么并发、什么输入长度下才显著？
5. 引入分阶段量化后，工程复杂度、维护成本和兼容性风险是否可控？

只有先锁定问题，后面的评测维度和方法才有意义。

三、评测对象说明：预填充与解码的本质差异

大模型的每一层核心运算都可以抽象为矩阵乘法：输入激活与权重相乘。这个过程包含两步——先把权重从显存搬运到计算单元，再执行乘法运算。

预填充阶段要一次性处理整段提示词，可能上千甚至上万 token。权重只需搬运一次，却要参与大量计算，因此是计算密集型，瓶颈在算力。

解码阶段每次只生成一个 token，输入数据量极小（批大小通常为一），但每一步都要完整搬运一遍权重。计算量很小，搬运量却没减少，因此是内存密集型，瓶颈在显存带宽。

用一个类比：预填充像一次性借回一摞书，搬运成本被大量阅读摊薄；解码像每次只借一本却要来回跑图书馆，真正花时间的是“跑路”而非“读书”。

“解耦量化”的核心主张正是：既然两个阶段的瓶颈不同，量化策略也不应该一刀切。例如可以在计算密集的预填充阶段采用更激进的量化以提升算力利用率，在带宽受限的解码阶段采用对精度更友好的量化以控制质量损失，或反之，具体取决于目标。

四、评测维度设计

评测分阶段量化方案，建议从以下维度建立框架：

维度	关注点	验证方式
精度保持	量化后输出质量下降幅度	对比量化前后在固定样本上的输出一致性
延迟表现	首 token 延迟、单 token 延迟	分阶段计时，区分预填充与解码
吞吐能力	不同并发下的 token 吞吐	逐步加压，观察拐点
显存占用	权重与激活占用	记录峰值与稳态占用
稳定性	长时运行、异常输入	持续压测与边界输入测试
兼容性	与现有推理框架、算子适配	接入改造工作量评估
运维复杂度	配置管理、版本升级	人工操作成本记录
成本结构	资源与人力成本	定性评估，不编造数值

每个维度都要明确“为什么重要”。例如精度保持直接决定业务可用性；延迟表现决定用户体验；显存占用决定单卡能承载的并发规模。

五、评测环境与前提

评测前必须固定条件，否则结果不可比：

• 硬件配置：明确 GPU 型号类别、显存容量、互联方式；
• 模型规模：固定参数量与层数，避免跨规模对比；
• 输入分布：准备短提示、长提示、混合提示三类样本；
• 批大小：分别测试批大小为 1 与较大批量的情况；
• 量化方案：设定基线（统一量化）与对照组（分阶段量化）；
• 调用方式：固定推理框架版本与调度策略。

所有条件尽量保持一致，做到控制变量。

六、评测方法

建议按以下流程执行：

1. 建立基线：先测未量化或统一量化方案，记录各维度数据；
2. 分阶段计时：将预填充与解码的耗时分开统计，避免混在一起；
3. 精度验证：在固定 prompt 集合上比较输出，观察语义一致性；
4. 压力测试：逐步提升并发，记录吞吐与延迟曲线；
5. 异常测试：输入超长提示、空提示、异常字符，观察容错；
6. 长时观察：持续运行数小时，记录显存与性能漂移；
7. 日志分析：收集错误率、重试次数、资源告警。

示意性伪代码（通用描述，不含具体工具）：

for stage in [prefill, decode]:
    record(start_time)
    run_inference(stage)
    record(end_time, peak_memory, output_tokens)
compare(baseline_metrics, disaggregated_metrics)

七、结果解读

解读结果时要避免绝对化。可以这样判断：

• 若解码阶段单 token 延迟明显下降而精度损失可控，说明分阶段量化在带宽瓶颈侧有收益；
• 若预填充阶段吞吐提升但首 token 延迟上升，需要结合业务对首响的敏感度判断；
• 若显存占用下降但稳定性测试出现波动，说明量化带来的数值不稳定需要进一步排查；
• 若收益只在超长输入或高并发下出现，说明该方案更适合特定负载。

性能差异往往来自资源配置、缓存策略、数据规模或并发模型，不能简单归因于量化本身。

八、适用场景与风险

适用场景：长提示、高并发、显存紧张、对解码延迟敏感的在线服务。

风险与限制：样本偏差、环境差异、量化精度在不同模型上表现不一、长期运行的不确定性、工程改造成本。

九、选型与使用建议

• 先明确业务瓶颈在预填充还是解码；
• 小规模验证精度，再放大压测；
• 关注运维复杂度是否可接受；
• 保留回退方案，避免一次性全量切换。

十、总结

预填充与解码的资源特征确实不同，分阶段量化在理论上具备合理性。但是否采用，需要结合精度、延迟、吞吐、稳定性和成本综合评估。本文提供的评测框架可帮助团队在自己的场景下做出有依据的判断，而非盲目跟风。