返回 Blog
迁移指南
发布于 2026年8月4日
7 分钟阅读
迁移到 OpenAI 兼容 API:改 Base URL 之前先检查这些事
兼容的不只是请求格式;错误、流式事件、工具调用、限流和模型别名都需要逐项验证。
核心结论把迁移当作契约测试,而不是字符串替换,才能避免在生产流量下才发现细微不兼容。
“兼容”有多个层级
最基础的兼容是路径、鉴权头和 JSON 字段一致,但应用真正依赖的行为更多:流式增量如何结束、工具参数是否合法、错误对象如何分类、usage 何时返回,以及未知字段是否被忽略。
因此,迁移清单应从你现有应用的真实调用中生成。列出使用过的模型参数、响应字段、流式事件和错误分支,而不是只照着快速开始发送一个最小请求。
建立契约测试集
- 普通非流式对话与多轮上下文。
- 流式首字节、增量顺序、中断与结束事件。
- JSON 输出或结构化输出的边界情况。
- 工具调用、并行工具和无效工具参数。
- 限流、超时、鉴权失败和不存在的模型。
- usage、request_id 与追踪头是否稳定可得。
ModelRush 推荐先做影子测试:同一批脱敏请求同时发送到旧入口和新入口,只比较结构、延迟和错误,不把新结果展示给用户。
显式管理模型映射
不要假设供应商模型名在兼容层中一一对应。使用应用自己的逻辑模型名,例如 fast-chat 或 code-quality,再在配置中映射到 ModelRush 的模型或自动路由。这样迁移和未来换模都不需要修改业务代码。
分阶段切流
从内部工具或低风险功能开始,逐步提高流量比例。每个阶段都比较成功率、P95 延迟、工具调用完成率、输出长度和单位成本。保留快速回退开关,并确保回退不会丢失会话状态。
迁移完成的标志不是“请求能返回”,而是异常分支、监控、账单和回退都已通过验证。
下一步
从这篇文章直接进入模型详情、当前价格、API 文档和 Playground。查看 API 文档
把文章中的架构和可靠性原则对应到请求、任务状态与错误处理。继续阅读
围绕相邻决策继续构建你的多模型技术栈。


