使用 llm-d 进行智能推理调度
llm-d 项目为任何想在现有部署框架（Kubernetes）中采用领先推理优化的用户规划了清晰的“明径”。这些是经过测试的方法，旨在使复杂的部署更简单、更高效。在这篇文章中，我们探讨第一条路径：智能推理调度。与基础的轮询负载均衡不同，此方法考虑了 LLM 的独特需求，从而带来全面的性能提升：更高的吞吐量、更低的延迟以及资源的高效利用。
为什么 LLM 推理需要智能推理
在 Kubernetes 上部署大语言模型 (LLM) 已成为常态，但 LLM 推理工作负载的行为与标准微服务截然不同。传统的统一副本配合轮询负载均衡模式假设每个请求使用相同的资源并在大致相同的时间内完成。相比之下，LLM 请求的 token 数量和计算需求差异巨大，使得简单的负载分配策略容易产生瓶颈和流量不平衡。
LLM 推理流水线包含两个截然不同的阶段：计算密集型的预填充（prefill）阶段和显存带宽密集型的解码（decode）阶段，两者具有根本不同的资源特征。如果不进行专门化处理，每个副本都必须同时处理这两个阶段，从而导致 GPU 周期或显存带宽的浪费。同时，许多 LLM 使用场景涉及多轮对话或智能体流（agentic flows），如果请求能路由回同一个实例，缓存的查询前缀计算将显著缩短响应时间。
除了这些挑战，LLM 端点通常还要服务于各种服务质量（QoS）需求。像代码补全这样的交互式任务要求毫秒级的延迟，聊天机器人可以容忍几秒钟，而批处理任务可能需要几分钟或更长时间。如果对每个 Pod 都一视同仁，那么为昂贵的推理调用满足严苛的延迟服务水平目标（SLO）将变得极其昂贵。
为了应对这些独特的需求，一个既能理解传入请求的特征，又能掌握集群实时状态的智能推理调度器，可以提升吞吐量、大幅降低尾部延迟，并最大化 GPU 资源利用率。
回顾：Kubernetes 中的推理服务、Gateway API 以及推理网关扩展
Kubernetes Service 配合 Deployment 以及标准负载均衡可以将流量均匀地分配到相同的副本中。这种模型非常适合请求统一且生命周期短的无状态微服务。但正如我们之前所见，LLM 推理调用的计算强度差异巨大，且受益于状态路由（例如前缀缓存），并要求严格控制尾部延迟——这些都是原生负载均衡无法很好处理的。
Gateway API 通过提供基于 CRD 的 L7 路由框架，取代并扩展了传统的 Ingress，从而实现了 Kubernetes 网络现代化。它为您提供精细的路由定义、可插拔的数据平面，以及与多集群或跨团队路由策略的天然兼容性。然而，Gateway API 自身缺乏基于推理特定特征和指标的 LLM 推理服务概念。
为了弥合这一差距，Gateway API Inference Extension 项目引入了推理网关（IGW）。IGW 复用了 Gateway API 的核心原语，但增加了新的 CRD——最显著的是 InferencePool——用以表示模型服务 Pod 的集合。InferencePool 可以携带额外的元数据，如基础模型、加速器类型和运行时能力。随后，网关调用可插拔的 EndpointPicker (EPP) 来执行“智能”负载均衡，利用 Envoy 的外部处理（ext-proc）将流量引导至正确的推理端点。
IGW 中的默认 EPP 为每个传入请求遵循结构化的调度周期：
- 端点发现： 枚举所有 InferencePool Pod 并收集其元数据（等待队列状态、已加载模型、缓存内容等）。
- 过滤： 排除因过载、资源不兼容或内存压力而无法处理请求的 Pod。
- 打分： 通过可扩展的打分器为每个剩余的 Pod 分配分数——评估队列深度、会话亲和性、前缀缓存命中和自定义 SLO 指标等因素。
- 选择： 选择合适的端点，并内置冲突解决和降级逻辑。
基于 IGW 的基础，llm-d 通过更先进的调度能力增强了 EPP。它引入了针对 KV 缓存局部性进行优化的打分器（提高前缀缓存命中率），并协调多个调度阶段，将预填充和解码阶段解耦到专门的 Pod 变体上。其结果是一个完全感知 LLM 的调度器，能够全面提升吞吐量、降低尾部延迟并实现更精细的资源效率。
使用 llm-d 进行智能推理调度
llm-d 的一个核心优势是能够将可配置的、感知 AI 的打分器插入推理网关调度流水线。这些打分器超越了通用的负载均衡，在决定每个请求应在何处运行时，会考虑 LLM 特有的工作负载特征，如 Token 数量的可变性、计算/内存阶段的差异以及 KV 缓存局部性。
LLM 工作负载并非千篇一律。某些用例——如多轮对话、RAG 流水线或智能体流——自然会导致高前缀重用，即请求会反复共享 Prompt 的大部分内容。而其他用例，如多样化的批量推理任务或单次补全，则表现出低前缀共享，缓存命中极少，每个请求基本上都是唯一的。
由于这种多样性，llm-d 可插拔、感知 AI 的打分器允许运营商根据工作负载特征定制调度策略。我们评估了两种配置：
- 仅前缀（Prefix-only）打分器 – 路由以最大化 KV 缓存命中。
- 前缀 + 负载（Prefix + Load）打分器 – 在利用缓存机会的同时增加动态负载感知。
为什么感知 AI 的打分器更胜一筹
以下基准测试显示了当缓存机会极少时的性能演变，并说明了一个重要观点：最佳调度策略取决于工作负载特征。
高前缀共享工作负载
当缓存局部性充足时，结果非常显著：
-
成功率： 仅前缀打分器频繁导致副本过载，仅在约 55% 的请求中取得成功，而“前缀 + 负载”打分器在所有 QPS 水平下均保持了 100% 的成功率。
-
首个 Token 时间 (TTFT)： “前缀 + 负载”打分器使 TTFT 始终保持在接近零的水平，而“仅前缀”打分器则迅速恶化，在高 QPS 下超过了 140 秒。
-
Token 间延迟 (ITL)： “前缀 + 负载”打分器实现了约 30ms 的 ITL，而“仅前缀”打分器约为 160ms——响应速度提升了 5 倍以上。
-
吞吐量： “前缀 + 负载”打分器随 QPS 线性增长，在 20 QPS 时达到约 60k tokens/sec。“仅前缀”打分器则停滞在 2k–3k tokens/sec 附近。
吞吐量 vs 请求速率
成功率
TTFT 和 QPS
Token 间延迟
在具有大量前缀重用的工作负载中，前缀感知调度结合负载感知对于避免瓶颈和最大化 GPU 利用率至关重要。通过将前缀评分与负载感知相结合，llm-d 实现了 100% 的请求成功率、更低的延迟和线性的吞吐量扩展——这正是智能、感知 AI 调度的本质所在。
低前缀共享工作负载
当缓存命中极少时，前缀感知的收益微乎其微，两种打分器的表现相似：
吞吐量： 两种打分器的表现几乎完全相同，随 QPS 线性扩展。在 20 QPS 时，两种策略的输出吞吐量均达到约 400 tokens/sec，总吞吐量约为 60k tokens/sec。
延迟
-
首个 Token 时间 (TTFT)： 随着负载增加，两者均稳定在 300–380 ms 范围内。存在细微差异，但没有哪个打分器表现出明显优势。
-
归一化每 Token 时间： 稳定在 0.65 ms/token 左右，两种打分器在各个 QPS 水平上紧密重叠。
-
Token 间延迟 (ITL)： 随负载线性增加，从 2 QPS 时的约 25 ms 增加到 20 QPS 时的约 50 ms——同样，打分器之间没有显著差距。
可靠性
两种打分器在整个负载范围内均实现了 100% 的成功率，这证实了当前缀重用率较低时，仅靠负载均衡就足够了。
在低前缀共享的工作负载下，前缀感知路由的好处自然会减弱。在这种情况下，增加负载感知或前缀感知的区别不大——两种策略都能平稳扩展并满足延迟目标。
结论
这些基准测试说明了为什么 llm-d 中的可配置打分器至关重要。
-
在高前缀工作负载中，“前缀 + 负载”打分确保了在不使副本过载的情况下利用缓存命中——从而实现线性的吞吐量扩展、低延迟和高成功率。
-
在低前缀工作负载中，简单的负载均衡即可满足需求，系统避免了不必要的复杂性。
这种适应性意味着运营商可以根据工作负载特征选择（或组合）打分器，在始终满足延迟和吞吐量 SLO 的同时，实现最佳的单 Token 成本效率。
展望未来：路线图与未来计划
IGW 和 llm-d 项目正在迅速发展，未来有几个令人兴奋的方向：
- 动态调度目标：支持根据工作负载类型、延迟目标或用户定义的策略对调度策略进行运行时重新配置。
- 多模型感知：增强路由逻辑，考虑模型兼容性、适配器堆叠（adapter stacking）和集成推理（下篇博文内容）。
- 插件生态系统：一套针对常见 LLM 用例的由社区贡献的可复用插件。我们正在考虑支持用任何语言编写的进程外插件，以便研究人员实验新的调度算法和想法——如果您有任何可以帮助实现的想法，请告诉我们！
结语
llm-d 的历程反映了我们对 LLM 推理思考方式的更广泛转变——不仅仅是将其视为一个无状态的函数调用，而是一个动态的、资源感知的编排问题。通过在 IGW 之上构建并扩展其边界，llm-d 为大规模智能调度提供了一个灵活、可扩展的基础。
无论您是运行单个模型还是运行一组微调过的变体，目标都是相同的：最大化性能、最小化延迟，并更智能地利用现有计算资源。
参与 llm-d 项目
llm-d 项目的繁荣离不开社区的贡献，有很多方式可以参与进来：