做按量计费的 AI 服务，难点不在收款，在计量。记录我把计量口径从「按请求」改成「按成功结果」的全过程，以及中间三次推倒重来。

     我做的东西很朴素：一个长文本清洗 API，给别的开发者调。一次调用的成本大概 3 厘钱。这个价格单次收不了——支付本身的成本都比它高。所以只能攒着，按量结算。这也是我选 Machine Pay 的原因，赛道的定位就是「AI 服务按实际使用量计费与结算」。

     这两周我几乎只干了一件事：想清楚"量"到底是什么。

     第一版：按请求数

     最简单的口径，来一个请求记一次。跑了两天就出问题：参数填错的请求、超时的请求、被限流拒绝的请求，全都被记为一次。对调用方来说，失败的请求也扣钱，这个说不通。我把异常请求单独拆出来，但拆完之后发现异常占比能到 8%，这 8% 的处理方式我纠结了很久。

     第二版：按 Token 数

     听起来更公平，用多少算多少。但实施上有个麻烦：我的服务有时候输入很长、输出很短，有时候反过来。按输入 Token 算，用户会觉得"我只想要个结果，凭什么按输入收费"；按输出算，遇到输出特别长的情况我这边成本兜不住。这个版本我做了两天就放下了。

     第三版（现在用的）：按成功结果计费

    只有完整返回结果、并且调用方确认收到的请求才计费。超时的、报错的、结果没送达的，一律不计费。这一版的好处是逻辑讲得清楚，坏处是我这边要自己承担失败请求的算力成本。算下来失败率 8% 左右，成本我能接受。

    定完口径之后还有两个配套的事：

     一是幂等。同一个请求重试了三次，不能记三次。我给每个业务请求加了幂等键，服务端去重。这个不难，但一定要一开始就做，我第一版没做，后来回滚数据回滚了一下午。

     二是对账。我自己的计数和收款侧的订单必须能对上。现在每天跑一次对账脚本，两边差值为 0 才放心。前几天差了一笔，查出来是我这边记了、但那笔订单因为网络问题没提交成功。

     几个关键数字，记录一下当前状态：

• 单次调用成本：约 3 厘钱（自测口径）
• 计费口径：仅成功结果，失败与超时不计费
• 当前异常请求占比：约 8%
• 对账频率：每日一次，目标差值 0
• 计量改造耗时：14 天，其中 3 次推倒重来

     作品提交截止 12 月 9 号，我还有时间。下一阶段想把计量做成可导出的明细，让调用方能自己下载账单——按量付费这种东西，信任是建立在对得清账上的。想了解这条赛道可以看看 PAYATHON 2026 活动页，Machine Pay 的交付形态是不做限制的，原型和研究性质的作品也有位置。

#PAYATHON 2026参赛手记 #MachinePay

本文为个人参赛记录，赛程与规则以官方最新说明为准。