Inference Gateway 是什么？Kubernetes 模型服务入口为什么需要新能力？

传统 Kubernetes 里，HTTP 流量入口通常由 Ingress 或 Gateway API 处理。它们擅长路径、域名、Header、权重、TLS 等通用能力。但 LLM 推理不是普通 Web 请求，推理入口需要理解模型、endpoint、负载、延迟和缓存。

Kubernetes Gateway API Inference Extension 正在探索这个方向。官方 getting started 文档说明，该项目仍处于 alpha 实验状态，目标是让工程师在 Kubernetes 上部署 Inference Gateway，并结合模型服务器如 vLLM 处理推理流量。

普通网关为什么不够

普通 HTTP 网关通常只能看到请求路径和一些 Header。模型推理还需要关注：

• 请求要发给哪个模型。
• endpoint 是否已经加载模型。
• 当前 GPU 显存和队列是否拥堵。
• 长 prompt 是否会拖慢某个实例。
• 是否可以利用 prefix cache。
• 失败时是否应该重试，重试到哪里。

如果入口完全不理解推理，可能把请求发给一个已经很忙的模型实例，导致整体延迟抖动。

Inference Gateway 可能带来什么

从架构上看，它把模型服务入口从“普通七层转发”升级为“推理感知路由”。

可能关注的对象包括：

• InferencePool：一组可服务推理请求的 endpoint。
• Endpoint Picker Extension：决定请求发往哪个后端。
• HTTPRoute：继续利用 Gateway API 的路由模型。
• InferenceObjective：描述推理目标或优化方向。

对运维来说，重点不是背 API，而是理解入口层会成为 AI 平台的一部分。

运维排查应该看什么

第一，确认 Gateway 和 CRD 是否安装：

kubectl get crd | grep -i inference
kubectl get gateway -A
kubectl get httproute -A

第二，确认模型服务 endpoint：

kubectl get pods,svc -n <namespace>
kubectl logs <model-server-pod> -n <namespace>

第三，确认 InferencePool 状态：

kubectl get inferencepool -A
kubectl describe inferencepool <name> -n <namespace>

第四，压测入口延迟，分开观察首 token 延迟、总响应时间和错误率。

现在应该上生产吗

如果项目仍标记 alpha，就不建议直接作为核心生产入口。更合理的做法是：

• 在测试集群部署。
• 用小模型验证路由和可观测性。
• 比较普通 Gateway、服务内负载均衡、推理网关的延迟差异。
• 关注 API 变化和兼容性。

AI 基础设施发展很快，但生产平台要稳，不要把实验项目直接放到关键链路。

和 llm-d 的关系

llm-d 项目介绍中提到它基于 vLLM 和 Kubernetes Gateway API Inference Extension。可以理解为，Inference Extension 关注推理入口和路由标准化，llm-d 关注更完整的分布式 LLM 推理框架。

这两个方向都说明一件事：Kubernetes 正在从“能跑模型”走向“更懂模型服务”。

常见问题 FAQ

Inference Gateway 是不是 Ingress 的替代品？

不是简单替代。它更关注模型推理场景，可能与 Gateway API 结合，而不是完全抛弃现有入口体系。

普通企业现在需要学吗？

如果计划建设 AI 平台、模型服务或私有推理集群，值得了解。普通业务系统可以先观望。

它为什么重要？

因为推理入口会直接影响 GPU 利用率、请求延迟和用户体验。入口层不懂推理，后端再强也可能被路由拖累。

如何学习最稳？

先学 Gateway API，再学模型服务，再看 Inference Extension。不要跳过基础网络和服务发现。

参考资料

• Kubernetes Gateway API Inference Extension: https://gateway-api-inference-extension.sigs.k8s.io/guides/
• CNCF llm-d 项目页: https://www.cncf.io/projects/llm-d/