一、为什么大模型调用需要网关

业务侧直接连 OpenAI / 国产大模型 / 自建 Ollama，短期省事，长期会踩三类坑：账单失控（突发流量打满配额）、稳定性差（上游抖动直接传导到用户）、重复成本高（相同 Prompt 反复计费）。一层大模型 API 网关可以把鉴权、路由、限流、熔断、缓存和观测收敛到统一入口，让 Agent 与业务服务只关心「发请求、拿结果」。

二、网关在架构里的位置

客户端 / Agent / 业务服务
        │
        ▼
┌───────────────────┐
│  LLM API Gateway  │  ← 鉴权 · 限流 · 熔断 · 缓存 · 路由 · 审计
└─────────┬─────────┘
          │
    ┌─────┼─────┐
    ▼     ▼     ▼
 OpenAI  国产云  自建Ollama

建议网关对外暴露OpenAI 兼容接口（/v1/chat/completions 等），对内按模型名或租户策略路由到不同上游。这样上层 Agent 框架几乎不用改代码，换模型只改网关配置。

三、限流：先护住配额与预算

大模型限流不止「防刷」，更是成本闸门。常见维度：

  • 按 API Key / 租户：每分钟请求数（RPM）、每分钟 Token 数（TPM）
  • 按模型：贵模型更严，小模型更松
  • 按路由：同步对话严一些，离线批处理可排队

实现上可用令牌桶 / 滑动窗口（Redis + Lua 足够落地）。返回时尽量用标准语义：HTTP 429，并带上 Retry-After 或业务错误码，方便客户端退避重试。

# 伪配置示例
limits:
  - key: tenant
    rpm: 60
    tpm: 80000
  - key: model:gpt-4o
    rpm: 20
  - key: model:local-qwen7b
    rpm: 120

实践建议：限流阈值按峰值的 70%～80%设软阈值，再配告警；硬拒绝前可对低优先级请求进入队列，避免「一刀切」伤体验。

四、熔断：上游抖了别拖垮自己

大模型上游常见故障形态：超时变多、5xx 突增、流式中断、区域性不可用。网关应实现熔断器状态机：

  • Closed：正常转发
  • Open：短时间内快速失败，避免打爆上游与线程池
  • Half-Open：放少量探针请求，成功则关闭熔断

触发条件可组合：错误率阈值、连续失败次数、P99 延迟超标。熔断打开后的策略按业务选：

  1. 降级模型：主模型失败切到更便宜/更稳的备模型
  2. 返回缓存/兜底文案：非关键路径可降级
  3. 快速失败：让上层 Agent 走重试或人工介入

注意：流式（SSE）场景要单独定义「半截失败」——已向客户端推送部分 token 时，更适合标记会话失败并记录，而不是静默切换模型导致答非所问。

五、缓存：重复请求别二次付费

缓存是网关 ROI 最高的能力之一，但要克制：

  • 适合缓存：温度低、确定性高的补全；FAQ / 文档问答；相同 system+user 的评测请求
  • 慎用缓存：带工具调用的 Agent 轨迹、强个性化对话、含实时数据的问题

推荐以规范化后的请求做 key：模型名 + 关键参数（temperature、response_format 等）+ messages 哈希。存储可用 Redis，value 存完整响应或可复用的 message 片段，并设置 TTL（例如 10 分钟～24 小时按场景）。

cache_key = sha256(
  model + "|" +
  canonical_json(params) + "|" +
  canonical_json(messages)
)

语义缓存（向量近似命中）能进一步提高命中率，但要接受「近似答」风险；生产建议先上精确缓存，再对明确业务场景开语义缓存，并打上 X-Cache: HIT/MISS 便于观测。

六、三者如何协作（推荐顺序）

一条请求进入网关时的建议流水线：

  1. 鉴权与租户识别
  2. 缓存查询（命中则直接返回，计入省下的 token）
  3. 限流判断（未通过则 429）
  4. 熔断检查（打开则降级或快速失败）
  5. 转发上游（超时、重试策略要保守，避免放大风暴）
  6. 写回缓存（仅对可缓存响应）
  7. 审计与指标（延迟、token、命中率、熔断次数）

重试只对幂等读、且上游明确可重试的错误码进行；写操作与已部分流式输出的请求默认不重试。

七、观测指标（没有指标等于没网关）

  • QPS / RPM、TPM、拒绝率（429）
  • 上游错误率、熔断打开次数、降级次数
  • 缓存命中率、节省 token 估算
  • 端到端 P95/P99 延迟（区分缓存命中与回源）

把这些指标和租户、模型两个标签绑在一起，成本异常时才能快速定位是「谁」「哪个模型」在烧钱。

八、落地最小集

若团队要两周内上线，不必一次做完美语义缓存。最小可用集可以是：

  • 统一 OpenAI 兼容入口 + API Key
  • Redis 滑动窗口限流（按租户 + 模型）
  • 错误率熔断 + 单备模型降级
  • 精确响应缓存（低温度、白名单路由）
  • 基础 Prometheus 指标与请求审计日志

跑通后再迭代：多上游加权路由、预算熔断（日消费上限）、语义缓存与内容安全策略。

九、小结

大模型 API 网关的核心不是「再包一层 HTTP」，而是把成本、稳定性、重复计算变成可配置策略。限流管住预算与公平性，熔断隔离上游故障，缓存吃掉重复调用——三者一起，才构成能支撑 Agent 工程化的调用底座。