You need to enable JavaScript to run this app.
文档中心
火山方舟

火山方舟

复制全文
下载 pdf
实践教程
突发流量处理最佳实践
复制全文
下载 pdf
突发流量处理最佳实践
本文介绍存在突发流量的业务如何通过简单改造业务代码,避免因为突发流量导致限流,保障请求成功率。
什么是限流
方舟模型服务 API 会对单位时间内的请求次数、token 使用量、使用量的增长幅度及同时发起的请求数量进行限制,以保障服务的稳定运行和资源的合理分配。当调用方发起的请求触发 API 的限流,会返回 “429: 'Too Many Requests'” 错误。
为什么有限流
大模型服务因模型参数量庞大(数十亿至千亿级),算力成本高昂及扩容周期更长,导致业界模型服务平台面临流量承接能力(尤其是突发流量)不足的问题。在此背景下,平台会尽最大努力提升请求成功率,保障模型服务的整体可用性。限流作为请求的第一层流量防护机制,主要作用如下:
  • 减少 API 滥用或者误用:恶意攻击会给服务器发送大量请求,试图让服务过载导致服务中断。方舟设置速率限制,可以有效防止此类情况。
  • 保障用户公平地访问:避免个人或者组织发送过多请求,导致其他人的服务访问和响应速度减慢。通过限制单个用户的请求通量(单位时间请求量),确保尽可能多的人能正常使用API,减少 API 服务速度变慢情况。
  • 帮助控制平台总体负载:如果 API 服务请求极速增加,可能会给服务端资源带来很大扩容压力,导致性能问题。通过设置限流,可以帮助所有用户保持流畅、稳定的体验。
注意
限流是单位时间服务用量的上限,而非服务用量的刚性保障。当任务量突增(如突发流量)或持续高负载时,仍可能触发限流。为了尽可能用好限流配额,避免失败请求占据限流配额,建议用户主动平滑流量曲线或做好模型间的流量分流等。
限流对象
当前方舟的限流对象主要有:
  • 模型限流:同主账号下,同模型(不区分版本)限流,由方舟设定,不可手动调整,各个模型默认限流信息请参见 模型列表。如有超额的流量需求,请通过 工单 提交提额申请。
  • 推理接入点限流:推理接入点(Endpoint)限流,作用于推理接入点,用户可以自行调整,用于灵活控制应用的模型服务使用量。
限流类型
方舟提供了不同的限流指标。
限流类型
解释说明
适用对象
TPM
每分钟可以处理的 token 量限制,包含模型的输入和输出。
通常是在线推理中按 token 计费模型的模型服务的限流指标。
TPD
每天可以处理的 token 量限制,包含模型的输入和输出。
通常是批量处理的模型服务的限流指标。
RPM
每分钟可发起的请求量限制,用以防 Dos 攻击。
几乎所有模型都有对应 RPM 指标。
IPM
每分钟可生成的图片数量限制,面向生图模型。
通常是图片生成模型的模型服务的限流指标。
Inflight Batchsize
并行在途请求数,同主账号下指定模型同时在处理的请求数量限制,在途请求包括排队、数据传输、计算处理、数据回传全流程的请求。
几乎所有模型都有对应的并发数指标。
限流错误码
详细方舟错误码见 错误码
什么是突发流量
在单位时间内请求量产生剧烈波动,常见在定时数据处理任务、热点事件等场景,平台会根据请求特征、资源水位、模型特征、用户历史流量等因素认定突发流量(通常情况下,建议您将 Token 用量的增长速率控制在每 3 分钟 20% 以内)。
突发流量示意图
说明
常见行为
  • 发送请求频率加快
  • 发送请求的输入或输出长度突然变长等监控指标(TPM、RPM)
  • 控制台: 在线推理 > 推理接入点的详情页 > 监控 页签
平台处理策略
针对突发流量场景,平台采取以下策略提升推理请求成功率
  • 快速扩容指定模型的服务集群,以逐步承载住服务。
  • 方舟会在用户可容忍的超时时间内,通过服务端重试爬坡策略提升请求成功率。
  • 当突发流量抢占过多资源影响整体服务可用性时,平台将优先限制/熔断突发流量,保障其他用户的可用性。
  • 在触发限制和熔断时,方舟会对突增的请求返回 “429: 'Too Many Requests'” 错误信息,并在资源扩容到一定程度后(分钟级)逐步恢复。
错误码信息
客户端处理策略
业务评估存在突发流量限流情况,推荐以下主动优化策略,进一步提升请求成功率并规避限流风险。
  • 客户端整流,主动平滑流量曲线:通过缓冲机制(如消息队列、本地任务队列)将瞬时突发流量转化为低波动请求,控制对平台的流量增长斜率。从源头避免因斜率过高触发ServerOverloaded错误。
  • 客户端分流,跨模型负载均衡:利用方舟多模型的独立突发容忍能力,将流量分散至多个具备冗余容量的模型,避免单一模型资源耗尽。
注意
  • 仅支持跨模型分流(如同时调用“模型A”和“模型B”):不同模型的资源池相互独立,可分散流量压力;
  • 同模型多Endpoint/多账号分流无效:同一模型的所有推理接入点和账号共享同一个底层计算资源池,流量最终会汇聚到同一资源池,无法规避该模型的限流阈值。
  • 购买模型单元,主动扩容资源池:购买模型单元,预测自己的流量波动趋势,提前15分钟下单扩容购买模型单元,用扩容到的模型单元来承接自己的突发增量。
策略选择建议
业务场景
推荐组合策略
方舟能力支撑点
不可预测瞬时峰值(热点事件)
整流+分流
动态容限曲线+多模型资源隔离
可预测周期性突发(定时任务)
分流+购买模型单元
提前15分钟扩容+独立资源池
高稳定性要求核心业务
整流为主+购买备用单元
稳定承载区间+资源优先级保障
实践 通过 header 配置(推荐)
对于无需即时完成的推理请求,可以通过请求 header 字段传入标识。方舟服务端会检测对应标识,尽可能在指定时间响应请求。
平台对配置了 header 排队标识的突发流量请求,会按照策略重试排队中的请求,直到请求开始处理或者排队超时。对比普通请求来说,在触发突发流量限流时,不是直接报错,而是在排队时间内帮用户进行重试。
核心配置
header 字段
示例
说明
X-Ark-Max-Wait-Timeout-Ms
300000
突发请求的最大排队时间。
单位:毫秒
建议值:[60000,600000],1~10分钟
常见配置:
  • 60000:1分钟
  • 180000:3分钟
  • 300000:5分钟
  • 600000: 10分钟
超时时间配置
长请求(深度思考、长输入输出)需关注超时时间,避免因叠加了排队时间,客户端超时关闭连接,导致请求失败。
非流式请求stream:false
  • 超时时间:原基础超时时间(非突发场景)+突发请求最大排队时间
流式请求stream:true
  • 超时时间:> 突发请求最大排队时间
注意:如使用方舟 Go SDK ,流式输出请求超时时间也需设置 原基础超时时间(非突发场景)+ 突发请求最大排队时间
举例
请求原基础超时时间(非突发场景下) 30 分钟,突发请求最大排队时间 5 分钟。
  • 非流式输出超时时间: 35 分钟
  • 流式输出的请求超时时间
  • 方舟 Python/Java SDK:大于 5 分钟( SDK 默认超时时间 10 分钟,无需重新配置)
注意:如使用方舟 Go SDK ,流式输出请求超时时间也需设置 35 分钟
示例代码
示例代码
实践 客户端削峰填谷
设计逻辑
Client端突发峰值请求 → MQ无限制接收(削峰) → 消费端斜率可控匀速消费(填谷) → 方舟SDK调用大模型
  1. 削峰:RabbitMQ 做流量蓄水池,生产者无任何速率限制,承接所有瞬时峰值请求,彻底隔离峰值与大模型服务;
  1. 填谷:消费端以平稳速率消费 MQ 积压请求,充分利用大模型服务能力,无资源浪费;
  1. 斜率可控:消费速率从5QPS开始,每 5 秒增长 2QPS,直到 30QPS 封顶,增长斜率恒定,无任何陡增,不会打满大模型服务;
  1. 可靠性:MQ 队列 + 消息持久化、手动 ACK 确认,消息零丢失;失败请求自动重回队列重试。
示例代码
实践 QPS 爬坡策略
客户端通过实时监测服务端响应状态,动态调整请求速率,逐步提升吞吐量,从而有效避免服务限流、确保服务稳定性。
设计思路
QPS 爬坡工作原理如下图所示,统计固定时间间隔的限流错误,来评估线上服务负载。
  1. 逐步提升请求发送速率(QPS);
  1. 当发现错误率提升时,按照策略降低或稳定 QPS;
  1. 当服务稳定后继续提升QPS,并循环1、2;
  1. 最终达到平台对应模型的总限流(TPM、RPM)。
核心机制1:动态调整速率
QPS Climber (每秒查询率爬坡器)采用"试错-调整"策略,通过周期性评估请求成功率,动态调整请求速率。核心实现在 adjustQPS() 方法中。
示例代码
核心机制2:客户端限流与重试策略
QPS Climber 实现了两层保护机制:
  1. 客户端令牌桶限流:通过 golang.org/x/time/rate 包实现令牌桶算法,确保请求不会超过设定的QPS上限
  1. 指数退避重试:对失败请求采用指数退避策略进行重试,避免短时间内反复冲击服务端
示例代码
核心机制3:错误分类后智能路由
将服务端响应错误分为下面几类:
  • ServerOverloadedCode:服务过载(如HTTP 429)
  • InternalServerError:服务器内部错误(如HTTP 500)
  • UnknownCode:其他请求错误(如 HTTP 400)
通过 convertToCode() 方法实现错误智能分类,为动态速率调整提供决策依据:
示例代码
代码配置
配置示例
参数说明
参数名
默认值
推荐值范围
调优建议
InitialRate
10
5-50
根据服务初始承载能力设置,新服务建议从低值开始
MaxRate
1000
需根据服务配额估算
可根据业务请求使用量(TPM)和请求频率(RPM)来估算,建议设置为服务额定QPS的80%-90%,留有余量。
AdjustInterval
10s
5-15s
流量波动大时可适当缩短间隔。
StrictErrorRatio
0.05
0.03-0.1
错误率阈值1,错误率高于该阈值,会降低请求频率。
对稳定性要求高时可降低该值。
RelaxErrorRatio
0.01
0.005-0.05
允许少量错误时可适当提高该值。
ProbeRatio
0.05
0.03-0.1
速率调整步长,波动大时可降低步长。
RetryBaseDelay
100 ms
50ms-500ms
单位 ms,初始重试延迟,根据服务响应速度调整。
RetryMaxDelay
3 s
3s-10s
最大重试等待时间。
使用建议
  • 单例模式使用:在应用中创建单一的 QPSClimber 实例,所有API调用共享该实例,避免资源浪费。
  • 统一错误处理:通过 needRetryError() 方法统一处理各类错误,确保重试决策一致性。
  • 并发请求控制:结合Go语言的 sync.WaitGroup 实现高效并发请求,同时通过QPS Climber控制总体速率。
  • // 请求总量
    var total atomic.Int64
    total.Store(100000)
    // 并发请求示例
    var wg sync.WaitGroup
    concurrency := 1000
    wg.Add(concurrency)
    for i := 0; i < concurrency; i++ {
    go func() {
    defer wg.Done()
    for total.Add(-1) >= 0 {
    // 业务请求代码
    req := &model.CreateChatCompletionRequest{...}
    _, err := qpsClimber.DoRequest(ctx, req)
    // 错误处理
    }
    }()
    }
    wg.Wait()
  • 预热机制:应用启动时设置较低的初始QPS,通过 adjustInterval 逐步提升,避免冷启动时的流量冲击,导致被熔断。
  • 自适应调整:利用QPS Climber的动态调整能力,让系统自动适应流量变化。
  • 监控告警:关注QPS调整日志,设置错误率、成功率等关键指标的监控告警。
  • 降级预案:在极端情况下,考虑实现请求降级或熔断机制,确保核心功能可用。
完整项目代码
  • Go
chat-request-climber.zip
  • Python
python_example.zip
实践 退避重试策略
使用退避算法进行请求重试,是避免限流的简单且有效方法(不仅仅在突发流量场景),其中随机指数退避算法实现自动重试请求。
核心设计思路
当遇到速率限制错误时,先进行短暂休眠,随后重新发起未成功的请求。若请求依旧失败,系统会增加休眠时长,再次尝试,该过程会持续进行,直至请求成功或达到最大重试次数。
具备如下优势:
  • 自动重试功能可使系统从速率限制错误中恢复,避免崩溃和数据丢失。
  • 指数退避特性能快速进行首次重试。若前几次重试失败,较长的延迟时间可减少速率限制的触发。
  • 在等待时间中加入随机抖动,避免大量请求同时重试。
注意
不成功的请求会计入每分钟的请求限制内,因此高频重试会更快达到限流阈值,导致更多请求失败。采用指数退避算法进行重试,能在遵守速率限制规则的前提下,提高请求成功的概率,保障系统的稳定运行。
示例代码
示例代码
实践 使用TPM保障包
在可预测或者重点保障的业务,为了应对流量突增,可考虑购买 TPM 保障包来覆盖突发流量,方舟允许 TPM 保障包额度内的突发流量,提供更高的 SLA 和资源优先级。用户无需变更任何代码,只需在指定的接入点上购买 TPM 保障包即可。详细介绍及购买指引见 在线推理(TPM 保障包)
最近更新时间:2026.09.22 16:52:17
这个页面对您有帮助吗?
有用
有用
无用
无用