openai 兼容格式的 api，一次讲清做法、成本和注意点

你在几个中转站之间来回切，发现同一段代码在 A 站跑通、在 B 站就报错，或者账单对不上。问题多半不在代码，而在兼容格式的边界和计费口径。这篇按“请求怎么发、钱怎么算、换站要注意什么”三块拆开讲，每块给出可直接照做的检查项。具体价格和模型清单不在这里写死，去站内对应页面核对当时的数字。

同一段调用代码，在 A 站跑得通，换到 B 站就 401 或 404，或者账单比你预估的高出一截。这类问题多半不在业务代码，而在两个地方：兼容格式的边界到哪为止，以及计费口径按什么算。前者决定你能不能换站，后者决定你换站之后还能不能控制成本。

下面按「请求怎么发、钱怎么算、换站注意什么」拆开讲，每块给能照着做的检查项和排查顺序。具体单价、模型清单这些会变的数字不写死，标出站内对应页面，自己去核对当时的数字。

兼容格式到底兼容了什么

不少人对「兼容」的理解是「换个地址就能用」，这个理解只对了一半。兼容通常指请求路径、鉴权头、消息体字段名、响应结构跟官方对齐，但模型能力、参数支持范围、限流策略、错误码含义，各家可以完全不一样。所以兼容意味着代码改动小，不意味着行为一致。

换站时真正要核对的只有三样：Base URL 拼到哪里、Key 放在哪个请求头、模型名怎么写。这三样对上了，请求大概率能通；对不上，报错往往还很有迷惑性，比如路径拼错返回的可能是网关的通用错误页，而不是明确的 404 说明。

• 参数层面：temperature、top_p、max_tokens 这类参数，各站接受范围不同，传了不报错不代表生效，以站内说明为准
• 模型名层面：同名模型在不同站背后可能不是同一版本，接之前用一句话提问测一下行为
• 能力层面：函数调用、结构化输出、图片输入这些，哪些站支持、支持到什么程度，要单独确认
• 可用性层面：动手改代码之前，先去 /tools/verify 这类检测页确认站点当下在线且能出结果

一次请求的结构，按块过一遍

把一次请求拆成四块看：鉴权、路径、消息体、响应解析。每块都有自己那一类常见错误，排查时按块定位，比从头读代码快得多。

1. 鉴权头请求头里带 Authorization，值是 Bearer 加一个空格再加 Key。Key 不要写进客户端代码或公开仓库，一旦怀疑泄露，立刻去站内后台停用并换新的。
2. 路径拼接确认 Base URL 是到 /v1 为止，还是本身就含 /v1，再拼 chat/completions 这类子路径。拼成双 /v1 或少了 /v1，表现就是 404 或者落到网关错误页。用 curl 打一次最小请求验证路径。
3. 消息体messages 是数组，每条要有 role 和 content，两个字段都别省。system 提示词是放数组第一条还是用单独字段，看站点说明，别想当然。
4. 响应解析非流式从 choices 里取第一条的文本；流式按 data 行切分，遇到固定结束标记就停。中间可能有空行或心跳行，解析时要跳过，别把它们当正文拼进去。

curl -sS https://你的站点地址/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"你的模型名","messages":[{"role":"user","content":"说一句话"}]}'

这段命令的作用是排除业务代码干扰，单看请求本身通不通。通了再往业务里接，不通就按返回的状态码走下面的排查表。

成本怎么估，别等账单出来才后悔

估算口径统一成一句话：按输入 token 加输出 token 的总量算。容易漏的是长上下文、工具调用回传的中间结果、以及多轮对话里整段历史每次都要重发，这些都会计入输入，量级可能比你以为的大。

单价口径各家不一样，官方直连价、中转价，按 token 计和按次计，可能同时存在。具体数字别照抄别人的文章，去 /official-api 看官方侧的挂牌，去 /price-watch 看中转侧追踪到的当时的数。

1. 跑最小请求用一句话的请求跑一次，把返回里的用量字段抄下来，作为单次调用成本的基准。
2. 乘调用量预估日均调用次数和平均对话轮数，乘上去。多轮场景记得把历史重发的部分算进输入。
3. 留重试余量失败重投可能重复计费，先确认上一次到底扣没扣。给重试留出额外预算，别按理论最小值卡死。

换站或加站时的注意点清单

接多家的核心不是写多套代码，而是把会变的东西抽出去。Base URL、Key、模型名这三样放在统一的配置层，业务代码只认配置键，不认具体站点的地址。

• 模型名映射表：同一个业务用途对应各站的实际模型名，换站只改映射，不改调用逻辑
• 超时分级：慢站给更长的读超时，重试走退避，别连续猛打把限流打成封禁
• 错误分档：先按 401 鉴权、404 路径、429 限流、5xx 网关四档归类，再往下查业务逻辑
• 回落策略：主站不可用时切到备站，切之前确认备站的模型行为大体一致
• 记录留痕：每次请求的站点、模型名、用量都落日志，账单对不上时这就是唯一凭据

什么情况下这套不适用：如果你的业务依赖某个站独有的能力，比如特定的函数调用格式或缓存机制，那就没法简单换站，得把该能力做成可选分支，缺了就走降级路径。

兼容格式省的是改代码的力气，不省核对参数和账单的力气。