计费、用量与成本核对

小白：一次费用由什么组成

最终费用不只由模型名决定，还可能受用户分组、输入/输出 token、缓存、推理 token、图片张数与尺寸、音视频时长、任务次数或动态计价规则影响。模型广场展示当前价格和端点；文档中的厂商价格不能替代本站运行时价格。

每次调用至少保存以下对账键：

Copytime, model, endpoint, request_id, task_id, http_status,
input_units, output_units, cached_units, final_status

预扣、结算和退款

为防止余额不足，网关可能在请求前预留额度；完成后再按真实 usage、媒体属性或任务结果结算，多退少补。失败是否退款取决于请求是否到达上游、是否产生有效结果以及计费规则。异步任务在 queued 时看到的金额不一定是最终费用，应等 completed 或 failure 后查看消费日志。

如何核对一笔请求

先用 Request-ID 或任务 ID 找到唯一日志，确认原始模型、映射后模型、分组、渠道、请求路径与终态，再比较响应 usage。没有 usage 的媒体或按次任务，应核对计价单位和任务属性。不要把多次重试相加后仍称为“一次调用”。

成本优化顺序

先删除不必要的上下文与重复输出，再选择满足质量目标的更小模型；对稳定前缀评估提示缓存，对非实时批量任务评估异步或批处理。用“每个成功业务任务的总成本”比较方案，其中包括失败、重试、检索、重排、工具调用、存储和人工复核。

限流与成本联动

RPM、TPM、并发和余额限制是不同维度。盲目提高并发会增加 429、超时和重试，反而提高单位成功成本。客户端要设并发上限、token 预算、最大输出、重试预算与日费用告警；余额不足和硬配额不是重试问题。

专家对账与告警

建立日级账本，把业务请求、网关消费日志、上游账单和退款按 Request-ID、任务 ID、模型与时间窗口关联。监控预扣未结算、终态无日志、重复扣费、负余额、缓存命中异常和单位任务成本突变。价格或路由变化必须带版本与生效时间，历史日志按当时快照解释，而不是用今天价格回算。