Llumnix揭示了LLM服务与传统DNN推理的根本差异，提出动态调度必要性，设计了首个支持跨实例实时迁移的LLM服务系统，旨在解决大规模语言模型（LLM）推理服务中的请求高效调度问题。通过动态请求迁移和细粒度调度策略，Llumnix在降低延迟、提高优先级支持和降低成本方面表现出色。

论文：(OSDI 2024)Llumnix: Dynamic Scheduling for Large Language Model Serving

代码：https://github.com/AlibabaPAI/llumnix

该文章参考自：

背景

LLM服务特性

异构性：不同应用场景（如聊天、摘要、代码生成）导致请求的输入/输出长度、延迟需求（GPT Plus）差异显著。
不可预测性：生成token数量未知，GPU内存占用动态增长，传统静态调度难以应对。

在推理过程中遵从Orca中提出的选择性批处理机制，使用vLLM中提出的动态内存分配机制不断地为新的KVcache分配新的内存。当GPU显存满载时，会将一部分的请求（蓝色的部分）从内存中驱逐，重新放回请求队列。

存在的问题与挑战

由于抢占带来的额外开销较大，导致P99延迟大，服务级别目标（SLO）难以满足。
请求之间的性能干扰。

批处理的数量越多，模型参数量越大，干扰就越明显。
内存碎片。
考虑到前两个挑战，应该将请求分散到不同的GPU，但这样容易造成显存的外部碎片化。导致外部请求（尤其是长请求）的延迟很高。
满足更高优先级
现在的系统一般都是平等对待所有的请求，缺乏优先级支持。（这里的平等是对每个请求的优先级都一致，关于请求公平性方面的研究可以参考FairnessLLM这篇OSDI24的工作）

解决方案

Llumnix通过运行时跨多个模型实例重新调度请求来应对上述挑战。类似于现代操作系统中的上下文切换，通过高效且可扩展的请求和内存状态实时迁移机制实现重新调度，以改善负载均衡、减少资源碎片化、区分请求优先级和SLO，还能实现弹性伸缩(更快地耗尽要终止的实例或使新实例饱和)。

实时迁移

多阶段迁移：假设复制一个KVcache是0.5ms，计算一个KVcache是1ms。现在已经有了100个KVcache，一边算一边复制迁移，当源实例计算到第200个KVcache的时候，目标实例上也有199个KVcache了。然后要真正进行停等的KVcache就只有第200个这一个了，等待第200个计算完毕，复制迁移即可。

为了保证迁移的可靠性，Llumnix设计了一套handshake机制。