背景问题：大模型调用正在从”接 API”变成”治理入口”
很多团队最初接入大模型时，通常只是把 OpenAI、Anthropic、Google、本地模型或云厂商模型的 API Key 放进应用配置里。这个阶段看起来简单，但当业务从单一 Demo 进入生产系统后，问题会快速暴露：
- 不同团队、不同租户、不同应用共用同一组 Key，难以追踪成本。
- 某个测试脚本或异常用户可能突然消耗大量 Token。
- 免费用户、付费用户、内部员工、Agent 自动任务使用的是同一套模型权限。
- 模型升级、Prompt 版本变更、Provider 切换缺少灰度和回滚机制。
- 线上问题发生后，只能看到应用日志，看不到请求级 Token、模型、成本、错误码和重试链路。
这类问题不是靠”多写几个 if 判断”就能长期解决的。随着大模型调用成为基础设施能力，团队需要一个统一入口，也就是 LLM Gateway。
LLM Gateway 的价值不是简单转发请求，而是把模型调用变成可治理、可观测、可限额、可审计、可发布的生产流量。
核心原理：LLM Gateway 是模型调用的策略执行点
一个生产级 LLM Gateway 至少要解决五类问题：
- 身份识别：当前请求属于哪个租户、用户、应用、环境和业务场景。
- 访问控制：这个身份是否允许调用指定模型、指定工具、指定上下文长度或指定输出模式。
- 预算与限流：是否超过 RPM、TPM、并发数、日预算、月预算或项目预算。
- 请求治理：是否需要重试、降级、缓存、Provider fallback、模型别名映射或灰度发布。
- 审计与观测：记录请求、Token、成本、延迟、错误、策略命中和版本信息。
Cloudflare AI Gateway 将其定位为”观察和控制 AI 应用”的入口，功能覆盖 analytics、logging、caching、rate limiting、request retry 和 model fallback。LiteLLM Proxy 通过 virtual keys 追踪 spend 并控制 model access，同时支持 user、team、key 级别的预算、RPM、TPM 和多窗口预算。Kong AI Gateway 强调 provider-agnostic API、集中管理 credentials、access tiers、usage analytics、rate limiting、semantic cache、guardrails 和 prompt engineering 等能力。OpenAI 官方 rate limit 文档也说明，生产 API 限制不仅有 RPM，还包括 RPD、TPM、TPD 以及组织和项目维度的限制。
从这些产品和文档可以看出，LLM Gateway 的核心不是”统一 URL”，而是统一策略边界。
推荐架构：控制面、数据面和策略面分离
生产环境中，不建议把所有逻辑塞进一个反向代理。更稳妥的架构是三层拆分：
数据面：低延迟转发与基础保护
数据面负责处理实时请求：
- 解析 API Key、JWT、租户 Header。
- 标准化 OpenAI-compatible 请求格式。
- 执行基础限流、超时、重试和熔断。
- 调用策略服务做准入判断。
- 转发到目标模型 Provider 或内部推理服务。
- 写入请求日志、Token 估算、响应摘要和错误信息。
数据面必须稳定、低延迟、可水平扩展。它不应该承担复杂审批流，也不应该动态加载过多业务规则。
控制面：配置、版本、发布和回滚
控制面负责管理配置：
- 租户、应用、用户组、环境和 API Key。
- 模型白名单、模型别名、默认模型和降级模型。
- 预算、限流、并发数、上下文长度和最大输出 Token。
- Prompt 模板版本、灰度比例、发布状态和回滚记录。
- 审计查询、成本报表和异常告警。
控制面输出的是可发布的策略快照，而不是让数据面每次请求都查一堆业务表。
策略面：独立的决策引擎
策略面负责回答一个明确问题：当前请求在当前上下文下是否允许执行？如果允许，应该用什么模型、什么预算窗口、什么降级规则和什么审计标签？
策略面可以自己实现，也可以参考 OPA / Envoy external authorization 的思路。OPA-Envoy 文档说明，Envoy 可以把请求上下文交给外部授权服务，由授权服务做上下文感知的访问控制；OPA 还支持 dry-run，用于策略重构或初始接入时观察”本来会被拦截什么”。这一点对 LLM Gateway 很有启发：新策略不要直接硬切生产流量，而应先 shadow / dry-run，再逐步 enforce。
策略模型：不要只做 Key，要做”租户 + 场景 + 模型 + 成本”
很多团队会把 LLM Gateway 简化为 API Key 管理，这是不够的。建议至少建立以下策略维度。
租户维度
每个请求必须归属到一个稳定的 tenant_id。不要只依赖用户邮箱或应用名，因为这些字段很容易变化。
tenant:
id: tenant_enterprise_a
plan: enterprise
environments: [prod, staging]
monthly_budget_usd: 5000
default_model_group: premium-chat应用维度
同一个租户下，客服 Agent、数据分析助手、代码助手、后台批处理的风险和预算完全不同。
application:
id: support_agent
tenant_id: tenant_enterprise_a
allowed_models: [gpt-5-mini, claude-sonnet, internal-qwen]
max_context_tokens: 64000
max_output_tokens: 4096
allow_streaming: true场景维度
同一个应用也需要区分场景。例如”用户在线问答”和”夜间批量总结”不应该共用同一套 SLO 和预算。
scenario:
id: realtime_support_reply
rpm_limit: 120
tpm_limit: 600000
max_parallel_requests: 40
retry_budget: 1
fallback_model_group: standard-chat模型访问维度
模型权限不应只写在客户端，网关需要统一判断：
- 这个租户能否使用高价模型？
- 是否允许长上下文？
- 是否允许多模态输入？
- 是否允许推理模型或工具调用？
- 是否允许访问某个私有部署模型？
这类判断放在客户端没有安全意义，必须在服务端强制执行。
一个可落地的请求决策流程
一次 LLM Gateway 请求可以按下面流程执行：
Request -> Authenticate identity -> Normalize provider-compatible payload
-> Resolve tenant/application/scenario -> Load policy snapshot -> Check
model access -> Check RPM/TPM/concurrency/budget -> Apply prompt/model
version -> Route to provider or internal serving -> Record usage, cost,
latency, policy decision -> Return response其中最关键的环节是 policy snapshot。不要在每次请求时临时拼规则，否则很难复现线上行为。每次策略发布都应生成不可变版本：
policy_snapshot:
version: gateway-policy-2026-07-01-001
status: active
created_by: platform-team
effective_at: 2026-07-01T10:00:00Z
rules:
- id: enterprise-premium-model-access
- id: free-tier-token-budget
- id: batch-job-night-window请求日志中必须记录 snapshot version，否则当用户反馈”昨天还能用，今天不能用”时，平台团队无法判断是模型变更、预算耗尽、限流触发，还是策略发布导致。
工程落地：从三类规则开始，不要一口吃成大平台
LLM Gateway 很容易做成庞大的治理平台。更现实的做法是先落三类规则。
第一类：访问规则
访问规则回答”能不能用”。典型字段包括：
| 字段 | 说明 |
|---|---|
tenant_id | 租户标识 |
app_id | 应用标识 |
environment | 环境（prod/staging/dev） |
allowed_models | 允许的模型列表 |
denied_models | 禁止的模型列表 |
max_context_tokens | 最大上下文长度 |
max_output_tokens | 最大输出长度 |
allow_tools | 是否允许工具调用 |
allow_multimodal | 是否允许多模态输入 |
示例规则（OPA 风格）：
package llm.gateway.authz
default allow := false
allow if {
input.tenant.plan == "enterprise"
input.request.model in input.policy.allowed_models
input.request.context_tokens <= input.policy.max_context_tokens
}这类规则要尽量确定性，不要依赖模型再判断模型调用是否允许。访问控制必须是可解释、可复现的。
第二类：预算规则
预算规则回答”还能不能花”。至少要有四层：
| 层级 | 目的 | 示例 |
|---|---|---|
| Key 级预算 | 防止单个 Key 泄漏或滥用 | 日预算 $50 |
| User 级预算 | 防止某个用户异常消耗 | 日预算 $10 |
| Team / Tenant 级预算 | 防止整个客户或团队超支 | 月预算 $5000 |
| Model 级预算 | 防止高价模型被低价值场景误用 | 日预算 $200 |
LiteLLM 文档中的多窗口 budget_limits 很值得参考：同一个 Key 可以同时设日预算和月预算。生产中建议加一个小时级软阈值，用于提前告警，而不是等月预算烧完才拦截。
第三类：速率与并发规则
速率规则回答”现在能不能进”。不要只配置 RPM，LLM 请求的成本与 Token 数、上下文长度和输出长度高度相关。更合理的限流应组合以下维度：
- RPM（Requests Per Minute）：请求数限制。
- TPM（Tokens Per Minute）：Token 吞吐限制。
- max_parallel_requests：并发请求限制。
- max_queued_requests：排队上限。
- max_estimated_cost：单请求预估成本上限。
OpenAI 官方文档提到 rate limits 使用 RPM、RPD、TPM、TPD 等指标，并且任何一个维度先触达都可能触发限制。对于自建 Gateway，也应采用多维限流，而不是只做请求数限流。
发布治理：策略必须支持 dry-run、灰度和回滚
LLM Gateway 的策略改动属于生产风险。一个错误规则可能导致：
- 大量用户被误拦截。
- 免费用户访问高价模型。
- 批处理任务绕过预算。
- 某个租户突然无法调用核心能力。
- Prompt 版本错误导致输出质量下降。
建议每次策略发布包含四个阶段：
- lint：检查字段、模型名、预算单位、时间窗口和引用关系。
- dry-run：只记录
would_allow/would_deny，不实际拦截。 - canary：对少量租户、少量应用或固定测试 Key 生效。
- enforce：全量执行，并保留一键回滚。
OPA-Envoy 的 dry-run 设计对这里很有参考价值：新策略先观察决策日志，再决定是否强制执行。LLM Gateway 也应该记录 policy_decision、reason_code 和 matched_rule_id。
示例审计日志：
{
"request_id": "req_20260701_001",
"tenant_id": "tenant_enterprise_a",
"app_id": "support_agent",
"model": "gpt-5-mini",
"policy_snapshot": "gateway-policy-2026-07-01-001",
"decision": "allow",
"matched_rules": ["enterprise-premium-model-access"],
"estimated_input_tokens": 1830,
"estimated_output_tokens": 512,
"cost_center": "customer-support",
"latency_ms": 1320
}常见误区
误区一：把 Gateway 当成 Provider SDK 封装层
SDK 封装只能降低接入成本，不能天然解决预算、访问控制、审计和发布治理。Gateway 必须是服务端强制执行点。
误区二：只做模型路由，不做权限边界
模型路由可以优化成本和可用性，但如果没有租户权限、预算和审计，路由越灵活，风险越大。
误区三：预算只按月统计
月预算适合财务管理，不适合阻止事故。生产中至少要有分钟级、小时级、日级和月级窗口。
误区四：策略变更没有版本号
没有版本号就无法复盘。每次请求必须记录策略版本、模型版本、Prompt 版本和关键限流结果。
误区五：把所有规则写进业务代码
业务代码可以判断业务语义，但平台级模型访问、预算和审计应该集中治理。否则多个服务会出现规则漂移。
上线检查清单
身份与租户
- 是否每个请求都能映射到
tenant_id、app_id、environment？ - 是否禁止匿名请求直接访问模型 Provider？
- API Key 泄漏后是否能快速禁用并追溯历史调用？
策略与发布
- 策略是否有版本号和状态机？
- 是否支持 dry-run、canary、enforce、rollback？
- 是否有策略 lint 和冲突检查？
- 是否记录
matched_rule_id和reason_code？
预算与限流
- 是否同时支持 RPM、TPM、并发数和预算窗口？
- 是否区分 key、user、team、tenant、model 级预算？
- 是否有 runaway usage 告警？
- 失败重试是否也纳入限流与预算统计？
观测与审计
- 是否记录模型、Provider、Token、成本、延迟、错误码？
- 是否能按租户、应用、场景和模型聚合成本？
- 是否能定位某次请求使用的 Prompt 版本和策略版本？
- 是否能导出审计日志给安全和财务团队？
可靠性
- Provider 超时后是否有 fallback？
- 降级模型是否仍满足业务合规要求？
- Gateway 自身是否有熔断和限流？
- 策略服务不可用时是 fail-open 还是 fail-closed？是否按场景区分？
适用场景
LLM Gateway 特别适合以下场景：
- 多个业务团队共用模型资源。
- 多租户 SaaS 产品需要按客户计费或限额。
- 同时使用多个模型 Provider。
- 有免费版、专业版、企业版等不同权限层级。
- 有 Agent、批处理、在线客服、内部助手等混合流量。
- 需要把模型成本分摊到部门、客户或项目。
- 需要对 Prompt、模型和策略发布做灰度治理。
如果只是单个内部脚本偶尔调用模型，不一定需要完整 Gateway。但一旦进入生产、多团队、多租户、多模型、多预算边界，Gateway 就会变成基础设施。