结论
- chat completions 能跑只是第一步兼容测试。
- Tool calling、JSON mode、streaming chunk 和错误格式会随 provider 变化。
- 用环境变量管理 OpenAI、Qwen、DeepSeek、GLM、Groq 或网关路线。
- 生产前要加 fallback 和花费日志，避免最便宜路线变成单点故障。
怎么做
- 盘点应用实际使用的 OpenAI 功能：chat、streaming、tools、JSON schema、embeddings、vision 或 batch。
- 选两条候选路线：一个 direct provider，加一个 gateway 或 fallback。
- 在 staging 设置 OPENAI_BASE_URL、OPENAI_API_KEY 和 MODEL，不要硬编码。
- 分别跑 plain chat、结构化 JSON、tool calls、streaming、限速行为 smoke test。
- 记录重试、失败、延迟和 token 花费后，再按 accepted-output 成本切流量。
推荐路径对比
| 平台 | 免费/额度 | 适合 |
|---|---|---|
| 通义千问 DashScope | 注册额度变化 | 中国大陆友好的 OpenAI SDK 兼容模式迁移 |
| DeepSeek | 价格/额度变化 | 低价推理和代码基准 |
| 智谱 GLM | 注册 tokens 变化 | 国产 fallback 与 GLM 工作流 |
| Groq | 开发者限额变化 | 高速推理实验 |
| OpenLLMAPI | 体验额度变化 | 一个兼容 base_url 管 fallback、日志和预算归因 |
自有平台承接
替换 base_url，但保留控制力
用一个 OpenAI-compatible endpoint 统一 provider fallback、花费日志和预算归因，同时应用保持原 SDK 形状。
FAQ
Agent 可以直接 base_url 迁移吗？
必须先做 tool-call 和 JSON smoke test。Agent 会通过重试和循环放大兼容差异。
最常坏在哪里？
模型名、streaming chunk、JSON 合法性、tool-call 参数、限速错误码和上下文限制。
直连 provider 还是用网关？
简单原型直连即可。需要一个 key、fallback、客户级日志或多地区 provider 时用网关。
能继续用 OpenAI SDK 吗？
可以，前提是 provider 支持兼容 endpoint；同时要显式设置 base_url/key，并用日志确认请求目的地。