手上的项目要同时接好几家中转站，每家都说自己「兼容 OpenAI 格式」。真动手时你会发现：SDK 能跑但字段被悄悄忽略，切一家站响应结构就变，账单出现莫名其妙的重复计费。这篇不重复协议底层，只按开发者落地顺序给一套判断标准和动作清单，帮你少走回头路。
手上项目要同时接好几家中转站，几乎每家都宣称自己「兼容 OpenAI 格式」。真接进去才发现麻烦不在协议：SDK 能跑通，但某些字段被悄悄忽略；换一家站，响应结构或者错误码就变了；月底账单冒出一笔说不清来路的重复计费。这篇按开发者实际落地的顺序讲：先划清兼容的边界，再看请求怎么写、成本怎么算、上线前查什么。
核心就一句话：把「兼容」当成一个需要自己验证的假设，而不是对方给的承诺。下面每一节都给判断标准和可以照做的动作，你按顺序过一遍，比上来就复制示例代码省事得多。
先把「兼容」这两个字的边界划出来
兼容只保证按 OpenAI 那套路径和字段发请求能通，不等于每个字段都被后端认真处理。模型名、温度这类核心参数大体有效，但像某些冷门采样参数、附加选项，很可能被静默丢弃——请求成功返回，结果和你预期的不一样。
同一段代码接多家站，差异往往不在协议，而在实现细节：模型名映射（对方内部换成哪个模型）、流式事件格式（分片边界和结束标记）、错误码口径（同样的问题报不同状态码）。这些都不能靠读文档确认，只能按站单独验证。
- 判断标准一：同一组请求分别打两家站，返回结构一致才算通过，只跑通一次不算
- 判断标准二：故意构造一个错误请求（比如模型名写错），比对两家的错误信息格式，看解析层会不会崩
- 判断标准三：同一段输入看两家的用量字段是否都能取到、口径是否一致，取不到就没法算钱
- 什么情况下不适用：只接一家站、且不做多站切换的项目，可以把验证范围收窄到错误处理，不必逐项比对
请求结构：一次调用里真正要盯的几块
鉴权走 Authorization 头，Base URL 指向各站给的地址，而不是官方默认地址。这两个值经常分散在不同页面，抄的时候容易把 A 站的地址配 B 站的 key，报出来的错误还看不出原因。建议给每个站单独建一份配置，别用全局变量。
消息数组、模型名、采样参数是最小可用组合，先跑通这个再谈别的。Token 和温度到底是什么意思，值得先去 基础概念词典（/ai-dict/category/basics） 对一遍，再决定要不要加额外的字段；字段名不确定时到 AI 术语词典（/ai-dict） 交叉核对，别凭记忆拼。
流式和非流式要各写一条路径，别假设改个开关就能切。两种模式下返回体的结构、分片方式和用量统计位置都可能不同；一个实用做法是把用量字段顺手打进日志，后面算钱全靠它。
| 要盯的块 | 验证动作 | 常见差异点 |
|---|---|---|
| 鉴权与地址 | 每个站单独配 key 和 Base URL，各发一次最小请求 | 版本段缺失、多余斜杠、key 与地址错配 |
| 请求字段 | 先用最小组合跑通，再逐个加字段看是否生效 | 冷门字段被静默忽略 |
| 响应结构 | 流式与非流式各取一次完整响应比对 | 结束标记、分片边界不同 |
| 用量字段 | 把 token 用量写进日志并抽查 | 字段缺失或统计口径不一致 |
成本怎么算才不被糊弄
成本由输入 token、输出 token、是否流式、有没有开图片或工具调用共同决定。只看单价表会低估实际账单，因为很多站的计费口径和官方并不完全一致，尤其是附加能力。估算时可以用 Token 单价换算（/tools/token-price-calculator） 和 模型成本计算器（/tools/model-cost-calculator） 过一遍，具体数字以页面当时显示的为准，别记死。
多站并发时，给每次请求至少记三个字段：站点、模型、用量。月底才能拆出哪家贵、贵在哪个环节。要是只记总账，等发现异常时已经没办法回溯到具体请求了。
- 先按单价估一轮用站内计算器把典型请求的用量换成成本，得到量级判断，不必追求精确
- 再拿真实日志回填跑一批真实请求，用日志里的用量字段重算一遍，和估算值对差异
- 定位偏差点如果差异很大，重点查流式请求和附加能力的计费口径，这两处最容易出错
- 固化统计口径把统计脚本写死成固定字段，后续换站只换数据源不改脚本
上线前的检查清单与常见坑
连接层最常见的问题是 Base URL 拼错：少写版本段、多带一个斜杠，都会表现成调用失败，但报错信息往往不指向原因。上线前先在 接口测速（/tools/speed-test） 量一次延迟基线，记下来，后面出现变慢时才有参照。
行为层要自己定超时、重试和退避策略。重试前先确认接口是不是幂等，否则一次超时可能变成两笔账，这是多站接入里最隐蔽的坑之一。质量层的做法是：切到新站后，用同一批提示词对比输出，交付标准自己定，别依赖对方宣传话术。监控层把错误码分布和 token 消耗做成看板，别等账单出来才反查。
- 连接层：Base URL、版本段、斜杠逐项核对，并留下延迟基线
- 行为层：超时与重试策略写进代码，非幂等接口禁止自动重试
- 质量层：同一批输入跨站对比输出，差异超出预期就回退
- 监控层：错误码分布和用量做看板，设置异常告警阈值
兼容格式省的是迁移成本，不是验证成本；验证省下来的钱，最后都会以账单的形式还回去。下一步把你打算接入的几家站放到一起对比可信度和线路表现，先筛掉明显不稳定的，再动手写适配层，能少返工一轮。→
常见问题
兼容 OpenAI 格式的 API，是不是换个 Base URL 就能用？
很多情况下确实能跑，但别把它当成通用的保证。换站之后模型名、流式事件、错误码、用量统计这四块要分别验一遍。只跑通一次 hello world 不足以说明问题，建议用一组覆盖流式、工具调用、长上下文的请求做回归，再决定要不要正式切。
多家中转站能共用一套代码吗？
能，但要把站点差异收进配置层，别散落在业务代码里。建议把 Base URL、模型名映射、超时和重试策略做成一份站点配置表，请求层统一读配置。这样新增一家站只是加一条配置，而不是改代码；出问题时也能快速定位是哪家、哪一项配置导致的。
怎么判断某家站的兼容接口是不是真的按 OpenAI 口径返回？
不用通读文档，用采样比对更实在：同一组请求分别发到官方和这家站，看返回结构、字段是否齐全、用量统计是否对得上。结构一致但某字段常年为空，就按「未实现」处理。站内的验证工具可以配合用，但最终以你自己这条业务链路跑通为准。
