什么是 解码阶段（Decode Phase）？
解码阶段（Decode Phase）是 Prefill 之后的自回归 LLM 推理阶段，系统不断接受输出 Token、扩展序列与可复用模型状态，直到满足停止条件。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
测量边界
客户端 Decode Duration 从首个非空流式输出到最后一个非空输出。[AIPerf 指标参考](https://docs.nvidia.com/aiperf/reference/ai-perf-metrics-reference)与 [vLLM 指标设计](https://docs.vllm.ai/en/stable/design/metrics/)给出事件边界。请求级 TPOT 用该区间除以 output_tokens - 1，因为首 Token 结束 TTFT，只有后续间隔位于 Decode Duration 内。ITL 逐个测量输出间隔。Chunk 合并、Reasoning Event、重试与抢占都会使结果不同。
调度与状态
Continuous Batching 会组合多个活跃序列的 Decode 位置，并在调度边界接纳新请求。它可能提高聚合利用率，同时降低单用户 Token 速率或增大 Jitter。Preemption 可能驱逐或重算状态，[DistServe](https://arxiv.org/abs/2401.09670) 也说明分离式设计必须计入 KV Transfer 与 Placement。比较时应同时记录 Queue、Cache Pressure、Preemption、Batch Occupancy 和 Cancellation，不能把所有延迟都归因于模型 Kernel。
优化与质量
量化、优化 Attention、KV Cache 布局、推测解码与并行策略都可能改变 Decode 成本，但只有输出语义仍满足要求时，速度提升才有效。固定模型、Tokenizer、Runtime、精度、采样策略和停止条件；使用相同输入输出分布；同时报告 p50/p95/p99 TPOT 或 ITL、单用户输出 TPS、聚合吞吐、错误与质量。更快但发生截断、重复、Schema 违规或 Tool Call 错误的流式输出，不是成功优化。
主要特点
- 从已接受前缀持续扩展请求，直到得到终止结果
- 复用并追加 KV Cache 或架构专属循环状态
- 单请求存在顺序依赖，但不同请求之间可以批处理
- 一次模型步骤或流式 Chunk 可能包含多个 Token
- 常用 Decode Duration、ITL、TPOT 与限定口径的输出 TPS 测量
- 必须结合质量、停止行为、失败与 Cache Pressure 评估
常见用途
- 排查首个输出到达后流式文本过慢或节奏不稳
- 在相同 SLO 下比较连续批处理与推测解码
- 为长输出和并发序列规划 KV Cache 容量
- 区分首个输出响应性与持续生成速度
- 发现 Runtime 优化引入的质量或终止行为回退
示例
Loading code...常见问题
Decode 阶段每一步一定只生成一个 Token 吗？
传统自回归解码在每个位置上存在顺序依赖，但推测解码和多 Token 方法可以让一次目标模型步骤接受多个 Token。流式传输也可能把多个 Token 合成一个 Chunk，因此步骤、Chunk 与 Token 是不同单位。
Decode Duration 与端到端延迟相同吗？
不同。客户端 Decode Duration 从第一个非空输出开始，到最后一个输出结束；端到端延迟还包含请求传输、排队、预处理、Prefill 和首 Token 生成。
TPOT 与 ITL 有什么区别？
TPOT 是请求级平均值，通常为 `(端到端延迟 - TTFT) / (输出 Token 数 - 1)`；ITL 逐个记录输出事件之间的间隔。Chunk 含多个 Token、节奏不均或聚合权重不同时，两者会不同。
为什么更高的聚合吞吐可能降低单用户 Decode 速度？
调度器可以把更多活跃序列组成 Batch，以摊薄模型权重读取并提高总输出 TPS；但每个序列获得服务的频率可能降低，因此单用户 TPOT 或 Token Delivery Jitter 可能变差。
如何验收 Decode 优化？
在相同模型、Tokenizer、请求分布、输出长度策略和质量测试下回放，对比尾部 TPOT 或 ITL、单用户输出 TPS、聚合吞吐、错误、抢占、显存与合格任务质量，而不是只看峰值 Token 速率。