LLM 推理调度：你以为的"最优"，可能连上帝视角都打不过

关联论文：2502.07115

LLM 服务系统每秒都在做一类隐式决策：把哪些请求拼成 batch 送进 GPU、什么时候让新请求开始 prefill、临近完成的请求是先结束还是再插入？这些决策直接决定尾延迟、吞吐上限和 KV cache 利用率。工程师已经摸出了 vLLM continuous batching、Sarathi chunked prefill 一套打法，但缺两件东西：一是"理想上限"的参照基准，二是流量突变时系统会不会崩坏的理论保证。

这篇论文的尖锐之处，是把"假设看穿未来"显式写成一个整数规划（HOPT）：变量是每对 (请求, 时段) 的"是否在飞"、约束含到达一致性 / KV cache 内存上限 / 完成一致性 / batch 容量、目标是最小化总时延。HOPT 本身不可实现，是给整个 serving 社区的"对照尺子"——任何在线算法都可以和它比一下差距。

然后论文给出坏消息：不可能性定理——当到达过程任意时，不存在确定性在线调度算法能达到常数竞争比。直觉很朴素：未来请求可以在你刚填满 GPU 时把内存打爆，也可以全部延迟到达让你空跑。这告诉业界，"找一个万能调度公式"不现实，把力气放在自适应 / 在线学习上更值得。在温和到达条件下，作者给出一个多项式时间在线算法：基于内存状态的准入 + 长度感知 batching（短 prefill + 长 decode 与反之互补配对）+ 轻度 swap 抢占，并证明能达到常数竞争比。

证据边界方面，仿真覆盖合成 trace 与 Llama2-70B 在 A100 上的模拟 trace，原文用延迟分布函数画"regime-level 行为"，没有给"M 比 N 提升 X%"的单点数字；"几乎不出现 KV cache 溢出驱逐"是解读升级措辞，原文为 "significantly fewer evictions"；竞争比常数上界依赖温和到达具体条件，附录定理编号需对照 PDF §3/§4 核验；仿真代码是否开源未明确。

工程局限在于：HOPT 在请求量 >100 时组合爆炸，生产 audit 只能用 LP 松弛或采样近似；输出长度预测的误差会在调度中"级联放大"，建议配合 mem_budget × 0.85 的保守边界；模型是单 A100 homogeneous，未建模多卡张量并行与 prefill-decode 分离拓扑，跨卡推理时需重新验证；最关键的边界是——任意到达下常数竞争比保障失效，生产中的 burst（凌晨流量突增、促销事件）正是论文证明"无银弹"的现实版本。

标题变体（3 条）

LLM 推理调度的"上帝视角"基准：一篇论文给 serving 系统装了把尺子
流量突变时调度器一定会崩——除非你别再找"万能公式"
短 prefill 配长 decode：把 vLLM 调度器改一行能压多少尾延迟？

小红书卡片文案

LLM serving 工程师别再问"哪个调度器最快"了，这篇 arXiv 2502.07115 直接给你造了一把尺子：Hindsight Optimal Benchmark，把"假设看穿未来"写成整数规划当对照基准。然后告诉你一个坏消息——任意到达下，不存在能稳赢的确定性在线算法。最实用的部分是温和条件下的多项式算法：长度感知 batching + 轻度 swap 抢占，配上保守的 mem_budget 边界就能用。最扎心的边界：burst 流量下常数竞争比失效，凌晨促销那次翻车可能正是论文证明"无银弹"的现实版。