中转站对比 love

打开几家中转站的报价页，看着都差不多：模型列表一样长，价格差一截，客服都说自己稳。真要比出高下，得有统一的比较维度——同一批指标去量每一家，量完自然有排序。这篇给的是这套维度怎么定、每一项用什么动作去验证，以及哪些情况下这套比法不成立。

打开几家中转站的报价页，看着都差不多：模型列表一样长，价格差一截，客服都说自己稳。真要比出高下，得先有统一的比较维度——同一批指标去量每一家，量完自然有排序。这篇不给你排名，给的是这套维度怎么定、每一项用什么动作去验证。

横向对比最容易犯的错，是先看单价再倒推其他。顺序反过来更靠谱：先按自己的使用场景给稳定、计费、售后排权重，再逐项找证据。下面拆成五个部分，前四部分是比较动作，最后一部分说清这套比法什么时候不成立。

先定三个比较轴：稳定、计费、售后

三根轴各管一件事，别混在一起问客服，否则对方一句「我们很稳」就把你带过去了。稳定的核心不是「不挂」，而是延迟和失败率在什么时候变差；计费比的是口径是否统一，不是单价高低；售后比的是响应结构，不是话术热情。

• 稳定：工作日高峰、深夜、模型切换时各测一轮，看的是波动而不是平均值
• 计费：倍率、分组、最低扣费、上下文是否重复计费，逐项对齐后再谈贵不贵
• 售后：有没有工单入口、多久首次回复、故障时是先发公告还是等用户来问
• 权重按场景排：跑批处理重稳定，做 demo 重计费透明，长期放量重售后

排权重的具体做法：把自己最近一周的调用场景列出来，标出「挂了会丢单」和「挂了重跑就行」两类，前者直接压稳定权重，后者可以把计费透明往前排。这一步做完，后面的对比才有主次。

稳定性拿证据，不拿感觉

「稳不稳」是可以量出来的，前提是量的时候变量可控：同一台机器、同一条网络、同一批提示词，分几个时段各跑一轮。如果只在网络好的时候试两下，得到的结论没有参考价值。

1. 量自己的延迟基线用同一批提示词，在工作日高峰和深夜各跑一轮，记录首字延迟和整段完成时间，先搞清自己这边网络的底色。
2. 对照站内实测数据把自测结果和站内测速工具上的失败率、响应分布对照，看同一模型的偏差是否在可接受范围，差太多就要追问原因。
3. 问清限速与并发口径是账号级还是密钥级限速、超了是排队还是直接报错，这两点直接决定你高峰期会不会整批失败。
4. 观察故障恢复方式故障时是切换上游、降级模型还是长时间不可用，你能否接受这种兜底，取决于业务对中断的容忍度。

计费横向比：把报价单翻译成同一句话

不同站的计费单位、分组、倍率写法都不一样，直接比数字没有意义。统一换算是唯一办法：把各家口径都折算成「跑完我自己那个真实任务，大概要消耗多少」。具体数字随活动变动，到站内价格监控页核对当时的报价。

• 小额实测后对一次账，用实际消耗反推报价口径有没有隐藏项
• 把「失败重试是否计费」写进自己的验收清单，这条最容易被忽略
• 包月类套餐要问清超出后的自动扣费方式，避免被动续费
• 任何口径都让对方给文字说明，群聊里的口头承诺不算数

如果发现某家的账单比自测预期高出一截，先别急着下结论，把长上下文、缓存命中、失败重试这几项逐个排除，通常问题就出在这里。

售后看结构，不看话术

售后不是看客服回得快不快，而是看遇到问题时有没有固定通道和可预期的流程。只有群聊、没有工单入口的站，出问题时你排队靠运气；有工单和公告位的，至少知道去哪找人、什么时候有回应。

工单入口

决定问题有没有记录和跟进，只靠群聊的站建议降低权重

公告位

涨价、限速、分组调整会不会提前说，决定你能不能提前排期

责任分界

模型报错、余额异常、账号风控分别找谁，开工前就问清

故障沟通

故障时是先公告还是等用户来问，这影响你的排查成本

不适用的情况也要说清：单价极低的按次套餐，通常是用低价换掉了售后投入，别拿同一套售后标准去要求它；反过来，如果你的业务中断一次成本很高，那这类套餐本来就不该进你的候选名单。

这套比法什么时候不成立

横向对比不是万能的，下面几种情况照做反而浪费时间。先把这些边界划出来，能省掉不少无效调研。

• 任务量太小：只是跑几次试用，比稳定的收益低于直接试错和比价的成本
• 上游不透明：渠道来源说不清时，你比的只是转售层，稳定性随时被上游变化推翻
• 合规要求高：涉及敏感数据，先看数据可见性与合规边界，稳定和价格都要让位
• 需求会变：先按当前模型和量级比，扩容或换模型后要重新跑一遍对比
• 没有基线：自己连延迟基线都没量过，任何横向结论都是别人给的

判断标准很简单：如果你没法说清「挂了会损失什么」，那稳定这一轴的权重就先给个中间值，等业务量上来再重排。对比结论隔一段时间要刷新一次，因为上游和中转层的口径都会变。