很多人第一次看到中转站报价都会愣一下：同一个模型，官方按量算下来不便宜，中转站却低一大截，甚至低到让人怀疑是不是看错了小数位。这篇不劝你买也不劝你别买，只把「便宜从哪来」拆成几类成本来源，再告诉你每一类对应什么风险、该去站内哪个页面核对当时的数字。看完你应该能自己判断某家站点的低价属于哪一种。
很多人第一次看到中转站报价都会愣一下：同一个模型，官方按量算下来不便宜，中转站却低一大截，低到让人怀疑是不是看错了小数位。这篇不劝你买也不劝你别买，只把「便宜从哪来」拆成几类成本来源，再告诉你每一类对应什么风险、该去站内哪个页面核对当时的数字。
看完你应该能自己判断某家站点的低价属于哪一种。核心思路只有一句：价格差不是玄学，是上游进货方式、计费口径、运营投入这三层里至少有一层被省掉了，而每一层省掉的东西，都会在某个场景下变成你的成本。
低价第一层来源：上游拿货的成本口径不同
中转站自己并不生产模型能力，它赚的是进货和出货之间的差价。所以它的报价高低，第一眼取决于它的上游是什么渠道。同样叫一个模型，官方批量额度、云厂商转售额度、账号池折价额度、逆向接口，这几种进货成本天然不在一个量级，报出来的价自然也不同。
- 官方批量额度
- 最贵但最稳，通常是走官方商务合作或大批量预充，渠道可查、模型标识稳定。
- 云厂商转售
- 成本居中，走的是云市场上架的同款模型，价差来自云厂商的补贴和结算周期。
- 账号池折价
- 成本低，靠批量注册或采购他人额度拼池，随时可能断供或限速。
- 逆向接口
- 成本最低，绕过官方计费直接模拟调用，稳定性、合规性、模型真实性都最没保障。
这里有个常见坑：同一家站点里不同「分组」报价差很多，往往就是上游渠道不同。你先要搞清自己看的是哪一组，别拿 A 组的价去对标 B 组的服务，那没有意义。
- 到 /official-api 看官方按量基准，先建立一个「官方价」的锚点。
- 再到 /ai-nav/category/ai-api 比同模型在各家的倍率和额度口径，注意是对齐同一个模型名再比。
- 看到明显低于同行均价一大截的，先去它的公告或说明页找「渠道类型」四个字，找不到就当默认没有。
- 确认自己看的报价属于哪个分组，不同分组的实际可用模型可能完全不同。
第二层来源：计费和交付口径上的差别
就算上游一样，两家的报价也能差出好几倍，因为「算钱的口径」本身就不统一。你看到的那个单价，可能只是输入 token 的价，也可能包含了缓存命中的折扣，还可能把思考和推理产生的 token 算在另一栏。比价之前先把口径拉平，否则就是拿苹果对橘子。
| 口径项 | 常见差异 | 你要确认什么 |
|---|---|---|
| 缓存命中 | 有的按折扣价算，有的直接按原价算 | 你的业务里重复前缀多不多 |
| 上下文长度 | 超过某个长度后是统一价还是阶梯价 | 你的单次输入大概多长 |
| 输出 token | 是否包含思考、推理、工具调用的 token | 你的任务会不会产生大量中间 token |
| 计费方式 | 按量、按次、包月不限量混着报 | 你的调用频率是稳定还是忽高忽低 |
有的低价是把「按量」包装成「按次」或「不限量」，看着便宜，但落回到你自己的真实任务上，单位成本不一定低。比如你的任务输入很短、输出很碎，按次计费可能更划算；反过来长文本任务，按次就会亏。
- 先量自己的真实用量统计你过去一周的输入平均长度、输出平均长度、日均调用次数，写成三个数。
- 再套进计算器用 /tools/token-price-calculator 和 /tools/model-cost-calculator 按这三个数分别算几家的实际月度成本，别只看单价。
- 最后看波动容忍度如果你的调用量波动大，优先看有没有阶梯价或封顶机制，避免高峰期单次成本暴涨。
第三层来源：运营上的省法，也是风险最集中的地方
这一层最隐蔽。中转站没有自己的技术团队、和别家共用同一个上游、随时切换模型、不囤冗余容量、不做监控告警，这些动作都能把运营成本压下来，报出来的价也就更低。代价是你这边会碰到高峰期排队、半夜掉线、模型被悄悄换掉、报错没有人工处理。
不是所有省法都不可接受。关键是分清哪些省法是你能忍的，哪些是忍不了的。下面这几条可以当作接受与否的分界线。
- 渠道类型公不公开：公开了至少说明它不怕你查，全程含糊的要多留个心眼。
- 模型标识稳不稳定：同一个模型名是不是长期指向同一个后端，还是隔几天换一次。
- 愿不愿意让你小额实测：靠谱的站点不怕你测，怕你测的通常有原因。
- 故障时有没有可见的状态说明：哪怕是公告一句「上游抖动」，也比彻底失联强。
判断流程可以固定下来：先用 /tools/verify 做一轮在线实测看模型的真假和一致性，再用 /tools/speed-test 量出你自己网络到该站点的延迟基线，最后去 /sites 对照同类站点的用户反馈和存活时长。三步走完再决定要不要充钱。
什么时候「便宜」这件事本身不成立
低价不是万能的。如果你的需求是稳定长跑、企业合规、数据不出境这类，便宜方案背后的隐性成本——重试、迁移、返工、数据泄露风险——往往超过你省下的那点钱。这时候比价的意义不大，直接看渠道透明度和 SLA 更实际。
反过来，短期、低敏感、可随时替换的活儿，比如内部小工具的批处理、做原型时的试用、对结果要求不高的批量翻译，用便宜方案是合理的。同样的低价，放对场景就是省钱，放错场景就是给自己埋雷。
| 你的需求特征 | 便宜方案适不适用 | 判断理由 |
|---|---|---|
| 调用失败可以重试、结果可接受延迟 | 适用 | 重试成本低，稳定性差一点无所谓 |
| 要跑长期稳定任务、出错有业务损失 | 不适用 | 一次掉线造成的返工可能超过长期省下的钱 |
| 数据敏感、有合规要求 | 不适用 | 渠道不透明意味着数据流向不可控 |
| 只是原型或内部试用，随时可换 | 适用 | 迁移成本低，试错本身就值这个价 |
判断动作很简单：先写清你这批调用的失败容忍度和数据敏感级别，两个都低，便宜方案就值得试；只要有一个高，就先把渠道透明度和稳定性放在价格前面。
下一步拿你手头正在用的或想试的那家站点，去 /sites 看它的渠道说明和同类站点对照，再用 /tools/speed-test 量一次延迟基线，两件事做完你心里就有数了。→常见问题
中转站比官方便宜那么多，是不是一定有问题？
不一定，但便宜一定有来源。上游拿货渠道、计费口径、运营投入这三处任何一处省下来，价格都能明显低一截。你要做的不是看价格高低，而是问清它省的是哪一处。省在上游进货是正常生意，省在掺水换模型、不囤容量、随时跑路上，才是真风险。
同一家站里不同分组价格差很多，怎么理解？
分组基本对应上游渠道类型，进货成本不一样，报价自然分层。贵的那组通常走更稳的官方或云厂商通道，便宜那组可能是账号池或逆向。你要先确认自己需要的稳定性和合规要求，再决定选哪一组，而不是无脑选最便宜那档。
怎么判断一个低价站点值不值得先充一点试试？
先小额、先实测、先分散。用一小笔钱跑你自己的真实任务，重点看三件事：模型是不是真的、高峰期会不会排队或掉线、帐单和你的用量对不对得上。任何一项对不上，就先别加仓。具体跑什么任务、跑几轮，参考站内的试水清单类文章。
