prefill 与 decode 是什么
自回归推理分两个阶段：prefill 一次并行处理整段输入，属于算力密集；decode 逐 token 生成，每一步都要把权重与 KV 读一遍，属于显存带宽密集。prefill 的耗时决定首 token 何时出现（TTFT），decode 的步时决定后面出字有多快（TPOT）。两阶段资源特征不同，优化手段也不同，混在一起谈「推理慢」往往得不出可执行的结论。
基本信息
| prefill 处理方式 | 整段输入并行计算，可用大 batch 吃满算力 |
|---|---|
| decode 处理方式 | 逐 token 串行生成，受权重与 KV 读取速度制约 |
| 分界点 | 第一个输出 token 产生之前是 prefill，之后进入 decode |
| 对应指标 | prefill 影响 TTFT，decode 影响 TPOT 与生成速率 |
| 输入的算力开销 | 随输入长度增长，注意力部分是非线性增长 |
典型使用场景
- 长输入短输出（文档问答、摘要、分类）：首字延迟由 prefill 主导，优化重点在前缀缓存与输入长度
- 短输入长输出（写文章、代码补全）：总时长由 decode 主导，优化重点在量化与解码效率
- 容量规划：两类请求分开估算，避免把长短请求混成一个平均值
- 混部调度：长输入的 prefill 会占用算力，需要避免它长时间挡住其他请求的解码
- 压测设计：按输入长度与输出长度分档造数据，才能看出瓶颈落在哪一段
两阶段的观测入口
两阶段的观测入口
# 引擎侧指标：分别对应两阶段（指标名随版本微调，先看实际输出）
curl -s http://127.0.0.1:8000/metrics | grep -E 'time_to_first_token|time_per_output_token'
# 现场对照：同一模型分别跑「1K 输入 + 短输出」与「短输入 + 1K 输出」
# 前者看 TTFT，后者看总时长，两者结论不会互相印证
# 若 TTFT 高而 TPOT 正常：问题在输入侧（排队或 prefill），不要在解码上使劲两阶段对照
| 阶段 | 处理方式 | 资源瓶颈 | 对应指标 |
|---|---|---|---|
| prefill | 整段输入并行计算 | 算力（矩阵计算） | TTFT 首字延迟 |
| decode | 逐 token 串行生成 | 显存带宽（读权重与 KV） | TPOT 每 token 延迟 |
| 混批调度 | 两阶段交错执行 | 调度策略与显存 | 两者同时受影响 |
分块 prefill（chunked prefill）把长输入切成小块，与解码交错执行，减少长前缀请求对其他请求解码的阻塞；具体开关与默认值随推理框架版本演进，以版本文档为准。
压测时按阶段看指标：长输入场景只看总时长会误判成「模型慢」，实际可能只是 prefill 在排队前吃了算力。