介绍 Gateway API 推理扩展

作者：Daneyon Hansen (Solo.io), Kaushik Mitra (Google), Jiaxin Shan (Bytedance), Kellen Swain (Google) |

现代生成式 AI 和大语言模型（LLM）服务在 Kubernetes 上带来了独特的流量路由挑战。与典型的短时、无状态 Web 请求不同，LLM 推理会话通常是长时间运行、资源密集且部分有状态的。例如，单个由 GPU 支持的模型服务器可能会保持多个推理会话活跃，并维护内存中的 Token 缓存。

专注于 HTTP 路径或轮询的传统负载均衡器缺乏处理这些工作负载所需的专业能力。它们也没有考虑模型标识或请求的关键性（例如，交互式聊天与批处理作业）。组织通常会拼凑临时解决方案，但缺少一种标准化的方法。

Gateway API 推理扩展

Gateway API Inference Extension 的创建旨在填补这一空白，它建立在现有的 Gateway API 之上，增加了推理专用的路由功能，同时保留了熟悉的 Gateways 和 HTTPRoutes 模型。通过在你现有的网关上添加一个推理扩展，你可以有效地将其转变为一个 Inference Gateway（推理网关），从而能够以“模型即服务”的理念自托管 GenAI/LLM。

该项目的目标是改进和标准化整个生态系统中针对推理工作负载的路由。关键目标包括实现模型感知路由、支持按请求区分关键性、促进安全的模型发布，以及根据实时模型指标优化负载均衡。通过实现这些目标，该项目旨在降低 AI 工作负载的延迟并提高加速器（GPU）的利用率。

工作原理

该设计引入了两个新的自定义资源（CRD），它们具有不同的职责，每个都与 AI/ML 服务工作流中的特定用户角色相对应：

Resource Model

  1. InferencePool 定义了一个在共享计算资源（例如 GPU 节点）上运行的 Pod 池（模型服务器）。平台管理员可以配置这些 Pod 的部署、扩展和均衡方式。InferencePool 确保资源使用的一致性，并执行平台范围的策略。InferencePool 类似于 Service，但专门针对 AI/ML 服务需求，并能感知模型服务协议。

  2. InferenceModel 一个由 AI/ML 所有者管理的面向用户的模型端点。它将一个公共名称（例如 "gpt-4-chat"）映射到 InferencePool 中的实际模型。这使得工作负载所有者可以指定他们想要服务的模型（以及可选的微调），以及流量切分或优先级策略。

总而言之，InferenceModel API 让 AI/ML 所有者管理**提供什么服务**，而 InferencePool 让平台操作员管理**在哪里以及如何提供服务**。

请求流程

请求流程建立在 Gateway API 模型（Gateways 和 HTTPRoutes）之上，中间增加了一个或多个额外的推理感知步骤（扩展）。以下是使用端点选择扩展（Endpoint Selection Extension, ESE）的请求流程的高级示例：

Request Flow

  1. 网关路由
    客户端发送一个请求（例如，一个到 /completions 的 HTTP POST 请求）。网关（如 Envoy）检查 HTTPRoute 并识别匹配的 InferencePool 后端。

  2. 端点选择
    网关不是简单地将请求转发到任何可用的 Pod，而是咨询一个特定于推理的路由扩展——端点选择扩展——来选择可用的最佳 Pod。该扩展会检查实时的 Pod 指标（队列长度、内存使用情况、已加载的适配器）以选择最适合该请求的 Pod。

  3. 推理感知调度
    被选中的 Pod 是那个在给定用户关键性或资源需求的情况下，能够以最低延迟或最高效率处理请求的 Pod。然后，网关将流量转发到该特定的 Pod。

Endpoint Extension Scheduling

这个额外的步骤提供了一种更智能、模型感知的路由机制，对客户端来说仍然感觉像一个正常的单次请求。此外，该设计是可扩展的——任何 Inference Gateway 都可以通过额外的推理专用扩展来增强，以处理新的路由策略、高级调度逻辑或专门的硬件需求。随着项目的不断发展，我们鼓励贡献者开发与相同底层 Gateway API 模型完全兼容的新扩展，从而进一步扩展高效和智能 GenAI/LLM 路由的可能性。

基准测试

我们针对一个基于 vLLM 的模型服务部署，将此扩展与标准的 Kubernetes Service 进行了评估。测试环境由多个运行 vLLM（版本 1）的 H100 (80 GB) GPU Pod 组成，部署在一个 Kubernetes 集群上，包含 10 个 Llama2 模型副本。我们使用 延迟概况生成器（Latency Profile Generator, LPG）工具生成流量并测量吞吐量、延迟和其他指标。ShareGPT 数据集用作工作负载，流量从每秒 100 次查询 (QPS) 逐步增加到 1000 QPS。

关键结果

Endpoint Extension Scheduling

  • 相当的吞吐量：在测试的 QPS 范围内，ESE 提供的吞吐量与标准的 Kubernetes Service 大致相当。

  • 更低的延迟:

    • 每个输出 Token 的延迟：ESE 在更高的 QPS（500+）下显示出显著更低的 p90 延迟，这表明其模型感知路由决策在 GPU 内存接近饱和时减少了排队和资源争用。
    • 整体 p90 延迟：出现了类似的趋势，与基线相比，ESE 降低了端到端的尾延迟，尤其是在流量增加到 400-500 QPS 之后。

这些结果表明，该扩展的模型感知路由显著降低了由 GPU 支持的 LLM 工作负载的延迟。通过动态选择负载最轻或性能最佳的模型服务器，它避免了在使用传统负载均衡方法处理大型、长时间运行的推理请求时可能出现的热点问题。

路线图

随着 Gateway API Inference Extension 迈向正式发布（GA），计划中的功能包括：

  1. 针对远程缓存的前缀缓存感知负载均衡
  2. 用于自动化发布的 LoRA 适配器流水线
  3. 同一关键性级别内工作负载之间的公平性和优先级
  4. 支持 HPA，可根据聚合的、每个模型的指标进行扩展
  5. 支持大型多模态输入/输出
  6. 额外的模型类型（例如，扩散模型）
  7. 异构加速器（在多种加速器类型上提供服务，并进行延迟和成本感知的负载均衡）
  8. 用于独立扩展池的解耦服务

总结

通过将模型服务与 Kubernetes 原生工具对齐，Gateway API Inference Extension 旨在简化和标准化 AI/ML 流量的路由方式。凭借模型感知路由、基于关键性的优先级划分等功能，它帮助运维团队平稳高效地向正确的用户提供正确的 LLM 服务。

准备好了解更多信息了吗？ 访问项目文档深入了解，通过几个简单步骤尝试一下 Inference Gateway 扩展，如果您有兴趣为项目做贡献，欢迎参与其中！