用户只提交了一次任务，应用最终也只返回了一份结果，为什么后台调用量可能增加？在排查大模型成本时，自动重试是值得检查的一环。
重试可以恢复短暂故障，但它通常意味着再次发起请求。如果前一次请求已经产生可计费用量，后一次也执行了处理，总费用就可能高于一次正常完成的调用。是否计费及具体金额，仍应以所用服务的规则和用量记录为准。
一、先区分超时位置与执行状态
“请求超时”可能来自客户端、代理或服务端。客户端等待超时，与服务端返回 HTTP 408，不能直接视为同一种事件。
连接尚未建立时，请求可能没有到达模型服务；请求已经发出后发生读取超时，则可能是处理尚未完成，也可能是响应没有顺利返回。客户端结束等待，不足以证明远端工作已经取消。
因此，排查时应分别记录本地错误类型、已收到的服务端状态，以及是否获得请求 ID。拿不到执行结果的请求，应保留“状态未知”，不要直接归为“未执行”。
二、检查一次业务调用背后的实际尝试次数
重试可能同时存在于 SDK、业务逻辑和代理层。业务代码看似只调用了一次 SDK，SDK 内部却可能已经进行了多次尝试。应检查实际安装版本和生效配置，不能只读业务代码中的循环次数。
例如，业务层最多尝试两轮，每轮 SDK 最多尝试三次。在持续遇到可重试错误、且没有被提前终止的简化场景下，最多可能出现六次底层请求尝试。
六次尝试不代表六次都到达服务端，也不代表费用必然增加六倍。这个示例用于提醒：排查调用量时，要把各层行为合起来看。
三、按任务关联记录，避免只看到最终成功
建议区分业务任务与调用尝试。下面只是通用日志字段示意，不是任何平台的接口格式：
{
"task_id": "task-example",
"attempt_no": 2,
"retry_owner": "application",
"retry_reason": "read_timeout",
"provider_request_id": null,
"execution_state": "unknown",
"usage_state": "pending"
}
其中，任务标识用于串起同一项工作，尝试序号用于识别重复调用；供应商请求 ID 在能够获取时保留。未知用量应标为待核实，不能因本地没有收到统计信息就记为零。
具备请求明细时，可进一步匹配模型、时间、用量和费用；只有汇总账单时，应保留无法精确对应的部分。日志中不要写入原始密钥，业务内容与个人信息也应脱敏。
四、减少不必要的重试，而非单纯缩短等待
先明确一个负责统筹重试的层级，核对其他层是否仍有独立重试。其次，把单次超时与任务总时限分开：请求等待、退避和后续尝试都应计入总耗时。
对于短时限流，按服务端提示等待并适当分散重试时间；对于参数、认证、权限或额度问题，先处理原因。超时设置过短，反而可能让正常的长请求不断触发重试。
预算判断可以结合输入规模、输出上限与价格估算，并留出余量。不过，用量回传有延迟，正在执行的请求也可能继续产生费用，预算控制不能撤销已发生的消耗。
最终应同时观察任务成功率、完成耗时和每项成功任务的成本。调用量增加如果带来了必要的恢复，未必需要取消；没有改善成功率、却持续增加等待和消耗的重试，才是优先优化的对象。
