多模型路由网关实战：OpenAI兼容API的设计教训

我一直都在做 ModelBridge 的开发——一个 OpenAI 兼容的 API 网关，用同一套 SDK 统一接入 GPT、Claude、Gemini、DeepSeek、Qwen 等多种模型。

以下是我希望在开始之前就知道的几点经验。

1. "OpenAI 兼容"对不同提供商含义不同

大多数提供商接受相同的请求结构，但行为差异显著：

System prompts——有些提供商将其视为严格指令，有些视为参考建议。

Structured output——有些严格强制 JSON Schema，有些则静默回退为纯文本。

Streaming——chunk 格式各异，Finish reason 不一致，错误处理也没有统一标准。

结论是："兼容"是一个光谱，而不是非此即彼的二选一。

2. 路由不是"选一个模型"那么简单

真实用户不会说"我需要很多模型"，他们会说"我需要一个满足约束条件的模型"。

所以路由变成了一个策略引擎，而不是一个 switch 语句。你需要知道每个模型能做什么、花多少钱、在负载下的表现如何、以及它适合处理哪些任务。

3. 延迟方差比平均速度更重要

一个模型通常 1 秒响应、但偶尔要 12 秒才会让人觉得不可靠——哪怕平均值看起来还不错。

我们开始追踪每个提供商的 p95 和 p99 延迟。这改变了对 fallback 和 failover 的思考方式。

4. Streaming 是抽象最容易破功的地方

普通的请求-响应很容易统一。Streaming 才是真正差异显现的地方：

构建流数据归一化层是这个项目最令人受教的部分。

5.用量统计更接近分布式状态而不是账单

在多模型网关中，用量本身就是运行时真相的一部分。你需要追踪：

Received → admitted → forwarded → partially streamed → completed → failed → compensated

而不是一条简单的"token 入 / token 出"记录。

ModelBridge——一个 OpenAI 兼容 API，多种模型，按量付费。

无供应商锁定。无复杂合同。只有开发。

我还在持续改进路由智能、成本优化和可靠性。如果你也在这个领域开发，很想听听你遇到了哪些挑战。