不要把 LLM 网关只当反向代理：Kubernetes 推理路由需要模型感知

边界说明：本文基于公开文档和本地配置推演，没有声称在生产 Kubernetes 集群压测过具体性能数字。所有 YAML 是最小设计骨架，落地前必须按所用控制器版本校验 CRD 字段。

核心观点

LLM 推理网关如果只做七层反向代理，很快会失效。传统 HTTP 网关关心路径、Header、TLS、限流和后端健康；推理流量还额外关心模型名称、请求关键度、队列长度、KV cache 命中、上下文窗口、token 预算、GPU 利用率和租户成本。Kubernetes Gateway API Inference Extension 与 Envoy AI Gateway 的共同信号是：AI 平台需要一个模型感知的控制面，而不是把所有请求都塞进普通 Ingress。

这并不意味着“网关里塞满 AI 逻辑”。更合理的边界是：网关负责统一入口、认证、路由、优先级、指标和策略挂载；模型服务负责推理执行；调度器和 autoscaler 负责容量；安全系统负责审计与数据边界。

背景与问题定义

自托管大模型在 Kubernetes 上运行时，流量特征和普通 Web API 不一样：

维度	普通 HTTP 服务	LLM 推理服务
单请求成本	相对稳定	随 prompt、输出 token、上下文窗口剧烈变化
后端容量	CPU/内存/QPS	GPU 显存、并发 batch、KV cache、队列延迟
路由依据	path、host、header	模型、版本、租户、关键度、实时负载
失败体验	4xx/5xx/超时	长尾延迟、流式中断、上下文截断、降级模型
观测指标	RPS、延迟、错误率	TTFT、tokens/s、队列时间、每租户 token 成本

Gateway API Inference Extension 的目标是把推理工作负载的一部分语义带入 Kubernetes 网络模型，例如推理网关、模型服务池和模型感知路由。Envoy AI Gateway 则更偏统一访问层：提供 OpenAI 兼容入口、上游 provider 抽象、认证、限流、可观测性和策略框架。两者不是简单替代关系，更像两层控制面的不同拼图。

控制面关系

图里的关键点是反馈闭环。没有 O -> S -> G2，网关只能按静态规则转发；一旦高优先级请求和批处理请求混在一起，GPU 队列就会把延迟 SLO 拖垮。

工程化设计

1. 先把网关拆成四个职责平面

平面	主要对象	不应承担的职责
接入平面	TLS、认证、租户识别、OpenAI 兼容 API	不在这里写复杂模型调度算法
策略平面	模型白名单、token 预算、数据分类、请求关键度	不直接操作 GPU 资源
路由平面	模型版本、pool 选择、endpoint picker、降级/fallback	不保存业务敏感上下文
观测平面	TTFT、tokens/s、队列时间、错误原因、成本归因	不只采 HTTP 5xx 和 p95

这个拆分能防止平台团队把所有问题都压到 Envoy 配置里。Envoy 很适合做统一入口和策略执行点，但模型调度还需要和 serving runtime、metrics、autoscaler 配合。

2. 模型感知路由的最小策略

一个可落地的策略至少要回答五个问题：

问题	示例字段	工程意义
谁在调用	tenant、service account、API key id	成本归因、权限和限流
调哪个模型	model、version、capability	防止任意模型访问和影子模型
请求有多关键	priority、deadline、interactive/batch	决定队列优先级和降级策略
成本上限多少	max input/output tokens、budget class	避免长上下文拖垮共享 GPU
数据能去哪	data classification、region、provider allowlist	防止敏感数据流向外部 provider

3. 配置骨架：先表达边界，再谈性能

下面是一个抽象配置骨架，用于表达平台契约。第一段使用标准 Gateway API 形态；第二段是平台自定义资源示例，字段名称需要按具体实现版本调整，不应直接复制到生产。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: ai-entry
spec:
  gatewayClassName: envoy-ai
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: api.example.internal
---
apiVersion: platform.example.com/v1alpha1
kind: ModelAccessPolicy
metadata:
  name: tenant-a-llm-policy
spec:
  tenant: tenant-a
  allowedModels:
    - name: llama-3-70b
      maxOutputTokens: 2048
      allowedPriorities: [interactive, batch]
  routing:
    interactive:
      preferredPool: gpu-critical
      fallbackPool: gpu-shared
    batch:
      preferredPool: gpu-batch
  audit:
    logPromptMetadata: true
    logPromptBody: false

这里故意把第二段写成平台自定义资源，而不是宣称某个上游项目已经固定支持这些字段。生产工程的重点是把策略意图变成可审计契约：租户能用哪些模型、能花多少 token、能否 fallback、记录哪些元数据。

可复现实验设计

如果要在实验集群验证模型感知网关，不建议一开始就上真实大模型压测。先用 mock backend 验证控制面。

步骤	验证对象	成功标准
1	Gateway/HTTPRoute 基础连通	OpenAI-compatible 路径能到达 mock backend
2	模型字段路由	`model=a` 与 `model=b` 进入不同 backend
3	租户限流	不同 API key/token 有独立速率和预算计数
4	优先级队列	interactive 请求在 batch 堆积时仍满足 TTFT 目标
5	指标导出	能看到 request、token、TTFT、queue time、upstream errors
6	降级/fallback	主 pool 不健康时按策略切换，而不是随机重试
7	审计	每个请求能关联租户、模型、策略版本和路由决策

一个安全的 mock backend 可以返回固定 token 流，按请求头或 JSON 中的 model 字段人为延迟。这样能验证路由和观测，不需要先消耗 GPU。

# 示例观测查询：真实指标名以所选网关和 exporter 为准
kubectl -n ai-gateway get pods
kubectl -n ai-gateway logs deploy/ai-gateway --since=10m | grep 'route_decision'
kubectl -n monitoring port-forward svc/prometheus 9090:9090

排错顺序应该从控制面到数据面：CRD 是否安装、GatewayClass 是否被控制器接管、HTTPRoute 是否 Accepted、后端 Service 是否有 Endpoint、策略是否匹配租户和模型、指标是否带上模型维度。

风险与安全边界

风险	具体表现	控制建议
数据外流	fallback 到外部 provider 时携带敏感 prompt	按数据分类做 provider allowlist，默认禁止敏感租户外发
成本失控	长上下文或批处理任务占满 GPU	token 预算、队列隔离、租户级成本指标
策略漂移	网关配置、模型服务和文档不一致	策略版本化，路由决策写入审计日志
延迟不可解释	只有 HTTP p95，看不到 TTFT 和 queue time	引入推理指标，拆分 prefill/decode/queue 维度
安全误边界	把 API key 当作唯一隔离	结合身份、网络、命名空间、模型白名单和审计
供应商锁定	只适配单一 provider SDK	保持 OpenAI-compatible/抽象接口，但不要抹平所有能力差异

尤其要注意：模型网关不是 DLP、不是权限系统、也不是 GPU 调度器。它是策略执行点和观测汇聚点，必须和身份、数据分类、secret 管理、Kubernetes RBAC、网络策略和模型服务运行时一起设计。

结论

LLM 网关真正的价值，不是把多个模型 API 统一成一个 URL，而是把模型选择、资源消耗、安全边界和可观测性变成平台契约。路由策略要区分交互、批处理和评测流量，观测指标要覆盖 TTFT、tokens/s 和 queue time，降级策略要在满载时有明确行为。落地成败取决于平台团队能不能把『模型感知』翻译成可验证的工程对象。