推理网关与负载均衡

摘要：本文面向需要把多个 LLM 推理后端统一暴露、并解决"轮询负载均衡对 LLM 是灾难"这一问题的平台工程师。讲解 Kubernetes Gateway API Inference Extension 的核心资源（InferencePool/InferenceModel/EPP），给出基于 Envoy Gateway 的部署示例、模型感知路由与限流，以及排障与安全。适用版本：Gateway API v1.1+，Inference Extension（[版本相关：CRD 为 inference.networking.x-k8s.io/v1alpha1，部分实现已演进到 /v1，以集群实际 CRD 为准]）。

适用版本与前提

Kubernetes：v1.28+，且集群已安装 Gateway API CRD（gateway.networking.k8s.io/v1）
一个支持 Inference Extension 的 Gateway 实现：Envoy Gateway、Istio（GAMMA）、NGINX Gateway Fabric 之一
后端已有 OpenAI 兼容推理服务（如 KServe+vLLM，见 kserve.md）

核心概念：为什么传统 Ingress 不适合 LLM

传统 Ingress / LoadBalancer 用轮询或最少连接，假设"每个请求成本相近"。但 LLM 推理分两阶段：

Prefill：编码输入，成本随输入长度增长；
Decoding：逐 token 生成，成本随输出长度增长。

一个 4k token 的 completion 与一个单词回答，算力可差百倍。轮询会把重请求都堆到同一张 GPU，造成热点与长尾延迟。Gateway API Inference Extension 的解决思路：

资源	作用
`InferencePool`	一组服务同模型的 Pod，作为路由目标，并引用 EPP
`InferenceModel`	把逻辑模型名映射到某 Pool，并设优先级（criticality）
`EPP`	端点选择器：用队列深度、KV Cache 利用率、前缀缓存亲和等插件打分，选出最优后端
`HTTPRoute`	标准 Gateway API 资源，`backendRef` 指向 `InferencePool`

生产实践 1：安装 Inference Extension 与 Envoy Gateway

bash

# 1. 安装 Gateway API CRD（若集群尚未安装）
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

# 2. 安装 Inference Extension CRD 与控制器
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/latest/download/manifests.yaml

# 3. 安装 Envoy Gateway（支持 InferencePool 的数据面）
helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.1.0 -n envoy-gateway --create-namespace

版本与实现差异

上述 URL/版本为示意。Inference Extension 仍在快速演进：CRD 组名在文档中可见 inference.networking.x-k8s.io（v1alpha1）与 inference.networking.k8s.io（v1）两种写法；请先 kubectl get crd | grep inference 确认你集群里的实际名称，再写 YAML。各 Gateway 实现对该扩展的支持程度不同，部署前查对应 conformance 报告。[版本相关 / 未实测]

生产实践 2：定义 InferencePool 与 InferenceModel

yaml

# inference-pool.yaml
apiVersion: inference.networking.x-k8s.io/v1alpha1   # [版本相关]
kind: InferencePool
metadata:
  name: qwen-pool
  namespace: models
spec:
  selector:
    app: qwen-inference
  targetPortNumber: 8000
  extensionRef:
    name: qwen-endpoint-picker
---
apiVersion: inference.networking.x-k8s.io/v1alpha1   # [版本相关]
kind: InferenceModel
metadata:
  name: qwen-7b
  namespace: models
spec:
  modelName: Qwen2.5-7B-Instruct
  poolRef:
    name: qwen-pool
  criticality: Standard

后端 Pod 需暴露 Prometheus 指标（EPP 依赖）：TotalQueuedRequests、TotalRunningRequests、KVCacheUtilization（指标名随运行时版本变化，[版本相关]）。vLLM 与 KServe 前缀缓存亲和需后端支持对应插件。

生产实践 3：用 HTTPRoute 把流量导给 Pool

yaml

# llm-route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-route
  namespace: models
spec:
  parentRefs:
    - name: inference-gateway
      namespace: envoy-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - group: inference.networking.x-k8s.io   # [版本相关]
          kind: InferencePool
          name: qwen-pool

客户端直接按 OpenAI 协议调用，由 Body-Based Routing（BBR）从请求体提取 model 字段做模型感知路由：

bash

curl http://<gateway-address>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"你好"}]}'

多模型共享 GPU 池

通过多个 InferenceModel 指向同一 InferencePool，并设不同 criticality，延迟敏感的聊天流量可抢占尽力而为的批处理流量（需 EPP 启用对应 scorer 插件）。这比"每模型一个独立 Deployment"显著省 GPU。

验证

bash

# 确认 CRD 与控制器已就绪
kubectl get crd | grep inference.networking
kubectl get pods -n inference-extension-system

# 确认 InferencePool / InferenceModel 已 Accepted
kubectl get inferencepool -n models
kubectl get inferencemodel -n models

# 压测观察：EPP 应把请求导向 KV Cache 余量最大的后端
# 指标端口与面板以实际部署为准（[未实测具体指标名]）

回滚与清理

bash

# 移除路由即停止对外暴露（不删除后端推理服务）
kubectl delete httproute llm-route -n models
# 彻底清理扩展
kubectl delete -f inference-pool.yaml

网关变更影响面

推理网关是所有 LLM 流量的统一入口，删除 HTTPRoute/InferencePool 会立即中断相关模型的全部调用。变更前评估受影响业务，灰度用独立 parentRef Gateway。

故障排查

现象	原因	排查
路由报 404/未命中 Pool	`backendRef.group` 写错或 Gateway 未启用扩展	`kubectl describe gateway` 看是否支持 inference 组
请求全打到同一后端	EPP 未拿到后端指标	查 EPP 日志 + 后端 `/metrics` 是否暴露 queued/running/KVcache
model 名路由错乱	BBR 未启用或 JSON 体不含 `model`	确认 BBR 处理器已挂载；请求体字段为 OpenAI 协议 `model`
延迟反而更高	EPP 打分插件配置不当	先退回普通 Service 路由对比基线，再调插件

安全与合规

网关是越权与成本失控的高危面

认证与 WAF：推理网关直接面向业务，必须启用 TLS 与认证（mTLS / oauth2-proxy），并对 /v1/chat/completions 启用 WAF，防止提示词注入与越权调用高价模型。
模型白名单：通过 InferenceModel 显式声明允许暴露的模型名，未注册模型名应被网关拒绝（防止调用未授权模型）。
限流：按 token 而非请求数限流（LLM 请求成本差异百倍）；配合优先级避免低优批处理挤占在线流量。
egress 收敛：网关与后端 Pod 收敛出网，防止通过推理通道外传数据。

成本与性能

收益来源：负载/缓存感知路由提升 GPU 有效利用率，减少热点与排队。第三方经验称合理调度可提升整体吞吐 20–40%（[未实测，取决于负载画像]）。
成本示例（[价格随云厂商/时点变化，未实测]）：同一张 H100（约 2–3 USD/小时）通过多模型共享池 + 智能路由，可比"每模型独占卡"节省 30–50% 卡时。具体需在你自有硬件与真实流量下实测，本文不引用具体 Benchmark。
监控：重点看 TTFT（首 token 延迟）、token/s、各后端 KV Cache 利用率与队列深度；用 Grafana 关联 EPP 决策与后端饱和度。

推理网关与负载均衡 ​

适用版本与前提 ​

核心概念：为什么传统 Ingress 不适合 LLM ​

生产实践 1：安装 Inference Extension 与 Envoy Gateway ​

生产实践 2：定义 InferencePool 与 InferenceModel ​

生产实践 3：用 HTTPRoute 把流量导给 Pool ​

验证 ​

回滚与清理 ​

故障排查 ​

安全与合规 ​

成本与性能 ​

参考资料 ​

推理网关与负载均衡

适用版本与前提

核心概念：为什么传统 Ingress 不适合 LLM

生产实践 1：安装 Inference Extension 与 Envoy Gateway

生产实践 2：定义 InferencePool 与 InferenceModel

生产实践 3：用 HTTPRoute 把流量导给 Pool

验证

回滚与清理

故障排查

安全与合规

成本与性能

参考资料