额度与计费
额度负责限制“最多可以用多少”，计费负责解释“已经消耗了什么”，两者需要和真实请求记录一起看。
账户有余额，不代表每一把 API Key 都能继续调用。排查时应同时确认账户状态、总额度、单 Key 额度和当前请求限制。
一套完整的成本闭环
调用前设置额度边界按环境与应用拆分 Key 和预算
调用中产生请求消耗模型、输入、输出和重试共同影响用量
调用后核对用量记录把请求、额度变化与账单记录关联
- 可限制
- 单 Key 与账户边界清楚
- 可归因
- 知道哪类请求产生消耗
- 可核对
- 业务记录能对应平台记录
- 可处置
- 异常用量能够及时止损
额度并不是月底才看的财务数字。它是调用链路上的运行边界：配置过小会影响正常请求，配置过大又会放大误调用、自动重试或密钥泄露带来的损失。
先区分三类信息
当“账户看起来正常，但请求仍失败”时，优先检查单 Key 状态与额度；当“额度下降得比预期快”时，则要回到请求和重试记录寻找来源。
推荐配置流程
按应用与环境拆分 Key
开发、测试和生产使用独立 API Key。名称至少能说明应用、环境和用途，避免多条业务线共享一把无法归因的凭证。
设置初始额度
测试 Key 从较小额度开始；生产 Key 根据预估请求量设置可用但受控的边界。初始值不是永久值，应根据真实用量调整。
完成一组基线请求
至少验证一次成功请求、一次参数错误和一次客户端取消或超时场景，并记录平台侧是否出现用量、任务或费用变化。
对照控制台记录
用请求时间、Key、模型和请求 ID，把客户端日志与 用量及账单 对齐，确认记录能够归因。
定期调整边界
根据业务增长、异常峰值和剩余额度调整限额。额度变化应保留原因和负责人，避免问题发生后无法解释。
日常应该看什么
额度异常时先做什么
不要把“提高额度”当作通用排障动作。鉴权、模型、参数、限流或服务异常不会因为提高预算自动恢复。