TPM 是如何计算的

系统必须在请求发出之前判断是否放行，无法等待模型返回实际消耗量，只能依据请求参数提前预估 Token 消耗，并累加到当前分钟的 TPM 计数中：

TPM 计数增量 = 输入字符数 / 3 + max_tokens

参数	说明
输入字符数	本次请求 `messages` 中所有消息内容的总字符数（Unicode 字符）
/ 3	字符转 Token 的保守估算比例（1 Token ≈ 3 字符）
max_tokens	请求中指定的 `max_tokens`；若未设置，默认按 4096 计算

为什么 TPM 计数远大于 usage.total_tokens

usage.total_tokens 是请求完成后由模型返回的实际消耗值（prompt_tokens + completion_tokens），而 TPM 限流使用的是请求开始前的预估值，差距来自三点：

原因	说明
max_tokens 按上限全额预扣	无论模型实际输出多少 tokens，限流时都按 `max_tokens`（或默认 4096）扣除配额
字符估算偏保守	英文约 1 token = 4 字符，中文更密；但系统统一按 1 token = 3 字符估算，预估值偏高
统计时机不同	限流在请求前扣配额，usage 在请求后统计实际消耗

具体示例：消息内容 1800 字符、未设置 max_tokens（默认 4096），则 TPM 限流计数 = 1800 / 3 + 4096 = 4696；而该请求实际 usage.total_tokens 约 800，TPM 计数约为 usage 的 5.9 倍。在并发场景下，同时发出 1280 个这样的请求，TPM 累计计数 ≈ 6,010,880（触发 600 万限额），而实际 total_tokens 合计仅约 102 万——这解释了「usage 仅约 200 万却触发 600 万 TPM」的现象。

如何避免触发 TPM 限流

显式设置合理的 max_tokens（最关键）：若业务输出通常不超过 512 tokens，建议设置 "max_tokens": 512 而非依赖默认 4096，可将每次请求的 TPM 预扣量降低约 87%。
控制并发请求数：TPM 是当前分钟内所有并发请求预估 Token 之和，高并发时即使单条请求字符数不多，累计预估量也可能迅速达到上限，建议通过速率控制（如令牌桶）分散请求。
精简输入消息长度：压缩 system prompt 和历史消息，只保留必要上下文。

信息

若发现 usage 仅约 200 万却触发了 600 万 TPM，这是正常现象——TPM 按预估值（含 max_tokens 上限）计算，而 usage 按实际消耗统计。设置合理的 max_tokens 是最直接有效的优化方式。