Kimi 的限流机制怎么读：并发、RPM、TPM、TPD 四道闸
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
Kimi 开放平台的限流不是一条线，是四道闸：并发、RPM、TPM、TPD。官方文档写得很清楚，速率限制”可能会在任何一种选项中达到，取决于哪个先发生”——也就是说四道闸里任意一道先触顶，你就吃 429，不需要四道都撞满。理解限流机制的重点有三个：第一，限速额度按账户累计充值金额划等级，而代金券不计入累计充值总额；第二，网关计算限速时用的是”请求 token 数 + max_completion_tokens”，不是实际生成的 token 数，这意味着你把 max_completion_tokens 写得很大却只生成了很短的回复，额度照样被按大数扣掉；第三，速率限制在用户级别而非密钥级别实施，且目前在所有模型间共享，所以多建几把 Key、换个模型调，都不会给你多出额度来。
先把四道闸的定义认全
Kimi 官方在「充值与限速」页把四个概念逐条做了解释，字面意思分别是：
- 并发：同一时间内平台最多处理的来自你的请求数
- RPM：requests per minute，一分钟内你最多发起的请求数
- TPM：tokens per minute，一分钟内你最多和平台交互的 token 数
- TPD：tokens per day，一天内你最多和平台交互的 token 数
这四个口径不是并列的备选项，而是同时生效的四道独立闸门。官方在平台介绍页里举过一个例子来说明这种关系：你可能只发了很少量的请求、每个请求的 token 数也很小，总的 token 消耗远没有摸到每分钟的上限，但只要请求条数先撞上每分钟请求数的上限，限流一样会触发。反过来也成立——一个超长上下文的请求可能单条就把每分钟的 token 预算吃掉大半，这时候请求条数还剩很多也没用。
所以排查限流问题的第一步，不是去猜”是不是发得太快了”，而是先确定自己撞的是哪一道闸。这四道闸对应的处理动作完全不同：撞并发要降并发度、撞 RPM 要降请求频率、撞 TPM 官方给的动作是降低调用频率或者升级 tier（实践上还可以从另一头下手，压缩上下文、拆分任务，把单条请求的 token 数降下来）、撞 TPD 则是当天没救了，官方给的说法是次日恢复或者升级套餐。关于这四种口径在不同厂商之间的通用差异，可以对照看 RPM 和 TPM 是什么、限流额度怎么估。
限速额度是怎么长出来的：跟着累计充值金额走
Kimi 目前的规则是基于账户的累计充值金额进行速率限制，累计充值金额同时决定账户等级与速率限制这四项。这里有几条容易被忽略的细则，都是官方明文写出来的：
代金券不计入累计充值总额。 官方在「充值与限速」页的「特别说明」里就只有这么一句话，但它的后果很实在：账上代金券再多也不会把账户等级往上推，你的并发、RPM、TPM、TPD 还是最低那一档。这一条对刚接入的团队影响很大——很多人以为账上有余额就等于有额度，结果一压测就撞线。
代金券本身对可用模型也是有限制的，别默认它跟充值余额等价。官方常见问题页把「代金券是否支持目标模型」直接列成了一条排查项，并且明确写了新用户注册认证赠送的代金券不可用于 Kimi K3。也就是说拿代金券去试旗舰模型跑不通，这跟限流完全是两回事，是代金券适用范围的问题，去降并发、降频率都不会有任何改善。
风控限速触发后不可解除。 官方的原话是当系统检测到账户存在异常行为时，会触发风控限速策略，该限制一旦触发即无法解除。这句话的分量比它的篇幅重得多：普通的限流是等一会儿就恢复的临时状态，风控限速是账户层面的持久状态。所以拿生产账号做无节制的压力测试是有实质代价的。
集群侧还有一层临时调整。 官方说明里写了，当集群负载达到容量上限时，平台可能采取临时的限流措施，对各类限速进行调整。这意味着你在后台看到的额度是名义值，高峰期的实际可用值可能低于它——这解释了为什么同样的代码昨天跑得好好的，今天开始报错。
如果确实需要更高的额度，官方给的路径是继续充值抬高账户等级，或者填写平台提供的「提升速率表单」提交更高需求。另外要留意，页面顶部挂着一条公告，说明平台预备对”充值等级与限速”规则进行更新，具体规则以官方页面当时的版本为准——这也是本文不写任何具体阈值数字的原因，写下来下个月就可能是错的。
最反直觉的一条：限速按 max_completion_tokens 预扣
这一条跟大多数人的直觉是反的，官方把它单独写在平台介绍页的「速率限制」一节里做了说明。
网关计算速率限制时，用的是请求中的 token 数量加上 max_completion_tokens 参数的数量，而不考虑实际生成的 token 数量。如果请求里带了 max_completion_tokens，就按你写的这个值算；如果请求里没带，就按默认的 max_completion_tokens 算（默认值以官方文档当前版本为准）。
而计费环节走的是另一套口径：按请求的 token 数量加上实际生成的 token 数量来算钱。
两套口径不一致，直接后果是：你可以有一个账单看着很省、限流却频繁触发的状态。典型场景是做分类、抽取、打标这类任务——每次实际只输出几十个 token，但为了图省事把 max_completion_tokens 设成了模型允许的最大值，于是每一条请求在限速账本上都按最大值记，TPM 很快就见底了，而账单上你确实只花了很少的钱。
这条机制反过来也给了你一个非常便宜的优化手段：按任务真实需要的输出长度去设 max_completion_tokens，对短输出任务把这个值收紧，就能直接换来更高的有效吞吐。这不需要改架构，也不需要充值升级等级，只是改一个参数。输出长度控制的通用做法可以参考站内的 并发怎么规划 一篇一起看。
限速挂在用户身上，不是挂在 Key 上
官方在同一节里附了两条注意事项，都很关键：
- 速率限制是在用户级别而非密钥级别上实施的
- 目前在所有模型中共享速率限制
第一条堵死了”多建几把 API Key 分摊额度”这条路——同一账户下建多少 Key，共用的还是那一份额度。第二条堵死了”换个便宜的模型跑批量任务来绕开限流”这条路——模型之间不是各自独立的额度池。
组织场景下还要再往上看一层。Kimi 的组织与项目体系里，官方明确写了：组织下的所有项目共享组织内的限速，同时也共享组织的账户余额。也就是说一个项目里跑飞的批量任务，会直接把同组织其他项目的线上服务挤掉。
平台给出的应对手段是项目级的独立限速配置：可以对单个项目可使用的最大 TPM 做限制，项目 API Key 的请求达到该 TPM 后请求会被拒绝。这里有一条边界必须记住——项目 TPM 不得超过组织的 TPM，如果你设置了超过组织 TPM 的数值，仍然会以组织 TPM 做限速。所以项目级 TPM 只能用来做”隔离与保护”，不能用来”扩容”。
预算侧还有一套并行的闸门：项目管理页可以设置每月/每日的消费额度，项目内 API Key 的消费达到预算后，后续该项目的 API 请求会被拒绝。注意这个拒绝跟限流不是一回事，触发它的是预算管控而不是速率闸门，遇到这种拒绝去降并发、降频率是白费力气，得去项目设置里看预算配置。至于预算超限时服务端具体返回哪个 error.type，官方文档里没有找到相关说明，所以别照着猜去写错误分支的判断逻辑，稳妥做法是先把响应体原样打出来看清楚。官方另外提示了因计费周期的关系，预算限制的实际执行会有一定延迟，不是即时切断，具体延迟以官方文档当前版本为准。
收到 429 先分诊，别急着重试
Kimi 的 429 不是单一原因。官方在常见问题页里明确要求先查看响应中的 error.type，错误码页则干脆按 error type 把 429 拆成了一张表。三类原因对应三种完全不同的动作：
engine_overloaded_error —— 典型 message 是 The engine is currently overloaded, please try again later。这是服务节点负载较高（比如高峰期容量压力）导致的。处理方式是按照 Retry-After 提示等待、降低并发并使用指数退避重试。这一类有个非常重要的判断依据：官方明说该错误由服务端容量导致，充值或提升 Tier 不能直接消除。看到它就别去充值了，充了也没用。
rate_limit_reached_error —— 这才是真正的”你超速了”。它细分成四种，正好对应前面那四道闸：触发组织级并发限制、触发组织级 RPM 限制、触发组织级 TPM 限制、触发组织级 TPD 限制。前三种降低调用频率或升级用户等级可解，TPD 那种官方给的说法是次日恢复或升级套餐。
exceeded_current_quota_error —— 这个归在 429 下面但其实是钱的问题：账户欠费或已停用、账户 token 额度不足、代金券失效。官方建议先通过查询余额接口确认 available_balance 再去充值，别盲目调限流参数。这一类可以配合 Kimi API 的限额怎么看 一起排。
还有一条对成本核算很友好的官方说明：因 429 错误中断的请求不会扣费。所以退避重试的成本焦虑可以放下一些，真正要担心的是重试把限流压得更死。通用的退避写法见 API 报 429 怎么办。
报错里的数字和后台对不上，先查是不是 Key 用错了
官方常见问题里专门列了这个现象。rate_limit_reached_error 的 message 模板形如 Your account {uid}<{ak-id}> request reached TPM rate limit, current:{current_tpm}, limit:{max_tpm}，里面会带上当前值和限制值。如果这个 limit 跟你在后台看到的等级对不上，官方给的排查方向不是去质疑平台，而是先确认是否用了当前账户的 api_key——通常这种不匹配的原因是用了错误的 api_key，比如误用了别人给的 Key，或者个人有多个账号时把 Key 混用了。
顺带一提，官方还写了中国站（platform.kimi.com）与国际站（platform.kimi.ai）的账户、余额和 Key 相互隔离。要注意这一条在官方文档里的位置——它是挂在「为什么调用返回 401、404 或 permission denied」这份排查清单下面的，跟 429 那一节不是同一批问题。换句话说，区域和端点对不上会表现为认证类报错，不会表现为限流；如果你手上的报错是 429，就别往区域这个方向排了。
别忘了 SDK 会自己偷偷重试
这是一个非常隐蔽的额度杀手。官方文档里点名说明：OpenAI SDK 等客户端默认会自动重试，一次操作可能放大为多次请求并占用限速额度，排查时请查看实际请求次数和客户端日志。
也就是说你代码里写的一次调用，落到限速账本上可能是好几次。官方甚至特别提醒，对于账户等级最低的用户，由于存在默认的重试机制，一次错误的请求就可能把每分钟的请求额度消耗掉。所以在做限流预算的时候，一定要按”客户端实际发出的请求数”算，而不是按”业务逻辑里调用了几次”算——这两个数在开了自动重试之后根本不是一回事。
并发调到多少合适
官方在压测最佳实践里回答过这个问题，给的原则相当克制：从较低的并发数开始；如果遇到限流导致的 429 错误，说明并发过高；找到一个能让你保持在速率限制内的合适并发水平。同一份文档还写了两条配套要求——保持较低的并发数以避免速率限制，以及重试逻辑是必须的，需要处理服务器过载、网络抖动、速率限制这类临时性故障。
如果你的任务本身不要求实时返回，还有一条更省事的路子：官方在批量推理定价页写明 Batch API 不受实时并发限制，适合大批量任务，代价是任务需要在指定的 completion_window 内完成，超时会变成 expired 状态。把离线的批处理挪到 Batch 上去，实时接口那边的四道闸立刻就宽松了。
最后：三条值得单独记住的坑
一是把余额当额度。账上有钱不代表限速额度高，代金券更是完全不进累计充值总额，等级该低还是低。
二是把 max_completion_tokens 当成”反正用不完就不算”。限速按预扣算，计费按实际算，这两套口径不一致，短输出任务尤其吃亏。
三是看到 429 就无脑重试。先读 error.type：服务端过载充值也没用，只能退避；组织级限速要降频率或升等级；额度不足得去查余额。分不清就重试，只会把并发压得更死，还可能把账户推向风控限速那条不可逆的路。
顺带说一句，本文所有机制描述都来自 Kimi 开放平台的公开文档，具体的等级划分、各档位阈值和定价随时可能调整，接入前请以官方「充值与限速」页面和定价页的当前版本为准。