硅基流动速率限制机制与触发后的处理

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

硅基流动的速率限制有三个和直觉不一样的地方，踩坑基本都踩在这三处：第一，官方文档列了七种限流指标（RPM、RPH、RPD、TPM、TPD、IPM、IPD），任意一种先达到峰值就触发限流，不需要几种指标同时超；第二，Rate Limit 定义在用户账户级别，不是 API Key 维度，你多建几把 key 分摊请求是没用的；第三，限额是按模型分别设置的，一个模型被限住不影响你调另一个模型。收到 429 之后正确的动作是先读 message 判断具体是哪一类指标超了，再对应去改调用节奏，而不是无脑重试。以上均以官方文档当前版本为准。

先搞清楚它到底在限哪七个东西

官方文档在限流那一节列出的指标有七种，按维度可以分成三组：

• 请求数：RPM（每分钟请求数）、RPH（每小时请求数）、RPD（每天请求数）
• token 数：TPM（每分钟 token 数）、TPD（每天 token 数）
• 图片数：IPM（每分钟图片数）、IPD（每天图片数）

值得注意的是它把小时级和天级窗口也纳入了限流口径，也就是说你即使把瞬时并发压得很低、每分钟稳稳不超，仍然可能在一天跑到后半程的时候撞上 RPD 或者 TPD 这种长窗口的墙。官方只给出了 IPM 与 IPD 这两个指标的名称，未说明它们的适用范围。

至于每个指标的具体数值，官方是让你去模型广场查对应模型的限额，本文不复述数值——这类阈值平台随时可能调整，写死在文章里过两个月就是错的。

「任一指标先达峰即触发」这句话的分量

这是最容易理解反的一条。官方文档明确写的是：任一指标先达到峰值就触发限流，不是要所有指标都达标才触发。

官方自己举的例子说得很清楚：假设某模型同时设了每分钟请求数上限和每分钟 token 数上限，你在一分钟之内发了一批体积很小的请求，每个请求消耗的 token 都少得可怜，token 那一路远远没有用满，但只要请求条数先摸到了上限，限流照样触发。

把这个逻辑写成代码里的判断，就是或不是与。我见过不少人自己实现节流的时候只盯着 token 预算做控制，理由是「token 才是花钱的那个」——在这套规则下这么做会漏。正确的做法是七个指标各维护一条计数，任意一条接近上限就压节奏。

反过来说，这条规则也解释了一类看起来很莫名其妙的现象：明明在跑一批极短的分类任务，输入输出都只有寥寥几十个 token，却比跑长文摘要更容易被限。因为短任务的特征就是请求条数密集，最先撞的是请求数那一路。关于 RPM 和 TPM 这两类指标在各家平台的通用含义，可以先看限流指标 RPM 与 TPM 是什么意思。

限额挂在账户上，不是挂在 key 上

官方文档里有一句话值得单独拎出来：Rate Limit 定义在用户账户级别，而不是 API Key 维度。

这句话的直接推论是：给不同的服务、不同的环境各建一把 API Key，并不能让你获得更多配额。多把 key 只解决权限隔离和泄漏时的止损问题，配额是共享的一个池子。有些团队在做微服务拆分的时候，习惯性地认为「每个服务一把 key 就等于每个服务一份额度」，这个假设在这里不成立，压测的时候会直接暴露。

真正需要做的是在账户这一层做统一的调用调度：把限流控制放在网关或者共享的客户端组件里，而不是让每个服务各自为战地重试。否则十个服务同时撞墙、同时开始重试，会把问题放大而不是缓解。多把 key 该做的事情是权限隔离，不是配额扩容，这两件事要分开看。

每个模型单独算，免费版和 Pro 版还不是同一套

第二条容易被忽略的规则是：每个模型单独设置限额，一个模型超限不影响其他模型。

这条其实是个好消息，它给了你一个不用改架构的缓解手段——被限住的时候，如果任务本身对模型不挑，切换到另一个模型可以立刻恢复，因为两个模型的计数器是分开的。官方给的通用排查步骤里也有「换一个模型试试」这一条，既是用来定位问题的，某种程度上也是应急手段。

再往下还有一层区分。硅基流动对部分同时提供免费版和收费版的模型，采用的命名规则是：免费版沿用原名称，收费版在模型名前加 Pro/ 前缀。这两者的限流待遇不一样：

• 免费版的 Rate Limits 是固定的，不会因为你账户消费得多就放宽
• 收费版的 Rate Limits 随账户的用量级别变化，级别越高限额越宽

所以「我充了钱为什么免费模型还是这么容易被限」这个问题，答案就在这里：你充值提升的是收费版那条线的待遇，免费版那条线的限额是定死的。想拿到更宽的口子，得把调用切到带 Pro/ 前缀的那个模型名上。这两条线的区别，在硅基流动免费额度用完了怎么办里还有更多展开。

顺带说一句，Pro/ 前缀在这里不只是限流待遇的区分。官方文档提到 DeepSeek R1 与 V3 是按支付方式区分命名的：Pro/ 版仅支持充值余额支付，非 Pro/ 版则支持赠费余额和充值余额支付。也就是说改个模型名，动的不只是限额，还有从哪个钱包扣费。

收费模型的用量级别是怎么算出来的

既然收费模型的限额跟着用量级别走，那就得知道级别是怎么定的。官方文档说明的规则是：

• 用量级别按月消费金额划分，这个金额既包含充值消费也包含赠送金额
• 取「上个月的消费」和「当月 1 号至今的消费」两者中的较高值来换算级别
• 达标即自动升级，立即生效，不需要手动申请
• 新注册用户从最低档开始

「取两者较高值」这个设计有点反直觉，但它带来的实际效果是防止跨月掉档：你上个月用得多，这个月月初还没来得及消费，级别不会在 1 号那天骤降。反过来，如果某个月开始集中放量，当月的累计一旦超过上月，级别也会跟着往上走，不用等下个月生效。

各档的门槛金额和对应限额本文不列，这类分级规则平台调整很频繁，以官方定价与限流文档的当前版本为准。

收到 429 之后，按这个顺序处理

官方文档给出的 429 响应文案是这样一句：

Request was rejected due to rate limiting. If you want more, please contact contact@siliconflow.cn

这句话本身不告诉你超的是哪个指标，但官方错误码表里给了判断路径：429 触发 rate limits 时，按 message 判断具体是 RPM、RPD、TPM、TPD、IPM、IPD 中的哪一种。所以第一步永远是把完整的 message 打出来，而不是只 catch 一个状态码就走重试分支。

之后的处理顺序建议这样走：

1. 打印错误码与完整 message。官方给的通用排查步骤第一条就是这个，很多人卡住是因为客户端库把响应体吞掉了，只剩一个 HTTP 状态码
2. 确认自己账户的用量级别和该模型的限额。官方对普通用户的 429 排查指引就是先查这两项，级别和限额对不上预期，说明问题在账户侧不在代码侧
3. 用 curl 复现一次。绕开所有 SDK 和框架，确认不是客户端封装引入的重复请求
4. 换一个模型试。前面说过限额按模型独立，换模型能立刻区分「是这个模型的额度问题」还是「账户整体出了问题」
5. 重试用指数退避。官方对超限的处理建议就是等待后重试并推荐指数退避，不要写固定间隔的死循环重试——固定间隔的重试在限流场景里会形成同步共振，多个客户端一起在同一个时刻重试，第二波照样全军覆没

如果你用的是专属实例，排查路径不一样：官方说明专属实例用户通常没有限额，所以出现 429 的时候要先确认两件事——是不是调用了专属实例的正确模型名，以及 api_key 是不是与专属实例匹配。官方给的就是这两个确认项，至于对不上时请求会落到哪里、按什么限额计，官方文档未作说明。429 在各平台的通用处理套路，另见API 返回 429 的通用处理方式。

别把这几个错误码当成限流

排查限流问题的时候，有几个错误码经常被误判成同一回事，官方错误码表里它们的含义完全不同：

• 402：账户欠费，充值后重试。不是限流
• 403：权限不够，官方点明最常见的原因是该模型需要实名认证，其他情况看 message。这一类看起来像「被拦了」，但跟调用频率无关
• 503 / 504：服务负载较高，稍后再试。这是服务端侧的压力，不是你超了配额。官方对这两个码额外给了一条建议——对话与 TTS 请求可以尝试改用流式输出
• 429：才是真正的 rate limits

把 402、403 混进限流的重试逻辑里是很常见的错误：欠费和未实名这两种状态，你重试一万次也不会自己好，只会把日志刷满。重试策略里应该只对 429 和 5xx 生效，4xx 里除了 429 之外的都应该直接失败并告警。

还有一条官方通用排查步骤容易被忘掉：如果开了代理，关闭代理再试。这条虽然是针对通用报错给的，但在排查间歇性失败的时候值得先排除掉——代理导致的连接异常有时候会以很奇怪的形态暴露出来，先把变量减掉再查会省很多时间。更完整的报错分类可以看硅基流动报错排查。

最后：先量一遍，再谈优化

处理限流最没有效率的做法，是一边猜一边调参数。硅基流动这套规则其实给了很清晰的定位路径：撞的是哪一类——message 会告诉你（官方错误码表列出可从 message 判别的是六项）；是账户级还是 key 级的问题——规则说了是账户级，那就别在 key 上做文章；是这个模型的问题还是全局问题——换个模型跑一次就知道。

真正需要你自己动手的只有两件事：一是在客户端把七类计数都埋上，别只盯 token；二是把重试策略从固定间隔改成指数退避，并且把 402、403 从重试分支里摘出去。这两件做完，剩下的就是根据业务量决定要不要把调用切到带 Pro/ 前缀的收费模型上，让限额跟着用量级别一起涨。具体每个模型的限额数值，去模型广场按模型查，别信任何第三方文章里抄下来的数字，包括这一篇——本文只讲机制。