"失败不计费" 到底是怎么实现的

"失败不计费" 是 ByteSpike 定价页上反复出现的那句话。常被合理地问：这不会只是 marketing 话术吧？老实答：要做到，网关得在 credit 账本上做实打实的 bookkeeping，机制是两阶段提交 — 多数其他 AI 网关跳过这步。

阶段 1：发起前预扣

请求到网关时，先按 worst-case 估出成本（文本: max tokens × 单 token 费率；图像/视频: per-call 费率），从调用方钱包预扣这笔钱。预扣是 hold 不是 debit — 余额显示已扣，但账本里还没出账目行。钱包不够覆盖预扣，请求在发上游前就被拒。

阶段 2：仅在成功时 settle

之后网关把请求转发上游，盯着回包。"干净成功"（2xx 且实际可用内容回到调用方）触发：按真实 token 数 / 实际产物算实际成本，从 reservation 里扣这部分，剩下的退回钱包。账本里这才出现一条 debit 行，记录真实发生的事。

什么算 "失败"

• 上游返 5xx 或连接中途断 → reservation 过期，不出账
• 内容审核拒（NSFW / 版权过滤 / 越狱检测）→ reservation 过期，不出账
• 图像 / 视频在上游生成成功但 asset URL 回不到调用方（CDN / 签名 URL 过期）→ reservation 过期，不出账
• 调用方在首个 content token 到达前断流 → reservation 过期，不出账
• 网关侧超时（文本默认 8s，视频更长）且无任何上游响应 → reservation 过期，不出账

这套机制的代价（以及为什么仍坚持）

每次调用做两阶段提交不便宜。上游侧失败我们自掏；reservation 账本要按 request ID 维护到最慢上游容忍时间（最慢视频 ~5min）；上游已成功响应但客户连接已断的 reservation 要异步对账。这些都不算技术上有趣，但都是其他网关跳过的工程量。

坚持的原因：替代方案 — 提交就扣 + 失败再返还 — 对客户体验和审计日志都更差。月底发票上一堆 "5xx 返还" 行项，你必然问为什么先扣的钱。两阶段提交让那行根本不存在。

“处理失败最便宜的地方，是 credit 还没动的时候。”

如何在你的账户里看到这一点

Console → Usage 标签每行 3 列：requested / reserved（pre-flight 期间 held）/ settled。成功调用 3 列差异只在 worst-case → 实际值的 delta；失败调用 reserved 有数但 settled 为 0 — 该行永远没 debit。/v1/balance 端点只反映 settled 金额，已 held 的 reservation 在 settle 或 expire 落地前不会让你的可见余额减少。

所以如果你跑实验 hammer 某个不稳的上游 —— 比如评测带严格审核的新图像模型 —— 你的余额不会漂。你会看到 reserved 起伏 + 即时释放，但底线数字只在真有东西交付时才动。