推理侧 — 调度优化
核心要点：
- prefill 算力密、decode 访存密，调度需分阶段
- Continuous batching：动态合批，吞吐数倍
- Chunked prefill：长 prefill 切块平滑尖峰
- Speculative decoding：小模型猜、大模型验
- 调度决定"跑得快"，KV 管理决定"放得下"
本文回答"长上下文推理时如何把硬件用好"的调度算法问题。本文涉及的框架内单实例调度，区别于 interconnect / 推理服务化通信 的跨实例 PD 分离调度。
长上下文加剧的调度矛盾
prefill 与 decode 需要不同硬件资源，长上下文把这一错配放大（依据见 02-第一性挑战）：
| 阶段 | 算力 / 访存特征 | 长上下文下放大 |
|---|---|---|
| Prefill | 算力密集，FLOP/Byte 高 | 1M prefill 单次 GPU 占用数十秒 |
| Decode | 访存密集，FLOP/Byte 低 | 单 token 延迟由 KV 大小 / HBM 带宽决定 |
@tbl-longctx-sched-prefill-decode-asymm prefill 与 decode 的算力错配
调度的核心矛盾：两阶段需要不同的硬件资源——prefill 想要算力、decode 想要带宽。如果混合放在同一批，要么算力浪费、要么带宽浪费、要么 SLO 崩盘。
Continuous Batching — 动态合批
核心问题：静态批被最长请求拖累，GPU 大量时间空跑，如何合批？
静态批的问题
传统 GPU serving 用静态批（static batching）：
Step 0: 收集 N 个请求，组成 batch 一起送 GPU
Step 1-K: 同步生成，直到最长那个完成
Step K+1: 整批返回，再收集下一批
问题：最长请求拖累整批。若 batch 内请求长度差 10 倍，GPU 90% 时间空跑（在等长的那个完成）。
Orca / 连续批
Orca / Yu et al., 2022 (OSDI)[1] 提出 iteration-level scheduling：
每个 token 生成 step 都检查：
- 完成的请求踢出 batch
- 新到的请求插入 batch
效果：GPU 利用率从 50% 提到 90%+，吞吐 2-7 倍。
关键设计：
- batch 大小 / 内部请求集合每步可变
- KV 管理需要支持"中途加入 / 退出"（→ 07-推理-KV 管理 / PagedAttention）
- selective batching：attention 层因 KV 形状不一致需逐请求算，其他层（MLP / LN）可批
业界采用
vLLM、SGLang、TensorRT-LLM、TGI 默认 continuous batching。这是当前 LLM serving 的事实基础。
Chunked Prefill — 把长 prefill 切块
核心问题：长 prefill 占满算力数十秒，如何避免冻结同批 decode？
长 prefill 的尖峰问题
在 continuous batching 框架下，长 prefill 是一根尖刺：
| 请求 | 算力需求 | 持续时间 |
|---|---|---|
| 1M token prefill | 满载算力 | 数十秒 |
| 短 decode | 低算力高带宽 | 每 step 几毫秒 |
@tbl-longctx-sched-spike-problem 长 prefill 与短 decode 在算力需求上的不对称
把两者同时放在一批：
- 要么先做 prefill：所有 decode 请求被冻结数十秒 → TPOT SLO 崩盘
- 要么 prefill 等 decode：长 prefill TTFT 进一步恶化
两者都不可接受。
SARATHI / Chunked Prefill
SARATHI / Agrawal et al., 2023[2] 与后续的 Sarathi-Serve (OSDI'24)[3] 提出：
把 prefill 切成 $K$ 个小块（chunk），每块与 decode 一起送 GPU。
1M token prefill → 切 8 个 chunk，每 chunk 128K
Step t: prefill_chunk_t + N 个 decode
Step t+1: prefill_chunk_{t+1} + N 个 decode
...
关键收益：
- TPOT 不再被冻结：每 step 都有 decode 推进
- GPU 利用率高：prefill chunk（算力密）+ decode（带宽密）算力 / 带宽都吃满
- TTFT 仅小幅变长：从纯 prefill 的 $T$ 变到约 $1.1 T$
Chunk size 是调度参数：太大无法与 decode 共存（仍冻结），太小算力不饱和。SARATHI 报告甜点在数千 token / chunk。
业界采用：vLLM ≥ 0.4 默认开启 chunked prefill，DeepSpeed-FastGen 也采用类似思路。长上下文部署几乎必开 chunked prefill。
vLLM V1 默认参数与 chunk size 调优
vLLM V1（2025 年起为默认架构）把 chunked prefill 设为默认开启[4]。long_prefill_token_threshold 默认约为 context window 的 4%，即 128K 模型约 5120 token；官方推荐在线场景设 8192、离线批处理设 16384，以平衡 TTFT 与吞吐。
Chunk size 要按场景调。社区实测（H200，SGLang v0.4.2.post4 / vLLM 0.7.2，30K input + 500 output，64 并发）[5]：
| 引擎 / 配置 | TTFT | 吞吐（tok/s） |
|---|---|---|
| SGLang，chunk 32K | 4.3 s | 25,428 |
| vLLM，默认配置 | 4.1 s | 23,770 |
| SGLang，默认 chunk 8K | 8.4 s | — |
@tbl-longctx-sched-chunk-bench vLLM vs SGLang 128K 场景吞吐对比（社区实测，H200）
SGLang 默认 8K chunk 在 30K 长上下文下 TTFT 劣化到 8.4 s，原因是 chunk 过小导致 prefill 轮次过多；扩大到 32K 后 TTFT 与 vLLM 默认接近，吞吐高出约 7%。这是社区 GitHub issue 实测数据，非学术论文结论。
SGLang Pipeline Parallelism 对超长 TTFT 的改善
SGLang v0.5.7+ 引入 Pipeline Parallelism（PP）[6]，把 prefill 跨 pipeline stage 流水，据报道 DeepSeek-V3.1 128K TTFT 从 48.5 s 降至 15.5 s（−67.9%）；Qwen3-235B PP8 配置下 128K TTFT 约 10.54 s。该机制在极长上下文（>64K）下补偿了 chunk 本身无法解决的 KV 计算总量问题。
Speculative Decoding — 用小模型猜、大模型验
核心问题：decode 单步只产一个 token，访存受限，如何一步产出多个？
算法机制
Leviathan et al., 2023[7] 和 Chen et al., 2023[8] 同时提出：
1. Drafter（小模型）一次生成 K 个候选 token：t_1, t_2, ..., t_K
2. Target（大模型）一次性 forward K+1 个位置，得到这 K+1 个分布
3. 比较：依次接受每个 t_i 如果 target 也喜欢；第一个被拒就停
4. 输出：接受的 token + target 在拒绝点的采样
收益：理论 $K \times$ 加速 decode；实际加速 $2 \text{-} 4 \times$（依赖 drafter 命中率）。
长上下文下的局限与修正
长上下文下 speculative decoding 有几个新观察：
| 维度 | 影响 |
|---|---|
| Drafter KV 同步 | Drafter 也要维护 KV，长上下文下 drafter KV 显存压力可观 |
| Target forward 成本 | Target 单步 forward 已经主要是 KV 读取（$O(n)$），多算 $K$ 个 token 增量极小 |
| Draft context 上限 | EAGLE 系列 draft context 有 2048 token 上限，超出后历史信息被截断 |
| Acceptance length | 128K 长上下文下 acceptance length 跌至约 1.28，近乎失效[9] |
@tbl-longctx-sched-spec-long 长上下文场景 speculative decoding 的特殊性
修正旧论断：长上下文不是 speculative decoding 的理想场景，而是其主要难点。Draft context 的 2048 token 上限使 drafter 丢失大量历史，导致 acceptance length 在 128K 输入下接近 1（即几乎每个 draft token 都被拒绝）。短上下文低并发下 EAGLE-3 可达 2–6× 加速（70B 级最高约 6.5× @温度 0），但该收益随上下文增长快速衰减[9]。
EAGLE 3.1 的修复：2026-05 据报道 EAGLE 3.1 修复了长上下文下的 attention drift 问题，acceptance length 最高提升 2×[10]。该工作尚属新进展，在 128K 场景的实际增益有待进一步验证。
代表实现
| 方法 | 特征 |
|---|---|
| Medusa[11] | 多 head 并行预测，无独立 drafter |
| EAGLE / EAGLE-2[12] | 用 target 自己的低层做 drafter，命中率高；draft context 上限 2048 token |
| EAGLE-3[9] | 短上下文 2–6× 加速，长上下文受 draft context 限制劣化 |
| EAGLE 3.1[10] | 据报道修复 attention drift，长上下文 acceptance length 提升最高 2×（新进展） |
| Self-Speculative | 同模型不同层 drafter / verifier，省 drafter 部署 |
| Recursive Speculative | 多层 speculative（drafter 自己也 speculative） |
@tbl-longctx-sched-spec-impl Speculative decoding 的代表实现
三者的组合
当前主流推理引擎（vLLM、SGLang、TensorRT-LLM）的调度技术栈见 ，四者层层叠加：
Continuous batching（基础）
└─ PagedAttention（→ 07-推理-KV 管理）
└─ Chunked prefill（长 prefill 解药）
└─ Speculative decoding（decode 进一步加速）
@tbl-longctx-sched-stack 推理引擎的调度技术栈
与 PD 分离的关系
| 视角 | 框架内调度 | 框架间 PD 分离 |
|---|---|---|
| 作用范围 | 单引擎实例 | 多实例间 |
| 解决问题 | prefill / decode 共存于一卡 | prefill / decode 分集群部署 |
| 通信代价 | 0 | KV 跨节点传输 |
| 适用 | 通用部署 | 极致 SLO + 跨集群资源池 |
@tbl-longctx-sched-vs-pd 框架内调度 vs PD 分离
两者互补不互斥：单实例内用 continuous batching + chunked prefill 把 GPU 用好；多实例间用 PD 分离把 prefill / decode 资源池分开。
PD 分离详见 interconnect / PD 分离原理、Mooncake、NVIDIA Dynamo。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 调度矛盾 | prefill 算力密、decode 访存密，同批混放必有一方浪费 |
| Continuous batching | iteration-level 合批是 serving 基础，吞吐 2-7 倍 |
| Chunked prefill | 长 prefill 切块与 decode 共存，保 TPOT SLO，TTFT 仅小幅变长 |
| Chunked prefill 调优 | vLLM V1 默认 ~4% context window；在线推荐 8192、离线 16384；chunk 过小 TTFT 劣化（社区实测） |
| SGLang Pipeline Parallelism | PP 把 128K TTFT 从 48.5 s 降至 15.5 s，补偿极长上下文 KV 计算总量瓶颈（据报道） |
| Speculative decoding 局限 | 短上下文低并发 2–6× 加速；128K 下 acceptance length 跌至约 1.28，draft context 2048 token 上限是根本制约 |
| EAGLE 3.1 修复方向 | 据报道修复 attention drift，长上下文 acceptance length 提升最高 2×（新进展，待验证） |
| 组合落点 | 吞吐 SLO 用 continuous batching + chunked prefill 打底，TPOT SLO 再叠 speculative decoding（需注意长上下文限制） |
@tbl-longctx-sched-takeaway 全文要点
参考资料
- Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI 2022. https://www.usenix.org/system/files/osdi22-yu.pdf
- Agrawal et al., SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills, 2023. https://arxiv.org/abs/2308.16369
- Agrawal et al., Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, OSDI 2024. https://www.usenix.org/conference/osdi24/presentation/agrawal
- vLLM Optimization Docs. https://docs.vllm.ai/en/latest/configuration/optimization/
- SGLang issue #3471（社区实测，H200，SGLang v0.4.2.post4 / vLLM 0.7.2，30K input + 500 output，64 并发）. https://github.com/sgl-project/sglang/issues/3471
- LMSYS Blog, 2026-01. https://www.lmsys.org/blog/2026-01-15-chunked-pipeline/
- Leviathan et al., Fast Inference from Transformers via Speculative Decoding, 2023. https://arxiv.org/abs/2211.17192
- Chen et al., Accelerating Large Language Model Decoding with Speculative Sampling, 2023. https://arxiv.org/abs/2302.01318
- Red Hat Developer, 2025-07. https://developers.redhat.com/articles/2025/07/01/fly-eagle3-fly-faster-inference-vllm-speculative-decoding
- MarkTechPost, 2026-05（新闻）. https://www.marktechpost.com/2026/05/27/eagle-3-1-long-context-speculative-decoding/
- Cai et al., Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads, 2024. https://arxiv.org/abs/2401.10774
- Li et al., EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty, 2024. https://arxiv.org/abs/2401.15077