AI 中转站到底在转什么？

原创

菠萝.

发布于 2026-09-10 17:02:46

210

01 为什么会有 AI 中转站？

如果一个系统只调用一个模型，通常可以直接请求模型服务：

业务系统
   │
   ▼
大模型

但实际使用中，往往不止一个模型，也不止一个调用来源。

例如：

                 ┌─ Claude
                 │
业务系统 ────────┼─ GPT
                 │
                 └─ Gemini

同一个模型还可能存在多个渠道：

Claude
 ├── 渠道 A
 ├── 渠道 B
 └── 渠道 C

这时候，业务系统需要面对的问题就多了：

不同模型怎么调用？
一个模型有多个渠道时怎么选择？
某个渠道不可用怎么办？
怎么统计 Token？
怎么统计调用成本？
怎么知道某个渠道当前是否正常？

如果这些逻辑全部放在业务系统里，随着模型和渠道增加，维护成本也会越来越高。

因此，很多系统会增加一层专门处理模型调用的服务。

这就是我们通常所说的 AI 中转站。

02 AI 中转站是什么？

可以先用一个比较直观的结构理解：

┌────────────┐
│  业务系统   │
└─────┬──────┘
      │
      ▼
┌────────────┐
│ AI 中转站   │
└─────┬──────┘
      │
      ├──────────────┐
      ▼              ▼
   渠道 A           渠道 B
      │              │
      ▼              ▼
   上游服务         上游服务
      │              │
      └──────┬───────┘
             ▼
           模型

它最基本的工作就是：

接收业务侧的模型请求，根据配置找到对应的渠道，再把请求发送给后面的上游服务。

所以“中转”这个名字其实非常直观。

但真正值得关注的并不是“转发”本身，而是：

请求进来以后，中转站如何决定把它转到哪里。

03 模型、渠道、上游，分别是什么？

这是理解 AI 中转站时最容易混淆的三个概念。

模型

模型是业务真正想使用的模型，例如：

Claude Sonnet
GPT
Gemini

渠道

渠道可以理解成一条具体的调用路径。

一个模型可能对应多个渠道：

Claude Sonnet
    │
    ├── Channel A
    ├── Channel B
    └── Channel C

上游

上游则是中转站实际请求的服务。

因此，可以先简单理解成：

模型
 ↓
渠道
 ↓
上游服务

不过不同中转站对“渠道”“上游”“Provider”等名称的定义可能并不完全一致，实际使用时还是要以具体系统的设计为准。

04 为什么同一个模型需要多个渠道？

最直接的原因是可用性。

假设 Claude 有三个渠道：

Claude
 ├── A
 ├── B
 └── C

正常情况下：

A  ✓
B  ✓
C  ✓

某个时间点，C 出现异常：

A  ✓
B  ✓
C  ✕

如果系统仍然把请求发送给 C，就会不断出现失败。

因此，中转站需要知道：

哪些渠道可用？
哪些渠道异常？
哪些渠道应该优先使用？

这也是多个渠道存在的主要价值之一。

05 一个请求进入中转站后，会发生什么？

可以把整个过程简化成：

请求进入
   │
   ▼
识别模型
   │
   ▼
匹配渠道
   │
   ▼
检查渠道状态
   │
   ▼
选择渠道
   │
   ▼
请求上游
   │
   ▼
接收响应
   │
   ▼
返回结果

如果开启了流式响应，那么返回过程则可能变成：

上游模型
   │
   ├── Token
   ├── Token
   ├── Token
   ├── Token
   └── ...
        │
        ▼
    AI 中转站
        │
        ▼
     调用方

中转站需要保证这条流能够正常传递。

06 什么是上游探测？

当一个模型存在多个渠道时，一个很现实的问题是：

怎么知道这个渠道现在是不是正常？

一种常见做法就是进行探测。

例如：

              上游探测

Channel A ─────────→ ✓ 正常
Channel B ─────────→ ✓ 正常
Channel C ─────────→ ✕ 超时
Channel D ─────────→ ✓ 正常

系统根据探测结果记录渠道状态。

例如：

渠道	状态	最近探测
A	正常	200ms
B	正常	350ms
C	异常	Timeout
D	正常	180ms

这样真实请求到来时，就可以避免继续使用已经发现异常的渠道。

这里需要区分两个概念：

探测

主动检查渠道是否正常。

故障转移

当前渠道发生异常后，将请求切换到其他渠道。

两者经常配合使用，但不是同一件事情。

07 渠道选择并不一定只是“随机选一个”

如果一个模型下面存在多个渠道，中转站就需要有一定的选择规则。

最简单的是：

A → B → C

也就是固定优先级。

更复杂一点，可以综合考虑：

渠道状态
+
优先级
+
响应速度
+
错误率
+
负载
+
成本

最终决定这一次请求走哪个渠道。

例如：

              Claude
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    Channel A Channel B Channel C
       │         │         │
     正常       正常       异常
       │         │
     800ms     1500ms
       │         │
       └────┬────┘
            ▼
        选择 Channel A

不同系统的具体策略可能差异很大。

所以看到一个“渠道优先级”或者“权重”配置时，本质上都是在解决：

这个模型的请求应该怎么分配。

08 Token 为什么需要统计？

AI 调用和普通 API 有一个明显区别：

调用本身是有 Token 消耗的。

一次请求可能包含：

Input Token
Output Token
Cached Token

例如：

Input Token   10,000
Output Token   2,000

中转站可以记录这些数据：

模型：Claude
渠道：A

Input Token：10,000
Output Token：2,000

进一步就可以计算：

Token 消耗
      ↓
模型价格
      ↓
调用成本

因此中转站通常不只是记录：

请求次数

还会记录：

请求次数
Token
耗时
错误
模型
渠道
成本

这也是 AI 调用统计和普通 API 统计比较明显的区别。

09 TTFT 又是什么？

AI 请求里还有一个经常出现的指标：

TTFT（Time To First Token）

它表示：

从请求开始，到收到第一个 Token 所需要的时间。

例如：

请求发送
   │
   │
   │────── 1.2s ──────│
                       ▼
                  First Token
                       │
                       ▼
                  后续 Token
                       │
                       ▼
                    完整响应

这里：

TTFT = 1.2s

而整个请求可能：

总耗时 = 8s

所以：

TTFT ≠ 总耗时

对于流式模型调用来说，TTFT 是非常重要的性能指标。

10 为什么还需要 P50、P90、P99？

假设统计了 10,000 次请求。

不能只看平均值。

例如：

平均耗时：2s

看起来不错。

但实际可能是：

50% 请求：1s
90% 请求：2s
99% 请求：10s

所以通常还会看：

P50
P90
P99

它们分别代表不同位置上的请求耗时水平。

对于中转站来说，可以进一步统计：

渠道 A
├── TTFT P50
├── TTFT P90
├── TTFT P99
└── Error Rate

渠道 B
├── TTFT P50
├── TTFT P90
├── TTFT P99
└── Error Rate

这样才能比较不同渠道的实际表现。

11 AI 中转站和 AI Gateway 是什么关系？

这里需要单独说明。

AI 中转站和 AI Gateway 不能简单画等号。

AI Gateway 更偏向一个架构概念和能力集合，关注的是：

统一接入
路由
鉴权
限流
监控
治理

而“AI 中转站”更多时候是在描述一种实际的服务形态。

一个 AI 中转站可能提供：

API 转发
模型聚合
渠道管理
Key 管理
Token 统计
成本统计
渠道探测
故障切换

其中当然可能包含 Gateway 的能力。

因此，两者更适合看成：

AI Gateway
     │
     │ 其中一部分能力
     ▼
AI 中转站

或者说：

两者在功能上存在大量重叠，但概念层级和使用场景并不完全相同。

具体到某一个产品时，还需要看它自己的定位和实现。

12 一个比较完整的 AI 中转站

把前面的内容放到一起，可以得到一个比较完整的结构：

                         业务系统
                            │
                            ▼
                  ┌──────────────────┐
                  │    AI 中转站      │
                  │                  │
                  │  请求处理         │
                  │  模型匹配         │
                  │  渠道选择         │
                  │  渠道状态         │
                  │  Token 统计       │
                  │  成本统计         │
                  │  请求监控         │
                  └────────┬─────────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
          Channel A    Channel B    Channel C
              │            │            │
              ▼            ▼            ▼
           上游服务      上游服务      上游服务
              │            │            │
              └────────────┼────────────┘
                           ▼
                          模型

从这个结构就可以看出来，中转站真正需要解决的并不是“把请求转发过去”这么简单。

它需要维护的是：

模型和渠道之间的关系，以及每条调用路径当前的状态。

13 总结

理解 AI 中转站，其实抓住几个概念就够了：

模型
 ↓
渠道
 ↓
上游

围绕这条链路，又会出现：

渠道选择
渠道探测
故障转移
Token 统计
成本统计
TTFT
P50 / P90 / P99

把这些关系理清之后，再去看各种 AI 中转站产品里的：

模型配置
渠道配置
上游探测
权重
优先级
Token
调用日志

就不会觉得这些配置是零散的了。

它们最终都在解决同一个问题：

如何让业务系统稳定、可控地调用不同的大模型服务。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

人工智能