LLM 请求分配到 GPU 后，形态仍会继续变化。请求到达时，prompt 长度已经可见，输出长度尚未揭晓。每生成一个 token，键值（KV）缓存都会扩展；分发时被视为开销很低的请求，随后会成为大量占用内存的邻居，拖慢整个批次。一次性的路由决定由此承担了一项预测任务，要预判自回归生成尚未显露的信息。

阿里巴巴工程师 Biao Sun、Ziming Huang、Hanyu Zhao 及其同事把这个问题带到 2024 年 USENIX OSDI 的讲台上。他们的系统 Llumnix 在多个 vLLM 实例之上加入连续重调度。它的核心动作十分直接：初始放置一旦效果欠佳，就把运行中的请求连同 KV-cache 状态迁往另一个实例，取代继续承受队列等待或在别处重算整项请求的做法。[1][2]

这场演讲约 16 分钟，适合看两遍。第一遍沿着五个观看节点理解系统。第二遍准备三栏——主张、机制、边界——等机制和测试条件都清楚可见，再把结果记入主张栏。以下时间段只用于定位，与逐字稿的用途有别。[1][3]

0:33–3:25 —— 分发器做出一次不可撤回的猜测

开场示意图很常见：用户把请求发送给分发器，由它将请求摊到多个模型实例上。每个实例内的推理引擎即使已经采用连续批处理、分页式 KV 缓存分配和抢占，也只能处理实例内部的问题。Llumnix 关注的重点落在集群分发继承的一项传统深度学习假设：请求大体同质、确定且无状态。实例内技术本身依然有效，但 LLM 请求让这三项假设全部失效。[2][3]

看演讲如何把输入长度和输出长度拆开。前者在请求到达时已知，后者随着 token 生成逐步显现。这种不确定性让 GPU 内存需求持续变化，因为生成序列越长，KV 缓存也越大。请求数量相等也无法代表负载相等。两个实例各自收到十个请求，最终承受的内存压力、排队情况与相互干扰会相差很远。

3:25–8:05 —— 重调度把四类情况归入一种能力

衡量重点因此要从平均吞吐量延伸到尾延迟。繁忙实例一旦抢占运行中的请求，就会造成停顿，在一些情况下还会触发重算。集群总体空闲内存足以容纳一个大型 prompt，单个实例却都没有足够空间时，请求仍会滞留在队首。紧急的交互请求也会与时间要求较宽松的工作共享一个批次。演讲从 3:25 起将这些问题分别称为性能隔离、碎片化和差异化服务级目标。它们共同来自无法修订的放置决定，属于同一问题的后果。[2]

6:02 左右，演讲引入操作系统类比。进程的持续时间未知，工作集也在变化；操作系统不会承诺进程启动后永远留在原处，也不会放弃抢占。Llumnix 把这层系统直觉用于 LLM 服务。这里的类比只取调度这一层：请求可以像进程一样重新调度，它的状态却是专用张量缓存，进度由自回归解码推进，与通用 CPU 进程仍有清楚差别。[1][2]

幻灯片列出四种迁移工作的理由。负载均衡在实际缓存增长暴露出实例过载后作出反应。碎片整理把一部分运行中的请求集中到别处，让某个实例腾出足够的 KV 缓存容量，接纳排队的 prompt。优先级调度把普通工作从延迟敏感请求旁边移走，省去长期预留整台机器的代价。自动扩缩容负责排空即将终止的实例，或更快填充新实例。初次分发依然重要；工作负载透露更多信息之后，迁移让调度器拥有第二次决定机会。[3]

区分清楚这一点，就能避开一种常见的过度解读。Llumnix 没有预测每个答案的最终长度，它削弱的是判断出错后的代价。策略价值来自可逆性：观察真实增长，再调整放置。

8:05–11:25 —— 复制稳定的过去，同时解码下一个 token

迁移请求听起来代价高昂，因为它的 KV 缓存会很大。朴素方案会把这笔代价直接暴露给用户。暂停请求并复制全部状态，服务就会在整个传输期间停住；在目标实例重新启动并重算历史，停顿还会随已有上下文增加。Llumnix 利用了一项特性：早期 token 对应的 KV 缓存块只追加。新的解码步骤只会写入新状态，旧块保持不变。[2]

迁移的第一阶段里，源实例继续解码，同时把已经完成的缓存块复制到目标实例。后一阶段再复制首次传输期间产生的较小增量。直到最后，Llumnix 才让请求退出源批次，复制最终增量，并在目标实例上继续运行。大批量传输依然需要时间，也会消耗带宽。设计力求保持近乎恒定的是迁移请求感受到的停顿时间，传输的总字节数仍会随缓存增长。[2][3]

论文的受控迁移测试给出了具体数字，也划清了适用范围。在 LLaMA-7B 和 LLaMA-30B 配置中，随着序列长度增加，报告的停顿时间保持在约 20–30 毫秒；重算一段 8,000-token 的 LLaMA-30B 序列则耗时 3.5 秒。对其他运行中请求测得的每步解码差异最高为 1%；在后续服务实验里，每个实例约有 10% 的运行时间都有请求正在迁移。这些测量在该测试平台上很有力度，适用范围也止于这一平台；其他模型、互连网络和缓存布局各有自己的结果。[2]

从录像转向论文图 7，可以看到短演示稿省略的握手过程。每个阶段开始前，目标实例都要预留足够的缓存块；遇到内存不足、请求完成、请求被抢占或参与方故障时，任一侧都可中止迁移。这条控制路径和复制技巧同样重要。“在线迁移”既包含快速张量传输，也包含计算继续时协调完成的所有权变更。[2]

11:25–13:40 —— virtual usage 让策略变得清晰可读

Llumnix 把调度工作分给全局调度器，以及每个实例内称为 llumlet 的组件。全局层掌握各实例负载，分发新到请求，为迁移源端和目标端配对，并控制扩缩容。llumlet 维护本地请求状态，在本实例被选为源端时决定迁移哪个请求，并协调传输。运行中请求的逐项细节由此留在本地，全局调度器只处理所需的汇总信息。[2][3]

实例上报的负载可以超出物理内存用量。Llumnix 引入 virtual usage（虚拟用量），用一个记账值让同一套负载均衡策略表达不同目标。常规情况下，虚拟用量跟随实际内存占用。对于受阻的 prompt，调度器可以把尚未满足的内存需求计入虚拟用量，促使运行中的工作迁走并腾出空间。调度器可以给高优先级请求加上虚拟余量，使所在实例的账面负载上升，从而把普通请求推向别处。即将终止的实例则可以被赋予人为负载，使工作逐步排空。[2]

这是演讲中最具复用价值的设计思路，因为它把机制与策略分开。在线迁移让放置可逆；虚拟用量告诉系统何时放置已经不理想。这两项功能对所选启发式规则的最优性都不作证明。论文采用一组简单规则，也明确提到策略选择和取舍。生产运营方仍要决定服务能够承受多少迁移流量、预留余量和队列优先级。

13:40–15:52 —— 每个提速数字都要连同分母一起读

演讲的评估页在结果之前给出分母：16 块 NVIDIA A10 GPU，每块 24 GB，分布在 4 台阿里云虚拟机上，每台 4 块 GPU，实例间网络为 64 Gb/s。论文评估了 16-bit LLaMA-7B 和 LLaMA-30B，负载来自 ShareGPT、BurstGPT 和生成的幂律请求长度分布。服务对比在每种调度器下统一使用 vLLM，并将 Llumnix 与轮询分发及作者优化过的 INFaaS 基线 INFaaS++ 比较。[2][3]

在真实轨迹实验中，相较 INFaaS++，Llumnix 对平均首 token 延迟和 P99 首 token 延迟的改善最高分别达到 2.2× 和 5.5×，P99 单 token 解码延迟最高改善 1.3×。在生成分布上，论文报告平均首 token 延迟最高改善 7.7×，P99 首 token 延迟最高改善 14.8×。另一些实验报告，高优先级请求延迟最高改善 1.5×；在选定的自动扩缩容对比中，当 P99 首 token 延迟大致相近时，平均实例成本降低 36%。[2]

这些最大值分属不同轨迹、到达率、目标与对比，各自保留自己的实验分母。幻灯片有意采用真实数据集里较小的醒目数字，论文则收录范围更广的最大值。仔细观看时，每看到一个“最高”，都要同时记录其下方的基线和指标。还要记下，64 实例可扩展性研究以计时模拟替代真实 GPU 执行，因为这个集群规模超过了物理测试平台。[2][3]

证据允许的结论范围要窄于“Llumnix 让推理快 15 倍”，同时也更有用：在接受测试的多实例配置中，迁移让调度器能够在分发之后修复负载失衡和碎片化，并在一次性放置代价高昂的条件下显著改善长尾。

2026 年的代码库已经不同于 OSDI 时刻冻结的产物

演讲之后，软件版本的范围发生了变化。原先基于 Ray 的代码库如今标为 Llumnix v0，并引导面向生产的用户转向经过重新设计、模块化且面向云原生环境的 Llumnix v1 代码库。v0 页面称这一版本更适合本地部署和快速调度实验，同时将其标为 alpha 阶段，并发布了后来在 Qwen2.5-7B/A10 与 Llama2-13B/A800 配置上的基准结果。这些后来的轮询和队列大小对比属于另一批实验，须同 OSDI 结果分开阅读。[5]

v1 代码库描述了一套更大的服务栈：初始调度器与重调度器、full 和 engine-transparent 两种模式、网关、实例状态追踪、KV 传输组件、故障处理，以及对 vLLM 和 SGLang 集成的支持。文档还写明 Llumnix 已用于阿里云 PAI-EAS，并把 2026 年 3 月版本标记为一套新架构。[4] 这些内容来自项目第一方文档，其证据性质与独立生产审计有别。它展示了维护团队后来如何发展这项思路，2024 年论文的证据范围仍保持原样。

第二遍观看——检验迁移是否值得付出代价

第二遍观看时，可以追问三个运营问题。第一，哪些状态必须跨网络传输？ 更长的上下文和更大的模型会增加缓存体积，即使最终停顿依旧很短。第二，迁移会与什么争用？ 缓存流量会在真实网络中与推理、存储和其他传输共享带宽；“近零停顿”仍然带着实际资源成本。第三，故障发生时，所有权如何变化？ 预留、中止和提交路径决定一次快速传输能否同时保持正确。

再把证据分成三类。OSDI 工作给出了机制、受控测试平台和对比延迟结果。[2] 代码库记录软件演进中的项目方主张，也给出可部署代码。[4][5] 运营方在新模型、加速器、拓扑或流量分布上的结果仍属第三类证据，需要本地试验来测量自身负载下的首 token 到达时间、token 间隔时间、抢占停顿、迁移频率、传输字节数和故障恢复。

因而，持续有效的 AI-China 信号超出一次基准测试的胜负，落在推理性能工程重心的转移。模型权重和计算内核很重要，集群在不可预测的请求启动后修订决定的能力也同样重要。Llumnix 最有力的一课清晰可见：当工作负载随时间逐步显形，调度器也应当从这些新信息中继续学习。

来源

1. USENIX，《OSDI '24 — Llumnix: Dynamic Scheduling for Large Language Model Serving》，Biao Sun 于 2024 年发表的演讲。
2. Biao Sun 等，《Llumnix: Dynamic Scheduling for Large Language Model Serving》，第 18 届 USENIX Symposium on Operating Systems Design and Implementation，2024 年。
3. Biao Sun 等，OSDI '24 官方演示文稿，2024 年。
4. Llumnix 项目，当前 Llumnix v1 代码库与架构文档。
5. Llumnix 项目，基于 Ray 的 Llumnix v0 代码库、升级说明与后续基准测试注记。
6. 阿里巴巴集团媒体资料库，“Apsara Conference 2024”编辑照片。