先说结论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 // 健康探测,喂给熔断 }覆盖面通常是这几类OpenAIGPT-4o / GPT-4o-miniAnthropicClaude 系列Sonnet / Haiku开源模型Llama / Qwen / DeepSeek 等自部署或第三方托管适配器接口设计好之后「新增一个供应商」应该是一天的活而不是一次伤筋动骨的改造——这是检验这层抽象合不合格的硬指标。第四层运营支撑层 —— 管钱、管账、管风险余额账户预充值模式实时扣减。对账系统日级别对账和各供应商账单核差异对不上自动告警。风控系统异常调用检测 熔断 限流。审计日志所有请求全量落盘出问题能回溯。这一层不性感但最容易出资损事故尤其是对账——多供应商各自的计费口径、延迟到账、汇率差一点乘上调用量就是真金白银。关键技术选型模块推荐技术选型理由API 网关Node.js Fastify高并发、IO 密集、生态丰富撮合引擎Rust性能敏感、要低延迟决策数据存储PostgreSQL Redis余额/对账用 PG强一致价格缓存用 Redis消息队列Kafka / RabbitMQ请求日志、异步对账解耦选型不是唯一解核心是按「一致性 vs 性能」把模块分开碰钱的走 PG 强一致碰速度的走 Redis Rust。风控把资损挡在发生之前多级策略从松到紧单用户限流——每秒/每分/每小时三档请求数上限。成本告警——单日消费超阈值自动通知别等月底看账单才发现被刷。异常熔断——某供应商连续失败率超阈值自动切走健康探测恢复后再放回。账户冻结——余额不足或命中异常行为模式自动冻结止血。熔断的响应速度要快1s 内切换否则一家供应商抽风会顺着网关放大成全站故障。一页速查模块技术栈关键指标API 网关Node.js请求延迟 50ms撮合引擎Rust决策延迟 5ms供应商适配标准接口新增供应商 ≤ 1 天风控实时检测熔断响应 1s一句话收尾Token 聚合网关的工程难点不在「调通某家 API」而在「撮合决策要快、对账不能错、单点故障不能扩散」这三件事上。想清楚这三点架构自然就落下来了。我们是 AI Enable Harness研发驱动的软件工程与技术服务团队做 AI Token 平台、AI 工作流、GEO/SEO 优化、企业官网与后端 API 等。上面这套架构是我们在该方向的能力实现与参考设计——有多模型聚合、成本优化相关的技术预研或落地需求欢迎评论区交流。官网已备案上线aigcharness.com。
