有个提问在中转站用户群里几乎每周出现一次：
"我就跑了个小脚本，充的 100 块三天就没了，这正常吗？"
底下通常有人回"你是不是开了长上下文"，"是不是流式没关"，"会不会被刷了"。这些都有可能，但都绕开了一个更根本的问题——你根本没有一个办法去验证它到底扣了你多少。
今年 7 月证券时报的调查报道里，把这个行业最普遍的问题摆到了台面上：部分中转站点通过虚报计费、模型掉包、退款套利等方式牟取不当利益。而 8 月腾讯新闻的深度报道写得更直白——中转站是"一层双向透明的流量跳板"，你的每一次请求、模型返回的每一段内容，都要先经过它的服务器；在这套结构下，"用户的用量统计、费用结算，完全由中转站后台自定义篡改，没有任何官方核验渠道"。
那篇报道里有一句话值得抄下来：
用户实际消耗一万 token，后台可随意记录为两万、三万，超额部分全部化为纯利润。普通用户无法溯源、无法对账。
这不是危言耸听，这是这门生意的结构性特征。律师事务所在拆解中转站盈利手段时，把"虚报 Token"单列为一类：正常情况下 1 个汉字消耗 1.5 到 2 个 Token，后台可以扣 3 到 4 个；与之并列的另外四类是薅免费额度、退款套利、模型掉包、卖用户数据。
所以这篇不打算讲"我们多透明"这种自说自话。这篇只给一套方法：不管你用的是哪家中转站，包括我们，你都可以在半小时之内，自己把账算一遍。
---
先理解：黑箱到底黑在哪一段
一次 API 调用的费用，链路是这样的：
你的请求 → 中转站计量（A）→ 转交上游 → 上游返回 usage（B）→ 中转站按倍率折算（C）→ 扣你的余额（D）
四个环节，你能看见的通常只有最后一个 D：余额少了。
- A 段是中转站自己数的 token，数多少它说了算；
- B 段是上游真实返回的用量，这一段你看不见；
- C 段是倍率，前端标 1.0，后台按 3~5 倍扣，你也看不见；
- D 段只剩一个数字，你连它是怎么算出来的都不知道。
媒体报道里提到过一个很典型的做法：表面卖 1 美元 100 万 Token，实际扣费按 3 到 5 倍的倍率计算。还有更隐蔽的——在高峰期自动降配，把顶配模型悄悄切换成低成本版本，你花的是 Opus 的钱，拿到的可能是一个开源小模型的输出。从业者的原话是："如果扣费快得不正常，大概率就是对方暗箱操作了。"
理解这一点很重要：问题不在于"会不会被坑"，而在于你有没有一道自己能跑的校验。 下面这五步，就是那道校验。
---
第一步：核对倍率——前端标价和真实扣费是不是一个数
倍率是中转站自己设定的结算系数：你实际扣费 = 请求成本 × 倍率。
很多站点会用分组倍率做价格阶梯，比如 0.15x / 1x / 1.5x / 2.8x，并暗示"倍率越低越划算"。但行业里有个反直觉的规律：倍率越低，掺水的可能性越大。有中转商在介绍分组时，直接给最低档标注"不够纯，介意勿用"——这句话本身已经把话说完了。
怎么验：
- 充值一个固定小额，比如 10 元；
- 记下充值后余额；
- 发一个内容完全固定的请求（建议用一段你已经写死的 200 字中文）；
- 记下扣费金额，重复 20 次；
- 用第 20 次的余额差 ÷ 20，得到单次真实扣费；
- 拿这个数字，去对比该站公示的"模型单价 × 倍率 × 你的 token 数"。
判定标准：真实扣费与公示口径差距超过 10%，这家就不值得继续。 不要接受"系统有误差"这种解释——计费系统如果是自己写的，误差只会往一个方向偏。
---
第二步：核对 token 数——自己数一遍，别信它的 usage
这是最直接的一步，也是最能暴露问题的一步。
API 响应里一般会带 usage 字段（prompt_tokens / completion_tokens）。问题是，这个字段由中转站填充，它想填多少填多少。你需要一个第三方参照系。
怎么验（以 Python 为例）：
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
text = "把你要发的那 200 字中文原文贴在这里"
mine = len(enc.encode(text))
# 发请求后，取响应里的 usage
# resp.usage.prompt_tokens
diff = abs(resp.usage.prompt_tokens - mine) / mine
print(f"本地计数={mine} 平台计数={resp.usage.prompt_tokens} 偏差={diff:.1%}")要点有三个：
- 用固定的原文，不要每次换内容，否则没法比；
- 中文按 1 个汉字 1.5~2 个 token 估，如果你的本地计数和平台计数差出一倍以上，那就不是分词器差异，是计量差异；
- 连续跑 20 次取平均，避开单次抖动。
判定标准：平均偏差 >15% 就要警惕，>30% 建议直接换。 媒体报道里"1 个汉字扣 3~4 个 token"的做法，在这一步会暴露得非常彻底。
---
第三步：核对模型——你买的是不是你拿到的那个
模型掉包是比虚报 token 更伤的一种，因为它骗的不只是钱，还有你的判断。
你付的是顶级模型的价格，拿到的是开源小模型的输出——最要命的是，你很难第一时间察觉。因为小模型的输出也通顺、也像回事，只是"好像笨了一点"。很多用户会归因为"今天模型状态不好"，然后继续充钱。
怎么验（挑三个高区分度的探针）：
- 身份探针：直接问"你是哪个模型，版本号是多少"。掉包站往往在这一题上露馅——它要么答非所问，要么报出一个和你购买的不一致的名字。
- 长链条推理：给一道需要 5~7 步推理的多步数学题或逻辑题。小模型在长链条上掉链子的概率远高于旗舰模型。
- 指令遵循：给一条嵌套的三层约束（比如"用 JSON 输出，字段名必须全小写，且第三个字段的值必须是前两个字段的字符数之和"）。这是大小模型差距最明显的地方。
判定标准：三个探针里挂掉两个，你手上的大概率不是你买的那个模型。 更进一步，可以在不同时间段各跑一次，如果质量随时间明显波动，那就是有人在后台做切换。
---
第四步：核对时段——高峰期有没有被"自动降配"
这一条最少人做，但也最能说明问题。
怎么验：
- 准备一个固定的测试集（10 条请求，内容完全固定）；
- 在工作日上午 10 点（高峰期）跑一遍，记录每条的响应质量打分与耗时；
- 在凌晨 3 点（低峰期）用同样的测试集再跑一遍；
- 对比两次的响应质量与耗时。
正常情况下，高峰期会慢一些，但质量不应该有系统性下降。如果高峰期的输出明显更短、更敷衍、更容易漏指令，同时你的 token 消耗反而持平甚至更高——那你大概率遇到了"高峰期自动降配"：把顶配模型悄悄切换成低成本版本，钱照收。
判定标准：质量出现时段性系统差异，就是降配的强信号。
---
第五步：核对明细——能不能把每一笔都导出来自己加总
前四步是抽样，第五步是结构性验证，也是最重要的一步。
问你的中转站一个问题：我能不能导出逐条调用明细，自己加总后和账单对上？
一条合格的调用明细，至少要包含这些字段：
- 时间戳（精确到秒）
- 使用的模型名
- prompt tokens / completion tokens
- 本次花费
- 请求状态（成功 / 失败 / 超时）
判定标准不是"有没有明细"，而是三件事：
- 能不能导出（不是只能在前台翻页看）；
- 能不能加总（导出的花费列加总，应该等于你的消费总额）；
- 失败的请求扣不扣钱（这一条很多人忽略了——失败的调用如果照样扣费，你的钱就在为别人的故障买单）。
如果一家站点只能告诉你"你这个月花了 87.4 元"，却拿不出逐条明细，那这 87.4 元本质上是一个不可证伪的数字。这不是"体验不好"，这是计费不透明。
---
顺带说一句：为什么"越便宜越危险"在这件事上是成立的
把这五步连起来看，你会发现一个闭环：
中转站的低价，要么来自补贴，要么来自成本端造假。而成本端造假最省事的两条路，恰好就是虚报 token 和模型掉包——它们都不需要任何技术门槛，只需要改后台的一个数字。
行业里流传的那句"看到满血旗舰模型 0.2 倍率甚至更低时，要意识到这并不合理"，就是这个意思。官方 Opus 级别模型输出价摆在那里，有人能长期按官方价的两折卖给你，多出来的那一块，一定是从别的地方补回来的——要么是别人的退款套利，要么是薅来的免费额度，要么就是你自己的 token 计数被多记了一倍。
所以选型的顺序应该是：先验证计费可不可对账，再谈便宜几毛。 一个能对账的 1.27 倍，和一个对不上账的 0.2 倍，前者的真实成本大概率更低。
---
我们自己：能给什么，给不了什么
按我们的规矩，能力边界一律两段式写，不夸大。
能给的四条：
- 单一倍率 1.27×，价格字典真实落库可查——不做 0.15x / 1x / 1.5x / 2.8x 那套分组倍率迷宫，也就没有"前端一套、后台一套"的空间。倍率是多少就是多少，写进数据库，不靠口头承诺。
- 调用明细可导出对账——每条含时间戳、模型名、token 数、花费、状态，你可以导出后自己加总。加总对不上，以明细为准，我们复核。
- 模型即官方模型，不存在掉包——上游是火山引擎官方渠道（第一类：官方授权聚合），我们这层只做转发与计量，没有替换模型的动机，也没有这个动作。
- 上面五步，欢迎拿来对着我们跑——尤其是第二步的 token 计数比对和第五步的明细加总。这两步跑完，你就能判断我们是不是在说实话。
给不了的两条，也说清楚：
- 我们给你的 token 数，同样是我们这一层的计量结果，你拿不到上游火山引擎的原始结算账单去逐条比对——那是我们与上游之间的商业协议数据，无法向第三方公开。我们能承诺的是：倍率公开、口径固定、明细可导出可复算；如果你发现明细加总与扣费不符，以明细为准，差额我们退。
- 目前火山方舟只激活了 1 个模型（DeepSeek-V4-Flash），模型广度确实受限。如果你需要多模型横向选型，现阶段我们不是最优选，这一点不绕弯子。
---
最后：把合规那条线也补上
8 月 28 日，"清朗·整治 AI 应用乱象"专项行动第一阶段成果公布：累计处置违规网站、应用程序、智能体等 AI 产品 1.4 万余款，清理违法违规信息 600 余万条，处置账号 2.6 万余个，下架违规 AI 商品 1300 余个。第二阶段已经启动，聚焦虚假信息、低俗内容、假冒仿冒、侵害未成年人权益、网络水军等突出问题。
把它和计费黑箱放在一起看，逻辑是通的：一个敢在 token 计数上动手脚的站点，你在它那里留存的 Prompt、文件、代码，安全性同样没有保障。 计费透明和数据安全，从来不是两件事，而是同一批人做选择时的两种表现。
所以那五步不只是为了省钱。它其实是一道更便宜的尽调——半小时就能跑完，比任何销售话术都可信。
---
延伸阅读：
- 《2026 中转站横评：Yady vs TeamoRouter vs 硅基流动 vs OpenRouter，四维度照着选》→
/blog/relay-benchmark-2026.html - 《你的公司要过等保 2.0 三级了？先问一句：中转站这一环卡不卡你》→
/blog/dengbao-level3-relay-gate.html - 《你的 API Key 经过了谁的手：一次请求的数据流向》→
/blog/where-your-key-flows.html - 《中转站调不通上游？先跑这份自检清单》→
/blog/relay-not-working-selfcheck.html
