推理调度器(Inference Scheduler)调研报告
推理调度器(Inference Scheduler)调研报告
当前主流推理调度方案可分为三层:引擎层调度(vLLM continuous batching、TensorRT-LLM in-flight batching)、集群层调度(Kthena、AIBrix、llm-d、KServe 等 K8s 原生方案)、路由层调度(KV Cache/Prefix 感知的请求级路由),而云厂商普遍采取"引擎层优化 + 集群层自研 + 路由层智能化"的组合策略。推理调度的核心矛盾已从训练场景的"资源凑齐"(Gang 调度)转向推理场景的"延迟-吞吐-SLO-成本四方权衡",KV Cache 感知路由和 PD 分离(Prefill-Decode disaggregation)成为当前最活跃的技术竞争点。
一、推理调度与训练调度的本质差异
训练调度的核心是资源分配问题:用 Gang 调度保证分布式作业的所有 Worker 同时启动,用拓扑感知减少通信开销,调度粒度是"作业级",一次决策影响整个训练过程。
推理调度的核心则是请求级实时决策问题,两者差异体现在:
| 维度 | 训练调度 | 推理调度 |
|---|---|---|
| 调度粒度 | 作业/任务级,一次调度 | 请求级,每个 Token/请求都可能触发决策 |
| 核心目标 | 作业吞吐、集群利用率 | TTFT(首 Token 延迟)、TPOT(每 Token 延迟)、SLO 达成率 |
| 资源特性 | 静态可预估 | KV Cache 动态变化,显存占用随上下文增长 |
| 批处理模式 | 静态 batch | Continuous batching(动态增删请求) |
| 典型死锁 | 资源不足导致 Gang 失败 | ITL(Inter-Token Latency)被慢请求阻塞 |
这解释了为什么训练调度器无法直接用于推理:kube-scheduler 只决定"Pod 放哪个节点",而推理需要在 Pod 内部继续决策"请求进哪个 batch、请求发给哪个实例、Prefill 和 Decode 是否分开处理"。
二、主流开源推理调度器对比
| 方案 | 归属/背景 | 核心机制 | PD 分离 | KV Cache/Prefix 感知 | 弹性伸缩 | 适用场景 |
|---|---|---|---|---|---|---|
| Kthena | Volcano 子项目(华为云主导) | ModelServing/ServingGroup/Role 分层架构 + Router 组件 | 原生支持,独立扩缩 P/D 比例 | KV Cache Awareness + Prefix Cache + LoRA Affinity 多算法 | 成本驱动(同构/异构) | K8s 生产级 LLM 服务化,多模型多引擎 |
| AIBrix | vllm-project(字节跳动开发) | Kubernetes 粗粒度 + Ray 细粒度混合编排 | 支持 | 分布式 KV Cache,吞吐 +50%、延迟 -70% | LLM App 定制化 Autoscaler(基于请求延迟 SLO) | vLLM 大规模集群,LoRA 多租户高密度 |
| llm-d | CNCF Sandbox(IBM/RedHat/Google/CoreWeave/NVIDIA 联合) | Gateway API Inference Extension + CRD | 一等公民支持,基于 NIXL-UCCL 传输 | kvcache.Indexer 实时追踪 block-locality,sub-ms 级查找 | 通过 Inference Extension | 与 KServe 协同的分阶段推理 |
| NVIDIA Dynamo | NVIDIA | 位于 vLLM 之上的编排层 | 支持,Worker 间 KV Cache 传输 | 估算 prefill/decode 成本 + KV 重叠 + 活跃块综合决策 | 多层 | GPU 硬件深度优化,与 NIM Operator 结合 |
| KServe | CNCF(原 KFServing + Knative 演化) | InferenceService CRD + KPA | 不原生支持(需配合 llm-d) | 不感知(需外部组件) | 基于并发/GPU 指标的 scale-to-zero | 通用 ML 模型服务化,中小规模 |
| SGLang Router | SGLang 项目 | Rust 实现的 router | 支持 DP-aware 路由 | Radix Tree 追踪 prefix 局部性 + 队列长度动态切换策略 | - | SGLang 引擎专用,单实例多 DP 场景 |
| Kueue | kubernetes-sigs | 作业级队列管理 | 不支持 | 不感知 | 与 Cluster Autoscaler 协同(需配合 ProvisionRequest 实现 gang autoscaling) | 批量推理作业,而非实时服务 |
值得注意的是,KServe 与 llm-d 已明确分工:KServe 负责 InferenceService 抽象、autoscaling、scale-to-zero 等通用能力,llm-d 专注 KV Cache 路由、PD 分离、SLO 感知等 LLM 特有调度,两者形成互补而非竞争关系。
三、Kthena 深度解析
Kthena 于 2026 年 1 月作为 Volcano 子项目正式发布,定位为"云原生推理的智能大脑"——不替代 vLLM/SGLang 等推理引擎,而是在其上做编排调度层。从模型服务平台演进视角看 Kthena 与 KServe 的分工差异,见同日另一篇 从 KServe 到 Kthena:云原生模型服务平台的技术演进。
架构分两大组件:
- Kthena Router:高性能多模型路由器,作为所有推理请求的入口,基于 ModelRoute 规则分发流量。原生支持 Gateway API 和 Inference Extension,无需额外部署 Envoy Gateway。
- Kthena Controller Manager:控制面,reconcile ModelBooster/ModelServing/AutoScalingPolicy 等 CRD,负责 ServingGroup 编排、P/D 角色拓扑亲和、Gang 调度、滚动更新与故障恢复。
核心设计是分层工作负载架构(ModelServing → ServingGroup → Role):一个 PD 分离部署可以管理为单一 ModelServing 资源,内含多个 ServingGroup 分别对应 Prefill 和 Decode 角色,实现统一声明式管理。
关键调度能力:
- PD 原生分离:将计算密集的 Prefill 路由到高算力节点、内存受限的 Decode 路由到高 HBM 节点,P/D 比例可独立弹性调整。
- 可插拔路由算法:Least Request、Least Latency、KV Cache Awareness、Prefix Cache Awareness、LoRA Affinity、Fairness Scheduling,支持按模型粒度配置策略。
- 多引擎抽象:通过统一 API 支持 vLLM、SGLang、Triton、TGI,并支持 GPU/NPU 异构共存。
- 成本驱动伸缩:同构场景基于业务指标精确伸缩,异构场景基于"成本-性能"比优化资源分配。
性能数据(4096 token 长 system prompt 场景):KV Cache Awareness + Least Request 组合相比 Random 基线,吞吐提升约 2.73 倍,TTFT 降低 73.5%,端到端延迟降低超 60%。
vLLM 官方文档已收录 Kthena 集成指南,用于部署多节点 vLLM 服务,进一步验证了其与主流引擎的兼容性。
四、llm-d:同类项目中的差异化设计
llm-d 于 2026 年 3 月捐赠给 CNCF 并进入 Sandbox,其独特价值在于作为**“一等 K8s 公民”**使用标准 CRD 和 Gateway API Inference Extension 构建,与 NVIDIA Dynamo(K8s 外部的编排层)形成鲜明对比。
核心组件采用事件驱动架构:
- kvevents.Pool:通过分片 ZMQ worker pool 实时摄取 vLLM Pod 的 KV cache 事件。
- kvblock.Index:将 block hash 映射到 Pod 的内存两级 LRU 缓存,实现亚毫秒级查找。
- tokenization.PrefixStore:LRU 缓存 tokenized prompt 前缀,避免重复分词开销。
- kvblock.Scorer:基于最长连续前缀匹配策略对 Pod 打分。
读路径设计:当请求到达时,Router 查询 Indexer 获取各 Pod 的 KV cache 命中情况,选择命中率最高(或综合评分最优)的 Pod 转发,最大化前缀复用、最小化重复计算。
v0.5 新增的 NIXL-UCCL 后端解决了 PD 分离架构中的尾延迟问题:KV cache 在 prefill 和 decode 节点间传输时,采用 host-resident 软件传输栈实现细粒度流分裂和自适应拥塞控制,支持原生 RDMA 和 GPUDirect TCP-X 传输。
五、云厂商与引擎厂商的自研方案
腾讯云:FlexKV + TACO + qGPU 组合拳
腾讯云 TACO 团队的 FlexKV 构建了 GPU → CPU → SSD → 远程存储的四级 KV Cache 缓存体系,可用缓存容量最高扩展至 GPU 显存的 100 倍以上。基于分布式 RadixTree 实现 KV Cache 跨节点统一索引与共享,无需中心化组件。2026 年 4 月 FlexKV 正式合入 NVIDIA Dynamo、vLLM、TensorRT-LLM 三大主流框架官方主线,成为其官方 KV Cache 卸载方案。
配合 qGPU 的算力最小 5% 切分、显存最小 1GiB 切分,以及"如意"在离线混部(CPU 利用率从 15% 提升至 45%),腾讯在 TKE 上形成了推理专属的调度技术栈。
华为云:Kthena + xDeepServe
除 Kthena 外,华为在 CloudMatrix384 超节点上的 xDeepServe 采用 request-job-task 的 serverless 抽象,支持 PD 分离和 PD 共置两种部署模式,通过 pre-warmed pods、DRAM preloading、NPU fork 实现秒级弹性(64 实例扩展),在 NPU-centric 架构上支撑大规模推理。
NVIDIA:Dynamo 的跨引擎编排
Dynamo 的请求路由同时估算 prefill 和 decode 成本,综合考虑 KV cache 重叠、活跃 decode 块、工作负载位置等因素,是引擎层调度的代表。它与 KServe、Kueue 组合形成"批量推理 + 实时推理 + 弹性伸缩"的完整 K8s GenAI 工作流,Red Hat 已发布组合评估报告。
六、演进脉络与未来方向
推理调度的演进呈现清晰的五阶段路径:
- K8s 原生基础(KServe/Knative):解决通用模型服务化,提供 scale-to-zero。
- 自研引擎层(TACO-LLM、TGI、TensorRT-LLM):continuous batching、PagedAttention 优化单实例性能。
- PD 分离架构(Kthena、llm-d、Dynamo):计算与内存解耦,独立伸缩。
- KV Cache/Prefix 感知路由:全局缓存视图 + 智能路由,Prefix 复用降低 TTFT。
- SLO 感知 + Serverless 化:以 SLO 达成率和成本最优为目标的动态调度(如腾讯 TI 潮汐调度夜间释放推理资源给离线训练,集群利用率从 30% 提升至 90%)。
学术前沿方向包括:
- TokenLake(北大 + 阶跃星辰):统一 segment 级 prefix cache 池,将缓存管理从调度器中解耦,解决负载不均、数据冗余、内存碎片三大问题。
- CPD(Cache-aware Prefill-Decode disaggregation,Together AI):增加 pre-prefill 层专门处理冷请求,避免冷 prefill 阻塞可复用上下文的快路径。
- LMCache:支持跨引擎/GPU 的缓存卸载与 PD 分离传输。
七、选型建议
不同场景的推荐组合:
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 通用生产部署、多引擎混合 | Kthena | 分层 CRD 设计和多引擎抽象降低运维复杂度 |
| vLLM 深度用户、需要 LoRA 多租户 | AIBrix | 字节跳动生产验证,分布式 KV Cache 收益显著 |
| 与 KServe 生态整合、需要标准化 API | KServe + llm-d | KServe 管生命周期、llm-d 管智能路由 |
| 纯 NVIDIA 栈、追求极致性能 | NVIDIA Dynamo + TensorRT-LLM + NIM Operator | 硬件深度优化 |
| 批量推理(非实时服务) | Kueue + JobSet + Cluster Autoscaler | 作业级队列足够 |
| 国产 NPU 环境 | Kthena(GPU/NPU 异构)或 华为 xDeepServe(昇腾深度优化) | NPU 生态适配 |
一个值得关注的趋势:推理调度器与 Gateway API Inference Extension 的标准化融合正在加速——Kthena v0.5+ 已支持 Inference Extension,llm-d 基于其构建,这预示着未来 K8s 生态可能出现统一的推理调度 API 标准,类似 Batch Job 的标准化进程。