去中心化 AI 计费：链上结算前先解决用量可信

去中心化 AI 计费：链上结算前先解决用量可信

一、AI 服务计费不只是扣钱

去中心化 AI 产品经常希望把推理服务、代理任务或数据标注结果放到链上结算。思路很有吸引力：用户按调用付费，服务节点按贡献收款，账本公开透明。但真正难的是用量可信。

一次模型调用花了多少 token，是否真的执行了任务，结果是否按约定返回，这些信息如果只由服务方自己上报，链上结算就失去意义。计费系统要先解决"谁证明用量真实"。

这个问题的棘手之处在于，AI 推理天然不适合链上直接验证。链上节点无法重跑一次 GPT 推理来确认 token 数量对不对——即使能，重跑本身又是一笔成本。更现实的路径是用可信执行环境或零知识证明生成用量凭证，但这两条路在工程成熟度上都远不如智能合约本身。所以计费系统在设计阶段就得承认：当前架构下的用量可信度有一个上限，协议规则要围绕这个上限来设计激励机制和惩罚边界，而不是假设用量绝对可信。

二、链下执行和链上结算要分层

flowchart TD A[用户请求] --> B[链下 AI 服务] B --> C[用量记录] C --> D[签名凭证] D --> E[链上结算合约] E --> F[付款与分账]

大模型推理不适合直接放在链上执行。更现实的架构是链下执行，链上结算。服务节点生成用量凭证，用户或协调节点验证后提交合约。

凭证应包含请求 ID、服务节点、模型标识、输入输出 token、价格版本、时间戳和结果哈希。合约不需要知道完整内容，但需要能验证凭证没有被篡改。

三、凭证格式要稳定

type UsageReceipt = { requestId: string provider: string model: string inputTokens: number outputTokens: number resultHash: string priceVersion: string signature: string }

如果涉及多服务节点，还要定义争议流程。用户认为结果无效时，是否允许申诉；申诉期间资金是否进入托管；仲裁依据是什么。这些规则比合约代码本身更难设计。

struct Receipt { bytes32 requestId; address provider; uint256 inputTokens; uint256 outputTokens; bytes32 resultHash; bytes signature; }

链上只保存必要字段，完整内容可以放在链下存储或由用户本地保留。这样能降低成本，也能减少隐私暴露。

四、价格版本和防滥用很关键

AI 模型价格会变，用量结算必须绑定价格版本。否则服务方和用户对同一次调用的费用理解可能不同。价格调整应有生效时间，避免正在执行的任务被突然改价。

还要防止刷量。服务节点自己构造请求骗补贴，用户恶意发起无效请求拖垮节点，都需要配额、质押、信誉和异常检测配合。去中心化不是没有运营规则，而是规则要提前写清。

计费系统还需要处理失败任务。模型超时、结果为空、用户取消、节点中断，这些场景是否收费，必须在协议层定义清楚。否则争议会集中爆发在边界条件上，而不是正常请求上。

另一个容易被忽略的大边界是：计价精度本身就是一个安全变量。AI 模型定价常以 token 为单位，而一次实际推理的 token 用量可能因为 prompt 拼装方式不同而产生偏差。计费协议需要约定 tokenizer 版本和计数规则，不能简单写"按 token 计费"五个字。用户在签名前看到的预估费用与实际结算费用之间的偏差范围，也应该是协议设计的一部分。偏差过大时，系统应阻断结算而非自动执行。

ai_billing_rules: timeout_charge: false partial_result_charge: "proportional" user_cancel_before_start: false provider_error_penalty: true

如果支持多节点竞价，还要把报价、服务质量和历史履约率一起展示。最低价格不一定是最好选择，用户可能愿意为更低失败率付费。链上结算记录也可以反过来形成节点信誉。

最后，结算合约要限制单次凭证金额和批量结算规模。任何自动结算系统都要假设凭证可能出错，金额上限能把事故半径控制在可承受范围内。

五、总结

去中心化 AI 计费要把链下执行、用量凭证、价格版本、争议流程和链上结算分开设计。

结算可信的前提是用量可信。没有可验证凭证，链上账本只能记录一套并不可靠的数字。