让「用量」这件事从黑盒变成可查的账

用户最想知道的其实只有一句话：这个月我花了多少、花在哪、还剩多少。把这三件事做清楚，用量系统就完成了它的使命。

调用明细要能下钻

不只是总数，还要能看到每一次调用：时间、模型、耗时、token、状态。有了明细，异常消耗才追得出来。

实现上，调用明细按 (request_id, usage_id) 做唯一约束，避免结算重试导致重复落库。

这在实现上要注意：未激活的 Key 在被调用时才开始计时，而不是从下单那天开始——否则用户买了却不用的那段时间会被白白消耗掉。

分页和保留策略要说清楚

明细通常只展示最近 100 条、默认每页 10 条。这个限制写在界面上，避免用户以为「只有这些调用」。

分清楚这三者，用户体验和客服成本都会明显下降。

用量统计的时间口径必须写清楚，是 UTC 还是某个业务时区，一周从哪天开始。

按业务维度聚合才是账

总用量只是起点。真正的成本分析是按业务线、模型、时间段切片之后，才能定位到花钱的地方。

有效的拆解方式是按三个维度切：按模型、按调用方（哪个业务线）、按时间（哪一天、哪个时段）。

如果每个业务方自己维护一份价格表，半年后一定会有对不上的地方。

明细本身要脱敏

调用明细里不要带完整的请求正文和完整 Key。用户看自己的数据可以，但存储和导出的形式要有边界。

宁可让用户看到「部分未知」，也不要给一个虚假的绿色。

例如「近一小时请求统计」和「历史明细保留 90 天」这类信息，必须在页面上明确标注。

实操：用查询凭证查用量，不必把完整 Key 交给前端。

查询凭证在这里的价值体现得最充分：低敏感度、可展示、可分享。

# 查询凭证是一段 10 位字符串，权限远低于完整 API Key。
curl "https://aiminis.info/api/v1/query-key/quota?key=QRY1234567"

# 返回里包含：今日剩余额度、每日额度、有效期、状态，
# 以及最近 100 条调用明细（默认每页 10 条）。
# 浏览器端还会把最近用过的查询凭证存在 Cookie 里，方便下次直接看。

几个容易踩的坑

• 把「今日额度」「并发上限」「账户余额」当成同一个东西。
• 日/周/月窗口用的时区没说清楚，用户看到的数字和自己的记录对不上。
• 没有 Key 级限流，一个跑飞的脚本把共享额度吃完。
• 结算重试没有幂等约束，同一笔用量被记了两次。

小结

网关这层看不见，但它的每一次选择都在影响你的延迟、成本和成功率，值得花点时间打磨。

上面提到的能力基本都来自 https://aiminis.info/ 这个自建的 API 网关，支持 OpenAI 与 Anthropic 双协议接入，还有公开的模型健康看板 https://aiminis.info/model-health 可以先看看状态。