最近和一些中转站供货商打交道，确实让我有些受够了。
正常做价格竞争，谁的采购成本低、线路稳定、服务到位，谁就更有优势。但有些供应商把模型换掉、把用量改掉，再拿低价来吸引用户。用户多花了钱，认真做服务的商家也跟着吃亏。
下面结合我在上游渠道对接中的亲自测试，聊聊几种掺水方式，希望大家后面选中转站时多留个心眼。文中的实测情况限于我测试过的渠道和当时的调用条件，本文不点名具体站点。
一、用便宜模型冒充昂贵模型
这种做法很直接：用户选的是昂贵模型，后台实际调用便宜模型，返回时仍然显示用户请求的型号。
以 gpt-6-astra 和 gpt-6.1-sol 为例：截至 2026 年 11 月 5 日，两者官方模型页列出的标准文本价格如下，单位为美元／百万 Token。
| 模型 | 普通输入 | 缓存输入 | 输出 |
|---|---|---|---|
| GPT-6 Astra | 10 | 1 | 50 |
| GPT-6.1 Sol | 2 | 0.10 | 10 |
这张表仅比较所列标准费率，不包含长上下文、缓存写入、加速模式、工具、区域和其他附加计价条件。最新价格以官方公布为准。
Sol 的官方定位就是以更低成本处理复杂工作，并在一些场景中接近 Astra 的表现。也正因为某些任务的效果差异不容易被普通用户察觉，如果有人拿 Sol 的成本、按 Astra 的名义交付，用户未必能从几轮聊天里看出来。
也就是说，用户请求 Astra，网关实际调用 Sol，却仍按 Astra 收费。如果用户事先知道并同意自动路由或故障回退，则不属于这里讨论的情况。
模型别名映射本来就是网关的常见功能。LiteLLM 等网关允许分别配置面向用户的模型名与实际调用的模型。因此，响应里显示 model: "gpt-6-astra"，并不能单独证明后面调用的一定是 Astra。
检验方法
可以用同一批复杂任务，固定上下文和推理设置，对比官方接口与中转接口的耗时、效果。长期存在明显差异时，就值得进一步查。
不过，Astra 不一定每个问题都比 Sol 慢。官方模型页没有公开完整参数规模，耗时还受推理预算、生成长度、缓存、排队、硬件、网络和服务档位影响。
比较时，至少应分开看首个有效输出的等待时间、持续输出速度、总完成时间和任务成功率。低延迟可能来自优化，高延迟也可能只是排队或网关缓冲。
服务商也可以故意延迟返回，所以仅凭耗时无法确认模型真假。
推理密文验证
OpenAI Responses API 中的加密推理项，主要用于在无状态等场景下保留和续接推理上下文，复用时存在模型家族和上下文条件。能返回一段密文，不代表客户可以据此独立验证本次调用所用的模型。
返回了密文、后续请求能接受这段密文，都不等于本次回答一定由指定模型生成。
在我亲自做过的渠道测试中，Astra 与 Sol 的推理密文在当时的调用条件下能够互通；我也测试过复用已生成内容的推理密文、重新包装返回内容的情况。这些是特定链路的测试结果，其他版本和接口需要另行测试。
做密文验证时，需要把密文来源、对应请求、后续续接结果和最终回答一起对照，不能只看是否通过。
规避方法
暂停追加充值，保留原始请求、响应和扣费记录；在固定参数下做多类任务对照，并要求服务商解释实际路由与回退规则。
如果还留有少量余额，又暂时无法退款，可以考虑改用标价明确的低价模型做低风险任务。不过，如果连用量和渠道都不可信，更换模型也解决不了问题。
二、修改 usage 返回信息
有些渠道用的是真模型，但把返回的用量和实际扣费放大了。
用户看到的是便宜的额度单价，实际使用时却发现余额消耗很快。假设同一项工作本应消耗 1 单位额度，系统却扣了 10 单位，那么“每单位很便宜”的宣传，并不能说明这项工作的实际成本便宜。
检查后续轮次
真实的 Agent 和长对话，会在后续轮次带上历史消息、工具定义、工具结果和新输入。有些问题也只有在这些轮次中才会显现。
首轮请求没有异常，不代表后面的扣费一定正确。测试要覆盖新会话、重复前缀、长对话、工具循环和失败重试，分别检查用量与扣费。
缓存读写挪账
比简单乘一个倍率更隐蔽的情况，是输入总量看起来没变，但计费类别变了：把应当按低价计算的缓存读取，记成价格更高的缓存写入。
下面用一笔假设账单说明问题。为避免混用厂商字段，先把输入整理成三个互不重叠的计费类别：
| 输入类别 | 实际用量 | 如果被错误改记 |
|---|---|---|
| 普通输入 | 10,000 | 10,000 |
| 缓存读取 | 80,000 | 40,000 |
| 缓存写入 | 10,000 | 50,000 |
| 合计 | 100,000 | 100,000 |
只看合计，两列完全一样。但如果这笔账单约定的普通输入、缓存读、缓存写的单价分别是 1、0.1、1.25，用同一计价单位计算：
- 正确计费权重：
10,000 × 1 + 80,000 × 0.1 + 10,000 × 1.25 = 30,500。 - 改记后的权重：
10,000 × 1 + 40,000 × 0.1 + 50,000 × 1.25 = 76,500。
两列 Token 合计相同，输入费用却相差约 2.51 倍。这是假设算例，不对应某次真实请求，也不包含输出及工具费用。
缓存读写费率取决于模型和缓存时长，不能把示例倍率套在所有模型上。同一批 Token 也不能重复算作普通输入和缓存写入。
缓存过期、前缀改变、推理配置变化或路由变化，也会导致缓存失效和重新写入。发现写入变多时，要结合请求记录检查原因。
对账方法
建议至少核对普通输入、缓存读取、缓存写入、输出、内部推理及工具费用；是否存在额外服务费和失败重试收费，也应说清楚。
不同 API 对 input_tokens、缓存 Token 和推理 Token 的包含关系不同。比如，部分接口的缓存用量是输入总量的子项，另一些接口则分别列出。不能把所有字段直接相加；已经包含在输出中的推理 Token，也不应再次加一次。
中转返回的 usage 和它自己后台显示的账单，通常来自同一套系统。两者数字一致，只能说明内部一致，不能替代独立核查。能提供对应的上游请求记录和计费依据，证据才更完整。
三、修改返回内容
有些服务商还会修改模型返回的内容，掩盖实际渠道。
以 Kiro 渠道为例，底层模型、调用渠道，以及 Kiro 附加的提示词和工具环境，都可能影响用户实际拿到的结果。
Kiro 提供来自 OpenAI、Anthropic 和其他供应商的模型。通过 Kiro 使用 Claude，并不意味着底层必然不是 Claude；但它也不能自动等同于用户理解中的 Anthropic 官方 API 直连。
如果服务商宣传某种特定渠道，却实际通过另一个产品渠道转发，再把回答中出现的产品名称替换掉，问题在于来源被隐瞒、返回内容被未披露地修改。
我亲自测试过 Kiro 渠道的返回内容被替换的情况：原本带有 Kiro 身份标识的回答，在对外返回时被改成了 Claude。用户看到的自我介绍已经被加工，实际调用渠道并没有改变。
这类案例的核查重点，是同一请求在链路中的原始返回与最终返回有什么差异。只展示一张“它说自己是 Claude”的截图，仍然不足以向读者完整说明加工发生在哪里。
检验方法
模型的自我介绍可能受到系统提示词、产品设定和会话内容影响。它自称 Claude，不足以证明渠道；它自称 Kiro，也不足以独立证明背后的具体型号。
在我测试过的 Kiro 调用方式中，产品附加的系统约束不能像直接调用原厂 API 那样由调用方自由控制，回答中也会出现 Kiro 的身份标识。其他版本和接入方式可能不同。检查时要看自己的提示词能否生效、Kiro 加入了哪些约束，以及服务商有没有说明这些差异。
所谓 CC Max、官转、纯净 等销售标签，也应由服务商给出可核查的定义。只看标签，无法确认账号类型、接口来源和服务边界。
全局替换的影响
如果粗暴替换模型返回的某个词，受影响的可能包括代码、文件路径、产品文档、引用原文和工具参数。用于讨论 Kiro 的技术文章，也可能被替换得前后矛盾。
四、多级转售的问题
中转服务可能存在多级供货：直接面向用户的站点向某个上游采购，上游又依赖别的聚合渠道。供货层级增加后，模型、配置、缓存和价格规则也可能经过多次转换。
最让人头疼的情况是，某一层已经做了模型映射或计费转换，信息却没有完整传到下一层。终端服务商自己没有核实清楚，仍然按上游的话术向用户保证。
用户遇到问题时，找的是收钱的服务商，不能只得到一句“上游就是这么说的”。
面向用户收费的服务商，至少应当能够说明模型与版本、渠道边界、回退规则、能力限制、计费公式，以及出了异常以后怎么核查和处理。涉及上游商业信息时，可以有合理的脱敏安排；但不能用“保密”代替一切解释。
这套要求也应当适用于 UnifyLLM。用户在查看模型价格或通过联系我们核查调用问题时，有理由要求费用与交付能被说明。
五、模型检测站的局限
模型检测工具通常只检测少量请求，无法保证后续调用都使用相同模型和配置。
需要分别看清它测了什么：接口格式、工具能力、行为相似度、固定测题结果，还是有独立依据的来源证明。这些不是同一个层次。检测失败也可能来自版本、参数、负载或兼容问题；通过则只说明它通过了当时那套规则。
如果规则过于固定、样本有限，服务端就有针对性适配的空间。它还可能只在被检测的请求上给出不同路由。这是测试设计需要防范的风险，不能因此倒推出所有检测站都在配合作弊。
GhostPrint 等研究也展示了较弱模型通过针对性微调模仿较强模型指纹、规避部分检测方法的可能性。实验结果不能直接推广到所有检测站。
如果检测页面同时卖推荐位、投放返佣链接或靠“验真认证”收费，更应检查它有没有披露商业关系、公开方法和误差。广告利益不自动证明结果造假，但读者需要知道它可能如何影响推荐。
看检测结果时，最好同时查看测试方法、原始样本和误差说明。
六、使用建议
- 小额、分阶段充值。 先验证真实任务、费用和售后，再决定是否扩大用量；对渠道有疑问时暂停追加资金。
- 固定对照条件。 同一模型版本、同样上下文、工具、推理配置和输出上限，再比较质量与费用。
- 覆盖后续轮次。 测试重复前缀、长对话、工具循环和失败重试，分别核查缓存读写与总扣费。
- 保存原始记录。 请求体、响应体或 SSE、时间、结束原因、用量与账单都要能对应；公开举证前先脱敏。
- 看每个成功任务的真实成本。 把重试、失败和人工返工一起考虑，不只比较充值页面上的数字。
- 把问题具体地问出来。 “这次为什么重新写入缓存”“这个字段有没有被忽略”“失败后回退到了哪里”，都比一句“你们是不是掺水”更容易得到可核查的回答。
如果服务商一直解释不清模型来源和扣费，建议停止充值，换个渠道。不要为了用完余额，再继续往里充钱。