硅基流动用量和额度怎么查：余额、限额与用量级别分开看

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

很多人问「硅基流动的额度在哪儿看」，问题本身就没问对——平台上根本不存在一个叫「额度」的统一数字。它是三本互相独立的账：一本是钱（还要再分充值余额和赠费余额，两者能付的模型不一样），一本是速率限额（七种指标，定义在账户级别，而且每个模型单独设一套），一本是用量级别（按月消费金额自动分档，档位决定收费模型的限额有多宽）。这三本账查的地方不同、变动规则不同，混在一起想只会越查越乱。最快的定位方式反而是看报错码：402 是钱的问题，429 是速率限额的问题，403 多半是实名认证的问题。

第一本账：余额分两种，能付的模型不一样

充值页面上那个总数不能直接当成「我还能用多少」，因为硅基流动的余额分充值余额和赠费余额两类，而模型对这两类余额是挑食的。

官方文档在讲模型命名规则时写得很明确：DeepSeek R1 与 V3 是按支付方式区分命名的，带 Pro/ 前缀的版本仅支持充值余额支付，不带前缀的非 Pro 版则支持赠费余额和充值余额支付。

这条规则的实际后果是：如果你手上主要是赠费余额，却把模型名写成了 Pro/ 开头的那个，调用就会走充值余额这条路——余额总数看着不少，付款却过不去。反过来也一样，想把赠费余额花掉，就得确认你调的是不带前缀的那个模型名。

顺带说清 Pro/ 前缀的另一层含义：官方规定部分模型同时提供免费版与收费版，免费版按原名称命名，收费版在名称前加 Pro/ 前缀。所以同一个模型在平台上可能存在两个名字，两个名字对应两套完全不同的限额规则（下一节讲）。查余额够不够用之前，先确认你代码里写的到底是哪一个模型名。

关于余额构成和赠费的更多背景，可以对照站内那篇讲硅基流动计费机制的文章一起看。

第二本账：限额要落到「某个具体模型」上才有答案

硅基流动的速率限制一共有七种指标：RPM（每分钟请求数）、RPH（每小时请求数）、RPD（每天请求数）、TPM（每分钟 token 数）、TPD（每天 token 数）、IPM（每分钟图片数）、IPD（每天图片数）。以官方文档当前版本为准。

关于这七种指标，有三条机制必须先搞清楚，否则查出来的数字也用不上：

第一，任一指标先达峰就触发限流，不是要全部达标。 官方专门举了个例子说明：当一分钟内发出的请求条数先到了顶，即使 token 用量还远没到上限，限流照样会触发。很多人查了 TPM 觉得「我离上限还早」，结果卡在 RPM 上——这是把七个指标默认成了「同时满足才拦」，实际是「任意一个先到就拦」。

第二，Rate Limit 定义在用户账户级别，不是 API key 维度。 这意味着多建几把 key 不会让额度变宽，几把 key 共用同一套限额；反过来讲，如果你用错了 key，查到的账户也是错的。

第三，每个模型单独设置限额，一个模型超限不影响其他模型。 所以「我的限额是多少」这个问题没有唯一答案，只有「某模型在我这个账户下的限额是多少」才有答案。

具体到某个模型的限额数值，官方给的查询入口是模型广场。至于免费模型和收费模型的差别：免费模型的限额是固定值，收费模型则按账户用量级别分层，级别越高限额越宽。也就是说，免费模型查一次就长期有效，收费模型的限额会随着你的用量级别浮动，需要定期回去核对。

想理解 RPM、TPM 这类指标在各家平台的通用含义，可以看限流指标 RPM 与 TPM 的通用解释。

第三本账：用量级别取「上月」和「当月至今」的最高值

用量级别是决定收费模型限额宽窄的那个变量，它的计算口径值得单独说，因为规则有点反直觉。

官方的说法是：用量级别按月消费金额划分，这个金额包含充值消费与赠送金额；换算时取「上月」与「当月 1 号至今」两者中的最高值；达标即自动升级、立即生效；新用户的初始级别为最低档。

拆开看有三个结论。其一，赠送金额也算进消费额，所以用赠费余额跑出来的量不是白跑的，同样在往级别上累。其二，因为取的是两个周期的最高值，上个月的消费额在本月仍然参与换算，不会因为跨月清零而让级别在月初突然掉下去。其三，升级是自动且立即生效的，不需要提交申请等审批——如果你发现限额突然变宽了，多半就是级别刚跳档。

至于各档的门槛金额和各档对应的限额数值，本文一律不写：这类分级是平台随时可能调整的运营参数，只能以官网当前页面为准。你要做的是记住规则形状（按月消费额、取双周期最高值、自动升降），而不是背某个数字。

充值和消耗是两本账，对账时别搞混

「用量查询」最后总要落到花了多少钱上，这里有一条官方规则很容易被忽略：充值页面的勾选项明确写着充值资金不支持直接开具发票，开票是按实际消耗费用开、并且需要发邮件申请。

这条规则等于平台在告诉你：充进去的钱和消耗掉的钱是两套账目，前者只是预存，后者才是你真正的成本。所以做月度成本核算时，看充值流水是没用的，得看消耗侧的账单。

官方「财务相关」这块文档的正文一共只有三部分：如何充值、如何查询账单、模型微调计费。其中模型微调计费是单独的一节；官方没有说明微调的计费口径与普通对话调用有何异同，做微调的话直接去看那一节。

需要如实说明的是：我核对的官方文档快照里，「如何查询账单」这一节并没有收录逐步的界面操作路径，所以控制台里账单页面的具体入口位置，本文不作臆测，以你登录后看到的当前界面为准。

跨平台的成本记账思路，可以参考站内的API 成本监控做法。

报错码是最快的额度体检工具

与其在控制台里翻页面，不如直接看接口返回的状态码，它对「哪本账出问题了」的指向非常准。以官方错误码文档为准：

• 401：API Key 没有正确设置。属于鉴权问题，跟额度无关，别急着去充值。
• 402：账户欠费，充值后重试。这是唯一一个明确指向余额的码。
• 403：权限不够，官方点明最常见的原因是该模型需要实名认证。这个码经常被误当成「额度不够」，实际是账户资质没到位。
• 429：触发了速率限制，官方要求按返回的 message 判断到底是 RPM、RPD、TPM、TPD、IPM、IPD 中的哪一种。429 的官方响应原文是 Request was rejected due to rate limiting. If you want more, please contact contact@siliconflow.cn。
• 503 / 504：服务负载较高，稍后再试；对话与 TTS 请求可以尝试改用流式输出。

错误响应的结构本身也带信息，官方给的示例形如 {"code":20012,"message":"Model does not exist. Please check it carefully.","data":null}——注意 code 字段和 HTTP 状态码不是一回事，排查时两个都要打印出来。

429 之后的处理，官方给的做法是等待一段时间后重试，并推荐使用指数退避，也就是每失败一次就把下一次重试的间隔拉长，而不是原地高频硬试——后者只会让下一个统计窗口继续被自己的重试请求占满。

三种「查了也对不上」的情况

已经充值成功，仍然提示余额不足。 官方给的排查方向有两条：先确认 api_key 是否与刚刚充值的那个账户匹配（多账号的人最容易踩这个）；其次可能存在网络延迟，等几分钟再重试。

明明没跑多少量却报 429。 官方按用户类型分了两条路：普通用户去查自己的用户等级和该模型的限额；专属实例用户通常没有限额，出现 429 要先确认是不是调用了专属实例的正确模型名、api_key 是否与专属实例匹配。

限额和账户对不上号。 回到前面那条机制——限额是账户级别的，不是 key 级别的。查限额时先确认你手上这把 key 属于哪个账户，再去看那个账户的用量级别。

官方给的通用排查步骤同样适用于这类问题：先把错误码和 message 打印出来；用 curl 复现一次以排除客户端因素；换一个模型试试看是不是模型侧的问题；最后，如果开了代理，关掉代理再试一次。

让余额别掉底：自动充值的机制

比起隔三差五手动去查余额，官方提供的支付宝自动充值更像是给余额装了个监控。它的机制是：签约后，余额低于你设定的阈值时自动补充。

几条流程性规则值得记住：平台每 10 分钟检测一次余额；默认夜间 22:00 至次日 08:00 不执行自动充值，这个时间段可以在设置中调整；执行前 10 分钟会发短信通知；一旦扣款失败会自动停止，需要手动解约后重新签约；想调整阈值，也必须先解掉旧约再签新约，不能直接改。

另外两种到账方式的节奏也顺带说清：在线充值（支付宝或微信，电脑端扫码、手机端跳转 App）是即时到账；对公转账汇款走的是企业大额通道，需要先完成企业认证再创建订单，打款账户名称必须与实名认证主体一致、金额必须与订单完全一致，转账后 1~5 分钟更新状态，官方特别提醒不要重复转账，未按要求转账导致失败的资金通常在 24 小时内退回。

最容易栽的坑

栽得最多的一个坑是没实名。官方写明，不实名的直接后果是无法充值、也无法申请开票；而且实名之后才能使用全部免费模型——这也解释了为什么有人调免费模型却收到 403。实名还有一条容易忽略的限制：30 天内只能完成一次变更或修改，所以个人认证和企业认证在做之前就得想清楚，官方明确提醒企业用户不要去做个人实名认证，一个账号也只允许绑定一个认证主体。

第二个坑是把免费模型的限额当成收费模型的限额。免费版限额固定、收费版随用量级别变化，同一个模型的两个名字查出来是两个结果。免费档的用法边界可以看硅基流动免费额度怎么用。

下一步建议这么做：把你实际在调的模型名列出来（注意区分有没有 Pro/ 前缀），逐个去模型广场核对限额；在代码里把返回的 HTTP 状态码和响应体里的 code、message 一起记进日志；月末对账时只看消耗侧数据，不看充值流水。这三件事做完，「用量和额度」就不再需要靠猜了。