延迟（Latency）

推理延迟（Inference Latency）是衡量大语言模型服务响应速度的核心指标，涵盖从请求到达到首 token 输出、再到完整响应生成的全链路时间。它不是单一数字，而是由 Prefill 与 Decode 两个计算特性截然不同的阶段共同决定——理解各阶段的瓶颈，才能有针对性地优化用户体验。

LLM 推理延迟并非单一数字，而是由多个分阶段指标共同描述。

• TTFT（Time To First Token）：从请求到达到输出第一个 token 的时间，反映用户感知的「响应快慢」，对话场景中尤为关键；包含调度等待时间与 Prefill 计算时间
• TPOT（Time Per Output Token）：解码阶段每生成一个 token 的平均耗时，等于总解码时间除以输出 token 数，决定输出的流畅感
• TBT（Time Between Tokens）：连续两个输出 token 之间的实际间隔，比 TPOT 更细粒度地反映流式输出的抖动情况
• 端到端延迟（E2E Latency）：TTFT 加上所有后续 token 生成时间的总和，是非流式场景下用户实际等待的时长
• P50/P99 延迟：统计分布视角，P99 延迟反映尾部用户体验，仅看均值容易掩盖长尾问题

LLM 推理在计算特性上分为两个截然不同的阶段，对应不同的硬件瓶颈。

• Prefill 阶段：并行处理输入提示的全部 token，生成 KV Cache 并输出第一个 token，是 TTFT 的主要决定因素
• Prefill 属于计算密集型（Compute-bound），可充分利用 GPU 的并行矩阵运算，输入序列越长耗时越高
• Decode 阶段：逐个自回归生成后续 token，每步仅产生一个新 token，对应 TPOT 与 TBT 指标
• Decode 属于内存带宽密集型（Memory-bound），瓶颈在于频繁读写 KV Cache 带来的显存带宽压力，而非算力
• 长 system prompt 或超长上下文会显著拉长 Prefill 时间，进而导致 TTFT 劣化；前缀缓存（Prefix Caching） 可复用固定前缀的 KV Cache 来缓解此问题

KV Cache 是 Decode 阶段的核心数据结构，其管理方式直接影响延迟与吞吐的平衡。

• 推理时，模型将历史 token 的 Key-Value 对缓存在显存中，避免每步重复计算，以空间换时间
• 随输出序列增长，KV Cache 体积线性膨胀，可占满数十 GB 显存，成为高并发请求的主要瓶颈
• PagedAttention（vLLM 提出）将 KV Cache 分割为固定大小的页，按需动态分配，可减少显存碎片与浪费约 90%
• KV Cache 命中率直接影响 TTFT：前缀缓存（Prefix Caching）对重复 system prompt 可实现毫秒级首 token 响应
• 显存不足时系统降级为 CPU 卸载（CPU Offloading），将大幅增加 Decode 延迟

业界通过多种技术手段在不同维度降低推理延迟。

• 投机解码（Speculative Decoding）：用小草稿模型并行生成多个候选 token，由大模型一次性并行验证；可将 Decode 延迟降低 2-3 倍，且不损失输出质量
• 连续批处理（Continuous Batching）：动态将不同请求的 Decode 步骤合并成批，提升 GPU 利用率，降低单请求的排队等待延迟
• 量化（Quantization）：将权重从 FP16 压缩至 INT8/INT4，减少显存占用与内存带宽需求，对 Decode 延迟改善尤为明显
• Flash Attention：通过分块计算和算子融合降低 Attention 的显存读写次数，主要改善 Prefill 阶段的计算效率
• Prefill-Decode 分离部署（PD Disaggregation）：将两阶段分配到不同机器或 GPU 实例，各自独立优化资源配置，彻底解耦计算与带宽瓶颈

在实际部署中，降低延迟与提升吞吐往往相互制约，需要根据业务场景做出取舍。

• 增大批处理大小（Batch Size）可提高吞吐，但因排队等待会拉高单请求的 TTFT
• 对话场景以低 TTFT、低 TBT 为优先目标，确保用户感受到即时响应
• 离线批量推理以高吞吐为优先目标，可容忍较高的端到端延迟
• SLA（服务水平协议）通常以 P95/P99 分位延迟为约束，而非平均值，以覆盖长尾请求
• 分块 Prefill（Chunked Prefill）（如 Sarathi-Serve 框架）将长 Prefill 切割为多个小块与 Decode 交错执行，可在同一批次中兼顾延迟与吞吐

准确测量延迟需要区分客户端视角与服务端视角，避免混淆指标含义。

• 客户端 TTFT 包含网络往返时间（RTT）和服务器内部调度队列等待时间，反映真实用户体验
• 服务端 TTFT 仅计算模型实际处理时间，不含网络传输，更能反映模型与推理系统本身的性能
• 测量时需在稳态负载下采集，冷启动或极低并发的结果往往无法代表生产环境
• 常用开源评测工具包括 vLLM benchmark、SGLang benchmark、Metron/Etalon（arXiv 2407.07000）等
• 评测指标应同时报告 TTFT、TPOT、P99 延迟和每秒请求数（RPS），单一指标难以全面反映系统性能

LLM 推理延迟优化经历了从粗放批处理到精细阶段分离的演进。

• 2023 年前：多数 LLM 部署采用静态批处理，延迟与吞吐量矛盾突出，优化手段有限
• 2023 年：vLLM 发布，引入 PagedAttention 与连续批处理，显著提升吞吐量，推动延迟优化进入系统化阶段
• 2023-2024 年：投机解码（Speculative Decoding） 被 Google、DeepMind 等机构系统化研究并落地，通过小模型起草、大模型并行验证的方式降低 Decode 阶段延迟
• 2024 年：Prefill-Decode 分离（PD Disaggregation） 架构兴起，将两阶段部署在不同计算节点，彻底解耦资源瓶颈，进一步降低 TTFT
• 持续演进：量化（AWQ、GPTQ 等）减少显存读取量缓解带宽瓶颈；前缀缓存成为云端 API 服务标配；Flash Attention 系列持续优化 Prefill 效率