本文目录#

引言：为什么“直接调模型 SDK”会在规模化时失控#

很多团队做生成式能力落地，第一步几乎都是“业务服务直接调模型 SDK”。这条路径能快速上线，但一旦从「单个团队试点」走到「多团队、多产品、多模型、多租户」，你会发现问题开始以一种非常工程化的方式堆积：

  • 密钥与鉴权四散：每个服务各自持有 Provider Key，权限边界变得模糊；一旦要做最小权限、密钥轮换、审计追责，链路很难统一。
  • 成本与配额不可控：同样是一次请求，有的团队开了长上下文、有的加了多轮重试、有的无缓存；成本像“隐形税”一样累积，直到某天账单爆炸。
  • 可观测性缺失：你能看到最终输出，但不知道中间用了哪个模型、走了几次重试、命中了没有缓存、触发了哪些安全/过滤规则，更无法回放与复盘。
  • 可靠性被供应商抖动放大：某个模型偶发超时、某个区域抖动、某个限流阈值变更，会直接把故障扩散到业务层。
  • 合规与安全变成“事后补丁”：PII 脱敏、数据驻留、日志留存、提示注入（prompt injection）与越权工具调用等风险，如果不在“统一入口”解决，后面会非常痛苦。[4][5]

这时你真正需要的，不是再写一套 SDK 封装，而是把 LLM 调用从“散落的代码片段”升级为平台级能力：像治理 API 一样治理模型调用。这个平台入口，就是本文要讲的 AI Gateway。

1. AI Gateway 的最小定义：统一契约 + 策略执行点 + 证据链#

我对 AI Gateway 的“最小定义”是三句话：

  1. 统一契约（Contract）：把各家模型/供应商的请求形态收敛成一套你能演进的请求/响应协议（包含元数据、幂等、错误码、版本等）。
  2. 统一策略执行点（Policy Enforcement Point）：把鉴权、限流、预算、路由、缓存、重试、脱敏、审计等治理能力集中在一个入口执行，而不是散落在每个业务服务里。
  3. 统一证据链（Observability & Audit Trail）：让每次调用可追踪、可度量、可回放：谁调用了什么、花了多少钱、触发了哪些规则、是否越权、出了问题怎么定位。

你可以把它类比为“API Gateway + Service Mesh + FinOps + 审计”的组合，但对象从 HTTP API 变成了 LLM（以及 Agent 的工具调用链）。

一个典型调用链可以画成这样：

1
2
3
4
5
6
7
8
9
10
Client / Service / Agent
        |
        |  (统一请求契约 + 业务元数据：tenant/user/use_case/trace_id)
        v
     AI Gateway  ----------------------+
        |                              |
        | (鉴权/配额/预算/限流/脱敏)     | (可观测：trace/metrics/logs)
        | (路由/灰度/降级/缓存)          |
        v                              v
  LLM Providers / Model APIs       Observability & Audit Storage

2. 统一“调用契约”：把模型调用变成可演进的 API#

如果你没有统一契约，治理会很快碎片化：每个团队会在自己的 wrapper 里定义不同的字段、不同的错误处理、不同的重试策略。久而久之，“平台治理”无法落地，因为你连“在一个地方做策略”都做不到。

一个实用的契约至少要包含这些要素（不等于具体实现，只是对外的“口径”）：

  • 身份与场景元数据：tenant_id / user_id / channel / use_case / data_classification
  • 请求可关联：trace_id / span_id / request_id（便于端到端追踪）[3]
  • 幂等与重试安全：idempotency_key（避免重试导致重复扣费/重复执行工具）
  • 预算约束：max_tokens / max_cost / max_latency_ms（把预算变成一等公民）
  • 模型选择语义：model_family / quality_tier / region_preference（而不是写死某个具体模型名）
  • 安全与合规模块：redaction_profile / retention_policy / pii_mode
  • 错误码规范化：把各供应商的错误统一成你自己的错误分类（超时、限流、无权限、内容违规、上游故障等）

这件事的关键不是“字段越多越好”，而是你要能做到两点：

  • 业务能稳定调用：不因换模型/换供应商而大改代码。
  • 平台能稳定演进：契约版本化，向后兼容，有灰度与回滚路径。

3. 治理能力拆解：AI Gateway 该“管什么”#

下面我按“治理目标”把能力拆成 6 组，你可以用它做需求清单，也可以当作架构评审 checklist。

3.1 身份与鉴权：谁能调、能调什么#

传统 API 里，鉴权常见是 API Key / OAuth / mTLS。到了 LLM 场景，你还需要更细的策略维度：

  • 按租户/团队/应用隔离：不同租户走不同的 key/结算/数据驻留策略。
  • 按用例分级：同一应用里，“客服回复”与“财务总结”可能需要不同的模型白名单与输出约束。
  • 最小权限：不是“给所有服务一个万能 Key”，而是把调用能力收敛成最小集合（能用哪些模型、能否使用工具、最大上下文与预算上限）。[5]

落地时，常见做法是在网关统一做身份解析与策略匹配：(tenant, app, use_case) -> policy。

3.2 预算与限流：把 Token/Cost 变成一等公民#

LLM 的“成本”不像传统 API 那样稳定：prompt 长度、输出长度、重试次数、工具调用、检索结果注入都会影响 token 与费用。

AI Gateway 应该提供三种层级的预算控制：

  1. 实时限流（Rate Limit）：按租户/应用/用例限制 QPS，并区分“生成/嵌入/图像”等不同操作。
  2. 预算闸门（Budget Gate）：按天/周/月设定 token 或金额预算，到阈值自动降级/拒绝/切换低成本模型。
  3. 单请求预算（Per-request Budget）：对单次调用设置 max_tokens / max_cost / max_latency_ms，超出直接中断或降级。

这样做的好处是：成本治理不再是“月底对账”，而是能在分钟级甚至秒级生效。

3.3 路由与降级：多模型、多区域与故障切换#

当你接入多个模型（或同一模型的多区域/多供应商），路由与降级会变成日常：

  • 按质量层级路由：同一用例可以声明 quality_tier=high/standard/cheap，网关再映射到具体模型与参数。
  • 按区域与数据驻留路由：欧盟用户走 EU 区域；敏感数据走私有部署；这类策略应当是网关层的一部分。
  • 按健康度故障切换：上游超时/限流时，自动切到备用模型或返回“可接受的降级答案”。

更进一步，网关还可以承载灰度与 A/B：让新模型只吃 1% 流量，观察成本/延迟/正确性指标，再逐步扩大。

3.4 缓存：Prompt Caching vs 语义缓存#

缓存是把成本打下来的“硬手段”，但也是最容易踩安全坑的地方。两类缓存常见：

  • Prompt Caching（精确缓存）：请求完全相同（或规范化后相同）就复用结果。适合模板化、重复率高、可接受一致性的场景。
  • 语义缓存（Semantic Cache）：近似请求命中近似答案，节省生成开销。适合 FAQ、知识类问答，但对“事实准确/最新”要求高的场景要谨慎。

网关层做缓存有两个优势：

  1. 统一命中口径：不然每个团队自己缓存，会出现“命中率统计不可比”。
  2. 统一安全策略：缓存是否可存、存多久、是否按租户隔离、是否需要加密，必须由同一处治理。

务必注意：缓存与日志一样，是合规与隐私的高风险点。你需要明确保留策略与脱敏规则。[5]

3.5 可靠性：超时、重试、熔断、幂等#

LLM 调用的失败模式通常比普通 HTTP 更复杂：上游限流、排队、长尾延迟、流式中断、响应被过滤等。网关需要把这些能力“产品化”：

  • 超时策略：不同用例设置不同 timeout；“交互式”优先低延迟，“离线总结”可以容忍更久。
  • 重试与退避：对可重试错误（如 429、5xx）做指数退避；对不可重试错误（如鉴权失败、内容违规）快速失败。
  • 熔断与隔离：当某个模型持续失败时，快速切走，避免雪崩。
  • 幂等：尤其在 agent 工具调用链里，如果你把“模型输出”进一步驱动“外部动作”，幂等与审计会直接影响事故概率。

这类机制并不新，Envoy 等代理体系已把它们做成成熟能力；AI Gateway 要做的是把这些能力“贴合到 LLM 语义”上。[2]

3.6 安全与合规：脱敏、审计、注入防线#

当 LLM 走进生产，安全不再只是“输出有没有违规”，而是更广义的风险面：

  • 数据外泄：PII/机密数据进入 prompt、进入日志、进入缓存，或者通过引用/工具调用被带出边界。
  • 提示注入与数据投毒：检索到的内容（网页/文档/工单）本身可能携带恶意指令，诱导模型越权调用工具或泄露信息。[4]
  • 合规留痕：当出现争议输出或越权操作，你需要能回答：谁触发的？用的什么数据？走了哪些策略？

AI Gateway 常见的做法是把安全能力分成三段：

  1. 入口净化与分级：按数据分级决定是否允许出边界、是否必须脱敏。
  2. 策略约束与白名单：允许哪些模型、哪些工具、哪些来源；对高风险动作引入审批/双人复核（视组织而定）。
  3. 审计与回放：将策略决策与关键元数据写入审计存储，形成可追责证据链。[4][5]

4. 可观测性：让一次模型调用变成“可回放的 Span”#

如果你已经写过分布式系统，你会知道：当系统复杂度上来，“可观测性不是锦上添花，而是生存条件”。AI Gateway 的价值之一，是把 LLM 调用天然变成一个可观测节点：

  • Tracing：每次调用是一个 span，至少包含 model/provider/tenant/use_case 等维度，并能关联到上游业务 trace。[3]
  • Metrics：请求量、成功率、p95/p99 延迟、token 使用、成本估算、缓存命中率、重试次数、限流次数、过滤触发次数等。
  • Logs：结构化日志记录元数据与策略决策（注意脱敏与保留策略）。

你最终要达到的效果不是“有一堆日志”，而是能回答这些问题：

  • 成本上升来自哪个租户/用例？是 prompt 变长还是重试变多？
  • 延迟变差是模型变慢、上游排队，还是网关侧缓存失效？
  • 安全事件触发时，是否能回放当时的决策链？能否验证策略是否生效？

这类观测体系最好直接对齐 OpenTelemetry 语义与采集链路，避免自建孤岛。[3]

5. 部署形态与选型：中央网关 vs Sidecar#

AI Gateway 并不只有一种形态，常见两类：

5.1 中央网关（Central Gateway）#

优点：策略集中、统一审计、统一缓存与路由、成本看板口径一致。
缺点：成为关键路径，需要高可用与容量规划；跨区域场景要考虑就近接入与数据驻留。

5.2 Sidecar/本地代理（Per-service Proxy）#

优点：就近处理、降低跨网延迟、与服务网格天然融合；局部故障影响面小。
缺点：策略与版本治理更复杂；统一缓存与统一审计更难做。

如果你在 Kubernetes 上，Gateway API 是一个值得关注的抽象：它让“网关能力”从具体实现（Ingress Controller）中抽离出来，用统一 CRD 描述路由与策略，再由实现（例如 Envoy）承载数据面。[1][2]

6. 渐进式落地路线：从旁路观测到强制治理#

如果你已经有一堆业务在直连模型，直接“切网关”往往风险很高。我更推荐 4 个阶段的渐进路线：

  1. 旁路观测（Shadow）：先让流量镜像/旁路到网关，只做打点与审计，不影响线上响应。
  2. 统一契约（Contract First）：在不改变业务功能的前提下，让业务逐步改成调用统一网关 API。
  3. 温和治理（Soft Enforcement）：先上限流/超时/重试/基本脱敏，策略命中但不强制拦截（只告警）。
  4. 强制治理（Hard Gates）：对高风险用例启用预算闸门、模型白名单、缓存策略与审计留存要求。

这条路线的核心是：先建立证据链，再谈红线。没有可观测与审计，任何治理都会变成拍脑袋。

7. 一个脱敏案例：把“成本失控 + 权限混乱”收敛到可运营#

一个很典型的场景（已脱敏）：

  • 三个团队各自接了两个供应商模型，Key 分散在各自服务的环境变量里；
  • 某次活动期间，客服机器人突然变“健谈”，token 消耗翻倍；同时因为上游偶发限流，业务代码做了三次重试，进一步放大成本；
  • 事后复盘时，团队只能看到“某些接口变慢了”，却无法还原：到底是哪个租户、哪个用例、哪种 prompt 变长、哪次重试导致；

引入 AI Gateway 后，团队先做了两件“小而硬”的事：

  1. 把调用契约统一：所有调用都必须带 tenant/use_case/trace_id，并写入统一审计。
  2. 把预算写进策略：对活动期的用例设置单请求 max_tokens 与租户级预算阈值，超限自动降级到更便宜的模型或返回短回复模板。

有了这两点，后续再逐步叠加缓存、路由与更细的权限策略，就进入了“可运营”的轨道：成本、延迟与风险不再是黑箱，而是可以被度量与治理的对象。

结语：把 AI 当作平台能力，而不是散落的 SDK#

AI Gateway 的本质不是“再加一层代理”，而是把模型调用这件事，按平台工程的方法论重新做一遍：契约、策略、观测、审计、灰度、回滚。

如果你的团队正在经历以下任一信号：

  • 多团队接入、多模型并存、需求快速膨胀；
  • 成本开始不可控，或你无法解释成本变化；
  • 合规、安全、审计要求逐步变严；
  • 线上偶发问题难复现、难定位；

那么你大概率已经到了“需要 AI Gateway”的阶段。它不会让模型更聪明，但会让你的系统更可控、更可靠，也更能承受规模化。

参考资料#

本作品系原创，采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可，转载请注明出处。