中转站 api 和官方 api 有什么区别

很多人第一次接大模型接口时都会卡在同一个岔路口：直接用官方 API，还是走中转站？两边都有人推荐，但推荐理由往往互相打架。这篇不站队，只把两类接口在稳定性、接入成本、协议口径、计费与风险上的差别拆开讲，并给出几条能立刻动手验证的检查动作，让你按自己的项目情况做决定。

很多人第一次接大模型接口时都会卡在同一个岔路口：直接用官方 API，还是走中转站？两边都有人推荐，但推荐理由往往互相打架。这篇不站队，只把两类接口在稳定性、接入成本、协议口径、计费与风险上的差别拆开讲，并给出几条能立刻动手验证的检查动作，让你按自己的项目情况做决定。

先说一个容易踩的误区：中转站和官方接口在上层代码里经常长得一模一样，都是「一个 Base URL 加一把 Key」，但这只说明协议外壳接近，不代表底下的链路、账号体系、配额池子也一样。中间可能多了一到两层转发，也可能被合并在某个共享资源池里。所以别用「代码改不改得动」当唯一判断依据，那只说明能不能接上，不说明接上以后稳不稳。

先分清：差的不是「谁更强」，是几层东西

官方 API 和中转站 API 的差异，不在模型本身谁更聪明，而在请求从你的服务器出发到模型返回这一路上，经过了几层、被谁管着、按什么规则结算。把这条链路拆开，你才能对着自己的项目逐项判断哪一层是你能接受的，哪一层是碰不得的。建议的判断顺序是：先定协议，再定链路，最后才是比价格。

网络链路

官方通常是你的服务器直连它的入口；中转站中间至少多一层转发，这一层在哪里、怎么调度，你看不到。

账号与配额

官方按你的账号额度走；中转站可能是它自己的多个上游账号组成的池子，你的用量和别人的用量共享资源。

协议兼容程度

基础对话补全两边往往一致，但流式行为、工具调用、结构化输出这些边角字段未必都能对齐。

计费与结算方式

官方是按量或按套餐直接计费；中转站有自己的折扣结构和结算周期，单价标签不等于你最终实际单价。

注意这里说的「差异」不是好坏判断，而是风险落在谁头上。走官方，链路的问题基本是官方和你自己网络的问题；走中转，多出来的那一层稳定性由对方负责，你只能通过实测和观察去估计。所以下面每一节，都尽量给你能自己动手验的动作，而不是让你信某个结论。

稳定性拆成四段看，别只盯「能不能通」

「能不能通」是最低标准，真正消耗开发时间的是那四类更细的问题。把它们分开看，你才好判断某个中转站给出的「稳定」到底指哪一层。同一句话在官方和在部分中转站上，实际落到哪个模型、走哪条线路，未必一致，这也是稳定性判断里最容易被忽略的一环。

• 可用性：官方看的是你自己账号的额度和区域可用性；中转站还多一层它自己的上游是否健康、池子里有没有可用资源。
• 延迟：多一跳转发通常抬高空载延迟，但如果你的服务器在国内而官方入口在境外，国内直连的中转有时反而把跨境往返压下来，要按你的部署位置实测。
• 限流：官方按账号分档限流，规则相对透明；中转站可能在它内部做了共享池，别人的高峰期用量会波到你身上。
• 长尾故障：超时、半截断流、返回格式偶发不一致，这类问题比整体宕机更消耗开发时间，也更难复现。

如果你打算把这条链路写进对外承诺，比如产品里明确写了响应时间，那第三段和第四段的风险要特别小心，因为它们不是「偶尔慢一下」，而是可能直接导致请求失败或返回不完整。这种情况下偏保守的选择是让核心链路走可控的入口，具体怎么权衡见后面选型那节。

接入成本不只是钱：钱、人、时间三笔账

很多人一比就是比单价，但接入成本其实是三笔账：花了多少钱、搭进去多少人力、以及从决定到上线花了多少时间。这三笔在不同阶段权重不一样，早期看时间，跑量以后看钱，出故障的时候看人。

这里不要凭记忆去记具体数字。价格、折扣、赠送额度这些东西变化很快，去 官方 API 资料页（/official-api）看各家的计费口径，再到 价格追踪页（/price-watch）核对当时的数字，比你脑子里那个旧印象可靠。

人力这笔账最容易被低估。官方接口出问题，你查的是自己的代码和官方状态；中转站出问题，你还要先判断是它挂了、还是它的上游挂了、还是协议被改过了。一个 5 人小团队如果没人专职盯运维，这笔隐形人力成本要在选型时先摆到桌面上。

协议兼容：能跑通和跑得完整是两回事

「OpenAI 兼容」这四个字被用得很宽。很多中转站在最基础的对话补全上确实能跑通，但一旦用到更复杂的字段，差异就冒出来了。如果你只发一句 prompt 收一段文字，两边差别很小；真正拉开差距的是那些边角能力。

• 流式输出：分片边界、结束标志、中途异常时的收尾行为，各家处理未必一致。
• 工具调用：参数字段、返回结构、多轮之间的拼接方式，是兼容度最容易露馅的地方。
• 结构化输出：约束字段和校验失败时的错误体，接之前最好实测一轮。
• 多模态入参：图片、文件的传法和对返回格式的要求，差异比纯文本大。
• 错误码语义：非 200 状态下的错误体长什么样，决定你的重试和降级逻辑怎么写。

做法上别只看文档：拿一份你项目里最复杂的那类真实请求，对两边各打一遍，重点看流式分片边界，以及故意造一个错误请求时返回的错误体结构。协议层的字段细节可以对照站内的 兼容接口形态说明（/openai-compatible-api-shape） 和 兼容字段对照页（/openai-api-compat-fields）逐项核。

动手验证：三步把不确定性压下来

光看文档和别人的说法没用，最省事的办法是自己跑一轮。下面三步从小到大，做完基本能对某个中转站当前的状态有个数。验证一定要在你真实使用的时段做，凌晨测出来的结果不代表白天高峰期。

1. 第一步：确认它当前活着用 在线实测工具（/tools/verify）做一轮探测，看接口是否真的可达、响应形态是否符合预期。这一步只排除「已经不能用」，不代表稳定。
2. 第二步：量自己的延迟基线用 测速工具（/tools/speed-test）从你自己的网络环境测，跑一段时间看波动，而不是只测一次就下结论。记录平均耗时和长尾耗时两个数。
3. 第三步：对拍核心请求把你的核心请求（含流式、含工具调用）写成一小段脚本，对官方和中转各跑一轮，把失败率、耗时分布、错误体记下来对比。跑够样本量再判断，别用三五次的结果定生死。

这三步做完，你手上就有了一份自己的对比数据，而不是别人的推荐语。需要提醒的是，这类实测反映的是当时的状态，中转站的后端配置可能变化，所以如果你真的要长期依赖它，最好把这种检查做成定期动作，而不是一次性任务。

什么情况选官方，什么情况考虑中转

没有普适答案，只有适配你项目的答案。下面给一组判断标准，按「什么情况下不建议走中转」先划红线，再谈什么情况可以考虑，最后说混合用法。

混合用法也成立：核心链路走官方，实验、铺量、非关键任务走中转。但要注意 Key 和额度分开管理，别把两边的配置混在一个地方，否则换源时容易漏改。另外，如果你把接口写进了对外承诺的 SLA 场景，无论选哪边都要先想清楚责任归谁。

万一要换源：留好退路的几个动作

选型不是一锤定音，半年后回头看可能需要换。所以真正划算的做法不是现在选对，而是让换源这件事变得便宜。下面几个动作建议在接入的第一天就做，不然后面改起来很痛苦。

• 把 Base URL、模型名、鉴权方式收敛到配置里，别写死在业务代码中。
• 抽象一层薄薄的调用封装，让上层不感知具体供应商，换源时只改一处。
• 日志里记录请求耗时、状态码、上游标识，方便事后判断到底是哪一段出的问题。
• 保留一份官方直连的可用配置作为备份，平时不用也要定期验证它还通。

这四条里，最容易被跳过的是最后一条。备份配置不验证，等到真要用的时候才发现早就不能用了，等于没有备份。可以把它挂到定期任务里，跑一个最轻量的请求确认通路即可。

选官方还是中转，问的不是哪边更好，而是哪边的风险你能接住、哪边的成本你算得清。