计费与限制
了解 API 积分费率、预占与结算机制、余额不足和请求频率限制。
API 调用与 Chat 共用同一个 GLM 5 积分余额,不存在单独的 API 钱包或 API 专属订阅余额。
API 积分费率
| 模型 | 输入 | 输出 |
|---|---|---|
glm-5.3 | 78 积分 / 100 万输入 Token | 245 积分 / 100 万输出 Token |
glm-5.2 | 78 积分 / 100 万输入 Token | 245 积分 / 100 万输出 Token |
glm-5 | 84 积分 / 100 万输入 Token | 278 积分 / 100 万输出 Token |
kimi-k3 | 834 积分 / 100 万输入 Token | 4,167 积分 / 100 万输出 Token |
kimi-k2 | 84 积分 / 100 万输入 Token | 334 积分 / 100 万输出 Token |
deepseek-r1 | 98 积分 / 100 万输入 Token | 362 积分 / 100 万输出 Token |
deepseek-v4-pro | 126 积分 / 100 万输入 Token | 251 积分 / 100 万输出 Token |
deepseek-v4-flash | 39 积分 / 100 万输入 Token | 78 积分 / 100 万输出 Token |
表格展示每 100 万输入/输出 Token 对应的积分消耗。美元价格仅作为辅助参考。
100 积分 = $1.80 的 API 使用价值。 内部按照 $0.018 / credit 把 API 用量换算成积分,并向上取整;完成的请求最低计费 1 积分。
预占与最终结算
GLM 5 使用两阶段计费:
- 估算输入 Token,并按请求中的最大输出预占积分;如果没有设置最大输出,则计费预占使用内部 8,192 Token 估算值。
- 把请求发送给模型。
- 读取本次完成请求的最终输入/输出 Token 用量。
- 用真实用量重新计算应扣积分。
- 返还没有实际使用的预占积分。
如果请求在预占之后失败,对应预占会被退款。
计费估算不是模型输出上限
未设置 max_completion_tokens 时使用的 8,192 Token 只是内部计费预占估算,不会改变模型的默认输出行为。最终按本次请求的实际用量结算。
计算示例
以 glm-5.3 为例,假设某次请求产生 50,000 输入 Token 和 1,000 输出 Token,并按当前内部 API 价值计算:
input = 50,000 / 1,000,000 × $2.50 = $0.1250
output = 1,000 / 1,000,000 × $7.50 = $0.0075
total = $0.1325
credits = ceil($0.1325 / $0.018) = 8
实际扣费以本次请求最终记录的 Token 用量为准,完成换算后再向上取整。
余额不足
如果当前可用积分无法覆盖请求预占,会返回:
{
"error": {
"message": "Insufficient credits.",
"type": "insufficient_quota",
"code": "insufficient_quota",
"param": null
}
}
HTTP 状态码为 402。
频率限制
每个 API Key 默认限制为每分钟 60 个请求;单个 Key 也可以配置自定义限制。
超过限制时返回 HTTP 429,错误码为 rate_limit_exceeded。
推荐使用带随机抖动的指数退避。额度不足、认证失败和参数校验错误不应立即自动重试。
请求体限制
POST /chat/completions 的请求体最大为 4 MB。超过限制时返回 HTTP 413 request_too_large。