为什么把 AI 网关做到 Kubernetes 网关里

Nantian Gateway 是一个 Kubernetes Gateway API 实现，数据面用 Rust 写的，支持 59 个 Gateway API 特性，conformance 全量通过。附带的功能是一个内嵌的 AI 网关模块，在同一个数据面进程里跑模型路由、Token 限流、语义缓存、PII 脱敏这些。不需要额外部署 LiteLLM 或 Portkey。

这篇文章讲为什么这么做，以及代价是什么。

架构

Gateway API 资源 (CRD)
       ↓
  Go 控制面 (Kubernetes reconciler + translator)
       ↓
  gRPC/xDS 推送快照
       ↓
  Rust 数据面 (Pingora 框架)
       ├── HTTP/HTTPS 代理
       ├── gRPC 代理
       ├── TCP/UDP/TLS 代理
       ├── AI 网关 (ntgw-ai crate, ~3,500 行)
       └── Wasm 运行时 (wasmtime)

控制面和数据面分离。控制面监听 Kubernetes 资源变化，翻译成内部 IR，通过 gRPC/xDS 推送给数据面。数据面拿到快照后独立运行，不需要控制面参与请求处理。

AI 网关是数据面里的一个 crate（ntgw-ai，约 3500 行 Rust），作为 HTTP 代理的一个 filter 阶段运行。请求进来先走常规路由匹配，如果匹配到 AIService 后端，就走 AI 过滤链，否则直接转发到普通后端。

为什么内嵌，而不是 sidecar

最开始设计是 sidecar，每个 Pod 旁跑一个 AI 代理进程。后来放弃了，三个原因：

资源翻倍。 每个 Pod 多一个容器，内存和 CPU 翻倍。AI 代理要做 Token 计数、语义缓存、PII 识别，这些都有内存占用。

延迟增加。 Sidecar 路径是 网关 → sidecar → 供应商，多一跳。同机 1-3ms，高并发下 connection pool 管理更复杂。

生命周期管理。 Sidecar 的启动顺序、热升级、故障隔离都是问题。内嵌到代理进程里，由代理框架统一处理。

内嵌的代价是耦合。AI 模块 panic 会带走整个进程。Rust 在这块有优势——类型系统在编译期消除了一整类问题，剩下的用 catch_unwind 兜底。

性能

10 分钟 vegeta 压测，100 并发，HTTP/1.1 GET，Kind 单节点：

指标	不开 AI	开 AI 路由 + Token 计数
RPS	9,000-11,000	9,000-10,500
P50 延迟	3-4ms	3-5ms
P99 延迟	11-15ms	12-16ms
内存	~105 MiB	~110 MiB
CPU	~1,100 millicores	~1,200 millicores

AI filter 按需执行——只有匹配到 kind: AIService 的请求才走 AI 链。普通 HTTP 请求零开销。

模块构成

AI 模块约 3500 行，12 个文件：

模块	行数	功能
`filter.rs`	764	过滤链编排
`pii.rs`	367	PII 识别和脱敏
`multitenant.rs`	287	多租户隔离
`token.rs`	276	Token 计数
`content_safety.rs`	272	内容安全过滤
`semantic_cache.rs`	246	语义缓存
`ab_test.rs`	254	A/B 测试
`ratelimit.rs`	170	限流
`prompt_guard.rs`	163	注入检测
`cost.rs`	143	成本追踪
`model_router.rs`	97	模型路由
`fallback.rs`	85	故障转移

配置

用 AIService CRD 声明模型和供应商：

apiVersion: gateway.nantian.dev/v1alpha1
kind: AIService
metadata:
  name: openai-router
spec:
  models:
  - name: gpt-4o
    provider:
      name: openai
      apiKeySecretRef:
        name: openai-key
        key: api-key
  - name: claude-3.5-sonnet
    provider:
      name: anthropic
      apiKeySecretRef:
        name: anthropic-key
        key: api-key
  rateLimit:
    tokensPerMinute: 100000

HTTPRoute 引用这个 AIService：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ai-route
spec:
  parentRefs:
  - name: ai-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1/chat
    backendRefs:
    - name: openai-router
      group: gateway.nantian.dev
      kind: AIService

局限性

供应商只支持 3 个（OpenAI、Anthropic、Ollama）。LiteLLM 支持 200+，这个差距短期内追不上。
v1alpha1。API 可能变。
语义缓存需要外部 embedding 服务，不是内置的。
没有模型管理 UI，全靠 kubectl。

和独立 AI 代理的对比

维度	Nantian Gateway (内嵌)	LiteLLM/Portkey (独立)
部署	一个 Helm install	网关 + AI 代理两套
延迟	进程内，无额外跳	多一跳，1-5ms
监控	统一 Prometheus	两套指标系统
供应商支持	3 个	200+
成熟度	v1alpha1	生产验证
灵活性	紧耦合	松耦合，可独立升级

已经在用 LiteLLM 接了几十个模型的，迁移不划算。从零开始或者只需要两三个主流供应商的，内嵌方案省心很多。

地址

GitHub: github.com/nantian-gw/gateway 文档: https://nantian.dev

helm repo add nantian-gw https://chart.nantian.dev
helm install nantian-gw nantian-gw/nantian-gw --namespace nantian-gw --create-namespace