Orca — Transformer 生成模型的分布式推理调度

是什么

Orca 是 2022 年 OSDI 提出的 大模型在线推理调度系统。它解决的核心问题是：用户请求长短不一、到达时间随机，传统「整批一起算」的 batching 让 GPU 大量空转。

日常类比：餐厅如果必须等一桌人全到齐才上菜，短桌客人干等、长桌客人饿着。Orca 像回转寿司——菜（计算任务）按迭代粒度不断加进传送带，谁到了谁先算，不等整桌。

两大技术：iteration-level scheduling（按生成步调度）和 selective batching（只把处于同一迭代阶段的请求编进一批）。

为什么重要

不懂 Orca，下面这些事说不清：

• 为什么 vllm 的 continuous batching 不是凭空出现——Orca 是思想源头之一
• 为什么 LLM serving 的吞吐不靠「更大的 batch」，而靠更细的调度粒度
• 为什么同一 GPU 上混跑 1-token 和 100-token 的请求会互相拖累
• 为什么 2022 年的系统论文比很多 2024 模型论文更影响工业部署

核心要点

1. Request-level batching 的浪费：生成模型要跑很多步，每步 token 数不同；按「整个请求」组 batch，GPU 在 padding 上空转。类比：大巴必须等满员才发车。

2. Iteration-level scheduling：调度器以单步 decode 为单位组 batch。这一步结束的请求退出，新到的插进来——即 continuous batching 的前身。

3. Selective batching：只合并当前迭代兼容的请求（同阶段、同算子路径），避免错误共享 KV cache 状态。

实践案例

案例 1：传统 vs Orca 时间线

# Request-level（3 个请求，生成长度 2/5/8）
t=0: [R1,R2,R3] prefill 一起算
t=1: [R1,R2,R3] decode   → R1 已完成仍占坑（浪费）
...

# Iteration-level（Orca）
t=1: [R2,R3,R4新到] decode  → R1 完成立刻腾出槽位给 R4

案例 2：调度伪代码

class OrcaScheduler:
    def schedule(self, waiting, running):
        # 按迭代阶段分组，不跨阶段硬 batch
        batch = [r for r in running if r.phase == "decode"]
        batch += pick_new(waiting, max_batch=len(batch))
        return run_one_iteration(batch)  # 只跑一步

案例 3：与 vLLM 对照

Orca (2022)     → iteration-level + selective batching
vLLM (2023)     → + PagedAttention KV 管理
工业 serving    → 两者组合成今天 LLM API 的默认架构

见 vllm、orca-continuous-batching。

Prefill 阶段（处理 prompt）算力密集、decode 阶段（逐 token）内存带宽密集；Orca 的 iteration-level 让两阶段请求可交错，但调度器必须识别阶段标签。vLLM 后续把这点与 PagedAttention 绑定得更紧。

SLO 视角：P99 延迟往往被最长请求拖累。Selective batching 允许短请求「插队」完成一步 decode，避免被长生成堵死——这是在线 API 体验的关键，而不只是平均吞吐。

复现 Orca 实验要看请求到达分布：泊松到达 + 几何长度分布是论文默认；若你的流量是批量离线，收益会小很多。

踩过的坑

1. 忽略 KV cache 生命周期：迭代调度必须和 cache 分配/回收绑定，否则 OOM。

2. 跨请求共享错误阶段：prefill 和 decode 硬塞一批，算子形状对不上。

3. 以为 batch 越大越好：大 batch + 长 padding 反而降吞吐。

4. 只抄论文不读 vllm 实现：PagedAttention 等后续优化同样关键。

适用 vs 不适用场景

适用：

• 在线 LLM API（ChatGPT 类）
• 请求长度和到达时间高度不规则
• 需要最大化 GPU 利用率

不适用：

• 离线大批量推理（静态 batch 就够）
• 极小模型（调度开销占比过高）
• 非自回归模型（调度假设不同）

进阶话题（可跳过）

这一节把前文和工业落地再绑紧一点，方便你读完就能动手选型或读论文。

1. 与 KV cache 协同：iteration scheduling 必须知道每请求已生成长度；vllm 的 PagedAttention 解决内存碎片，Orca 解决时间碎片。
2. 优先级队列：付费用户低延迟需单独队列，避免被免费长请求饿死。
3. 监控指标：GPU 活跃 SM%、batch 填充率、每步 decode 延迟分布——比平均吞吐更能定位问题。
4. 多模型混部：不同模型 KV 形状不同，selective batching 不能跨模型硬拼。

历史小故事（可跳过）

• 2020 前：CV 推理 batch 成熟，LLM 生成式 serving 空白。
• 2022 OSDI：Orca 提出 iteration-level 范式。
• 2023：vllm 加 PagedAttention，continuous batching 工业化。
• 今天：所有主流 inference engine 都继承这条路线。

学到什么

1. 生成式 serving 的瓶颈在调度，不只在算子
2. 迭代粒度是 continuous batching 的核心抽象
3. 系统论文有时比模型论文更长寿
4. 读 Orca + vLLM 才能拼出完整 serving 图景

延伸阅读

• 论文：OSDI 2022 Orca
• vllm —— PagedAttention + continuous batching 工业实现
• orca-continuous-batching —— 思想延续条目
• whisper-2022 —— 另一类大规模推理负载（ASR）

关联

• vllm —— Orca 思想的工程放大器

• orca-continuous-batching —— 同一技术脉络

• whisper-2022 —— 大规模弱监督模型，部署也需 batch 策略

• [[gemini-1.5-2024]] —— 长上下文 serving 对调度提出新挑战

• 入门路径：先读「是什么」+「核心要点」，跑通一个最小案例后再翻「进阶话题」。

• 复习抓手：把「为什么重要」四条用自己的话复述一遍，能讲给同事即算掌握。

• 与仓库其他笔记：用文内 wikilink 跳到已写条目，别孤立读单篇。

• OSDI 2022 视频 talk 有助于理解 iteration 时间线动画。

• 复现需模拟请求到达过程，静态 batch 对比无意义。

• 与 TensorRT-LLM、TGI 等引擎对照读可拼完整 serving 栈。

• KV cache 容量规划是调度器上游约束。

• 长 prompt 的 prefill 仍可 batch，decode 才需精细调度。

读者练习（可跳过）

用 10 分钟做一个小练习，巩固上文：

1. 用自己的话向朋友解释「这篇解决什么问题」。
2. 从「实践案例」挑一个命令或代码块在本地或纸上走一遍。
3. 列出两个你会踩的坑，并写下规避句。

反向链接

• fastertransformer-2021 —— FasterTransformer 2021 — NVIDIA 第一代开源 LLM 推理引擎
• orca-continuous-batching —— Orca — 让一批 LLM 请求随到随走，不再排队等最长那个
• vllm —— vLLM — 高吞吐 LLM 推理引擎
• whisper-2022 —— Whisper — 68 万小时弱监督训出的语音识别