JITServe: SLO-aware LLM Serving with Imprecise Request Information #

Wei Zhang, Zhiyu Wu, Yi Mu, Rui Ning, Banruo Liu, Nikhil Sarda, Myungjin Lee, Fan Lai (UIUC / Google / Cisco Research) | 2025-04 | https://arxiv.org/abs/2504.20068 Category: framework | Tags: slo-aware, llm-serving, scheduling, goodput, agent-serving, length-prediction Read: 2026-04-18

Core Contribution #

首个面向多类型 SLO 的 LLM 服务调度系统——用"保守估计 + 在线精化"的方式处理未知的响应长度与依赖图，然后用 Grouped Margin Goodput Maximization (GMAX) 算法把"刚好够用的带宽"just-in-time 分配给每个请求，使 service goodput 相比 SOTA 提升 1.4× –6.3×，并给出常数竞争比（≈1/8.55）的可证明保证。

Summary #

Motivation (为什么现在做)：LLM 服务的请求类型正在从单一 chat 快速扩散到 三类 SLO 差异巨大的工作负载——latency-sensitive (TTFT/TBT)、deadline-sensitive (E2EL 截止时间)、compound (多阶段依赖，例如 multi-agent / deep research / test-time scaling)。现有调度器要么只看聚合吞吐 (vLLM FCFS, Sarathi-Serve)，要么只看 mean E2EL (Autellix LAS, LTR SJF)，作者在 Appendix D.1 中证明 SJF / EDF 对 goodput 的竞争比可以任意差。与此同时，精确预测响应长度和依赖图几乎不可能 (BERT/Llama3-based 预测器误差巨大)。

Method：JITServe 提出 JIT (Just-in-Time) 调度原则——允许信息不精确但可在生成过程中连续精化。系统由两部分组成：(1) Request Analyzer 用 Quantile Regression Forest (QRF) 预测响应长度的高分位上界 (7ms 推理，比 BERT 快 7×)，每 50 个 token 重新调用以逐步收紧上界；对 compound 请求用 pattern graph + Gaussian-kernel 图相似匹配找历史相似执行图，按累积贡献比 $\phi(s)=t_{\leq s}/t_{\text{total}}$ 给每一阶段分配 sub-deadline。(2) GMAX scheduler 把每个请求建模为一个需要 $\text{bw}_\Delta(r) = \frac{t_\text{gen}(r)}{t_\text{rem}(r)}\cdot\Delta$ 带宽的"矩形"，按 $\text{Priority}(r)=\text{goodput}(r)/t_\text{gen}(r)$ 排序，过滤得到 top-$p$ 候选后按 input length 滑动窗口 选出 batch size $B$ 的一组——前者保证 goodput，后者保证 batch 内长度同质以发挥 Flash Decoding 的效率。

Results：在 16×A100、Llama-3.1-8B/70B、Qwen2.5-14B、Qwen3-30B-MoE-A3B 上跑 Chatbot / Deep Research / Agentic CodeGen / Math Reasoning 混合工作负载 (>10K requests/run)。JITServe 相比 Sarathi-Serve / vLLM / Autellix / LTR 的 token-level goodput 提升 1.4× – 6.3×，或者在相同 goodput 下节省 28.5% – 83.2% 资源，且吞吐仅为 Sarathi-Serve 上限的 96–98%。距离 oracle (精确知道长度+依赖) 只差 3–9%。

Key Findings #

• SJF 和 EDF 的竞争比可任意差：作者在 Appendix D 用 Multiple-Knapsack 归约证明最优调度是 NP-hard，并构造对抗工作负载让 OPT/SJF 与 OPT/EDF 的比值 → ∞。这是 JITServe 存在的理论合法性。
• 上界预测 (QRF) > 点估计：所有基于 BERT/Llama3 fine-tune 的点估计器在线上都会显著低估长度——这直接导致 SLO 违反。QRF 的"保守上界 + 每 50 token 精化"策略把每次预测开销压到 7ms 且不会低估。
• Batch 内长度异质是独立于 Flash Decoding 的 second-order bottleneck：Figure 8 显示即使用 Flash Decoding，batch 内混合长输入和短输入仍会显著减慢 per-token 速度——这是 GMAX 强制 "输入长度相似" 分组的硬件原因，不是算法原因。
• JITServe 的性能保证是常数竞争比 ≈ 1/8.55：在 $\delta=10\%$ 的 preemption threshold 下 (作者用信用分摊 + 抢占链几何级数证明)，goodput(JITServe) ≥ (1/8.55)·goodput(OPT)。EDF/SJF 没有任何这样的保证。
• 3–9% 距离 oracle：说明 QRF 上界 + 在线精化策略的 "信息损失" 非常小，剩余改进空间有限——这实际上给未来调度器的论文定了一个上限。
• 非侵入：整套方案作为中间件加在 vLLM 之上，仅需几行 API 改动 (client.responses.create(..., deadline=None, target_tbt=0.2, target_ttft=5, waiting_time=5))，QRF + graph matcher 通过 gRPC 异步 offload，元数据仅几字节/事件。

Key Figures #

Figure 1: Three request patterns (latency / deadline / compound) #

What it shows：论文开篇的"灵魂分类图"——把 LLM 服务请求分为 latency-sensitive (streaming chat，以 TTFT/TBT 衡量)、deadline-sensitive (单次 E2EL 截止，agent tool call)、compound (多阶段依赖 DAG，deep research / multi-agent)。

Why it matters：这是整篇论文的"问题定义"——一旦承认这三类共存、且在单一请求的生命周期内甚至会互相切换 ("thinking" → "streaming")，就无法再用单一调度目标 (throughput / mean E2EL) 覆盖，也就论证了 JITServe 的 necessity。

Detailed description：三行子图。第一行画一个 streaming chatbot，用户持续读取 token，重点标注 TTFT 和每个 token 之间的 TBT；第二行画一个 "LLM → external tool" 的单体请求，只要求整体 E2EL 在 deadline 前完成；第三行是 compound 的 DAG，若干 LLM/tool 节点之间有边，总 E2EL 决定整个 workflow 的 SLO。

Figure 3: Existing schedulers fail under workload diversity #

What it shows：在混合工作负载上，Autellix (LAS/SJF 风格) 虽然把 mean E2EL 降下来了，但 SLO 违反率 > 90%；Sarathi-Serve (chunked prefill 优化 TBT) 则在 deadline-sensitive 上 TTLT 很大。

Why it matters：这张图是 motivation 的"铁证"——证明聚合指标改善并不等于 goodput 改善。也说明 Appendix D.1 里的理论结果 (SJF/EDF 非竞争性) 在真实系统上会真的 manifest。

Figure 4: JITServe system overview #

What it shows：Request Analyzer (QRF length predictor + pattern-graph matcher) → SLO-Aware Scheduler (GMAX) → SLO Tracker，整个 loop 挂在 vLLM 上作为中间件，只加几行 API 代码。

Why it matters：理解 JITServe 架构的"一张图"；特别是看清 Request Analyzer 是旁路的 (gRPC)，Scheduler 是核心路径，Tracker 反馈到 Analyzer 用于在线精化。

Figure 5: QRF vs BERT/Llama3 length prediction #

What it shows：(a) QRF 推理 7ms，比 fine-tuned BERT 快 7×；(b) QRF 能随生成过程输出"从上到下"收紧的保守上界 (ratio → 1)，而 BERT/Llama3 的点估计器会系统性低估。

Why it matters：这是论文最核心的"工具论证"——如果 QRF 不能给出可用的上界，整个 GMAX 的前提 (bw 估计) 就崩塌了。图 (b) 中红线 ratio=1 是 ground truth，QRF 的阴影区间始终在 ratio=1 上方下探。

Figure 10: GMAX algorithm visualization #

What it shows：左图——每个请求 rectangle 的高度代表带宽需求 $\text{bw}_\Delta(r)$，在每个 frame $\Delta$ 内填入 $B$ 个 slot；右图——先按 Priority = goodput/t_gen 过滤出 top-$p$ 候选，再在候选集按 input length 排序用长度为 $B$ 的滑动窗口选出 sum(priority) 最大的那一组作为 batch。

Why it matters：GMAX 算法最直观的可视化，把"maximize goodput"和"batch 内长度同质"两个目标解耦为两步——第一步保 goodput 的下界 (top-$p$ 过滤)，第二步在候选内部保 batch 效率 (滑动窗口)。正是这种解耦使得作者能在 Appendix D.2 证明出 $p$ 只引入 $p$ 的乘法损失。

Figure 11: Service goodput over 1-hour online deployment #

What it shows：在一个 1 小时的 online serving trace 下，JITServe 的 service goodput 稳定在高位，而 vLLM / Sarathi-Serve 随时间累积 head-of-line blocking 导致 goodput 逐步退化。

Why it matters：这是论文的主结果图——说明 JITServe 不仅瞬时性能好，而且在长时间运行下不会出现 baseline 常见的"雪球"式 SLO 违反。

Figure 13: Near-oracle performance #

What it shows：JITServe 相比 JITServe\* (oracle，已知精确长度+依赖) 在各种 RPS 下只差 3–9%。

Why it matters：给出了"imprecise information 的成本上限"——即使把未来研究的预测器做到完美，goodput 也只能再涨 3–9%。这实际上限制了下游 length-prediction 类论文的价值空间。

Figure 19: Component ablation #

What it shows：分别移除 Request Analyzer (退化为 avg length)、移除 GMAX (退化为 SJF using QRF estimates)，goodput 都显著下降——两者缺一不可。

Why it matters：说明 JITServe 不是"用 QRF + 普通调度器就行"或"随便估计长度 + GMAX 就行"——两个组件乘性地贡献最终效果。

Key Tables #

Table 1: User study on SLO diversity within the same application #

Application	Real-Time (low TBT)	Direct Use (low E2EL)	Content-Based (mixed)
Code generation	38.1%	30.5%	31.4%
Report generation	39.1%	36.2%	24.7%
Deep research	38.6%	47.1%	14.3%
Real-time translation	36.2%	39.9%	23.9%
Batch data processing	15.6%	49.6%	34.8%
Reasoning task	28.9%	47.4%	23.7%

Takeaway：即使在同一个应用内部，用户对 SLO 的偏好也显著分化——例如 code generation 中 38% 希望流式读取、30% 希望整体最快返回。这直接否决了"按应用分类 + 专用集群"的朴素方案。

Table 2: Example request length statistics (two of four applications) #

Workload	Type	Input Mean/Std/P50/P95	Output Mean/Std/P50/P95
Chatbot (Single)	latency	93 / 244 / 27 / 391	318 / 313 / 225 / 1024
Chatbot (Compound)	multi-stage	1300 / 912 / 1097 / 2767	4458 / 1176 / 4417 / 6452
Deep Research (Single)	deadline	1911 / 2781 / 403 / 7573	534 / 644 / 410 / 1544
Deep Research (Compound)	multi-stage	12223 / 8407 / 10807 / 29282	3541 / 2370 / 3148 / 7525

Takeaway：Deep Research compound 请求的输入均值比 Chatbot single 的输出均值还大一个数量级——batch 内混合 chatbot 和 deep research 会产生极端的长度异质，这正是 GMAX 引入"滑动窗口按长度分组"的直接动机。

Limitations #

• 训练 QRF 需要历史 prompt → response length 的标注数据——冷启动场景（新模型、新应用）下 QRF 初期精度未量化。
• Pattern graph 匹配依赖历史相似模式——对于 truly novel 的 agent workflow (例如首次出现的深度研究结构)，匹配退化到通用估计。
• 只支持 A100 + vLLM，没有评估在 H100/MI300X 或 SGLang/TRT-LLM backend 上的可移植性。
• SLO 是外部输入——JITServe 不自己推断 SLO，所有分析都假设 developer 提供 deadline/target_tbt/target_ttft。
• 没有讨论 multi-tenant fairness (跨 tenant 的 goodput 隔离) 和 计费模型 (保守带宽估计是否会让便宜 tier 抢占昂贵 tier)。

Infrastructure Impact #

• Algorithm：提出了 goodput-as-first-class-objective 的调度抽象，下一代 online RL / agentic RL 系统可以借鉴 pattern-graph + GMAX 思路。
• Kernel：本身不触碰 kernel，但结论 "batch 长度异质 → per-token 变慢 (即使用 Flash Decoding)" 为未来长度异构的 attention kernel 提出了新需求。
• Framework：直接推动 vLLM/SGLang 把 SLO 作为一等公民 API；deadline/target_tbt/waiting_time 很可能被 OpenAI 风格 API 采纳。
• LLM：对模型架构无要求——dense、MoE 都测过；但 QRF 的精度会依赖模型响应长度分布稳定性。
• Agent：这是本文最大的增量——pattern-graph matching 为多 agent workflow 提供了可伸缩的 "sub-deadline 分配" 机制，解决了过去 agent serving 的 E2E deadline 管理空白。
• Code：工程上只改 vLLM 调度器层 + 一个异步 gRPC 服务，复现门槛很低；未开源 QRF 训练 pipeline 是最大障碍。

---

Deep Analysis (framework) #

0. 时代定位与约束推导 (从 Phase 2 继承并补深) #

时代定位：2024–2025 年 LLM serving 的 low-hanging fruit (continuous batching / paged attention / chunked prefill / 分离 P-D) 已被 Orca / vLLM / DistServe / Sarathi-Serve 挨个摘走。下一阶段的核心矛盾从"系统吞吐"转向"应用级 goodput"——因为 agent / deep research / multi-agent 三类 workload 把 SLO 空间从一维 (TBT) 扩张到三维 (TBT × E2EL × compound-E2EL)，单一调度目标已经不够用。JITServe 代表的就是"serving 进入深水区"：从无视 SLO 的 FCFS/SJF 过渡到 SLO-aware + imprecise-info tolerant 的调度。

约束推导（为什么不能用更简单的方案？）：

替代方案	能否 work	失败原因 (first principles)
按应用分专用集群	❌	Table 1 显示同一应用内部用户 SLO 偏好分化到 38%/30%/31%，按应用分并不能消除 SLO 多样性；且请求在生命周期内会从 "thinking" (deadline) 切到 "streaming" (latency)，跨集群迁移 KV cache 代价极高。
EDF (earliest deadline first)	❌ 任意差	Appendix D.1.1 构造：一个高 goodput 长任务 A + N 个小而紧 deadline 的低 goodput 任务 B_i，EDF 会优先 B_i 导致 A miss SLO；竞争比 OPT/EDF = M/N 可任意大。
SJF (shortest job first)	❌ 任意差	Appendix D.1.2 同类构造：SJF 系统性地偏好短任务，忽略 goodput value；竞争比同样发散。
精确预测长度后再调度	❌ 不可行	Figure 5(b) 和 §2.2 给出证据：BERT/Llama3-based predictor 系统性低估；自回归生成 + 随机采样 + self-reflection 使得精确预测在信息论上几乎不可能。
DP on request rectangles	❌ 规模问题	文中提及 $DP(\mathcal{R}, t, B)$ 对上千请求 + 在线抢占不可扩展 (Figure 9 显示 GMAX 扩展到 thousands of requests，而 DP 无法)。
单纯用 QRF + SJF / LAS	❌ 部分	Figure 19 ablation 证明：仅去掉 GMAX (换成 SJF-on-QRF) 也会显著掉 goodput——预测精确不能补偿调度错误。

剩余可行设计空间："保守的上界估计 + 基于 goodput/bandwidth 的启发式优先级 + batch 内部长度同质约束"——这正是 JITServe 占据的 niche。

核心技术壁垒：不是 QRF (现成工具)，也不是 margin goodput 公式 (直观)，而是 GMAX 的"两步解耦"——top-$p$ 过滤 + 滑动窗口分组。这种解耦是可证明竞争比的根源：作者在 Appendix D.2 证明 top-$p$ 引入的只是 $p$ 的乘法损失 (Eq. 50)，而滑动窗口仅在候选集内部运作，不会把 priority 拖到 $p \cdot R(r_{(B)})$ 下方。其他任何"直接联合优化 goodput + length homogeneity"的写法都会破坏这个竞争比分析。

质疑假设：JITServe 的 QRF 预测只有 7ms 这个数字，前提是 QRF 在部署点已经训练好。作者没有披露 QRF 训练数据量、训练耗时、re-training 频率。对新模型 (Qwen3-MoE) 或新 application (未见过的 agent workflow) 下的 cold-start 精度是个未知数——这部分的 3-9% oracle gap 很可能会放大。此外，pattern-graph matching "500 graphs 足够" (Figure 7) 是在作者选取的 workload 上测得，对 deep research 这种图结构可以有 10+ stage 的应用是否仍成立存疑。

设计绑定批判：JITServe 强制绑定了 (a) 外部提供的 SLO——没有 deadline/target_tbt 就无法工作；(b) vLLM 风格的 continuous batching + chunked prefill——GMAX 的 frame 模型假设 batch size 在一个 $\Delta$ 内近似恒定，若换成 P-D 分离或大 chunk 预填，$\text{bw}_\Delta$ 的定义需要重写；(c) QRF 训练数据——对完全冷启动 (全新模型 + 全新应用) 没有兜底方案。

生态影响追踪：论文声称只需几行代码即可集成 vLLM，且 API 形式 (deadline=, target_tbt=) 与 OpenAI 现有 API 风格一致——这强烈暗示作者希望被 OpenAI / 云厂商吸收。截至 2025 Q2 尚未看到 vLLM / SGLang 主线 PR 采用此设计，但 AdaServe / Autellix / u-Serve 等后续论文已经把 JITServe 列为对照组，说明在学术圈已经成为新的 goodput baseline。

1. System Scope #

• Primary goal：online LLM serving——接收 HTTP 请求、返回生成 token，核心指标是 service goodput。
• Scale：论文评估使用 16×A100 单一 cluster；通过 data parallelism 扩展到多 replicas (Figure 20)。未评估跨 DC 或大规模 (100+ GPU) 部署。
• Online / latency-sensitive：调度粒度是 per-frame $\Delta$，典型 frame = 秒级以下。
• Workloads：Chatbot (latency-sensitive) + Agent CodeGen (deadline-sensitive) + Math Reasoning + Deep Research (compound)；模型覆盖 Llama-3.1-8B/70B、Qwen2.5-14B、Qwen3-30B-MoE-A3B (dense 和 MoE 都有)。

2. Architecture & Data Flow #

Figure 4: JITServe system overview (重复引用于本节) #

解读：Request arrival → Request Analyzer (1️⃣ QRF 预测 len_upper + pattern-graph match 依赖图) → SLO-Aware Scheduler (2️⃣ GMAX) → Execution Backend (vLLM engine, chunked prefill + continuous batching) → SLO Tracker 监测真实生成速度并反馈给 Analyzer 用于 online refinement。

Control plane vs data plane separation：Request Analyzer (QRF + graph matcher) offloaded 到独立进程，通过 gRPC 与主调度器通信；元数据仅几字节/事件。Scheduler 本身是 vLLM scheduler layer 的 policy module 扩展 (data plane 内)，但用 priority cache 摊薄计算。

Stateful components：(1) SLO Tracker (per-request actual generation speed)；(2) Request Analyzer 中的 pattern-graph 历史库 (K-medoids 聚类 + 0.9/hour 衰减)；(3) Scheduler priority cache。

Stateless components：QRF 推理本身 (given prompt → quantile)；GMAX 决策函数 (given request set + priorities → batch)。

Failure handling：作者只提到 monitoring daemon 跟踪 component liveness + 周期性 checkpoint metadata，未深入讨论 GPU/node failure 的 mid-request recovery。

2a. End-to-End Data Flow #

Stage	Input → Output	Location	Latency	Data format
Tokenize	text → token IDs	CPU (vLLM frontend)	<1ms	List[int]
Request Analyze	prompt + history → len_upper, graph_sig, priority	独立 CPU 进程 (gRPC)	~7ms QRF + <5ms graph match	几字节/event
GMAX Schedule	request queue + priorities → batch of $B$	main scheduler (CPU)	<1ms (priority cache 摊薄)	in-memory struct
Prefill/Chunked Prefill	tokens → KV cache	GPU HBM	O(input_len²)	[layers, heads, seq, dim] fp16/bf16
Decode	KV cache + last token → next token	GPU HBM	O(batch × layers) per token	logits [vocab_size]
SLO Track	actual token output → per-req speed update	CPU	<1ms	scalar per req
Refine	every 50 tokens trigger QRF re-call	CPU (gRPC async)	~7ms	新 len_upper

2b. Data Movement Hotspots #

1. KV cache in HBM：paged via vLLM (继承)，per-decode 一次。JITServe 通过 prefix caching 尽量复用。
2. Scheduler ↔ Analyzer gRPC：每请求每 50 token 一次，总量"几字节/event"，与 compute 重叠。
3. vLLM chunked prefill：GMAX 不改变这一步，但 "batch 长度同质" 约束让 prefill chunks 大小更均匀，减少 ragged-batch padding 浪费。

3. Design Space & Constraint Analysis #

见上文 0. 时代定位与约束推导 中的 feasibility matrix 和核心技术壁垒分析。

Assumption audit（补深）：

• QRF 能给出有意义的上界 — 在 prompt 可提取的 feature (长度、语言、模板) 与 response length 有足够相关性时成立；在对抗性 prompt 或分布偏移 (新模型、新领域) 下可能失效。
• Pattern graph 相似匹配有用 — 要求历史库中存在 "结构相似" 的执行图。对于真正 novel 的 workflow (例如刚上线的 agent 架构)，会退化到 "匀分 sub-deadline"。
• Batch 内长度相似 → 效率提升 — 论文 Figure 8 在 A100 上验证；H100/MI300X 的 TMA + dynamic shapes 可能让这个不等式变弱。
• Preemption 成本可 amortize — $\delta=10\%$ 阈值下只允许"高 goodput 打低 goodput"，作者用几何级数论证链长有限 (Eq. 34)；但没评估 KV cache eviction / reload 的绝对开销。

4. Key Innovations #

Innovation	Mechanism	Benefit	Cost / Tradeoff
QRF upper-bound length prediction	Quantile Regression Forest，每 50 token re-invoke	7ms/次，比 BERT 快 7×；不会低估	需要离线训练 QRF；对 cold-start 未量化
Pattern-graph matching	K-medoids 聚类 + Gaussian-kernel 相似 + 0.9/hour 衰减	<5ms for 500 graphs，准确率 > 80%	对真正 novel workflow 退化
Margin goodput priority	Priority(r) = goodput(r) / t_gen(r)	对 $\Delta$ 不敏感；可证明竞争比	需要 goodput(r) 的 closed-form 定义
GMAX two-step (filter + window)	top-$p$ 过滤 + input-length 滑窗	同时保 goodput 下界 + batch 效率；可证明 $p$ 损失	候选集大小受 $p$ 影响，$p$ 需调
$(1+\delta)$ preemption threshold	只有 goodput ratio > $1+\delta$ 才抢占	抢占链长有限（几何级数收敛）	$\delta$ 过小→抢占风暴；过大→ goodput 损失
Starvation-avoid additive $\delta$	每帧给 goodput(r) 加常数	长等请求最终升到顶	可能让 best-effort 请求也消耗 bandwidth

5. Scheduling & Resource Management #

• Batch formation：每个 $\Delta$ frame 内由 GMAX 决定——不是传统 continuous batching 的"完工即加新"，而是主动按 priority+length 选 $B$ 个请求。
• Memory management：继承 vLLM PagedAttention + prefix cache，不改动。
• GPU utilization：GMAX 强制 batch 内长度相似 → Flash Decoding 效率提升 → 不会因 ragged batch 引入 idle。
• Multi-tenancy：通过 SLO 参数隐式区分 tenant，但未显式讨论公平性隔离。
• Priority / SLO-aware：核心。Priority = goodput/t_gen，每帧重算。

6. Target Scenarios & Bottleneck #

Scenario	Workload	SLO	主瓶颈	为何其他系统失败
Chat streaming	短输入短输出，高并发	TTFT<2s, TBT~100ms	scheduling-bound (HOL blocking)	vLLM FCFS 被长请求堵塞
Agent tool call	中长输入，一次输出	E2EL<20s	length-prediction bound	Autellix SJF 用错预测器
Deep research (compound)	长输入长输出，多阶段	E2EL=20×#stages	compound-deadline 分配	现有系统无 sub-deadline 概念
Math reasoning	长 thinking + 短 final	混合 deadline→latency	请求类型切换	静态分类无法处理

Figure 11: Goodput over time (本节重复引用) #



解读：JITServe (紫) 在 1h trace 上保持平稳高 goodput；LTR/Sarathi-Serve/Autellix 都在累积 HOL blocking 后缓慢下滑。这直接证明 scheduling-bound 是四个系统在混合 workload 下的共同瓶颈，JITServe 是唯一能持续抑制它的系统。

7. Performance Evaluation #

7a. Metrics #

Metric	Definition	Unit	Direction
Token-level goodput	# tokens meeting SLO	tokens/s	↑
Request-level goodput	# requests meeting SLO	reqs/s	↑
TTFT / TBT	time-to-first-token / time-between-tokens	ms	↓
E2EL (TTLT)	time-to-last-token	ms	↓
Throughput (system)	all tokens/s (ignores SLO)	tokens/s	↑ (not primary)
Resource saving	GPU hrs to hit same goodput	%	↑

7b. Before-After Comparison #

Optimization	Metric	Baseline	JITServe	Improvement	Conditions
Full JITServe	token-goodput	Autellix	5.3–6.1×	5.3×+	16×A100, 1h online
Full JITServe	token-goodput	LTR	1.3–1.7×	1.3×+	同上
Full JITServe	request-goodput	LTR	2.3–4.5×	2.3×+	同上
Full JITServe	vs oracle JITServe\*	3–9% gap	-	near-oracle	across RPS
No Request Analyzer	token-goodput	full JITServe	显著下降	ablation	Figure 19
No GMAX	token-goodput	full JITServe	显著下降	ablation	Figure 19
Full JITServe	throughput	Sarathi-Serve	96–98%	无退化	Figure 14
Full JITServe	multi-replica goodput	baseline	1.34–2.42×	scalable	Figure 20
Full JITServe	latency-only workload	Sarathi-Serve	1.72×	在其强项上也赢	Figure 22

7c. Bottleneck Shift #

vLLM FCFS:        scheduling-bound (HOL blocking)
 → Sarathi-Serve: scheduling-bound (TBT good, TTLT bad)
 → Autellix LAS:  scheduling-bound (mean E2EL good, SLO violation 90%+)
 → JITServe:      SLO-estimation bound (3–9% gap to oracle)

JITServe 实际上把 bottleneck 从"调度策略错误"推到了"信息完美性"——而 oracle 上限表明再改进只剩 3–9% 空间。

Figure 13: Near-oracle (本节重复引用) #



解读：在 4 个不同 RPS 上，JITServe (实线) 紧跟 JITServe\* (虚线，oracle)，gap 3–9%。这证明作者关于"imprecise information is actionable enough"的论断在实验上站得住。

7d. Baselines & Fairness #

• 同硬件 (16×A100)、同模型、同 workload trace；所有 baseline 都是 vLLM backend 上实现，差别仅在 scheduler。
• 10K+ requests/run，>1h online 窗口——比大多数 serving 论文的 5-min 小 window 更有说服力。
• Sarathi-Serve 在 latency-only workload 上被 JITServe 打败 1.72×（Figure 22）——在其自身设计点上仍然输，这是最尴尬的比较。
• 公平性补丁：LTR 确实在 deadline-sensitive 上 E2EL 不错 (prior knowledge via predicted rank)，但在混合 workload 上全面落后；作者没有回避这一点。

Figure 19: Ablation (本节重复引用) #



解读：从左到右 — JITServe\* (oracle) / JITServe (full) / no-Analyzer / no-GMAX / Sarathi。移除任一组件掉 goodput 都很明显，且剩下的性能接近 Sarathi，说明 QRF+graph matcher 与 GMAX 是相互必需的。

8. API & Usability #

• OpenAI-compatible 扩展：client.responses.create(model, input, deadline=None, target_tbt=0.2, target_ttft=5, waiting_time=5)。
• 模型格式：HF SafeTensors (继承 vLLM)。
• 部署：vLLM 本身的 Docker/K8s path 可用；QRF 需单独起一个进程。
• 配置复杂度：核心新增 4 个用户参数 (deadline / target_tbt / target_ttft / waiting_time)；内部超参 ($\Delta$ frame size, $p$ 过滤阈值, $\delta$ 抢占阈值=10%) 可用默认。

9. Infrastructure Impact #

Layer	Impact
Algorithm	激活 goodput-aware online scheduler 研究方向；pattern-graph 为 agent training 系统做 sub-deadline 分配提供模板。
Kernel	无新 kernel 需求；但暴露"混长 batch 比长度同质 batch 慢"的现象，为未来长度感知 attention kernel 提供动机。
LLM	不挑模型（dense + MoE 都测过）；但要求响应长度可用 QRF 预测——高度创造性输出 (open-ended generation) 上 QRF 精度待测。
Agent	最大增量——为 multi-agent / deep research 框架提供了原生的 E2E deadline management。
Ops	API 风格可直接进现有 OpenAI 生态；监控 daemon + metadata checkpoint 基本满足生产需求，但缺 autoscaling hook。

10. Comparison Matrix #

Feature	JITServe	vLLM	Sarathi-Serve	Autellix	LTR
Continuous batching	✓ (inherit)	✓	✓	✓	✓
Paged attention	✓ (inherit)	✓	✓	✓	✓
Chunked prefill	✓ (inherit)	✗	✓	✗	✗
SLO-aware scheduling	✓ (multi-type)	✗ FCFS	✓ (TBT only)	✗ (mean E2EL)	✗ (rank-SJF)
Length prediction	✓ QRF 上界	✗	✗	✗	✓ 点估计
Compound/agent deadline	✓ pattern graph	✗	✗	部分 (LAS)	✗
Provable competitive ratio	✓ ~1/8.55	✗	✗	✗	✗
Multi-node	data-parallel replicas	✓	✓	✓	未强调
Preemption-aware	✓ ($\delta$=10%)	✗	✗	✓	✗

11. Adoption, Maturity & Ecosystem Influence #

• 开源状态：论文提及"only a few lines of code modification to existing serving stacks"，但未贴公开 repo；QRF 训练脚本和 pattern-graph 数据暂未公开是最大落地门槛。
• 生产部署：论文通过"讨论两家大型 LLM 服务商 + 550+ 用户调查"为动机背书，暗示已有 production 对接意向，但未 name-drop。
• 下游影响：截至 2025 Q2 尚未出现在 vLLM / SGLang 主线 release note；但理论 artifact (SJF/EDF 非竞争性证明 + 1/8.55 竞争比) 已经被 AdaServe / Autellix follow-up 版本引用。长期看，deadline= 类 SLO 参数进入 OpenAI-style API 规范的概率较高。
• Open questions：(1) QRF 在 open-ended reasoning 模型 (o1/R1) 上的精度；(2) 与 P-D 分离 serving (DistServe / MoonCake) 的集成；(3) KV-cache 迁移型 failover 下 GMAX 的鲁棒性；(4) fairness/billing 怎么融入 Priority = goodput/t_gen 公式。