硅基流动官方博客发布API速率限制与 429 重试策略说明，指出限流基于用户账户级而非单个API Key，并按模型分别配置；429 响应包含信息可帮助判断是RPM、TPM、RPD、TPD、IPM还是IPD触发。
AI解读：硅基流动官方博客发布《SiliconFlow API Rate Limits and 429 Retry Strategies》，说明其API的限流维度、429 错误成因和处理方式。文中指出，限流定义在用户账户级别，而非每个API Key独立计算，在同一账户下创建多个Key不会产生独立容量。
限额同时按模型分别配置：触达某一模型的上限通常不妨碍账户调用其他仍有容量的模型。免费模型可能有固定限额，付费模型的限额可随账户等级、模型类别和模型规模变化，硅基流动建议在生产配置前查看当前模型详情。
429 响应意味着触达了某一适用限额，不一定是请求数量过多。文中列举的成因包括小请求突发触达RPM、长上下文触达TPM、同账户多服务共用同一限额、流量突发、自动重试放大负载，以及部分模型的按小时或按天限制等。
重试方面，官方建议只重试临时性失败，采用指数退避（如约 1 秒、2 秒、4 秒、8 秒）并加入随机抖动，设置最大延迟和最大重试次数，使用请求队列控制释放速率，并避免在应用层叠加SDK自带重试。
文中区分了 429、503、504 等状态码：429 应降低请求释放速率并退避重试；503 为临时服务负载，可有选择地重试或回退到其他模型；504 为请求超时或服务负载，可考虑流式响应；400、401、403 分别对应参数或模型ID错误、鉴权失败和权限不足。
对于持续接近限额的正常生产流量，硅基流动称可通过Model Plaza提交RPM和TPM提额申请，提交表单会启动评估但不保证获批；持续高吞吐的负载也可评估专用实例，专用实例通常不适用标准账户限流。
硅基流动官方博客发布关于API速率限制与 429 重试策略的说明文章，梳理其限流指标、触发原因和应对方式。文章称，硅基流动的限流定义在用户账户级别，而不是每个API Key单独计算；在同一账户下创建多个API Key不会产生独立的容量。
文章介绍硅基流动使用多种限流指标，包括RPM（每分钟请求数）、RPH、RPD、TPM（每分钟Token数）、TPD、IPM和IPD。语言模型应用主要需关注RPM和TPM，但某些模型或账户还可能有按小时或按天的限制；任一适用指标达到上限，请求都可能被限流。
RPM与TPM衡量不同维度
文章解释，RPM限制一个账户在一分钟内可向某模型发送的请求数，TPM限制一应用在一分钟内可处理的Token数。自动补全、聊天应用、Agent循环等场景容易出现用户一次操作触发多次模型调用：例如一个Agent任务可能在规划、工具选择、结果校验和最终生成各发一次请求，用户提交一个任务却消耗四次或更多请求。
TPM方面，长系统提示、对话历史、检索文档、源代码、推理内容以及较大的输出上限都会增加Token消耗。文章用两个应用对比：同样每分钟发送 10 次请求，每次 300 Token的应用约处理 3,000 Token，每次 8,000 Token的应用约处理 80,000 Token，后者即使请求量不高也可能先触达TPM上限。
- RPM：每分钟请求数，常见瓶颈为高频小请求。
- TPM：每分钟Token数，常见瓶颈为长提示、大上下文或长输出。
- RPH/RPD：每小时/每日请求数，可能为模型特定限制。
- TPD：每日Token数，常见于高日消耗场景。
429 错误的多种成因
文章称，HTTP 429表示触达了某一适用限额，并不总是意味着请求数量过多。除小请求突发和长请求超出TPM外，同一账户下的多个应用、后端服务、worker或API Key可能共用同一账户级限额，单个服务看似流量低，合计仍可触达上限；流量也可能在短时间内突发，即使日均值低于容量。
自动重试会进一步放大负载：立即重试把更多流量送入已被限流的系统，多个worker同时重试可能形成重试风暴，延长原有问题。此外，部分模型可能有额外的按小时或按天限制；专用实例配置错误（例如调用错误的模型ID或使用与专用实例不匹配的API Key）也可能返回 429。文章建议第一步记录HTTP状态码和完整响应体，硅基流动的 429 响应包含消息，可帮助判断是RPM、TPM、RPD、TPD、IPM还是IPD导致失败。
重试与流量控制建议
文章建议生产应用只重试临时性失败，且不应无限重试。指数退避可让重试延迟逐次增加，例如约 1 秒、2 秒、4 秒、8 秒，同时应设置最大延迟和最大尝试次数；随机抖动可避免多个实例在同一时刻重试。请求队列可吸收临时突发并按受控速率释放请求，交互请求可优先，后台任务等待容量。
文中提到，3 到 5 次尝试对部分交互应用可能合理，但正确次数取决于请求超时、用户体验和业务重要性；最终失败后应返回清晰错误、稍后处理或路由到经批准的备用模型。对涉及支付系统、数据库、文件操作等外部副作用的Agent工作流，重试模型请求不应自动重复已成功的动作，可使用幂等键或操作ID去重。此外，部分SDK（如文中示例使用的OpenAI Python库）自带自动重试，再在应用层添加重试循环会使总尝试次数成倍增加。
错误状态码区分与并发估算
文章区分了临时性错误与需要修正的错误：429 为触达适用限额，应降低请求释放速率并退避重试；503 为临时服务负载，可有选择地重试或使用合适的回退模型；504 为请求超时或服务负载，可选择重试、考虑流式并检查超时设置；400 通常为参数或模型ID错误；401 为API Key无效或缺失；403 为权限不足。文章还称，对较长的非流式请求反复出现 504 时，重复发送同一请求可能无法解决，可考虑流式响应、减少请求输出或检查客户端超时。
关于并发估算，文章给出一个容量规划示例：假设模型有 1,200 RPM、60,000 TPM，观测到每次请求 1,200 Token、P95响应时间 4 秒，并按 80% 安全系数计算，则TPM是更紧的约束，估算活跃并发为 2 到 3 个请求。文章称这只是容量规划估算，并非保证的API限制；并发上限本身也不执行RPM或TPM限制，需配合队列、令牌桶或漏桶式限流器控制新请求释放节奏。
应用侧设计与提额途径
文章建议把限流处理纳入应用架构：测量每个用户操作产生多少次模型调用，跟踪prompt、completion和total Token的中位数、P95和最大值，按模型分别控制流量，清理重复上下文、限制检索结果、总结较旧对话历史并设置现实的输出上限。工作量可按质量、延迟、成本和容量要求路由到合适模型，但文章强调路由应反映任务需求，而非用于规避平台限制，每条路由仍需质量、延迟、Token和失败监控。
对于评测、文档处理、分类和大规模抽取等离线任务，文章建议在可用时使用硅基流动Batch API，并确认当前支持的模型、端点、处理行为和适用限制。当正常生产流量持续接近可用RPM或TPM限额时，可在Model Plaza左侧边栏底部选择Higher Limits，提交RPM和TPM提额申请，需包含真实流量估算、预期Token消耗、负载模式和生产需求；文章称提交表单会启动评估，但不保证所有申请获批。持续高吞吐或需要更可预测容量的应用还可评估专用实例，专用实例通常不适用标准账户限流，但仍需监控实例吞吐、延迟、超时、队列深度及应用栈其他位置的限制。