HopBase先說答案:大模型 API 的高並發問題,本質不是「網關轉發快不快」,而是三件事疊加——上游配額稀缺(RPM/TPM 有硬頂)、上游錯誤常態化(429/5xx 是日常而非事故)、單請求生命週期長(串流幾十秒、影片任務分鐘級)。所以企業級網關的高可用靠的不是吞吐參數,而是調度:多上游互備、把錯誤納入調度判決的自動 failover、以及不犧牲快取命中率的親和調度。這三樣在接入前都可以用可復現的方法驗證,文末給出清單。
大模型 API 的高並發,和傳統 API 不是一回事
傳統 API 網關談高並發,拼的是每秒轉發多少請求;大模型網關的瓶頸根本不在這裡:
- 單請求生命週期長:一次串流對話幾十秒,一個影片生成任務分鐘級,並發容量吃的是「同時在途的長連接」,不是 QPS;
- 上游配額稀缺:每個上游帳號的 RPM/TPM 有硬頂,單帳號永遠扛不住業務峰值,「高並發」的第一性來源是帳號池的總配額;
- 上游錯誤是常態:429 限流、5xx 波動、時段性擁堵在所有大模型上游都存在,網關不處理,這些錯誤就會原樣砸在每個調用方頭上。
結論:傳統網關拼吞吐,大模型網關拼調度。評估一個「高並發網關」,要看的是它的調度層怎麼設計。
多上游分組:並發容量的第一性來源
HopBase 的做法是分組調度:一把 API Key 背後是一個分組,組內是多個上游帳號與通道,並發容量等於組內配額之和,而不是任何單帳號的 RPM。業務側的用法:
- 按業務線或團隊拆分組,配額互相隔離,批量任務不會擠占在線業務;
- 峰值業務單獨建組、單獨擴容,不影響其他調用方;
- 換模型、換通道在網關側調度完成,客戶端不改一行代碼。
分組機制怎麼同時把成本降下來,另有一篇:一個 API Key 調度多家上游。
failover:錯誤要參與調度判決,而不是直接甩給你
多數網關對上游錯誤的處理是「原樣返回,重試留給客戶端」——高並發場景下這等於把上游的不穩定放大給每一個調用方。我們的做法:
- 上游報錯先進入調度判決:不止 5xx,絕大多數可判定的 4xx 同樣觸發自動換帳號、換通道重試;
- 重試窮盡後,把上游的原始響應回放給你——不吞錯誤碼、不把 429 改造成超時,你客戶端自己的退避邏輯不會被毀掉;
- 計費以真實成功為準:失敗的請求(錯誤碼非空)不計費,這一條在用量導出裡逐行可驗。
探針與事件流:問題要在用戶感知之前被發現
高可用的另一半是主動發現,而不是等用戶報錯:
- 常駐健康探針持續撥測各通道;
- 每個上游帳號的錯誤與恢復形成事件流,異常帳號自動降權或摘除,恢復後再回池;
- 判斷上游死活用憑證直連對照實測,而不是猜——「感覺上游掛了」和「證明上游掛了」是兩回事。
快取親和:高並發不該犧牲 prompt cache
這是最容易被忽視的一項。prompt cache 的命中要求請求落在同一個上游帳號上;把請求隨機撒進帳號池的「負載均衡」,命中率會掉到接近零——高並發和快取收益在樸素設計裡是互斥的。
解法是親和調度:同一會話釘住同一帳號,親和窗口覆蓋官方快取的有效期,擴容時不打散既有會話。命中的收益是雙重的:快取讀取按折扣價計費,首字延遲也顯著下降。原理與實測見Prompt Cache 能省多少錢。
怎麼驗證一個網關的高並發成色(可復現)
機制要能被驗證才有意義。接入前建議跑這五項,對任何供應商都適用:
- 並發壓測看分布:固定任務集、溫度 0,並發 N 跑,看首字延遲(TTFT)的 P95/P99 而不是均值——長尾抖動大說明鏈路在排隊;
- 長輸出斷流率:讓模型輸出長內容,統計串流中途靜默截斷的比例,這是最惡劣的故障形態;
- 錯誤透傳測試:故意觸發限流或傳錯參數,看返回的錯誤碼是否與官方行為一致;
- 快取命中率:同一長系統提示連續請求,看 usage 裡快取讀取 token 的佔比是否穩定;
- 隔時段複測:高峰與低谷各測一輪,防時段性劣化。
模型身份與質量的驗證(防偷換、防降智)是另一套方法,見保真檢測方法。
常見問題
HopBase 支持多大並發?
並發承載按業務場景配置:企業批量任務、研發團隊共享、多業務線峰值調用是設計目標。接入前聯繫顧問按量評估,給出與你的負載匹配的分組方案。
為什麼不直接承諾 99.99% SLA?
頁面上的可用性數字無法被你驗證,我們更願意給可復現的驗證方法和公開的通道屬性(每條通道是什麼渠道、什麼倍率,定價頁全部寫明)。商務合同層面的服務條款,聯繫顧問洽談。
上游全部故障時會發生什麼?
多通道互備把單點故障變成局部降級;極端情況下所有重試窮盡,網關把上游原始錯誤透傳給你,不偽造成功,失敗不計費。
高並發擴容會導致快取命中率下降嗎?
不會。親和調度按會話釘帳號,擴容增加的是新會話的容量,既有會話不被打散,命中率不受擴容影響。