新用户第一次选模型：先把一个后端的计费链路跑顺，再去横向比较其余

刚接入聚合站的新用户，最常见的错误是第一天就把六个后端全部配好，然后在同一段 prompt 上做横向对比。问题不在对比本身，而在于你还没搞清楚「一次调用在账上长什么样」，比较结果就没有统一的计量基准。

先固定一个默认后端

聚合站的价值是一个 API key 调多个模型，但这不等于第一天就要用满。建议先选定一个默认后端，把所有调用都指向它，理由有三个：

• 计费链路只跑一条，出问题时容易定位是请求格式、模型名、还是账户余额的问题。
• 用量记录的字段含义可以反复对照同一批请求来理解，而不是被多个模型的差异干扰。
• 客户端 SDK、超时设置、重试策略只需要调一次。

选哪个后端并不关键，选你现有代码最容易接上的那个即可。等你对账目有把握之后，再扩展第二个。

看懂 ×1.3 的扣费记录

聚合站的扣费规则是：按模型官方价乘以 1.3 从账户余额中扣除。理解这条链路，重点是把「一次调用」和「一条扣费记录」对上。

建议按下面的顺序核对：

1. 发一个输入输出都很短的请求，让它容易估算。
2. 在用量列表里找到这条记录，确认模型名、输入 token、输出 token 三个字段。
3. 用官方价分别算出输入侧和输出侧的成本，相加得到基准金额。
4. 把基准金额乘以 1.3，和你实际被扣的金额比对。

如果你能对上这一条，说明你对「token 怎么计数、单价怎么取、系数怎么乘」这条链路已经有把握。之后任何模型的账单，都只是把单价换掉而已。

为什么不在第一天做横向 A/B

多后端 A/B 的结论只有在计量口径一致时才有意义。第一天就同时压六个后端，常见后果是：

• 不同后端的输入 token 计数方式有细微差别，短 prompt 上看不出来，长上下文上会积累偏差。
• 有的模型有缓存命中、有的按不同维度计费，混在一起看总额会得出错误结论。
• 一旦出现某次调用失败或重试，你分不清是网络问题还是计费异常。

先把一条链路跑顺，等于先建立了一个可信的测量工具。没有工具的比较，只是感觉。

扩展第二个后端的正确姿势

当你对第一条链路有信心之后，加入第二个模型。这时建议只观察差异，不急着下结论：

• 用同一段输入分别调用两个后端，比较输入 token 计数是否接近。
• 分别核对两条扣费记录，确认系数都是 1.3，差异只来自单价。
• 记录输出质量的主观差异，但不要用单次结果下判断。

等两三个后端都能稳定对上账，你就有了一个可靠的比较基础，再谈性价比才有依据。

如果你同时是贡献者

聚合站也接受用户贡献自己的 key，按官方价的 1.1 倍返还 USDC，优质 key 可达 1.2 倍。这里要分清两件事：

• 你作为调用方被扣的是官方价 ×1.3。
• 你作为贡献方得到的是官方价 ×1.1 或 ×1.2 的返还。

这是两条独立的链路，不要把它们直接相减当成自己的净成本。是否需要贡献 key，取决于你有多少闲置额度、以及是否愿意承担被他人调用的流量。先把自己调用侧的账跑顺，再考虑这件事。

充值这一步不用急

站内支持用 Base 上的 USDC 充值，无 KYC。第一次建议小额充入，够跑完上面几轮核对即可。等确认扣费记录和你的预期一致，再决定是否加大额度。把充值、调用、对账这三步走完一遍，比任何选型攻略都更能帮你建立判断力。