计费说明

Zivv 根据实际模型调用记录扣费。文本模型通常按 Token 计费，图片、视频和部分能力可能按张、秒、请求或上游定义的计量单位计费。

实时价格是唯一依据

模型、分组倍率和计费单位会更新，请以 模型广场 展示的实时价格为准。文档只说明计费结构，不维护重复价格表。

文本模型计费

一条文本请求通常包含：

• 输入 Token（Input）：提示词、系统指令、历史对话、工具定义和其他输入
• 输出 Token（Output）：模型生成的文本、推理内容或工具调用参数
• 缓存写入（Cache Write）：将可复用提示前缀写入 Prompt Cache
• 缓存读取（Cache Read）：后续请求命中缓存时读取的 Token

概念公式：

请求费用 = 输入用量 × 输入单价
        + 输出用量 × 输出单价
        + 缓存写入用量 × 写入单价
        + 缓存读取用量 × 读取单价

并非所有模型都支持 Prompt Cache，也不是所有响应都会同时返回四类用量。最终以用量日志和模型广场计价规则为准。

图片、视频和按请求计费

非文本模型可能使用不同计量方式：

类型	常见计量因素
图片生成	模型、尺寸、质量、生成数量、是否流式
图片生成（按张）	模型、输出图张数与各张尺寸档、参考图张数、是否图层拆分
图片编辑	模型、输入图片、输出尺寸、质量和数量
视频生成（按秒）	模型、分辨率、时长、生成数量和任务结果
视频生成（按 Token）	模型、输出分辨率、时长、是否包含参考视频和任务结果
特殊工具或能力	请求次数、处理量或上游定义的单位

提交异步视频任务前应确认价格和参数。任务已进入处理流程后，即使客户端停止轮询，也不代表上游任务自动取消或不计费。

按 Token 计费的视频

部分视频模型不按秒计费，而是按上游返回的 Token 用量计费：

请求费用 = usage.total_tokens ÷ 100 万 × 档位单价 × 分组倍率

单价随两个维度变化：

• 输出分辨率：480P / 720P / 1080P / 4K
• 是否包含参考视频：请求 content 里带 video_url 的按「含视频输入」档计价

Token 用量约等于 输出宽 × 输出高 × 帧率 × 时长 ÷ 1024；包含参考视频时，时长项按「参考视频时长 + 输出时长」计算。最终以上游返回的 usage.total_tokens 为准，估算公式只用于事前预算。

计价与结算规则：

• 创建任务时锁定单价。档位按请求的分辨率和输入类型确定并冻结，结算不再重选 —— 上游只返回 Token 数、不返回分辨率
• 只对成功的任务计费。failed 的任务不计费，已预扣金额全额退还
• 先预扣、后结算，差额只退不补。提交任务时按可能的最大用量预扣余额，任务成功后按实际 usage.total_tokens 结算并退还差额
• 请求落到未配置价格的分辨率档位时会被拒绝，不会按 0 元放行
• 任务超过 24 小时未进入终态会被标记过期并退还预扣金额

按张计费的图片

部分图片模型按输出张数计费，而不是按请求次数或 Token：

请求费用 = Σ(每张输出图 × 该张所属尺寸档单价)
        + max(参考图张数 − 1, 0) × 参考图单价
        × 分组倍率

• 输出图逐张定档，不按最大尺寸一刀切。图层拆分一次返回 1 张底图加多个图层，各图层尺寸参差不齐，逐张计价更接近实际用量
• 参考图第一张免费，第二张起按张计费。张数以上游返回的 usage.input_images 为准
• 图层拆分单独计价，单价为普通图片生成的一半
• 计费量全部取自响应内容（usage.input_images 和 data[].size），不依据请求参数推算。响应缺少尺寸信息导致无法定档时请求会报错，不会按猜测的档位收费
• 相关档位价格未配置完整时，请求在发出之前就会被拒绝

用量日志中的单价一栏在逐张不同价时显示的是加权均价（总输出费用 ÷ 输出张数），逐张明细以响应内容为准。

分组与实际扣费

实际费用可能受到以下因素影响：

• 模型输入、输出或媒体单价
• Key 所属模型分组和分组倍率
• Prompt Cache 命中情况
• 请求使用的尺寸、质量、时长和数量
• 上游响应中的实际用量
• 团队预算、成员子预算和 Key 额度限制

团队没有独立余额；团队 Key 的消费从 Owner 个人余额 扣除。详见 团队协作。

查看余额与充值

查看余额

登录 Zivv 控制台，在 订阅页面 查看余额和充值记录。

充值

前往 订阅页面 完成充值，或按页面提示联系管理员。到账状态以控制台为准。

余额或预算不足

请求可能因个人余额、Key 额度、团队总预算或成员子预算不足而被拒绝。客户端通常只显示 402、403 或通用“额度不足”信息，应结合 用量日志 和 错误码 判断具体原因。

查询用量

登录控制台并进入 用量日志，可按时间核对：

• 请求使用的模型和 Key
• 输入、输出、缓存等用量
• 图片、视频或其他计费项
• 单次费用和汇总费用
• HTTP 状态、请求时间和耗时
• 团队、成员或应用维度的消费

完整的额度、RPM/RPH 和异常消费排查见 用量、额度与限流。

API 响应中的 usage

标准文本响应通常包含用量字段，但不同协议命名不同。

OpenAI

{
  "usage": {
    "prompt_tokens": 150,
    "completion_tokens": 80,
    "total_tokens": 230
  }
}

Anthropic

{
  "usage": {
    "input_tokens": 150,
    "output_tokens": 80,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

响应中的 usage 适合应用侧统计，但账单对账应以控制台最终用量记录为准。流式请求的用量字段可能只在结束事件中出现。

控制成本

1. 按任务选择模型：简单分类、摘要和格式化不必始终使用最高价模型。
2. 限制输出长度：合理设置 max_tokens 或 max_output_tokens。
3. 压缩上下文：删除无关历史，避免每轮重复发送大型文件。
4. 复用稳定前缀：模型支持时使用 Prompt Cache，并检查是否真正命中。
5. 拆分 API Key：开发、生产、客户端和批处理使用不同 Key。
6. 设置预算与限流：为 Key 设置额度、有效期、RPM/RPH；团队设置总预算和成员子预算。
7. 限制自动重试：只对可重试错误进行有限次数退避，避免故障时重复消费。
8. 监控异常波动：定期按 Key、模型和成员查看用量。

常见问题

流式输出会更贵吗？

通常不会因为开启流式就改变相同内容的 Token 单价，但实际生成长度、客户端中止行为和模型计费规则仍会影响最终费用。

请求失败会计费吗？

取决于失败发生阶段和上游是否已经处理请求。认证、参数校验阶段通常没有模型用量；已进入上游推理后，即使连接中断，也可能产生实际用量。以用量日志为准。

为什么相同 Prompt 的费用不同？

模型输出长度、历史上下文、缓存命中、工具调用、分组倍率和媒体参数都可能不同。先在用量日志逐项对比输入、输出、缓存和模型。