为何将 llm-d 贡献给 CNCF：实现 AI 未来的标准化发展

今天，我们将 llm-d 作为沙盒项目贡献给云原生计算基金会（CNCF）。

这不仅仅是代码的移交，更是在践行我们的坚定承诺：推动将高性能 AI 服务打造为云原生技术栈中具备核心价值且可移植的能力。我们于 2025 年 5 月推出 llm-d，旨在弥合 AI 实验与大规模任务关键型生产推理之间的巨大能力鸿沟。如今，将 llm-d 纳入 CNCF，我们进一步拓展了多供应商联盟的目标，联合 CoreWeave、IBM、谷歌、英伟达等企业，共同打造分布式推理领域的开放标准。

推理能力赋能代理时代发展

随着我们迈入代理主导的未来，支撑企业级代理广泛应用的 AI 推理技术即将迎来爆发式增长。当务之急是，确保推理的成本与复杂性不会盖过代理本身所带来的商业价值。但是，推理成本可能极为高昂，需要消耗大量专用加速器，而且在规模化应用场景下，成本可能会进一步飙升。llm-d 的高级功能直接解决了这一问题，既能满足企业服务级别目标，又能最大限度地提高基础架构效率。此外，企业组织需要能够灵活地在数据中心、云或边缘等任何合理位置，基于自选硬件部署推理。唯有依托开源技术与开放标准构建底层生态系统，才能实现这种灵活性。

弥合云原生领域的差距

尽管 Kubernetes 已成为编排领域的行业标准，但其最初并非为满足大语言模型（LLM）推理的独特有状态需求而构建。在传统的微服务中，所有请求本质相同，每个副本都可以同等地处理任意请求。而在生成式 AI 场景下，单个请求的处理成本会差异悬殊，主要取决于提示和输出词元长度、模型大小和架构、缓存位置，以及模型是处于预填充（计算密集型）还是解码（内存密集型）阶段。

标准服务路由机制无法感知这些动态差异，从而导致资源分配效率低下且延迟难以预测。而这正是 llm-d 发挥作用、弥合鸿沟之处。它作为专用的数据平面编排层，衔接 KServe 等上层控制平面与 vLLM 等底层引擎。它使用网关 API 和 LeaderWorkerSet（LWS）等 Kubernetes 原生原语，将复杂的分布式推理任务转化可管理、可观测的云原生工作负载。

以开源贡献强化生态系统

通过将 llm-d 贡献给 CNCF，我们将开辟一条标杆路径，依托经过验证、可复制的蓝图，将分散的 AI 组件转变为模块化、可互操作的微服务。这项贡献的意义远超单一项目本身，其核心在于丰富整个云原生环境，使推理与基于容器的传统应用一样，在该环境中享有同等重要的地位。

这项工作的核心部分是端点选取器（EPP）。llm-d 充当 Kubernetes 网关 API 推理扩展（GAIE）的主要实施方案，而 EPP 则支持可编程、具备推理感知能力的路由。这意味着系统会根据引擎的实际状态做出路由决策，并针对 KV 缓存命中率和硬件加速器特征进行优化。这也是在严格的服务级别目标下，维持稳定吞吐量的基本要求。

llm-d 对 CNCF 现有生态形成补充与拓展：

• Kubernetes：为 AI 工作负载提供主要基础架构平台。
• 网关 API：推动 AI 特定路由实现上游统一，确保流量管理始终是核心开放组件。
• KServe：作为与 llm-d 集成的高级控制平面，支持解耦式服务和前缀缓存等高级功能。
• LeaderWorkerSet： 使用 Kubernetes 原生原语来编排复杂的多节点副本和专家并行机制，将 vLLM 等引擎转换为可管理的云原生工作负载。
• Prometheus & Grafana：导出首个词元生成时间（TTFT）等专项指标，为生成式 AI 提供企业级可观测性。

携手开拓推理技术的未来

自 llm-d 诞生之初，协作便一直是其核心理念。去年在红帽全球峰会上宣布推出 llm-d 时，该项目的创始贡献者、行业领导者和学术支持者的通力协作便已成为红帽引以为傲的成果，不仅在于成功推出 llm-d，更在于构建了面向未来的协作基石。此后 10 个月里，llm-d 广泛应用于企业 AI 私有 MaaS 以及大规模 AI 计划。更重要的是，随着贡献者与合作伙伴生态系统的持续壮大，项目的开源根基也在不断深化。开发人员和公司对 llm-d 寄予厚望，而将该项目贡献给 CNCF 将有力支持并守护一个开放的未来。开源 AI 创新的成功之路任重而道远，但我们正携手共建实现这一目标的基础架构。