用量、额度与限流

Zivv 会同时检查账户余额、Key 限制、团队预算和上游可用性。理解这些限制，有助于控制成本并正确处理 402、403 和 429。

在哪里查看用量

• 用量统计：按时间、模型、Key 查看汇总
• 用量日志：查看单次请求的状态、延迟、Token 和费用
• 钱包：查看余额和充值记录
• 团队上下文：按成员、Key、模型查看团队消费

四类限制

限制	作用范围	常见错误
账户余额	用户或团队 Owner	insufficient balance
Key 额度	单个 API Key 的累计消费	key quota limit exceeded
RPM / RPH	单个 Key 或团队的请求频率	rate limit exceeded
团队 / 成员预算	团队日、月、总额和成员子预算	team ... budget exceeded、member budget exceeded

遇到限流怎么办

RPM / RPH 限制的是一段时间内的请求数量，不等同于并发数。即使并发很低，短时间连续请求也可能触发 RPM。

推荐策略：

1. 读取 Retry-After 响应头
2. 对 429、503、529 使用指数退避
3. 重试加入随机抖动，避免多个任务同时再次请求
4. 为批处理设置最大并发，不要无限创建请求
5. 不要自动重试 400、401、402、模型权限类 403

const retryable = new Set([429, 502, 503, 529])

const delay = Math.min(30_000, 1_000 * 2 ** attempt)
const jitter = Math.floor(Math.random() * 500)
await new Promise(resolve => setTimeout(resolve, delay + jitter))

费用为什么会不同

单次请求费用通常与以下因素有关：

• 模型输入和输出单价
• 输入、输出 Token 数量
• 分组倍率或用户组价格
• Prompt Cache 的写入和读取用量
• 图片、视频、工具调用等非文本计费项
• 请求是否成功以及对应端点的计费规则

实时价格以 模型广场 为准，计费公式见 计费说明。

控制成本的建议

• 每个应用使用独立 Key，并设置额度
• 测试脚本使用低额度和过期时间
• 长对话定期压缩上下文，避免重复发送无关内容
• 能复用稳定前缀时使用 Prompt Cache
• 批处理限制并发，并记录失败请求而不是无限重试
• 团队为成员设置子预算，避免单个任务耗尽总余额

排查异常消费

1. 在用量日志按时间定位异常区间
2. 检查模型、Key、客户端、Token 和状态码
3. 确认是否存在重复重试、循环任务或超长上下文
4. 停用可疑 Key，并按 Key 轮换 创建新 Key
5. 仍无法解释时，按 帮助中心 模板提交请求信息