AI生成计费怎么做才对?PRINTFILM钱包「预扣→用量→结算」体系源码解读
发布时间:2026/9/29 11:55:43 作者:尧图编辑部 阅读量:1,286

AI生成计费怎么做才对PRINTFILM钱包「预扣→用量→结算」体系源码解读【免费下载链接】printfilmPRINTFILMAI 视频获客与 AI短剧创作平台项目地址: https://gitcode.com/gh_mirrors/pr/printfilmAI 生成计费怎么做才对这是做 AI 产品绕不开的一道题一次 AI 短剧或 AI 视频的生成要跑几分钟中途可能调用多次大模型、出图、出视频成本事先算不准用户还怕钱没了但片子没出来。PRINTFILM 是一个AI 视频获客与 AI 短剧创作平台它用一套「预扣 → 用量 → 结算」的钱包计费体系解决了这个问题先冻结估算金额过程中逐笔记录真实用量任务结束后多退少补。本文带你读懂这套体系的源码设计看懂后你也可以为自己的 AI 项目搭建一套靠谱的 AI 生成计费系统。一、AI生成计费的三个难题给 AI 功能收费和传统 SaaS 按年订阅不一样至少难在三处成本不确定用户说一句话后台可能触发 1 次聊天 LLM 3 次资产生图 8 段视频生成每一笔多少钱事先无法精确知道时长不可控一次视频生成可能排队 渲染十几分钟钱不能生成完再算否则余额不足的用户能无限白嫖失败要退款上游模型报错、任务被取消时已收的钱必须退还不能重复退。PRINTFILM 的解法是把每次 AI 调用都挂在一个「任务」上围绕任务做钱包操作。先看它钱包的三张核心数据表定义在 backend/app/models.py数据表作用wallet_ledger钱包流水每笔freeze/unfreeze/settle/topup都留一条流水含变动金额和变动后余额可追溯每一分钱usage_events用量明细每次调用上游模型LLM / 图 / 视频 / TTS记一行token 数、成本cost_fen、扣费charge_fen、是否估算task_runs任务计费快照记录billing_estimate_fen预扣额、billing_charged_fen实扣额、billing_refunded_fen退回额和billing_status状态一个关键细节钱包单位是分fen全程用整数运算避免浮点误差。完整规则可对照官方文档 docs/BILLING.md。二、第一步「预扣」先冻结一笔估算金用户提交任务后、AI 真正开跑之前系统先按任务类型估算一笔钱并冻结这一步叫freeze预扣核心实现在 backend/app/services/billing/settlement.py 的freeze_for_task估算backend/app/services/billing/estimates.py 的estimate_task_fen按「业务域 任务类型」查表估算——LLM 类按预估 token 数折算生图按每张官方价视频按时长 × 清晰度秒价TTS 按次估价加缓冲token / 时长类估算会乘一个 1.2 左右的缓冲系数billing_estimate_buffer防止低估导致结算时超支冻结行锁住用户钱包SELECT ... FOR UPDATE把估算金额从可用余额移入frozen_fen并写一条freeze流水余额不足直接抛错前端收到 HTTP 402余额不足。为什么这一步很重要它把承诺提前了用户排队中的任务占用也是被校验的pending_task_commitment_fen会汇总排队中未冻结的估算避免一个用户用几块钱同时塞进 100 个视频任务。三、第二步「用量」每一笔 AI 调用都记账预扣只是押金真正的账单来自执行过程中的用量记录。billing_scope 上下文任务执行体backend/app/services/tasks/executor.py在freeze_for_task之后用 backend/app/services/billing/context.py 的billing_scope(task.id)把当前任务 ID 放入上下文变量。之后任何嵌套的 LLM 调用比如生成角色图之前先调一次视觉提示词LLM都能自动归属到正确的任务不会记串账。唯一写入口 record_line所有用量行都从 backend/app/services/billing/usage.py 的record_line写入usage_events。这个入口做了两件聪明事优先用上游真实成本如果上游网关TokenFree / New API返回了真实消耗quota、Kie credits 或火山 usage直接按官方成本折算estimatedFalse拿不到就用保守估价上游不返回用量时按billing_keyllm_chat/seedream/seedance2:video0/tts的单价表估算并标记estimatedTrue方便管理端区分实账和估账。换算逻辑集中在 backend/app/services/billing/pricing.py用户支付价 上游真实成本不再加价user_charge_fen这是它对用户最友好的一点。四、第三步「结算」多退少补幂等可重入任务跑完成功、失败、取消都算settle_task接管收尾规则一句话实扣 用量行之和与冻结额多退少补。实扣 冻结额 → 差额走unfreeze流水退回余额视频失败时几乎全额退回实扣 冻结额 → 超出部分走settle流水补扣所以预扣才要留缓冲结算完成把billing_status置为settled用量行标记settledTrue。settle_task的防御性设计值得抄作业行锁 状态门闩只有frozen状态的任务能进入结算重复调用直接返回已有结果杜绝二次退款钱包侧幂等先查wallet_ledger是否已存在该任务的unfreeze/settle流水存在则只对齐状态不动钱异常中断兜底reconcile_terminal_frozen_tasks定期对账扫描——如果任务已到终态但billing_status还卡在frozen比如结算瞬间数据库故障120 秒宽限期后自动重新结算保证冻结的钱不会长期卡住。五、两种任务形态长任务与轻量调用不是所有 AI 调用都值得进任务队列。PRINTFILM 把任务分成两档计费方式统一异步长任务漫剧剧本、分镜、视频生成、科普 pipeline走任务队列executor 自动freeze → 执行 → settle每个阶段script / assets / videos独立预扣独立结算互不拖累同步轻量调用AI 助手聊天、开放 API、工作室工具用 backend/app/services/billing/ephemeral.py 的run_billed_ephemeral——现场创建一条轻量 TaskRun同一请求内完成「预扣 → 执行 → 结算」响应里带回task_id余额变化立即可见。还有第三种延迟结算。开放 API 生视频提交上游后先保持awaiting_poll不结算后台轮询到上游成功才记真实用量并结算settle_deferred_video_poll失败则全额解冻——避免提交成功即扣费、结果上游失败的资损。六、配套能力告警与对账计费体系不只是扣钱PRINTFILM 还配了两个运营侧能力消费告警backend/app/services/billing/alerts.py用户累计消费每跨越一个档位如 ¥10弹一次消费提醒每笔结算最多弹 1 条防刷屏平台侧上游成本超阈值时给管理员发周期去重的邮件官方用量对照管理端可拉取 TokenFree / New API 的官方日用量快照upstream_usage_daily表与本地usage_events成本对照验证估账和实账的偏差。七、给 AI 产品计费的设计清单从 PRINTFILM 源码里提炼做 AI 生成计费可以照这份清单检查✅金额用整数分运算钱包、流水、用量三张表分账✅任务开始前先 freeze 估算额含排队任务在内的可用余额不足直接拒绝402✅每次上游调用记一行 usage优先真实成本、拿不到再保守估价并打标✅结算多退少补行锁 状态机 流水查重保证幂等失败全额解冻✅异常中断要有对账兜底卡死的冻结额自动修复✅消费里程碑提醒让用户对余额有感知。想深入细节建议按 docs/BILLING.md → backend/app/services/billing/ → backend/app/services/tasks/executor.py 的顺序阅读再配合管理端「订单与流水」「任务详情-计费 Tab」对照实际数据就能完整理解这套 AI 计费体系的运转方式。【免费下载链接】printfilmPRINTFILMAI 视频获客与 AI短剧创作平台项目地址: https://gitcode.com/gh_mirrors/pr/printfilm创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考