流式与阻塞调用在聚合站上计费一样吗：在 1.3 倍规则下 stream:true 会不会影响扣费

很多开发者第一次在聚合站使用流式输出时，会担心 stream: true 是否会导致额外扣费，或者是否因为连接时间更长而多算钱。本文从计费原理出发，解释流式与阻塞调用的费用差异，并给出选择建议。

计费基于 token，与传输方式无关

聚合站的计费规则很明确：按模型官方定价乘以 1.3 的系数，从你的 USDC 余额中扣除。乘数针对的是 token 消耗量，而不是请求的持续时间或传输方式。

无论你使用 stream: true 还是等待完整响应，模型实际处理的输入 token 和生成的输出 token 数量是相同的。因此，在相同输入和相同输出长度下，两种调用方式的扣费完全一致。

流式调用不会改变 token 计量

流式响应只是把生成结果分块逐步返回，模型端的推理过程并没有变化。聚合站记录用量的方式仍然是统计请求中的输入 token 和响应中的输出 token。

换句话说：

• 输入 token：由你发送的 prompt 决定，与是否流式无关。
• 输出 token：由模型实际生成的内容决定，与是否流式无关。
• 扣费金额：两者之和乘以官方价再乘以 1.3，与是否流式无关。

因此，不必因为担心费用而避免使用流式输出。

什么情况下流式更“省钱”

严格来说，流式本身不省钱，但它能帮你 更早止损。在流式模式下，你可以边接收边判断输出是否符合预期。如果发现模型跑偏，可以主动中断连接，避免继续生成无用的 token。

阻塞调用则必须等完整响应返回后才能判断，一旦输出很长且不理想，你已经为全部输出 token 付费。

所以，对于输出长度不确定、需要人工或程序实时判断的场景，流式调用可以间接减少浪费。

什么情况下阻塞调用更合适

如果你需要一次性拿到完整结果再做后续处理（例如结构化解析、批量入库），阻塞调用更简单。此时输出长度通常可控，流式带来的“止损”优势不明显，反而增加代码复杂度。

另外，短输出场景下两种方式的费用差异可以忽略，选择实现更简单的方式即可。

控制成本的关键不在 stream

在 1.3 倍规则下，影响费用的核心因素始终是 token 用量。与其纠结调用方式，不如关注：

• 精简 prompt，减少不必要的输入 token；
• 设置合理的 max_tokens，避免模型生成过长内容；
• 对失败请求避免盲目重试，重试会重复计费；
• 利用流式输出及时中断不满意的生成。

小结

流式与阻塞调用在聚合站上的计费完全一致，stream: true 不会影响扣费。选择哪种方式应基于业务需求：需要实时反馈和止损时用流式，需要完整结果且输出可控时用阻塞。真正决定成本的是 token 用量，而不是传输方式。