2.8x
推理吞吐提升
-60%
P99延迟降低
+3.2x
显存利用率
vLLM
推理框架
研究背景与动机
大语言模型(LLM)的推理服务呈现出与传统的在线服务截然不同的负载特征:每个请求具有高度可变的输入/输出长度、推理过程是自回归的(每个Token的生成依赖之前所有Token)、KV-Cache的显存占用随序列长度线性增长。这些特征使得传统的请求级调度策略(如轮询、最少连接)在LLM推理场景中表现不佳——它们无法利用连续批处理(Continuous Batching)的吞吐优势,也无法有效管理显存碎片化问题。更根本的挑战在于,LLM推理的「内存墙」问题——计算能力以每年约3.2倍的速度增长(得益于Tensor Core等专用硬件),而显存带宽的年增长率仅为1.3倍,这一剪刀差意味着推理吞吐将越来越受限于显存带宽而非计算能力。
本项目的核心目标是:在vLLM推理框架上,设计并实现一种基于连续批处理与KV-Cache感知的请求调度算法,同时探索显存碎片整理机制,以最大化推理吞吐并控制尾部延迟。项目还进一步探索了多模型实例的协同调度与基于优先级的服务质量保障机制。
技术栈
- vLLM
- CUDA
- Ray Serve
- PagedAttention
- PyTorch
- NCCL
- Triton
- Prometheus
核心技术贡献
- KV-Cache感知的自适应批大小调度 — vLLM的PagedAttention机制将KV-Cache分割为固定大小的Block,使得多个请求可以共享显存空间。我们在此基础上设计了基于显存水位线的自适应批大小策略:调度器维护一个显存预算(GPU Memory Budget),每次调度决策时,根据当前空闲Block数量与每个候选请求的预期序列长度,动态计算可容纳的最大批大小。与传统固定批大小的策略相比,自适应策略将显存利用率提升了3.2倍,减少了因显存不足导致的请求排队延迟。
- 显存碎片整理与Block迁移 — 在长时间运行的推理服务中,KV-Cache Block的频繁分配与释放会导致显存碎片化——虽然总空闲Block数充足,但缺乏连续的大块显存来容纳长序列请求。我们设计了一种在线的显存碎片整理机制:通过CUDA的异步内存拷贝,在GPU空闲间隙将分散的Block迁移到连续的显存区域,实现显存的紧凑化。碎片整理的平均开销控制在推理吞吐的3%以内,但将因碎片导致的请求拒绝率从8.7%降至0.3%。
- 请求优先级与抢占式调度 — 针对在线服务场景中延迟敏感请求(如交互式对话)与吞吐优先请求(如批量评估)混合的特点,设计了基于优先级的抢占式调度策略。延迟敏感请求被赋予高优先级,可在必要时抢占正在执行的吞吐优先请求的GPU资源——被抢占请求的KV-Cache保留在显存中,待高优先级请求完成后恢复执行。该策略将高优先级请求的P99延迟从1.8s降至720ms。
- 多模型实例的负载均衡 — 在Ray Serve分布式推理框架上,实现了基于模型实例负载热度的请求路由策略。每个模型实例定期上报其显存使用率、批处理队列长度和平均Token生成速率,路由器使用加权最少连接(Weighted Least Connections)算法分配新请求。当检测到某个实例过载时,自动触发Ray Serve的弹性伸缩机制启动新实例。
- 推理性能剖析与优化 — 使用NVIDIA Nsight Systems与PyTorch Profiler对vLLM推理流水线进行了详尽的性能剖析。发现两个关键瓶颈:(1) Attention Kernel的Launch Overhead——在批大小较大时,每个Attention Head的Kernel Launch累积开销占比达到12%;(2) KV-Cache Block Table的查找开销——在长序列场景下,Block Table的随机访问模式导致L2 Cache Miss率升高。针对前者,通过Kernel Fusion减少了Launch次数;针对后者,通过Block Table的预取优化提升了Cache命中率。综合优化将推理吞吐从基线提升2.8倍。
系统架构
调度器架构:调度器作为vLLM的插件运行在AsyncLLMEngine内部,在每次推理Step之前被调用。调度器读取当前显存状态、各请求的KV-Cache占用情况、以及请求优先级队列,输出本Step应处理的Token批次。调度决策的耗时控制在100μs以内,不成为推理流水线的瓶颈。
可观测性:集成Prometheus采集调度器关键指标——批大小分布、显存碎片率、请求排队延迟、抢占频率、KV-Cache命中率等。Grafana仪表盘提供实时的调度状态可视化,支持按模型、按请求优先级维度的下钻分析。