先说结论（BLUF）

当一家公司同时在用 OpenAI、Anthropic、还有几个开源模型时，最痛的三件事是：账号和计费散在各家、价格波动没人盯、某一家挂了整条业务跟着抖。

解决它的形态，是在你和各家大模型之间架一层聚合网关——对内提供一个统一的 API，对外动态路由到当前性价比最优的供应商。它交易的「Token」是大模型推理的计费单位（每千 token 多少钱），和区块链没有半点关系。海外的 OpenRouter 已经把这条路走通了，本质是一个「大模型推理算力的携程」。

这篇文章把我们做这类平台时沉淀的四层架构摊开讲，每一层的关键设计决策和踩点都给出来。适合正在纠结「多模型调用要不要自建网关」的团队做技术预研。

---

什么时候值得自建这层网关？

先泼盆冷水——不是所有团队都需要。判断标准就一条：月调用量到没到千万级 token。

• 没到：直接用某一家、或者直接接 OpenRouter 这类现成聚合，自建是过度工程。
• 到了：多供应商聚合 + 定价撮合通常能省 20%–40% 推理成本，加上可用性冗余，自建（或找人搭）开始划算。

下面的架构，是给「已经到量」的场景准备的。

---

核心架构：四层模型

┌─────────────────────────────────────┐
│         API Gateway / 统一入口        │
│   REST / gRPC / WebSocket 协议适配    │
├─────────────────────────────────────┤
│           定价撮合引擎                │
│   实时价格聚合 → 最优供应商选择 → 路由  │
├─────────────────────────────────────┤
│        供应商适配层                    │
│   OpenAI / Anthropic / 开源模型 / 其他  │
├─────────────────────────────────────┤
│        运营支撑层                      │
│   余额账户 / 对账 / 风控 / 审计         │
└─────────────────────────────────────┘

从上到下：网关收口、撮合决策、适配器屏蔽差异、支撑层管钱管风险。逐层说。

第一层：API Gateway —— 把「对接 N 家」变成「对接 1 家」

用户侧只对接一个 API 格式，各供应商的协议差异全部由网关吸收。这一层要做四件事：

• 请求级路由：不是启动时选好一家，而是每一次请求都动态选最优供应商——价格和可用性随时在变。
• 协议适配：对外统一，对内把请求翻译成 REST / gRPC / WebSocket。
• 鉴权与限流：API Key 级别的权限和配额控制。
• 用量计量：实时记录每次调用的 token 消耗，这是后面对账和风控的数据源。

延迟预算要卡死——网关自身的开销尽量压在 50ms 以内，别让「省钱的中间层」变成「拖慢的中间层」。

第二层：定价撮合引擎 —— 平台真正的护城河

这是整套系统里最值钱、也最难的一层。它实时聚合各家价格，结合延迟、可用性等多维因素，为每次请求选一家。三种基本撮合策略：

• 价格优先：直接选当前最低价。
• 质量优先：价格差在阈值内时，选质量更好的那家（比如复杂推理任务不为省一点点钱牺牲效果）。
• 负载均衡：请求摊开，避免把单一供应商打过载、也避免触发对方的限流。

决策必须快——撮合逻辑本身的延迟建议压在 5ms 量级，所以这一层对性能敏感，值得用 Rust 之类的语言单独写，价格表放 Redis 热缓存。

第三层：供应商适配层 —— 一个接口收编所有家

每个供应商实现同一个标准适配器接口，新增一家就是加一个实现类，不动上层：

interface ProviderAdapter {
  chat(messages, options): Response   // 统一的对话调用
  getPricing(): Price[]               // 拉取实时价格
  healthCheck(): Status               // 健康探测,喂给熔断
}

覆盖面通常是这几类：

• OpenAI：GPT-4o / GPT-4o-mini
• Anthropic：Claude 系列（Sonnet / Haiku）
• 开源模型：Llama / Qwen / DeepSeek 等自部署或第三方托管

适配器接口设计好之后，「新增一个供应商」应该是一天的活，而不是一次伤筋动骨的改造——这是检验这层抽象合不合格的硬指标。

第四层：运营支撑层 —— 管钱、管账、管风险

• 余额账户：预充值模式，实时扣减。
• 对账系统：日级别对账，和各供应商账单核差异，对不上自动告警。
• 风控系统：异常调用检测 + 熔断 + 限流。
• 审计日志：所有请求全量落盘，出问题能回溯。

这一层不性感但最容易出资损事故，尤其是对账——多供应商各自的计费口径、延迟到账、汇率，差一点乘上调用量就是真金白银。

---

关键技术选型

模块	推荐技术	选型理由
API 网关	Node.js + Fastify	高并发、IO 密集、生态丰富
撮合引擎	Rust	性能敏感、要低延迟决策
数据存储	PostgreSQL + Redis	余额/对账用 PG（强一致），价格缓存用 Redis
消息队列	Kafka / RabbitMQ	请求日志、异步对账解耦

选型不是唯一解，核心是按「一致性 vs 性能」把模块分开：碰钱的走 PG 强一致，碰速度的走 Redis + Rust。

---

风控：把资损挡在发生之前

多级策略，从松到紧：

1. 单用户限流——每秒/每分/每小时三档请求数上限。
2. 成本告警——单日消费超阈值自动通知，别等月底看账单才发现被刷。
3. 异常熔断——某供应商连续失败率超阈值，自动切走，健康探测恢复后再放回。
4. 账户冻结——余额不足或命中异常行为模式，自动冻结止血。

熔断的响应速度要快（1s 内切换），否则一家供应商抽风会顺着网关放大成全站故障。

---

一页速查

模块	技术栈	关键指标
API 网关	Node.js	请求延迟 < 50ms
撮合引擎	Rust	决策延迟 < 5ms
供应商适配	标准接口	新增供应商 ≤ 1 天
风控	实时检测	熔断响应 < 1s

一句话收尾：Token 聚合网关的工程难点不在「调通某家 API」，而在「撮合决策要快、对账不能错、单点故障不能扩散」这三件事上。想清楚这三点，架构自然就落下来了。

---

我们是 AI Enable Harness，研发驱动的软件工程与技术服务团队，做 AI Token 平台、AI 工作流、GEO/SEO 优化、企业官网与后端 API 等。上面这套架构是我们在该方向的能力实现与参考设计——有多模型聚合、成本优化相关的技术预研或落地需求，欢迎评论区交流。官网已备案上线：aigcharness.com。