AI Coding 成本失控？从中转站到 AI Gateway，理解模型调用治理

模型名字没变，为什么用起来像换了一个模型？

一家公司把 Claude Code、Codex、Cursor 和内部 Agent 都指向同一个“OpenAI 兼容地址”。所有人请求的还是原来的模型名称。过了一周，问题开始出现：

• 账单确实便宜了，却无法和官方供应商的用量对上；
• 同一种任务，有时一次完成，有时反复返工；
• 长任务越来越慢，工具调用更容易失败，也没人说得清最后到底是哪一个模型回答的。

原因在于，AI Coding 工具和底层模型 API 之间的那个地址，从来不只是一个“转发流量的水管”。它可以验证用户、修改请求、选择上游账号、改用另一个模型、排队限速、失败重试、记录 Prompt、重新计算 Token，甚至改写返回结果。

这些能力用得好，可以形成可靠的模型调用控制系统；用得不好，也能制造一个很难验证的黑箱。

这篇文章不急着教你部署某个网关。我们会先借助 LiteLLM、Sub2API 和 AxonHub 拆开中转站的内部结构，再讨论好的网关应该治理什么、黑中转可能怎样偷工减料，以及怎样验证一条模型调用链。

一、你的理解没错：AI Gateway 就是在模型 API 前加一道控制系统

先把结构压缩成一条线：

AI Coding 客户端 → 网关或中转站 → 上游模型 API

但在真正的生产环境里，这套系统至少包含三个不同部分。把它们混在一起，很多概念就会越说越乱。

数据面：每一次请求都要从这里经过

它接收客户端连接，检查下游 Key，把一种 API 协议翻译成另一种，选择上游地址，转发流式输出，并在失败时重试。

由于网关需要处理请求内容，它通常能看到你的 Prompt、代码片段、工具定义和模型输出。客户端到网关、网关到模型供应商可能都有 HTTPS，但数据仍会在网关处解密和处理。这里并不存在天然的“端到端不可见”。

控制面：决定这次请求应该怎么走

它保存模型别名、供应商凭证、团队权限、预算、速率限制、路由权重、降级规则和数据策略。

例如，客户端请求的不是某家供应商的具体模型，而是 coding-standard。今天它可以对应两个区域的同款模型，下个月也可以换成一组经过验证的新路线，而不用让每位开发者重新配置电脑。

证据面：记录这次请求实际上怎么走了

一条完整记录应该能回答：谁发起请求、请求了什么路线、实际去了哪个上游、用了哪个模型版本、重试了几次、花了多少 Token、触发了哪条策略、最后如何计费。

以 OpenAI 为例，官方 API 会返回 x-request-id 和速率限制响应头，也允许客户端传入自己的 X-Client-Request-Id。把客户端 Trace ID、网关 Trace 和上游请求 ID 串起来，排错证据会比“控制台显示调用成功”强得多。具体字段可参考官方的 API 请求调试说明。

所以，AI Gateway 不只是“用一个地址访问多个模型”。它既是策略执行点，也是调用证据的产生地。不过，如果路由、计费和唯一一份日志都掌握在同一个陌生运营者手里，这些证据就谈不上独立。

二、“中转站”说的是所处位置，不代表它一定好或一定坏

中文开发者语境里的“中转站”，其实混合了几种完全不同的东西：

开源不等于某个公开部署就可信。开源代码只能告诉你“这套软件能够做什么”，不能证明陌生人部署时用了原版代码、配置了什么路由、接入了哪些账号。

反过来，收费服务也不天然等于“黑中转”。如果一家托管网关能够提供明确合同、供应商账单、数据处理条款、可导出日志和可审计路由，它可能比一套无人维护的自建代理更安全。

三、从三个开源项目看懂中转系统的内部零件

LiteLLM、Sub2API 和 AxonHub 都能站在模型 API 前面，但它们强调的问题并不相同。正是这种差异，帮助我们看清“中转站”内部到底能做多少事。

LiteLLM：统一多家模型 API，再集中做访问治理

LiteLLM 提供统一的多供应商调用接口，也可以作为团队共享的 Proxy Server。官方文档列出的能力包括协议转换、统一输出、重试与 Fallback、鉴权和日志 Hook、成本追踪、速率限制、虚拟 Key 和项目预算。

它的重心是一个通用的多模型网关：客户端尽量使用同一种调用方式，复杂的供应商差异集中在网关里处理。

不过，“统一格式”不代表供应商之间真的完全一样。不同模型对 Reasoning 参数、Prompt Cache、工具调用、流式事件、安全字段和错误码的支持都有差异。AI Coding Agent 依赖的功能，仍然需要逐项测试，不能只看到“OpenAI Compatible”就认为无损兼容。

Sub2API：把订阅额度和账号池变成下游 API

Sub2API 对自己的定位非常直接：面向“订阅额度分发”的 AI API Gateway。它的 README 明确列出了多种上游账号类型，包括 OAuth 和 API Key；同时支持生成下游 API Key、按 Token 计费、粘性会话、智能选号、账号与用户并发限制、速率限制和请求转发。

这套设计把“账号池”如何工作展示得很清楚：一条请求不只是发给某个供应商，系统还会从一批账号中挑选当前可用的账号；为了保持会话连续性，可以尽量粘在同一个账号；额度不足或账号受限时，再切换到其他账号；最后按照平台自己的账本向下游用户扣费。

如果这些账号归同一组织所有，而且上游产品授权这种使用方式，这可以是一种内部额度管理方案。可一旦它由陌生运营者对外出售，就必须多问几层：上游产品是否允许这种接入方式？账号从哪里来？账号被限流或关闭后如何处理？不同客户是否会互相抢占额度？

这些问题的答案取决于上游条款、账号所有权和实际授权。项目开源本身既不能证明合规，也不能证明违规。

AxonHub：把渠道、故障转移和调用追踪放到核心位置

AxonHub 强调跨协议访问、请求追踪、RBAC、配额和数据隔离、负载均衡、故障转移与实时成本追踪。它在示例里展示了把 OpenAI SDK 指向 AxonHub，再路由到其他模型体系的方式。

它让“模型渠道”这个概念变得很直观：客户端只面对一个入口，入口后面可以挂多种协议、多家供应商和多条渠道，网关再根据映射和健康状态选择具体路径。

三者放在一起看，重点不是比较谁更强，而是看到同一个中间位置可以有不同的设计中心：

真正选型时，还要回到各项目仓库核对当前 License、发布节奏、安全响应、供应商功能覆盖和运维依赖。功能清单不是生产可用性证明。

四、一条请求进入中转站以后，究竟发生了什么

假设某个 Agent 发出了这样一条概念化请求：

{
  "model": "coding-standard",
  "messages": ["...仓库上下文..."],
  "tools": ["shell", "search", "edit"],
  "stream": true
}

网关内部可能连续执行九步：

1. 验证下游 Key：把 Key 解析成开发者、团队、项目和预算；
2. 执行访问策略：判断这个人能否发送代码、调用工具、访问这条模型路线；
3. 解析模型别名：把 coding-standard 映射到一个或多个真实部署；
4. 选择渠道或账号：结合健康状态、区域、价格、剩余额度、并发和会话粘性作出选择；
5. 转换请求协议：处理消息角色、工具 Schema、Reasoning 参数和流式格式；
6. 调用上游 API：使用网关自有凭证，或企业托管在网关里的 BYOK 凭证；
7. 重试或降级：判断故障是否暂时，并选择允许的替代路线；
8. 转换返回结果：统一流式事件、错误和用量字段，再交还客户端；
9. 记录并计费：把路线、Token、延迟、策略决定和价格写入台账。

每一个加粗动作都是一次治理决定，也都是不透明运营者可以动手脚的位置。

五、负载均衡、故障转移和模型降级不是一回事

很多中转站把这些词混在一起说：

• 负载均衡：把等价请求分散到多条健康渠道；
• 故障转移：当前路径失败后，切到事先批准的替代路径；
• 成本路由：根据价格和预算选择目的地；
• 语义路由：先判断任务类型，再选择适合的模型；
• 模型降级：为了继续服务，接受能力上的实质下降。

合理的 Fallback 应该先做语义变化最小的动作，只有任务允许时才继续向下走。

最危险的规则是：“只要失败，就随便换一个便宜模型。”AI Coding Agent 仍然可能输出很流畅的文字，但上下文长度、工具可靠性、图片输入、Reasoning 强度或指令遵循能力已经下降。

因此，路由策略最好表达业务意图，而不是只写供应商名字：

routes:
  coding_sensitive:
    primary: provider_a/model_x@region_1
    fallback:
      - provider_a/model_x@region_2
    when_exhausted: fail_closed

  coding_low_risk:
    primary: provider_a/model_x@region_1
    fallback:
      - provider_b/evaluated_model_y
    disclose_actual_route: true
    when_exhausted: ask_user

如果任务对行为一致性要求很高，应尽量固定模型版本，并在改变映射前运行自己的评估集。OpenAI 官方 API 文档同样建议：需要稳定行为时使用固定模型版本，并持续运行 Evals。

六、一个好的 AI Gateway 到底能给团队带来什么

真正可靠的网关，可以提供单个客户端配置做不到的能力：

• 统一身份：开发者拿到短期或虚拟 Key，不再到处复制上游密钥；
• 模型白名单：某个团队或仓库只能调用经过批准的路线；
• 预算与速率策略：按项目分配额度，而不是月底对着一张共享账单猜；
• 透明容灾：重试和 Fallback 有规则、有记录；
• 数据控制：不同任务可以使用不同的留存、脱敏、区域和日志策略；
• 调用审计：把请求路线、真实部署、上游请求 ID、用量和策略决定串在一起；
• 统一熔断：发生泄漏或供应商事故时，可以集中停用一条路线或一个凭证；
• 客户端可迁移：Claude Code、Codex、Cursor 和内部 Agent 不必各自实现一套治理逻辑。

这正是上一篇“本地控制面”继续向组织层面发展的地方：本地控制面回答的是“这台电脑现在应该用哪套配置”；AI Gateway 回答的是“谁可以把什么任务发给哪家模型，在什么限制下运行，最后留下什么证据”。

七、黑中转可能怎样把服务悄悄做差

下面讲的是网关所处位置在技术上具备的操作空间，是风险模式，不是对前面几个开源项目的指控。

1. 用便宜模型冒充高级模型

客户端请求一个高级模型别名，中转站内部却把它映射到更便宜的模型，再在统一响应里填回用户请求的名称。因为别名解析和返回字段都由中转站控制，所以响应里的 model 字段不能单独证明真实上游。

2. 模型没换，却把能力剪掉一部分

中转站可以限制最大输出、降低 Reasoning 配置、删除不支持的工具字段、缩短上下文、关闭缓存，或者先对历史记录做激进压缩。表面模型名不变，用户买到的有效能力却已经缩水。

3. 暗中限速和超卖

排队与限流本身是正常的容量控制，前提是规则公开。如果服务商宣传独享或高速，却把很少的上游额度卖给大量用户，就变成了不透明的超卖。

常见迹象包括：高峰期延迟突然抬升、每秒输出 Token 大幅波动、频繁出现类似 429 的失败，以及首个 Token 前长时间没有响应。但这些只能说明容量或链路有问题，不能仅凭一次变慢就断定服务商作假。

4. 用不稳定账号拼成账号池

运营者可以轮换大量订阅账号、OAuth 凭证或 API Key；账号被限流或关闭后，就换下一批。粘性会话能暂时保持连续，但账号频繁变化仍可能带来额度、区域、模型可用性和数据来源不稳定。

如果价格低得离谱，真正应该问的是：支撑这项服务的长期上游权益是什么？如果这个问题没有清楚答案，所谓“便宜”可能只是把账号风险和服务中断风险转给了用户。

5. 用自己的账本证明自己的账单

中转站既能看到上游用量，也能重新计算下游费用。它的控制台可以很直观，但并不是独立证据。价格表没有及时更新、缓存折扣未计算、倍率被人为调整、用量字段被改写，都可能让最终账单失真。

6. 留存 Prompt、代码和工具参数

只要网关需要做内容相关的路由，它就必须处理明文请求。除非架构明确提供并证明了更强保护，否则应该假设运营者有能力记录源码、Prompt、工具参数、误带进上下文的密钥和模型输出。

OWASP 的 LLM 供应链安全指南 建议审查供应商、服务条款、隐私政策和安全状态。选择中转站时，这不是法务流程里的装饰，而是模型调用链本身的一部分。

八、不要通过问模型“你是谁”来验真

模型可能复述系统提示词，可能模仿另一种模型的语言风格，也可能对自己的身份胡说八道。靠一道“只有某模型会回答”的题，证据非常弱。

更合理的做法，是把模型身份当成一项供应链声明，从多个方向收集证据。

先保留一条官方直连基线

保留一个小额度的官方供应商账号。把同一套有版本的 Canary 任务分别通过官方 API 和网关运行，并重复采样。模型输出和网络延迟本来就有随机性，单次对比没有意义。

测能力边界，不要测语言性格

Canary 应该覆盖 AI Coding Agent 真正依赖的功能：

• 实际可用的上下文边界；
• 工具 Schema 遵循和并行工具调用；
• 如果业务需要，图片或文件输入；
• 流式事件格式与首 Token 延迟；
• 固定模型在小型工程评估集上的表现；
• 预期的用量字段、缓存行为、错误码和限流响应头。

如果差异很大，就需要调查，但仍不能直接当成“模型被调包”的密码学证明。原因也可能是协议转换丢字段、供应商行为变化，或者公开的路由本来就不同。

串起请求证据

客户端生成自己的 Trace ID，保留网关 Trace；如果上游支持，再保存上游请求 ID 和供应商侧用量记录。OpenTelemetry 提供了一套通用的 Semantic Conventions，可以让 Trace、Metric 和 Log 使用一致字段，更容易跨系统关联。

对齐三本账

如果上游账号归企业所有，可以做三方核对：

客户端任务台账 ↔ 网关调用台账 ↔ 供应商用量与账单

对比请求数、输入/输出/缓存 Token、重试、真实路线和价格表版本。无法回溯到上游证据的网关总数，不应该成为付款或治理的唯一依据。

验证运营者，而不只是测速一个地址

还要问清楚：域名由谁运营？数据在哪里处理？Prompt 保存多久？会不会用于训练？上游访问权从哪里获得？是否存在其他数据处理方？事故如何通知？

对于敏感代码，合同里的来源保证、数据条款和审计权，往往比一张漂亮的延迟曲线更重要。

九、给一个 30 人研发团队设计最小治理方案

假设团队同时使用 Claude Code、Codex、Cursor 和两个内部 Agent。与其共享上游 Key，不如先建立三条逻辑路线：

每位开发者拿到与团队和项目绑定的虚拟 Key。每次调用至少记录：

task_id、调用者、请求路线、真实供应商、真实模型版本、
网关 trace_id、上游 request_id、输入/缓存/输出 Token、
重试路径、策略决定、价格表版本、最终成本

团队每周检查的是异常，而不是拿用量给个人做“生产力排名”：未批准路线、反复 Fallback、P95 延迟、预算耗尽、三方用量不一致，以及便宜模型导致重试和人工审查反而增加的任务。

这套方案不保证买到最便宜的 Token，但能让成本、质量和风险决定都有解释。

十、自建、采购，还是继续直连？

如果只有一个人使用一家供应商，官方控制台已经够用，也没有共享策略需要执行，那么你可能根本不需要 AI Gateway。多加一层只会增加故障点。

当团队确实需要多供应商迁移或内部控制，而且有能力保护凭证与数据库、处理升级、备份、高可用和安全事故时，可以考虑自建。

如果治理需求真实存在，但维护模型流量入口不是团队专长，可以采购托管网关。评估它时，应把它视为会处理核心源码的关键数据处理方，而不是一个普通 SaaS 看板。

对于价格很低的公共中转站，则应该单独划一个风险等级：上游来源和数据条款无法验证时，不要传私有仓库、生产日志、密钥、客户数据，也不要让高权限 Agent 通过它执行重要操作。

验证清单

在把 AI Coding 流量交给任何中间层之前，逐项回答：

• 上游账号属于谁，谁有权使用？
• 客户端请求的别名，是否映射到明确供应商和固定模型版本？
• 允许哪些 Fallback，发生时是否通知用户？
• 网关能否保存 Prompt、代码、工具参数和模型输出？
• 一次任务能否关联到上游请求 ID 和供应商侧账本？
• Token、缓存折扣、重试和价格表版本能否核对？
• 速率与并发限制是否公开，而不是赶工时才发现？
• 预算耗尽后是自动降级、询问用户，还是失败关闭？
• 路由、Key 和日志能否导出，网关能否被干净替换？
• 团队是否针对依赖的能力做过官方直连与网关的对照测试？

如果其中很多问题的答案只是“运营者说没问题”，那你得到的是方便，不是治理。

AI Gateway 真正治理的是什么

AI Gateway 不会凭空提升模型智能。它治理的是：模型能力如何被购买、访问、限制、观察，以及发生故障时如何被替换。

所以，同一种架构能够产生完全相反的结果。好的网关把散落在各台电脑里的调用，变成公开策略和可审计证据；不透明中转站则把身份、路由、计费和数据集中到了一个你无法验证的人手里。

以后再看到“支持某某高级模型”，不要只问它能不能连上。更重要的问题是：

我能否说明这次任务究竟由哪个模型处理、使用了谁授权的账号、遵守了哪条策略、花了多少钱、降级时改变了什么，并拿出证据证明这条路径？

下一篇文章会沿着这个问题继续向前：即使路线身份是真的，我们又该怎样判断一个模型是否真的能完成团队里的工程任务？

权威资料

• LiteLLM 官方文档：统一供应商接口、Proxy、路由、成本、预算和限流。
• Sub2API 项目仓库：订阅额度分发、上游账号管理、调度、计费和转发。
• AxonHub 项目仓库：协议转换、模型渠道、故障转移、追踪、RBAC、配额和成本。
• OpenAI API 请求调试说明：请求 ID 和速率限制响应头。
• OpenAI 模型文档：官方模型目录与能力说明。
• OWASP LLM03:2025 Supply Chain：供应商、来源、条款、隐私和供应链风险。
• OpenTelemetry Semantic Conventions：用于关联 Trace、Metric 和 Log 的通用字段约定。