AI API 网关自建实战：用 OpenResty/Envoy 统一代理多供应商流量

当公司从一家供应商升级到"OpenAI + Anthropic + DeepSeek + 国产模型混部"时，最先崩的往往是网关层。每个供应商有自己的域名、自己的鉴权头、自家的限流策略，前端代码被迫写一堆 if/else 区分来源。这篇文章讲清楚怎么自建一层统一的 AI API 网关，把所有差异屏蔽在网关内部，前端永远只看到一个稳定入口。

为什么需要自建 AI 网关

中转站虽然解决了"统一域名"和"统一计费"的问题，但有几个场景自建网关更合适：

两种主流方案对比

下面分别给两种方案的最简可用配置。

方案一：OpenResty 路由 + 限流 + 多上游

# /etc/nginx/conf.d/ai-gateway.conf
upstream openai_backend {
    server api.openai.com:443;
    keepalive 32;
}

upstream anthropic_backend {
    server api.anthropic.com:443;
    keepalive 32;
}

upstream deepseek_backend {
    server api.deepseek.com:443;
    keepalive 32;
}

# 路由表：根据 model 字段分发
map $request_body $backend_name {
    default "openai";
    ~*"claude" "anthropic";
    ~*"deepseek" "deepseek";
}

# 限流：每秒 100 次，超出排队 50
limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=100r/s;

server {
    listen 8443 ssl;
    server_name ai-gateway.internal;

    ssl_certificate     /etc/ssl/certs/ai-gateway.crt;
    ssl_certificate_key /etc/ssl/certs/ai-gateway.key;

    location /v1/chat/completions {
        limit_req zone=ai_limit burst=50 nodelay;
        limit_req_status 429;

        # 透传客户端 API Key（按业务方隔离）
        set $api_key $http_authorization;

        # 路由分发
        content_by_lua_block {
            local backend_map = {
                openai     = "openai_backend",
                anthropic  = "anthropic_backend",
                deepseek   = "deepseek_backend"
            }
            local model_name = ngx.var.request_body and ngx.var.request_body:match('"model"%s*:%s*"([^"]+)"') or "openai"
            local key = "openai"
            if model_name:find("claude") then key = "anthropic"
            elseif model_name:find("deepseek") then key = "deepseek"
            end
            ngx.var.upstream = backend_map[key]
        }

        proxy_pass https://$upstream$request_uri;
        proxy_set_header Authorization $api_key;
        proxy_set_header Host $upstream_host;
        proxy_ssl_server_name on;
    }
}

这段配置实现了：

• /v1/chat/completions 单入口
• 按请求体里的 model 字段自动路由到 OpenAI / Anthropic / DeepSeek
• 全局限速 100 QPS + 50 突发
• 客户端 API Key 透传

方案二：Envoy + AI Gateway 扩展

Envoy 路线更适合 K8s 环境，配合 Envoy AI Gateway 扩展可以做更复杂的语义路由：

# envoy-ai-gateway.yaml
listeners:
  - name: ai_listener
    address: 0.0.0.0:8443
    filter_chains:
      - filters:
          - name: envoy.filters.network.http_connection_manager
            config:
              stat_prefix: ai_gateway
              route_config:
                virtual_hosts:
                  - name: ai_service
                    domains: ["*"]
                    routes:
                      - match: { prefix: "/v1/" }
                        route:
                          cluster: ai_router_cluster

clusters:
  - name: ai_router_cluster
    type: STRICT_DNS
    lb_policy: RING_HASH
    load_assignment:
      cluster_name: ai_router_cluster
      endpoints:
        - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: ai-router-service
                    port_value: 8080

# AI 路由配置由 ai-gateway-controller 通过 xDS 下发

AI Gateway 通过 xDS 下发路由表后，可以做到：

• 按请求 header（x-business-line: vip）走不同模型池
• 自动重试（不同模型、不同供应商之间）
• Token 级别限流
• 成本归集（每个请求打到哪个供应商、多少钱）

网关层应该做的事 vs 不该做的事

该做的：

• 统一鉴权（验 API Key / JWT / mTLS）
• 路由分发 + 限流 + 重试
• 请求/响应日志（含 prompt hash、token 数、延迟）
• 成本打点（按业务方、按用户）
• 灰度发布（5% 流量试新模型）

不该做的：

• 缓存答案（让业务自己用语义缓存）
• 改写 prompt（保持网关中立）
• 限流过严（影响业务）

监控三件套必做

网关层必须能看到这些指标（Prometheus + Grafana）：

熔断是最重要的可靠性手段——一家供应商挂了，网关自动切到下一家，业务代码完全无感。

与中转站的关系：互补而非互斥

很多团队的最终形态是：

客户端 → 自建 AI 网关（限流/路由/监控）→ 中转站（统一计费）→ 各家官方 API

自建网关负责流量治理（公司内的事），中转站负责上游抽象（供应商的事）。两边职责分清楚，系统才稳。

如果还在纠结选哪家供应商，可以去 openairouter.net 的中转站对比页面看看各家稳定性和价格的实测数据，作为网关上游选型的参考。