详细解释
每分钟 Token 数（Tokens Per Minute，TPM） 是衡量模型吞吐能力的第二根限速轴。与 RPM 不同，TPM 统计的是一分钟内流经 API 的 Token 总量（输入+输出），所以一个 10 万 Token 上下文的超长请求可以一口吃掉你整个分钟配额。
主流厂商对 TPM 的口径并不完全一致：
- 通用 TPM：把输入和输出加在一起算（OpenAI、Google Gemini 多数模型采用）。
- ITPM + OTPM 分轴：ITPM（输入每分钟 Token）与 OTPM（输出每分钟 Token）独立统计（Anthropic 采用）。
为什么 TPM 容易被忽视
许多开发者做压测时只发短 Prompt，结果上线跑 RAG 时把 200 页 PDF 塞进去——单次请求就是几十万 Token，瞬间把 TPM 打满，返回 429。这种情况与代码 bug 无关，纯粹是负载形态从”短而多”变成了”长而少”，限速轴从 RPM 切换到了 TPM。
唯元智创（Weimeta）平台的监控面板会分别展示 RPM 和 TPM 两条曲线的占用比例，帮你快速定位是哪条轴先越线。
缓存对 TPM 的影响
提示词缓存（Prompt Caching） 对 TPM 影响巨大。以 Anthropic 为例，从缓存读取的 Token 不计入 ITPM：假设你有 200 万 ITPM，配合 80% 的缓存命中率，实际每分钟可驱动约 1000 万输入 Token（其中 800 万缓存 Token 不占额度）。
参考官方文档：OpenAI Prompt Caching。
计算示例
假设某模型 TPM 上限 = 400,000，每次请求平均消耗：
- 输入 8,000 Token
- 输出 2,000 Token
则每分钟最多可跑 40 次 请求（40 × 10,000 = 400,000）。
常见问题
输入和输出 Token 哪个占 TPM 更多？
RAG 和长对话场景下输入 Token 占大头；文案生成、代码补全场景下输出 Token 占大头。建议分别监控 ITPM 和 OTPM。