S22：Serving 请求生命周期与核心指标

内容类型：预习教材（不代表已完成）
日期：2026-12-14
阶段：P2 · AI Systems Engineering 90
总路线：Day 112 / 360
周次 / 节奏：W4 · 周一概念与阅读
状态：教材已备；学习未完成
主题：arrival、queue、prefill、decode、TTFT、ITL

一句话定义

LLM serving 把持续到达、长度不同的请求经过准入、排队、prefill、逐 token decode 与输出传输转化为响应，其用户体验由各阶段时延与共享资源调度共同决定。

学习目标

1. 能画出 arrival → admission → queue → prefill → decode → response 流程。
2. 能区分 TTFT、inter-token latency、end-to-end latency、throughput 和 tail latency。
3. 能解释 prefill 与 decode 的计算/内存访问特征为何不同。
4. 能识别 KV cache、batch scheduler 与请求长度怎样互相影响。

核心知识

请求到达后可能先鉴权、限额与估计资源，再进入队列。Scheduler 选择哪些请求进入 prefill 或 decode。Prefill 一次处理输入 token，生成首个输出并建立 KV cache，通常计算密集且随 prompt 长度增加。Decode 每轮为活跃序列生成下一个 token，反复读取权重与 KV 状态，常更受内存带宽和 batch 组织影响。

TTFT 是从请求到达到首 token 可见的时间，包含前置处理、排队和 prefill；ITL/TPOT 描述后续 token 间隔；端到端延迟还取决于输出长度。吞吐可用 tokens/s 或 requests/s，但二者都需要说明输入/输出长度分布。P50 反映典型请求，P95/P99 揭示排队、长请求和共享资源造成的尾部体验。

KV cache 让 decode 不必重算全部历史，但其容量随层数、KV heads、head dimension、序列长度和并发增长。Cache 不足会限制 active sequences、触发 eviction 或拒绝新请求。Continuous batching 在每个调度迭代加入/移除请求，提高利用率，却带来公平性与调度复杂度。

机制与推导

单请求端到端延迟可拆：

[ L=T_{front}+W_q+T_{prefill}+\sum_{i=1}^{n_{out}}T_{decode,i}+T_{network} ]

TTFT 约覆盖到首 token；平均 ITL 约为后续 token 时间除以 n_out-1。若只比较 E2E 而输出长度不同，会混淆模型行为与系统速度。

KV cache 粗估：

[ M_{KV}\approx 2\times L\times B\times S\times H_{kv}\times D_h\times bytes ]

2 对应 key/value。Paged 管理可减少连续预留和碎片浪费，但不会消除 token 状态本身。队列等待受到达率 λ 与服务能力 μ 影响；当长期 λ≥μ，队列无界增长，单纯优化平均 kernel 不能解决容量不足。

最小练习或观察步骤

1. 画一个短 prompt/短输出和长 prompt/长输出请求，标出各阶段。
2. 为每类请求写 TTFT、ITL 与 E2E 各回答什么体验问题。
3. 用假想数值计算 queue 20ms、prefill 80ms、10 个 decode×30ms 的近似延迟。
4. 列出长上下文会增加的计算、cache 和排队影响。
5. 在图上标出 admission、backpressure 和 load shedding 可发生的位置。

常见误区与边界

• 把模型 forward benchmark 当端到端 serving 延迟。
• TTFT 低就认为生成体验一定流畅，忽略 ITL 抖动。
• 用 requests/s 比较不同长度分布的工作负载。
• 认为 KV cache 只影响单请求速度，不影响并发容量。
• 把 vLLM/CUDA 性能结论直接套到 Apple Silicon 本地环境。

系统场景连接

客服摘要更看重整体完成时间，交互式助手更敏感 TTFT 与 ITL，批量合规分类则可能优先吞吐和成本。平台不能只给一个“延迟”指标。请求还携带租户、优先级、数据权限和工具调用状态，这些将在 queue/admission 与后续 Agent runtime 中继续影响系统。

自检问题

1. Prefill 和 decode 的主要资源特征有何不同？
2. TTFT 包含哪些阶段，不能说明什么？
3. KV cache 容量怎样限制并发？
4. 当持续到达率超过服务率时，为什么队列优化不足以解决问题？

专业课程对齐

• 阅读 vLLM 官方文档 中 serving、PagedAttention 与 scheduler 相关概览，把 request、sequence、KV block 和 scheduling iteration 映射到本日流程图。
• 阅读 CMU Deep Learning Systems 的 inference/execution 与性能内容，理解模型算子时间只是端到端请求生命周期的一部分。
• 阅读 Stanford CS329S 的 deployment、monitoring 与 system design 主题，把模型服务指标连接到具体用户体验和业务 SLO。

深入学习提示

精读时画两条并行时间线：请求视角与 worker/scheduler 视角。请求看到等待、首 token 和逐 token；worker 看到 batch 形成、prefill/decode 迭代和 cache 分配。遇到吞吐数字先补齐硬件、模型、长度分布、并发和 latency target。能把数字放回工作负载条件，才是 serving 系统理解。

学后填写区

• 我的请求生命周期图：
• 三类时延的定义：
• 一个 KV 容量估算：
• 长上下文的传播影响：
• 尚未理解的 scheduler 问题：