百鍊 API 按請求數和 Token 用量限流。本文提供從平台配置到用戶端流控再到架構兜底的應對方案。
百鍊 API 對請求數、Token 用量和增長速率設有限制,即限流。大模型請求延遲高,且同時受請求數和 Token 量兩個維度約束,單純"遇錯重試"效果有限,需要針對性的流控措施。
本文按改動成本從低到高,介紹三類方案:
限流按主帳號維度、模型獨立計算,觸發後通常 1 分鐘內恢複。各模型的限流條件和當前用量參見模型限流條件和模型用量監控。百鍊 API 有以下三種限流規則:
同一錯誤碼可能由不同限流維度觸發。高並發下服務端飽和也可能導致響應變慢或逾時,可通過自適應擁塞控制策略緩解。
以下方案依賴平台能力,用戶端改動極少或無需改動。
針對增速/突發限流(Traffic Burst),百鍊支援在要求標頭中聲明最大等待時間。服務端收到後,在指定時間內排隊重試,直到請求開始處理或逾時。相比直接返回 429,該機制可顯著提升突發流量下的成功率。
配置方式
在要求標頭中添加
逾時時間配置
配置排隊等待後,需相應調整用戶端逾時時間,避免因疊加排隊時間導致串連提前關閉:
預設額度不足時,可在百鍊控制台直接提升臨時限流額度,提交後立即生效。目前支援華北2(北京)和新加坡地區。
適用情境:業務增長導致 RPM/TPM 配額不足,或短期活動需臨時提升輸送量。操作詳情參見限流。
操作簡單,建議在嘗試用戶端流控前優先評估。
PTU 服務提供獨立預留的專享算力,可避免公用資源集區的競爭,是保障即時高吞吐的首選。
適用情境:業務對輸送量有確定性要求(如 SLA 承諾),或希望免去用戶端流控開發,直接獲得穩定高吞吐。
PTU 為預留資源,未滿負荷使用也持續計費。建議根據實際峰值評估規格,避免閑置浪費。
資料清洗、離線分析等無即時性要求的任務,可使用 Batch API 批量提交。任務在低峰期非同步執行,不受線上限流約束。
適用情境:資料標註、日誌分析、批量摘要等允許數小時至數天返回結果的任務。費用通常低於即時 API。
結果返回時間不確定,不適用於需即時響應的線上業務。提交後需通過輪詢或回調擷取結果。
當平台方案(如服務端排隊等待、提升額度等)無法滿足需求時,需在用戶端引入流控。核心原則:將請求均勻分布在時間視窗內,避免突發觸發限流。系統啟動或長時間空閑後,應逐步提升並發而非瞬間拉滿。
以下四種策略按工程複雜度遞增,每種包含上一級能力並增強:
四種策略在不同負載下的輸送量表現:
適用於個人測試、本地指令碼等低並發情境。不限制發送速率,僅在收到
上述代碼使用指數退避而非固定間隔重試。固定間隔重試會讓所有失敗請求同時重發,再次觸發限流。指數退避 + 隨機抖動將重試打散:
被動重試難以應對真實業務流量,頻繁重試增加延遲。該策略引入主動流控:請求發出前先自檢,將無序湧入的請求梳理成符合 RPM 限額的隊列。主動平滑帶來少量可控的排隊延遲,但遠低於”報錯—等待—重試”迴圈的代價——用確定的小代價,避免不確定的大延遲。
適用於 Chatbot 等輕量互動、對首字延遲敏感的線上服務。
用戶端主動排隊分兩級控制:
RAG 即時入庫、長文檔批量分析等高穩吞吐情境中,請求速率限制存在 TPM 盲區。流量整形策略升級為雙重資源感知(RPM & TPM),並在發送端引入整形機制,將突發脈衝削峰填穀為平滑流速。
在請求速率限制基礎上,增強了以下能力:
該策略採用保守平滑機制,會犧牲部分峰值並發,不適用於極致低延遲的線上服務。
適用於 API Gateway、複雜代理、多租戶等大規模動態負載情境。
請求速率限制和流量整形基於靜態配額,負載穩定時完全適用。但在網關級情境下,下遊負載複雜多變(短請求與深度推理交織),平台閾值也動態波動,靜態策略難以兼顧效率與穩定。
該策略借鑒 BBR,建立基於 EBP(Elastic Bandwidth Probing) 的閉環控制系統。以 RPM/TPM 配額為指導上限,根據即時反饋(延遲、限流訊號)動態計算最佳發送速率。
相較於原生 BBR,針對大模型特性做了以下改造:
當平台配置和用戶端流控仍無法滿足可用性或峰值吞吐要求時,可在架構層面引入兜底。
主模型因限流或異常無法響應時,自動回退至配額寬裕的備選模型,保障主流程持續可用。
降級鏈路設計原則
模型降級可與用戶端流控策略組合使用。例如,在請求速率限制策略的重試邏輯中整合降級判斷:當重試次數耗盡仍觸發限流時,切換至備選模型。
不要求即時響應的後端業務,可引入訊息中介軟體(如 RabbitMQ、Kafka)削峰。突發流量先寫入 MQ,消費端按限流配額勻速拉取處理,從根本上解耦前端峰值與後端調用。
適用情境:使用者提交任務後可非同步通知結果的業務,如工單處理、內容審核、批量標註等。
設計要點:
上述樣本基於 Python asyncio 單線程迴圈,用於示範核心演算法。大規模生產前需關注以下問題。
- 平台配置方案(低改動成本):服務端排隊等待、提升限流額度、PTU、Batch API。
- 用戶端流控策略(改用戶端代碼):從基礎重試到自適應擁塞控制,按工程複雜度遞進的四種策略。
- 架構兜底方案(改系統架構):模型降級(Fallback)、基於訊息佇列(MQ)的削峰填穀。
429 報錯,可查看錯誤診斷與策略推薦定位原因。若為突發流量(Traffic Burst)觸發,推薦先試服務端排隊等待——只需加一個要求標頭。
平台限流機制
限流按主帳號維度、模型獨立計算,觸發後通常 1 分鐘內恢複。各模型的限流條件和當前用量參見模型限流條件和模型用量監控。百鍊 API 有以下三種限流規則:
- 分鐘級配額限制(RPM / TPM):每分鐘允許的最大請求數(Requests Per Minute,RPM)和最大 Token 用量(Tokens Per Minute,TPM)。
- 瞬時頻率限制(RPS / TPS):每秒允許的最大請求數(RPS)和最大 Token 用量(TPS)。單秒內請求或 Token 消耗過於密集時觸發。
- 增速限制(Traffic Burst):短時間內請求量或 Token 用量激增時觸發。閾值隨服務狀態動態調整,逐步提升請求量可避免觸發。
錯誤診斷與策略推薦
同一錯誤碼可能由不同限流維度觸發。高並發下服務端飽和也可能導致響應變慢或逾時,可通過自適應擁塞控制策略緩解。
錯誤碼 (DashScope / OpenAI) | 觸發維度 | 特徵診斷 | 推薦策略 |
|---|---|---|---|
Throttling.RateQuota / limit_requests | 請求頻率超限 | 間歇性報錯,成功率隨時間下降 | 令牌桶:控制單位時間內的請求配額 |
請求頻率超限 | 啟動瞬間或並發激增時集中報錯 | ||
Throttling.AllocationQuota / insufficient_quota | Token 用量超限 | 長文本處理時間歇性報錯 | 雙重令牌桶:同時限制 RPM 和 TPM 配額 |
Token 用量超限 | 長文本並發時瞬間 Token 消耗過大 | ||
Throttling.BurstRate / limit_burst_rate | 流量增速超限 | 啟動或空閑恢複後突然發起大量請求 | 推薦首選服務端排隊等待;或令牌桶設定低初始值(如 |
平台配置方案
以下方案依賴平台能力,用戶端改動極少或無需改動。
服務端排隊等待(推薦首選)
針對增速/突發限流(Traffic Burst),百鍊支援在要求標頭中聲明最大等待時間。服務端收到後,在指定時間內排隊重試,直到請求開始處理或逾時。相比直接返回 429,該機制可顯著提升突發流量下的成功率。
該功能僅適用於增速/突發限流(Throttling.BurstRate),不適用於 RPM/TPM 絕對值限流。
X-DashScope-Wait-Timeout 欄位:
Header 欄位 | 樣本 | 說明 |
|---|---|---|
X-DashScope-Wait-Timeout | 30 | 突發請求的最大排隊等待時間,單位為秒。
|
- 非流式請求(stream: false):逾時時間 = 原基礎逾時時間 + Wait-Timeout 值。
- 流式請求(stream: true):逾時時間 > Wait-Timeout 值。流式請求在收到首個 chunk 後開始計時,只需確保首次響應逾時大於排隊時間。
程式碼範例
程式碼範例
OpenAI Python SDK
提升限流額度
預設額度不足時,可在百鍊控制台直接提升臨時限流額度,提交後立即生效。目前支援華北2(北京)和新加坡地區。
適用情境:業務增長導致 RPM/TPM 配額不足,或短期活動需臨時提升輸送量。操作詳情參見限流。
操作簡單,建議在嘗試用戶端流控前優先評估。
預置吞吐單元(PTU)
PTU 服務提供獨立預留的專享算力,可避免公用資源集區的競爭,是保障即時高吞吐的首選。
適用情境:業務對輸送量有確定性要求(如 SLA 承諾),或希望免去用戶端流控開發,直接獲得穩定高吞吐。
PTU 為預留資源,未滿負荷使用也持續計費。建議根據實際峰值評估規格,避免閑置浪費。
非同步批處理(Batch API)
資料清洗、離線分析等無即時性要求的任務,可使用 Batch API 批量提交。任務在低峰期非同步執行,不受線上限流約束。
適用情境:資料標註、日誌分析、批量摘要等允許數小時至數天返回結果的任務。費用通常低於即時 API。
結果返回時間不確定,不適用於需即時響應的線上業務。提交後需通過輪詢或回調擷取結果。
用戶端流控策略
當平台方案(如服務端排隊等待、提升額度等)無法滿足需求時,需在用戶端引入流控。核心原則:將請求均勻分布在時間視窗內,避免突發觸發限流。系統啟動或長時間空閑後,應逐步提升並發而非瞬間拉滿。
以下四種策略按工程複雜度遞增,每種包含上一級能力並增強:
- 基礎重試僅做被動防禦;
- 請求速率限制加入主動排隊;
- 流量整形進一步引入 Token 維度管控和平滑發送;
- 自適應擁塞控制則基於即時反饋動態調整發送速率。
各策略的輸送量表現對比

- 基礎重試策略:低負載下有效,高並發下易觸發擁塞崩潰,輸送量斷崖式下降。
- 請求速率限制策略:防崩潰能力強,但長文本混合負載下因缺乏 Token 管控,輸送量呈鋸齒狀波動。
- 流量整形策略:穩定性高,以犧牲部分峰值吞吐換取平穩輸出。
- 自適應擁塞控制策略:高負載下可動態收斂至穩定高吞吐點,但存在冷啟動探測開銷。
基礎重試策略
適用於個人測試、本地指令碼等低並發情境。不限制發送速率,僅在收到 429 或 5xx 時觸發帶隨機抖動的指數退避重試。
沒有前置流量控制,多線程並發下易觸發限流並導致請求積壓。
程式碼範例
程式碼範例
- 等待時間逐步翻倍:如
1s:2s:4s...,避免短時間內反覆請求。 - 加入隨機抖動:引入隨機值(如
2s +/- 0.5s)打散重試流量,防止"紮堆"重試形成二次洪峰(驚群效應)。
請求速率限制策略
被動重試難以應對真實業務流量,頻繁重試增加延遲。該策略引入主動流控:請求發出前先自檢,將無序湧入的請求梳理成符合 RPM 限額的隊列。主動平滑帶來少量可控的排隊延遲,但遠低於”報錯—等待—重試”迴圈的代價——用確定的小代價,避免不確定的大延遲。
適用於 Chatbot 等輕量互動、對首字延遲敏感的線上服務。
用戶端主動排隊分兩級控制:
- RPM 令牌桶:限制每分鐘請求總數。桶容量即 RPM 配額,令牌恒定速率填充。支援預支:令牌不足時可透支未來額度,嚴格 FIFO。
- 並發訊號量:限制並發請求數,防止瞬時高並發觸發 RPS 限制。
initial_tokens=rpm_limit),適合線上服務啟動時立即處理請求。若滿桶啟動觸發限流,可降低初始值(如 initial_tokens=0,空桶啟動),使系統以更平緩的速率進入工作狀態。
該策略不追蹤 Token 用量,長文本任務中仍可能耗盡 TPM 配額。
程式碼範例
程式碼範例
流量整形策略
RAG 即時入庫、長文檔批量分析等高穩吞吐情境中,請求速率限制存在 TPM 盲區。流量整形策略升級為雙重資源感知(RPM & TPM),並在發送端引入整形機制,將突發脈衝削峰填穀為平滑流速。
在請求速率限制基礎上,增強了以下能力:
- 雙重資源管控(RPM & TPM):同時維護 RPM 和 TPM 令牌桶,所有請求在發出前必須通過兩個維度配額檢查。
- 輸入事前預扣,輸出事後結算:模型輸出長度請求前未知。TPM 令牌桶發送時僅預扣輸入 Token,完成後結算實際輸出。即使結算後令牌為負,後續請求也會等待回正,自然平滑流速。
- 勻速預熱:冷啟動期間,令牌發放速率隨時間軸性增長,消除初始突發風險。
- 平滑限速:通過強制請求間保持最小間隔(Pacing),平滑發送速率,降低觸發速率限制的風險。
initial_tokens=0)實現安全啟動,降低用戶端複雜度。Python 令牌桶僅用於示範思路,生產環境建議使用成熟限流組件(如 Java Guava 的 SmoothRateLimiter)。
程式碼範例中平滑等待置於並發鎖內部。多個請求可能在等待結束後同時競爭訊號量,導致流量在出口再次擁堵。鎖內平滑雖輕微降低並發效率,但能確保發送間隔可控。
完整的流量整形鏈路為:預估輸入 Token → 雙重准入(RPM & TPM)→ 並發鎖 → 平滑整形 → 發送 → 輸出 Token 結算。

程式碼範例
程式碼範例
自適應擁塞控制策略
適用於 API Gateway、複雜代理、多租戶等大規模動態負載情境。
選型提示:該策略並非通用方案該策略的價值在於應對高度不確定與劇烈波動的環境,並非普適選擇:
- 效能悖論:若負載可預測(如定量批處理),直接設定最優靜態參數通常優於需要"試探與收斂"的動態探測。
- 探測損耗:動態演算法必然伴隨冷啟動爬坡與試探波動,在可知情境下是不必要的效能損耗。
- 維護成本:閉環反饋機制增加系統複雜度與排查難度。
- 彈性探測(EBP):記憶歷史最高成功水位,根據當前並發與最高水位的距離類比彈簧張力計算探測增益(距離遠加速,近減速)。疊加微小線性推力確保高飽和區仍能探索邊界。
- TPT 擁塞感知:大模型產生耗時與長度成正比,長文本延遲高不代表擁塞。使用 TPT(Time Per Token)作為指標,濾除內容長度雜訊,僅在 TPT 顯著惡化時判定為計算飽和。
- 防突發調速器:無論 EBP 算出的目標多高,調速器強制限制並發增長加速度,確保流量平滑上升,避免階梯跳變觸發增速限制。

- 指導性探測:引入已知的 RPM/TPM 配額作為"指導上限",避免盲目試探導致的頻繁撞牆。
- 訊號源改造(RTT → TPT):原生 BBR 依賴 RTT,但大模型中內容長度帶來的延遲差異遠大於網路抖動,改用 TPT 剔除幹擾。
- 響應機制強化(ProbeRTT → Hold):面對延遲波動,選擇保持當前並發水平,而非主動退避降低吞吐。
- 硬限流響應(Packet Loss → 429 Drain):一旦觸發
429錯誤,進入激進的 Drain 狀態,冷卻期結束後執行快速恢複。
- TPT 噪點:當前 TPT 按"總延遲 / 總 Token 數"粗估,混入了網路往返、排隊與首字產生耗時,易受抖動或長輸入幹擾而虛高,可能誤觸發 Hold 狀態。
- 大請求饑餓:為追求調度效能採用了非嚴格 FIFO 喚醒機制,配額緊缺時短 Token 請求可能搶佔資源,導致長 Token 請求等待過長。
- 冷啟動:需要預熱時間建立統計模型,低負載或短時任務中輸送量可能低於前三種策略。
程式碼範例
程式碼範例
架構兜底方案
當平台配置和用戶端流控仍無法滿足可用性或峰值吞吐要求時,可在架構層面引入兜底。
模型降級(Fallback)
主模型因限流或異常無法響應時,自動回退至配額寬裕的備選模型,保障主流程持續可用。
降級鏈路設計原則
- 選擇不同系列的模型:百鍊限流按模型獨立計算,可選不同模型作為備選,例如
qwen3.6-plus降級至qwen3.6-flash。 - 僅限流錯誤時降級:降級針對
429限流錯誤,網路逾時或參數錯誤切換模型無法解決。 - 備選模型需提前驗證:確保備選模型支援業務所需功能(如 Function Calling、結構化輸出),避免降級後功能異常。
程式碼範例
程式碼範例
以下樣本示範了基於 429 錯誤碼的模型降級邏輯:主模型請求觸發限流時,自動切換至備選模型重試。
基於訊息佇列(MQ)的削峰填穀
不要求即時響應的後端業務,可引入訊息中介軟體(如 RabbitMQ、Kafka)削峰。突發流量先寫入 MQ,消費端按限流配額勻速拉取處理,從根本上解耦前端峰值與後端調用。
適用情境:使用者提交任務後可非同步通知結果的業務,如工單處理、內容審核、批量標註等。
設計要點:
- 消費速率控制:消費端應配合請求速率限制或流量整形策略,按 RPM/TPM 配額勻速消費,而非無限制地拉取訊息。
- 死信處理:多次重試仍失敗的訊息轉入無效信件佇列並警示,避免無限重試阻塞消費。
- 背壓傳遞:MQ 積壓超閾值時向上遊反饋壓力(如返回排隊狀態),避免隊列無限增長。
生產環境注意事項
上述樣本基於 Python asyncio 單線程迴圈,用於示範核心演算法。大規模生產前需關注以下問題。
-
非文本模型的適配
上述策略以文本模型為例,核心思想同樣適用於多模態模型(映像產生、語音合成等)。計量單位不同,但本質均為限制提交速率和處理容量:
- 語音辨識等模型:通常受單位時間內請求數(如 RPM)和用量(如音頻時間長度)雙重約束,策略與文本模型基本一致。
- 圖片/視頻等模型:通常受任務提交速率和並發任務數約束。可沿用請求速率限制策略的思路,限制任務提交速率並配合訊號量控制並發數。
-
並行存取模型的原子性
樣本:
asyncio單線程協作式調度,狀態修改天然原子,單進程內無需額外並發保護。 生產建議:多線程或多進程環境需確保令牌桶及統計視窗的並發安全,否則競態條件會導致流控失效。 - 分布式限流 樣本:流控組件均為本地記憶體實現。 生產建議:多執行個體部署中各執行個體獨立流控,實際總用量可能超標。建議使用中心化計數器(如 Redis)統一管控。
- 優先順序隊列與饑餓預防 樣本:均未實現優先順序區分。自適應擁塞控制策略為追求調度效能採用了非嚴格 FIFO 喚醒。 生產建議:業務存在高低優先順序請求時,建議實現加權優先順序隊列保障高優頻寬,同時為低優隊列保留最小配額防止饑餓。