LLM 代理与 AI 网关：你需要哪种架构？
对比 LLM 反向代理与 AI 网关在路由、鉴权、计费、故障转移与可观测性上的差异，并说明各自适用场景。
LLM 反向代理以最小策略把 OpenAI 形态请求转发到一个或多个上游模型 API；AI 网关则是在传输之上增加鉴权、授权、路由、配额、用量记账、故障转移与运维可见性的控制面。如果只需要隐藏 base URL，代理可能足够。当多个团队、密钥、供应商或预算共享同一流量路径时，你需要网关职责——无论组件如何命名。
本文是一份选型指南：这一跳分别承担哪些工作、缺少这些职责时会如何失败，以及如何在不编造胜负排名的前提下做决定。自建实施方案请继续阅读 自建 LLM API 网关。供应商 SDK 迁移仍分别位于 Claude 和 Gemini 的 OpenAI SDK 文章中。
先从每一层真正承担的工作出发
团队常把「代理」与「网关」混用，因为两者都位于客户端与供应商之间。生产中真正重要的是这一跳拥有哪些职责。
LLM 反向代理
典型代理工作：
- 终止 TLS 并转发 HTTP
- 改写 host 头或 base 路径
- 注入或替换上游 API Key
- 可选的对连接失败的简单重试
- 可选的基础访问日志
代理优化的是传输简单性。它接近 nginx、Envoy、Caddy，或向单一供应商的 /v1/chat/completions 发帖的小型 Go 服务。
AI 网关
典型网关工作：
- 签发并校验租户或用户 API Key
- 将逻辑模型名映射到供应商通道
- 强制限流、预算与模型白名单
- 在需要时翻译供应商特定载荷，例如把 OpenAI 工具入口转换为上游 Claude Messages
- 记录用量、成本估计与审计轨迹
- 运行健康感知路由与故障转移
- 为通道、日志与价格上下文提供运维 UI
网关优化的是可运维的多租户或多团队模型访问。本仓库这类可自建 Go 网关把 OpenAI 兼容入口与通道配置、用户管理与用量记账结合，而不是充当纯管道。
并排对比
| 关注点 | LLM 反向代理 | AI 网关 |
|---|---|---|
| 主要目标 | 转发请求 | 治理模型访问 |
| 鉴权模型 | 常为共享上游密钥 | 作用域密钥、分组、类 RBAC 控制 |
| 供应商 | 经常一个，有时静态多上游 | 一等公民的多通道路由 |
| 模型命名 | 透传 | 别名与目录 |
| 计费 / 配额 | 外部或无 | 内置使用日志与预算 |
| 故障转移 | 手动或粗糙重试 | 策略驱动的备份通道 |
| 可观测性 | 访问日志 | 请求历史、通道健康、看板 |
| 载荷转换 | 很少 | 常见（OpenAI ↔ Claude / Gemini 形态） |
| 最适场景 | 单应用、单供应商边缘跳 | 服务多应用的平台团队 |
两列都没有「更正确」。无节制生长的代理往往会变成偶然网关，却没有刻意网关该有的测试与 UI。
何时反向代理是正确答案
在以下多数成立时选择薄代理：
- 一个应用团队同时拥有客户端与凭证
- 一个主供应商覆盖几乎全部流量
- 你不需要在代理内做按功能预算
- 故障转移由应用代码处理，或可接受停机
- 现有 APM 与供应商账单已满足审计
- 改代理的人与发版应用的人是同一批
示例：
- 把
api.openai.com改写到区域镜像的预发环境 - 注入密钥以免容器存储原始供应商密钥的 sidecar
- DNS 或证书切换期间的临时迁移跳
这些情况下，网关功能只会增加运维面，而不改变决策质量。
何时需要 AI 网关
出现以下任一情况时，迁移到网关语义：
多个消费者共享一条路径
内部聊天、批量评估、支持智能体和产品功能不应全部嵌入同一把不受限的供应商密钥。作用域密钥、基于角色的访问控制和分组策略能够缩小爆炸半径。
多供应商是产品策略的一部分
如果 Claude、Gemini 和 OpenAI 都是实际选项，客户端不应各自实现供应商 SDK 和临时故障转移。兼容 OpenAI 的 API 网关 保持一套客户端契约，同时由通道承载上游多样性。尤其要注意，供应商直接提供的“OpenAI 兼容”模式可能只面向评估——Anthropic 对其 OpenAI SDK 路径就是如此——而生产环境需要在同一个入口下映射到原生上游。
成本必须可归属且可限制
供应商账单来得太晚，无法做功能级控制。暴露请求级用量、定价上下文以及钱包或配额概念的网关，让团队能回答“谁在什么模型上花了多少”，而不必进行表格考古。可结合 LLM 使用日志与成本跟踪。
可靠性是平台 SLA
如果产品经理要求“供应商 A 短暂故障时聊天仍然可用”，共享故障转移策略就应位于同一跳中。参见 LLM API 故障转移策略。当没有健康通道时，应用仍需处理用户可见的降级。
安全与租户隔离重要
工具调用智能体、提示词中的客户数据以及多租户 SaaS，都会提高共享主密钥的风险。网关密钥作用域、模型白名单和审计日志，是受控平台与任意共享反向代理之间的区别。
架构草图
代理路径
App --Bearer provider key or injected secret--> Reverse proxy --> Single provider API
\
access log (optional)
网关路径
Apps / agents / eval jobs
| HTTPS + gateway key
v
AI gateway
- authN/authZ, quotas, aliases
- OpenAI-compatible /v1/*
- usage logs + operator UI
|
+--> Channel: OpenAI
+--> Channel: Anthropic (native Messages)
+--> Channel: Gemini
+--> Channel: Azure / Bedrock / others
客户端继续使用 OpenAI SDK，上游多样性由配置管理。这也是 可移植工具调用 和多供应商评估计划通常会发展出一个网关，而不是再增加三个代理的原因。
决策用功能清单
在设计评审中使用此列表。若你需要的不只是两三条「仅代理」行，你现在或之后紧急重构时都会买下网关工作。
- 身份 — 调用方以服务、用户还是租户认证？
- 授权 — 每个调用方都能调用每个模型吗？
- 预算 — 在失控 agent 耗尽资金前有没有硬停？
- 路由 — 逻辑模型名能否隐藏供应商更名？
- 翻译 — 工具调用或流式是否必须跨供应商归一？
- 故障转移 — 谁拥有备份模型选择？
- 审计 — 事故后能否重建可计费请求？
- 运维 UX — 非值班工程师是否需要通道与日志 UI？
- 数据边界 — 某些流量是否必须留在特定供应商或区域？
- 变更速度 — 模型 ID 与价格多久变一次？
常见失败模式
「聪明代理」陷阱
代理堆积一次性脚本、自定义头与未文档化的重试规则。只有一名工程师懂它。当供应商改变流式错误格式时，所有客户端崩溃且日志不足。若你需要这些规则，把它们提升为带显式配置的经过测试的网关。
双控制面
有些组织给「简单」应用跑代理，给「平台」应用跑网关。会出现两套密钥系统与两套日志格式。即便对简单租户禁用部分高级策略，也优先一套入口契约。
客户端侧网关化
每个微服务实现自己的供应商抽象、预算与重试。那是没有共享可见性的分布式网关。要么集中策略跳，要么接受重复事故。
账单驱动运维
如果财务第一次看到模型花费是月账单，你就缺乏网关级计量。即便是带按密钥日志的适度自建网关，也胜过事后 CSV 清理。
把供应商兼容层当作平台
让每个微服务直接指向 Anthropic 或 Google 的 OpenAI 兼容 base URL，看起来可能像是多供应商策略。实际上通常只是五份评估接线：没有共享配额、没有统一别名，而且每家供应商静默丢弃的字段也不同。兼容端点很有用，但不能替代控制面。
AveMujica API 如何落在网关一侧
AveMujica API 面向网关职责：/v1/chat/completions、/v1/responses 等 OpenAI 兼容端点、供应商通道、模型目录、使用历史和看板概览。团队仍可在前面放置普通反向代理来处理 TLS 或 IP 白名单；这些网络职责补充 AI 控制面，而不是替代它。
选择网关路径后，日常运维应使用部署中的模型目录、通道配置和使用历史视图；与利益相关者共享时，则使用等价的公开模型或定价页。面向非运维读者的架构文档中，不要放置需要鉴权的控制台深层链接。
决策指南
| 你的情况 | 更倾向 |
|---|---|
| 一应用、一供应商、临时边缘跳 | 反向代理 |
| 仅密钥注入 | 反向代理或 sidecar |
| 多应用、一平台团队 | AI 网关 |
| 多供应商路由与别名 | AI 网关 |
| 按团队预算与审计 | AI 网关 |
| 使用共享策略的大量工具智能体 | AI 网关 |
| 不确定，但预期 agent 增长 | AI 网关（先窄后宽） |
若仍不确定，先用单一供应商与单一团队实现网关路径。你可以保持路由简单，同时已把密钥、日志与配额放在正确层。
官方与项目来源
最近核对：2026-07-15。
常见问题
AI 网关只是反向代理的营销名吗？
不是。营销有时模糊用语，但运维差异是真实的：网关拥有身份、策略、计量与多通道路由；代理主要转发字节，或许再注入凭证。
可以在 AI 网关前再放反向代理吗？
可以。网络代理处理 TLS、WAF 或 IP 限制。AI 网关仍在其后拥有模型策略与用量记账。
如果只用 OpenAI，还需要网关吗？
不总是。具备强应用级鉴权的单一团队可能够用。当多个产品共享花费、需要更严格密钥作用域，或很快会有额外供应商时，网关更有价值。
代理不够用的最早信号是什么？
通常是 (1) 多个团队共享一把供应商密钥，或 (2) 财务要求功能级 AI 成本归属而访问日志答不上来。
故障转移应放在应用还是网关？
共享故障转移策略应在网关，使每个客户端继承相同重试分类与备份模型。当没有健康通道时，应用仍应处理对用户可见的降级。
写出职责表
为当前 AI 跳写一页职责表：身份、预算、路由、日志、故障转移。若超过一半行是「未定义」或「各应用各做各的」，先建立网关通道配置，把一个真实工作流迁到作用域密钥，再增加更多供应商。