一句话定义：TPM（AI 词典：Token">Tokens Per Minute，每分钟 token 数）和 RPM（Requests Per Minute，每分钟请求数）是模型平台给 API 调用设的两条“每分钟”上限；一旦超过其中任一条，请求就会被拒绝或排队。
打个比方：把 API 想成高速收费站。RPM 限制的是“每分钟最多放几辆车过闸”，TPM 限制的是“每分钟最多过多少吨货”。有的车只捎一个小包裹，也就是问一句“帮我把这句话改得客气点”；有的车是满载集装箱，比如贴一份几十页合同让模型总结。因此只数车不够，只称重也不够。
为什么两条都要：如果只限 RPM，你完全可以把整本书塞进一次请求，用一辆“超重卡车”把算力占满；如果只限 TPM，你又能狂发几百个几个字的小请求，token 总量虽小，但每次请求都要占用鉴权、调度、排队这些固定开销。两个维度同时限制，才能防止这类绕过。还有个细节：多轮对话里，历史上下文会一并带上，聊得越久，单次请求的 token 会不断累积；于是你每分钟能发的请求数反而变少。输入与输出怎么计入、是否预留最大输出，各家口径不同，以官方页面为准。
和相邻概念的区别：
| 概念 | 限制的是什么 | 超过后的表现 |
|---|---|---|
| TPM / RPM | 每分钟的瞬时速度 | 短时高频报错，如 429 |
| TPD / RPD（Per Day） | 每天的总量 | 通常要等次日重置 |
| 并发数（concurrency） | 同时进行中的请求数量 | 新请求排队等待 |
| 上下文窗口（context window） | 单次请求能容纳多少 token | 直接拒收这一次请求 |
一句话：日额度管“一个月油费”，TPM/RPM 管“每分钟能开多快”，上下文窗口管“后备箱多大”。
对从业者的意义：限流不应被当作异常，它是接口契约的一部分。常见做法是：客户端做令牌桶（token bucket）控速，重试要带指数退避（exponential backoff）加随机抖动（jitter）；一旦触碰到限制，客户端就立即重新发送，这会把 429 变得更严重。批量任务拆小、长文分块、把非实时任务挪到队列里跑，都比硬扛划算。另一个实用判断是根据业务形态预判哪条限速会先触发：长文档总结、代码库分析这类“每次请求消耗大量 token、但请求次数很少”的场景，会先受 TPM 限制；分类打标、实时补全这类“每次请求消耗的 token 很少、但请求次数很多”的场景，会先受 RPM 限制。知道先触发哪条限制，才知道该往哪个方向申请提额，以及要不要在架构上加一层缓冲。
对普通职场人的意义：你用的聊天产品背后也有这套限制。高峰期“转圈”“稍后再试”，多半不是模型变笨了，而是排队所致。另外，按量计费通常与 token 挂钩，长对话比短问答贵得多，删掉没用的历史上下文，既更快也更省钱。