计费规则

不要只看一张模型价格表；生产接入还需要确认用什么单位计量、什么时候形成消耗，以及如何把费用对应到真实请求。

平台实际可用模型和结算口径以当前控制台、账号配置与实际费用记录为准。文档中的外部官方价格快照用于理解模型成本，不等同于GGPU平台最终账单。

先确认四个问题

问题	需要得到的明确答案
按什么单位计费	输入 Token、输出 Token、请求次数、任务次数或其他专用单位
什么时点形成消耗	请求受理、模型执行、成功返回或任务完成
失败与取消如何处理	哪类失败未执行，哪类失败可能已经产生上游消耗
记录在哪里核对	响应用量、用量页面、账单记录和任务详情如何对应

不同能力、模型和任务类型可能采用不同口径。未确认之前，不要用一种接口的结论推断所有调用。

文本调用通常需要关注输入与输出规模；图片或异步能力还可能使用请求、任务或资源型口径。模型、上下文长度、输出长度、生成数量与调用模式都可能影响最终消耗。

“客户端看到失败”不等于“平台没有执行”。连接超时、用户取消或客户端断开时，上游调用可能已经开始；自动重试又可能形成第二次独立请求。

同一次业务动作可能关联 API 响应、任务记录、用量变化和账单记录。核对时应使用时间、Key、模型、请求 ID 或任务 ID 把它们串起来。

保存请求时间、Key、模型和响应用量；随后确认控制台中出现相符的用量或费用变化。

构造一个不会真正进入模型执行的参数错误，观察错误类型与记录变化，建立“调用未受理”的基线。

确认客户端停止等待后，平台或上游是否仍可能继续执行。任务型接口还要检查是否已经生成任务 ID。

记录每次尝试，而不是只记录最终结果。确认自动重试次数、退避策略，以及每次尝试是否形成独立消耗。

选择一个固定时间窗口，把业务请求数、平台用量与费用记录做一次人工核对，再决定生产预算与告警阈值。

以下页面保留各官方来源的价格快照，适合了解不同计费项和渠道差异。价格会变化，使用前应核对页面标注的日期与官方来源。

上线前至少记录：

有了这份基线，异常时才能判断是业务增长、参数变化、重复请求，还是计费记录本身需要继续核对。