怎么自己测中转站有没有偷换模型：三个五分钟做完的验证方法

群里经常出现这种截图：一道逻辑题，某个中转站的端点答错了，官网直连答对了，配文是「这家又降智了，赶紧换」。然后底下一串跟帖，有人当场拔线换站。

问题是，这张截图作为证据太弱了。大模型本身带随机性，同一个官方端点同一道题连跑十次也未必十次都对；采样参数不同、输出长度被截断、系统提示词被中间层塞了一段，都能让同一个模型在同一道题上翻车。拿一次失败去断定「端点被换了模型」，结论可能恰好是对的，但推理过程是坏的——坏的推理下次就会冤枉一家没做错事的服务商，而你也白折腾一次迁移。

所以这篇写的是三类自己动手就能跑完的验证方法，但每一类我都会把「它能证明什么、不能证明什么」写在方法后面。后半部分比方法本身重要。

一、先把那个常被引用的数字的出处说清楚

关于中转站偷换模型，流传最广的一个数据是：有学术测评论文测了 28 个中转站，45.83% 的 API 端点存在模型身份不匹配——你付的是高价模型的钱，实际提供服务的是更便宜的模型或国产模型。这条结论在中文社区被多处二手引用。

三点必须说明白：

第一，这是那篇测评论文的结论，不是我们实测的。我们没有这 28 家的账号，也没有跑过任何一次对比测试。本文所有方法写的都是「可以这样构造、预期会看到什么信号」，不是「我测过、结果是多少」。你看到任何一篇文章把这个数字说成自己跑出来的，先怀疑它。

第二，这是某个时间点对某一批端点的采集。它不等于「现在市面上一半的端点在骗人」，也不等于「另一半清白」。它的真正用途是给你一个概率量级：这件事的发生率高到值得你在接入前花五分钟自己验一遍，而不是高到可以让你预设每家都有罪。

第三，「模型身份不匹配」是个技术描述，不是道德判定。它涵盖恶意替换，也涵盖上游本身做了替换而中间层没有同步说明。这两件事的性质差得远，而客户端测试区分不了。

二、五分钟准备：先把变量固定住

没有基线的测试等于没测。所有三个方法都建立在同一件事上：同一条请求，同时打两个地方——中转站端点和官方直连端点——然后比差异。

开测之前把这几项固定下来：

• model id 写死，两边用同一个模型标识，不要一边写别名一边写全名。
• 采样参数显式写死，不要依赖默认值。两边的默认值大概率不一样，这是误判的头号来源。
• 输出长度上限显式写死，否则你会把「被截断」误读成「不会答」。
• 同一台机器、同一时间窗内发出，网络与排队因素才勉强可比。
• 原始响应完整存盘，包含 HTTP 状态码、响应头、完整响应体、请求耗时。不要只存你关心的那一段文字——你事后想归因时，缺的一定是你当时没存的那部分。

对照对象怎么组织，就是把 base_url、key、model id 三件事收成配置项，跑测试时只切 base_url。这层配置怎么摆见 模型接入的 base_url 与端点组织方式。顺手提一句：以力达云网关一期只接 DeepSeek 这个现状为例，它的对照基线就是 DeepSeek 官方端点，OpenAI 格式是 https://api.deepseek.com，Anthropic 格式是 https://api.deepseek.com/anthropic——这两个地址来自 DeepSeek 官方文档，不是我们编的。

三、方法一：长上下文测试

怎么构造。 准备一段明显超出小模型处理范围的长文本（自己拼的文档、日志、几章小说都行），在开头、正中间、结尾各埋一条互不相关的具体事实。埋的内容必须是你自己现场生成的随机短语——随机人名配随机编号那种，不要用网上流传的经典「大海捞针」题面，那些题面很可能已经进了训练数据，或者被上游针对性优化过。然后只问中间那一条。

进阶一点的问法是要求它做全局扫描类的事：某个随机标记在全文出现了几次、第几段和第几段说法冲突。这类问题没法靠读开头结尾蒙。

预期看到什么信号。 被换成小上下文模型的端点，典型表现有三种：直接返回上下文超限类的错误；悄悄截断，只回答开头或结尾附近的内容，对中间那条一无所知；或者干脆编一个看起来像答案的东西。第二种最值得留意——它不报错，所以你不看正确性就发现不了。

它能证明什么。 能证明这个端点实际可用的上下文窗口远小于它宣称的规格，或者中间层对长请求做了截断。这属于容量级证据，比较硬，因为它不依赖模型「聪不聪明」这种模糊判断，只依赖一条事实能不能被取出来。

它不能证明什么。 不能证明背后是哪个模型。同一个模型在不同部署上完全可以被配置成更小的上下文上限，这是部署选择不是身份问题。也不能区分「恶意换小模型」和「中间层做了上下文压缩或摘要」——后者有些产品是当作特性来做的，只是没告诉你。还有一种情况是端点直接拒收超长请求，那你连身份都没测到，只测到了一个配置上限。

四、方法二：复杂推理题，以及怎么不被缓存糊弄

为什么这类题能区分。 不同能力档位的模型，失败模式不一样：多步算术的中途出错、需要严格遵守输出格式时的走样、精确计数类任务的偏差。这些差异在统计上比较稳定，在单次结果上很不稳定——所以这个方法从一开始就得按「统计」来设计。

题怎么选。 只用答案唯一且能程序化判对错的题。自己写一个判题函数，跑完直接得到通过率。不要用主观题、不要让自己去人工感觉「哪个答得更好」，人的感觉会跟着预期走。

怎么避免被缓存糊弄。 三件事：

一是题目现场随机生成，把数字、人名、单位都做随机替换，每次换种子。固定题面的问题不只是可能被特判，更常见的是被缓存——上游的提示词缓存是真实存在的计费机制，DeepSeek 官方定价页就把输入 token 分成「缓存命中」和「缓存未命中」两个价位来计。你重复发同一条 prompt，很可能并没有触发同样的一次计算。

二是不要用社区流传的测试题。流传越广，越可能被上游或中间层做过针对性处理，也越可能已经在训练数据里。

三是多次采样看通过率，不看单次。把采样参数调到偏确定性的一侧，同一批题在两个端点各跑若干轮，比的是两条通过率曲线，不是两个答案。

它能证明什么。 能给出一个统计意义上的能力差：如果同题、同参数、同轮次下，中转端点的通过率系统性低于官方直连，这是「可能被降配或被替换」的信号。注意「信号」这个词——它是让你继续查下去的理由，不是结论。

它不能证明什么。 不能证明换成了哪个模型。不能证明是恶意：量化部署、中间层注入的系统提示词、默认采样参数不同、输出被提前截断，都会压低通过率，而其中有些是实现选择。更要紧的是，单次或两三次结果几乎什么都不能证明，因为模型输出本身就有方差。这个方法上最常见的错误就是跑了三道题就发帖定性。

五、方法三：元信息与一致性比对

怎么做。 同一条 prompt 发多份：同一时间段内多次、间隔几小时再来一轮、如果站点提供多条线路或多个渠道就每条各发一份，同时官方直连也并行发一份。然后把存盘的原始响应拿去做 diff。

看哪些地方。 响应体的字段结构有没有多出来或少掉的部分；返回里声明的模型标识与你请求的是否一致；错误语义是否符合上游官方文档的划分——比如上游文档把「余额不足」和「认证失败」分成两个不同的状态码，如果某个端点把各类失败一律压成同一个码，说明中间层重写了错误处理；还有用量统计上的差异，同一段文本在两边的 token 计数如果差得明显，值得追。具体字段叫什么名字，请以你的上游官方文档为准，不要照抄别人文章里的字段名，不同厂商的响应结构本来就不一样。

跨线路这一项单独强调：同一个 model id，在同一个站的不同线路上行为应该一致。第三方给中转站做筛选建议时，把模型一致性放在价格之前，并明确指出标注「差异明显」的线路有替换嫌疑。跨线路不一致是这三个方法里最省事的硬信号，因为你不需要官方基线也能发现它。

它能证明什么。 能证明中间层对请求或响应做了改写，能证明同一站内多条线路行为不一致。这两件事都不是猜测，是可复现的差异。

它不能证明什么。 这个方法的上限很低：元信息可以伪造。一个用心的中间层完全能把响应体改得和官方一字不差，所以「元信息全部一致」不能证明没有替换。它只抓得住粗糙的做法。另外它测不出任何服务端的事——你的请求内容有没有被留存、有没有被拿去做微调训练，任何客户端测试都测不出来，那只能看条款和看这家的历史。

六、三类证据的强弱，和四种常见误判

你观察到的现象	证据强度	最多只能支撑到什么结论
中间段事实取不出来、超长请求报错	较强	该端点实际上下文能力或截断策略与宣称不符
多线路对同一 model id 行为不一致	较强	站内线路供给不统一，至少有一条线路不是你以为的那条
通过率系统性低于官方直连	中等	可能被降配或替换，需要继续查参数与提示词注入
响应结构与官方不同	中等	中间层做了改写，性质待查
单次答错、偶发格式走样	极弱	什么都不能证明
延迟比直连高、偶尔超时	极弱	只说明链路多了一跳或在排队

对应四种最常见的误判，值得单独点出来：

误判一：一次答错就是降智。 方差被当成信号。判断标准应该是通过率而不是某一次输出。

误判二：延迟变高就是换了模型。 中转站在你和上游之间多加了一跳，排队、带宽、上游拥塞都会体现在耗时上，跟模型身份没有必然关系。

误判三：返回的模型标识和请求的不完全对得上就是作恶。 这里有个反例值得记住：DeepSeek 官方定价页的脚注里写得很清楚，某些旧模型名仍然可以调用，但对应模型已经下线，请求由新版本模型提供服务并按对应档位计费。也就是说，「同一个 model id 背后换了实际服务的模型」这件事，上游厂商自己公开地在做，而且有说明。中转站出现类似现象，可能是它照搬了上游行为，甚至可能是它不知道上游变了。要定性，得先去查上游官方文档有没有同样的说明。

误判四：「感觉变笨了」。 最常见也最不可靠。你自己的 prompt 在这期间也变了，你的耐心阈值也变了。这条只能当作「去跑一次方法二」的触发条件，不能当作数据。

为什么要这么小心：冤枉一家正常服务商，你付出的是一次无谓的迁移成本，而公共讨论里多一条没有证据的指控，下一个人做判断时的噪音就更大一点。这个市场里点名指控的成本几乎为零，所以噪音一直很多。

七、有些事测不出来，只能靠制度性判断

上面三个方法覆盖的是「模型身份」这一类问题。还有几类问题客户端测试碰不到：

• 日志去向。 只能看服务条款怎么写、看这家有没有公开上游来源。行业调查报道记录过，部分超低价站点的隐蔽利润来源就是把 prompt 与输出倒卖用于微调训练——这是报道的记录，不是我们的观察，也不针对任何具体商家。
• 供给稳定性。 报道也记录过号池拆分这种供给方式：一个订阅账号被拆给多个用户共用。这种供给天然不稳定，表现出来往往就是「时好时坏」，而你测的那一刻可能正好是好的。
• 存续与资金。 这跟模型身份完全是两件事，见 API 中转站的风险清单。

配合着看的判据：第三方给出的筛选顺序是先看评级与近 7 日可用率，再看模型一致性，最后才比价格；建议远离闲鱼、小红书上的不知名站点，避开「月抛站」，看运营时长、社群活跃度与口碑。另外有一条反直觉的：按第三方报告（apiranking.com 发布的 2026 大陆 AI API 中转站全景报告）某一次采集的结果，这个市场过去一年零新进入者，活站 86 家，报告因此判断行业已进入存量淘汰阶段。这是某次采集的快照，站点生死变动很快，但它带来的推论是稳的：在这个市场里，一家站点宣称「刚上线」「公测中」，本身就是个危险信号。更完整的判据清单见 怎么判断一个 API 中转站靠不靠得住，中转站这个环节到底在产业链什么位置见 API 中转站是什么。

八、这三招也请用在力达云自己身上

我们做的网关同样是中间层，没有理由豁免。把限制先摆出来：力达云网关是独立运营的第三方模型接入服务，与 DeepSeek 及其他任何模型厂商没有官方合作、代理或授权关系，也不是它们的关联方；一期只接 DeepSeek；模型的生成质量、可用性与响应速度最终取决于上游服务，我们不对模型输出本身作出保证；可用模型的增减、计费规则调整、频率限制变化以站内公告与控制台的模型列表为准。这些原话都在 网关服务条款 里，包括我们对上游关系的自我披露；本文这几种方法怎么用到我们身上、以及我们自己明确不占优的地方，另写在 怎么验证我们。

正因为一期只接 DeepSeek，上面三个方法在我们这里特别好做：对照基线就是 DeepSeek 官方端点，切一下 base_url 就能跑，长上下文、随机生成的推理题、跨时段的一致性比对，一样都不缺。请自己测，不要因为我们写了这篇文章就默认我们干净。

九、这三招测不出什么

这三个方法能抓到的是明显的替换：上下文能力对不上、线路之间行为不一致、通过率有系统性落差。它们抓不到的是「同一个模型但被降配」这一整类——量化部署、上下文被静默压缩、采样参数被改、系统提示词被注入、输出长度被压低。这些在客户端看起来都只是「有点不一样」，而它们造成的实际质量损失可能比换模型更大。

真要确定，只有一条路：拿官方直连做对照，而且是持续对照，不是接入那天测一次。做法上就是把你的评测集固定下来，定期在两个端点上各跑一遍，只看通过率曲线有没有分叉。这件事有成本，所以你得先问自己值不值得——如果你的业务对模型身份敏感到需要天天验，那结论也许不是「找一家更可信的中转站」，而是这一层中间件你本来就不该有。