你在客户端里把 Base URL 一改就连上了中转，聊天挺顺，于是想顺手把整份 PDF、一段视频、一个带图的提示词也发过去，结果要么报参数不认识，要么图直接丢了。问题不在你的代码，而在中间那一层只实现了官方协议的一个子集。这篇按四个维度拆开对比，帮你判断哪些调用可以走中转、哪些必须回官方，以及回不去时怎么绕。
你在客户端里把 Base URL 一改就连上了中转，聊天挺顺，于是想顺手把整份 PDF、一段视频、一个带图的提示词也发过去，结果要么报参数不认识，要么图直接丢了。问题不在你的代码，而在中间那一层只实现了官方协议的一个子集：它能转的它转过去，转不过去的字段它不报错，只是悄悄丢掉。
这篇按协议兼容、多模态与长上下文、限流配额、结算方式四个维度拆开对比，帮你判断哪些调用可以放心走中转、哪些必须回官方，以及一时回不去的时候怎么在本地绕一下。结论不是「中转一定差」，而是「哪些用法走中转会掉功能」，先对齐这个再选路线。
协议兼容：中转多半给你的是 OpenAI 形状的壳
官方 Gemini 走的是自己的 REST 与 SDK 调用方式，中转站通常只暴露一层 OpenAI 兼容接口，把请求翻译过去、拿到结果再翻译回来。对你来说好处是客户端不用改，坏处是这一层翻译是有损的：它按自己支持的字段集来映射，其余字段直接忽略。
最容易被吞掉的是多轮对话的组织方式、系统指令、工具（函数）声明、结构化输出约束这几类。它们在不同协议里的表达并不一一对应，翻译层映射不上时通常不报错，而是静默失效——你看到的是一段通顺的回答，实际上系统指令根本没传过去。
- 自查动作：准备同一条请求，必须同时包含系统指令和一个工具声明，分别打官方端点和中转端点
- 把两次返回的原始 JSON 都存下来，逐字段对比，重点看系统指令有没有被并入首条用户消息、工具声明有没有被降级成普通文本
- 不要只看回答像不像，像不代表参数传对了；同一条提示词换两次措辞，行为不一致往往就是字段被吞的信号
- 给工具调用写个断言：如果返回里没有结构化的调用块，说明这条路走中转拿不到原生能力
功能完整性：多模态与长上下文最容易掉
多模态输入是最常被砍的一块。图片、音频、视频、PDF 直传，中转端要么只收文本字段，要么在中间把附件转成一段文字摘要再喂给模型。后者更隐蔽：你以为发的是原图，模型看到的其实是别人写的图注，原始信息你事后无法还原，也很难判断错在谁。
长上下文同样会打折。上下文窗口和单次输出上限常被中转端按自己的成本口径设一个天花板，超出就截断或报错，而不是按官方口径原样透传。依赖整篇文档理解的用法，在这种链路下会得到「读了一半就开始回答」的结果，而且不告诉你读了哪一半。
| 你的用法 | 走中转的典型结果 | 替代方案 |
|---|---|---|
| 图片/音频/视频直传 | 附件被转文字或直接丢弃 | 抽成独立链路走官方端 |
| 整篇长文档理解 | 上下文被截断，只见前半段 | 本地先分段摘要，再送摘要 |
| 原生函数调用 | 降级成文本约定，解析不稳定 | 在应用侧自己解析并校验 |
| 结构化输出约束 | 约束被忽略，返回自由文本 | 本地加一层解析与重试 |
判断标准很简单：先把你实际要用到的能力列成清单，逐条在两端各跑一次最小用例。跑不通的那几条，就是这次不能走中转的部分，不必纠结整体好坏。
限流与配额：谁在替你排队，谁在替你计数
走官方时配额绑在你自己的项目上，你能看到用量和剩余，涨没涨心里有数。走中转时你共享的是该中转上游的池子，别人的高峰就是你的 429。同一个脚本，上午跑得好好的，下午集体超时，往往不是你的并发写错了。
更麻烦的是错误信息被吞。中转端常常把上游的真实原因简化成一句「限流」或「超时」，你按这个提示去调自己的并发，方向就偏了。遇到反复限流，先怀疑链路而不是先改代码。
- 阶梯加压测稳定档位从低并发起步，逐档往上加，记录每档的错误率；出现持续错误的那一档往下退一档，当作你当前的稳定值
- 给重试加退避重试必须带指数退避加随机抖动，并在队列里排队；无退避的立即重试只会把限流坐实
- 记录真实错误分布把每次失败的原始响应体落盘，观察是不是同一类错误；具体档位和当期配额口径，到 /tools/speed-test 和 /official-api 核对当时的数字
结算方式：按量、预付余额与不透明倍率
官方是绑卡按量结算，账单能按模型、按天拆开；中转是往余额里充值，扣费口径由中转自己定义。同样一段请求，不同中转扣掉的余额可能差出不少，而且这个差额不一定对应质量差异。
- 计费单位
- 是按 token 还是按次，按次的话长请求明显更划算
- 多模态折算
- 图片、音频、PDF 是否按另一种倍率计费，容易在账单里被忽略
- 失败计费
- 报错和重试的请求计不计费，这条最容易被漏看
核账别只看单次扣费。固定跑同一批请求，分别记下两端各自扣了多少，连续记几天看倍率是否稳定；波动明显，说明上游在换源，今天便宜的那家明天不一定还是它。价格和倍率的当期数字，到 /official-api 和 /sites/all 核对，别拿几个月前的印象做决策。
哪些用法必须回官方，回不去怎么绕
把上面的维度收成一条线：必须回官方的，是那些一旦被翻译层或中转端削弱、你就无法判断结果是否可信的用法；可以留在中转的，是结果错了你能一眼看出来、或者错了也不致命的用法。
- 必须回官方：原生多模态直传、依赖长上下文整篇理解、依赖官方特有的文件与缓存能力、需要按项目维度出账单
- 可以留在中转：纯文本批量处理、非关键路径的草稿生成、成本敏感且能容忍质量波动的场景
- 折中做法：把多模态单独抽成一条链路走官方，其余留在中转；或在本地先转文字再送，但要在提示里写明这是转述而非原图
- 收尾排查顺序：先确认协议字段有没有被吞，再确认能力有没有被砍，接着看限流，最后核账；顺序反了会白折腾很久
最后提一个判断习惯：任何「换掉 Base URL 就完全等同官方」的说法都值得怀疑，因为翻译层不可能覆盖全部字段。能跑通不等于功能齐全，只说明你这次没用到被砍的那部分。
下一步先按上面的能力清单在两端各跑一遍最小用例，再去看各家中转的当期倍率和稳定性记录，比直接听推荐靠谱得多。→常见问题
Gemini 走中转是不是就等于用不了图片和文件？
不一定，取决于该中转实现了多少。有的只做纯文本，有的支持图片但支持不了视频和原生文件接口。别听说明，自己拿一张图和一段音频各发一次，看返回里有没有真正读到内容，试过再决定这条链路要不要留。
为什么同样的代码，官方能跑，换成中转就报参数错误？
多半是字段对不上。中转提供的是 OpenAI 兼容形状，Gemini 官方那套参数名和结构并不一样，翻译层不认识的字段有的会被忽略、有的会直接报错。把两端返回的原始 JSON 存下来对比，比盯着报错文字猜要快得多。
怎么判断该不该把 Gemini 的调用整个切到中转？
按用量分：纯文本、量大、可以接受质量波动的那部分切过去；涉及多模态、长文档整篇理解、需要清晰账单的那部分留官方。切成两条链路多写一点路由代码，比事后发现功能掉了再回滚省事。
