硅基流动的限速怎么算：RPM、TPM 与六个用量等级

有一类问题隔一段时间就会被人重新问一遍：监控面板上每分钟的请求数明明离上限还差一截，服务端却开始返回限流。第一反应往往是怀疑平台的限速文档写错了，或者怀疑自己的计数器有 bug。两个方向大概都白查——在硅基流动这种双维度限速的平台上，这个现象本身是正常的，它说明你只盯着了两个闸门里的一个。

下面按三层把这件事拆开：两个维度各自管什么、模型名里那个前缀为什么会让同一个模型有两套配额、以及为什么这里的配额不是一份可以抄下来的规格表。

一、RPM 和 TPM 是两把独立的闸

按官方限速文档的口径，硅基流动的分层限速同时看两个维度：RPM，每分钟请求数；TPM，每分钟 token 数。关键在于这两个是并联关系而不是串联关系——任意一个触顶都会触发限流，不需要两个都满。

于是「RPM 没用满却被限流」的解释很直接：先撞墙的是 TPM。而且在真实负载里，TPM 先于 RPM 触顶是更常见的那一边，原因是一次请求吃掉的 token 越多，同样的请求数下消耗的 token 预算就越多，撞上 TPM 的时刻就越早。

哪些负载是 token 大户，其实不难点名：

• 长上下文对话，历史消息每轮都重新提交一遍，输入侧随轮次线性膨胀；
• RAG 场景，检索回来的若干段原文拼进提示词，单次输入量由检索召回条数决定，而不是由用户那句话决定；
• 需要长输出的任务，比如整篇改写、结构化长表格生成，输出侧的消耗不比输入侧小；
• 反过来，高频的短分类、短抽取请求是典型的 RPM 大户而非 TPM 大户。

这里可以推出一个不依赖任何具体数值的算法，也是我认为比记数字有用得多的东西：拿你自己业务的单请求平均 token 量（输入加输出，从日志里真实统计，不要凭感觉估）去除限速里给的 TPM，得到的商是「TPM 这个维度所允许的等效每分钟请求数」。把它和 RPM 上限放在一起取较小的那个，那才是你这条负载真正的并发上限。同一个账号、同一个等级，做长文改写和做短文本分类算出来的可用并发会差得很远，因为分母完全不同。

这也解释了为什么「照抄别人文章里的限速数字」这件事从根上就不成立：数字是平台给的，分母是你自己业务给的，别人那篇文章里没有你的分母。关于把并发和限流当成一个整体来设计，可以再看一下聚合网关到底解决了什么问题里关于配额与调度的那部分。

二、Pro/ 前缀：同一个模型，两个名字，两套限速

第二层机制藏在模型名字符串里。硅基流动请求示例里的模型名形如 Pro/deepseek-ai/DeepSeek-R1，这个 Pro/ 不是修饰词，它是一套有明确含义的命名规则。

按官方公告的说明：同一个模型，不带前缀的是免费版，沿用「厂商名/模型名」的写法；带 Pro/ 前缀的是付费加速版。这套命名规则的由来就是为了区分免费与收费两种形态，同时保住原有调用方式的兼容性。而在速率上，免费版的速率与并发都更低——也就是说这两个名字对应的不是同一份配额，而是两套。

把这条机制翻译成工程语言，它的杀伤力在于：一个字符串前缀的差别，决定了你这条流量落进哪个限速池，而这个差别在代码里几乎不显眼。两种典型的错法：

一种是开发阶段用免费版名字把链路跑通了，功能验证全绿，上线时忘了改模型名，结果流量一上来就开始批量限流，而报错信息只告诉你被限流了，不会告诉你「因为你用的是免费档」。另一种是压测阶段用付费版跑出一份漂亮的容量报告，生产配置却回退到了免费版名字，容量结论直接失效。

所以这件事的正确处理方式不是「记得小心」，而是把 model id 从代码里拔出来收成配置项或环境变量，跟 base_url 和密钥放在一起管，让它在部署清单上可见、可在发布前被人眼扫一遍。关于这套字符串该怎么收口，base_url 该怎么配和OpenAI 兼容意味着什么、不意味着什么里讲的是同一个思路：凡是换平台就得改的字符串，都不该写死在调用点上。

顺带一句，免费版按官方说明速率与并发更低，这个定位本身是清楚的——它适合用来验证链路是否通、返回格式是否符合预期，不适合用来承接线上流量。把它当成生产容量的一部分，是在拿一份没有保障的余量做承诺。

三、六个用量等级：这是个变量，不是一份规格表

第三层是最容易被误解的一层。硅基流动的分层限速设了六种用量级别（0 到 5），按账号的月度消耗金额划分，新用户注册后默认在最低级，等级越高对应的 RPM 与 TPM 越高；官方也提供通过充值一步到位的「等级包」方式升级。

这套设计意味着一件对容量规划影响很大的事：你的限速不是产品规格，是账号状态。 它随消费额变，同一个账号在不同月份可以处在不同的档位上。由此有三个推论：

第一，任何一篇文章（包括这篇）里写出来的具体数值，对你都不成立。写文章的人有他自己的等级，还有他写作那天的版本，两个变量你都对不上。这也是我这篇通篇不给数值的原因——给了反而更糟，因为它看起来像是可以直接抄进容量表里的东西。

第二，容量规划的动作要从「查文档记下规格」改成「登录控制台确认账号当前处在哪一档」。官方模型广场页面（https://cloud.siliconflow.cn/models）可以看到模型、价格与限速，限速文档给的是分层规则，两处结合起来看的才是你现在真实拥有的配额。

第三，也是我觉得官方文档说得不够清楚的地方：公告只说了按月度消耗金额划分等级，没有明确讲降档怎么判定——判定周期是自然月还是滚动窗口、消耗下降之后多久生效。对有明显季节性的业务（比如只在特定几个月放量的活动型流量），这件事直接关系到旺季来的时候你手里还有没有上个月那份容量。这一层我不打算替官方补答案，只能提醒：以控制台实际显示的当前等级为准，如果这条对你的业务是关键路径，值得在放量之前先问清楚。

四、这三层机制落到客户端限流上

知道了机制，客户端该怎么写就比较清楚了：

双计数器，而不是单计数器。 大多数人的客户端限流器只数请求数，这在双维度限速下只防住了一半。token 侧也要有一个分钟窗口的计数器：输入侧的 token 量在发出请求前是可以算出来的，输出侧算不准，就按这次请求设定的输出上限保守计入，宁可估高。

退避要对齐分钟窗口。 既然两个维度都是「每分钟」的口径，被限流之后毫秒级的紧密重试几乎没有意义，它只是在同一个已经满了的窗口里反复撞门，还会把重试本身变成新的负载。退避的量级应该朝着窗口翻页去设计。

长请求和短请求分池。 如果长上下文任务和短请求共用一个队列，长请求会把 TPM 预算吃掉，然后所有短请求一起被限流——明明短请求自己一点也不超。按 token 量级把它们拆成两条队列分别限流，长的那条按 TPM 卡，短的那条按 RPM 卡，互相不影响。

不要把限速余量当性能指标。 RPM 和 TPM 是配额，不是吞吐能力；它们变高说明你的账号档位变了，不说明模型跑得更快了。这两件事在压测报告里最好分开写，混在一起会得出错误的结论。成本与调度上的取舍可以顺着按成本做路由那篇继续看。

五、上线前值得走一遍的自检

• 从真实日志里统计出单请求的平均输入与输出 token 量，而不是估一个数；
• 用这个平均值算出 TPM 维度允许的等效请求数，和 RPM 上限取较小值，记为这条负载的并发上限；
• 逐个确认生产配置里的 model id：该带 Pro/ 前缀的带了没有，不该带的有没有误带；
• 登录控制台确认账号当前所处的用量等级，并把这一项写进容量文档（连同确认日期，因为它会变）；
• 客户端限流器是请求数和 token 数两个计数器，退避对齐分钟窗口；
• 压测的观测指标里要有「限流请求占比」，而不是只看单请求延迟——延迟好看但限流比例高的结果，上线之后就是间歇性失败。

六、这篇为什么一个数值都不给

这篇通篇没写一个限速数值，是故意的。各等级的 RPM/TPM 具体是多少、等级包怎么定价、哪些模型有免费版，这些以官方模型广场与限速文档为准，我不认为把它们抄进一篇文章里对读者有正面价值——抄的那一刻就开始过期，而读者拿它做容量规划的时候不会知道它已经过期了。

真正有价值的是那个分母：你的业务单请求平均吃多少 token。这个数只有你自己的日志里有，任何一篇文章、任何一份别人的压测报告都替不了它。上线之前按你自己的 token 与请求比测一遍，得到的那个上限才是你能拿去承诺的。

至于要不要再加一层网关来做多平台分流——那是另一个话题。力达云自己是独立的第三方服务，与任何模型厂商都没有官方合作、代理或授权关系，一期也只接了 DeepSeek，所以如果你在硅基流动上用的是别的开源模型，这边暂时给不了对应的替代，这些边界写在可验证声明里，可以自己核。选型这件事上，能自己验的判据永远比别人的结论可靠。