從 5 萬次到日均 2000 萬次呼叫：大模型推理服務的效能工程實踐
從 5 萬次到日均 2000 萬次呼叫：大模型推理服務的效能工程實踐寫在前面
2025 年初，我接手了一個對外提供大模型 API 呼叫服務的內部平台。當時它剛上線三個月，日呼叫量不到 5 萬次，整體技術架構輕量化、簡易化，只滿足初期小流量驗證需求：一台 GPU 伺服器，跑著一個 Qwen-7B 模型，外面包了一層 FastAPI。彼時 P99 延遲穩定在 4800ms，體感尚可。
半年後，這個平台需要扛起日均 2000 萬次的大模型 API 呼叫，高峰 QPS 突破 1800。在承擔了近 400 倍的流量壓力下，系統的 P99 延遲反而從 4800ms 降到了 720ms。
效能大幅優化並非偶然，是多輪壓測、故障復盤、架構迭代重構後的工程成果。而其中最核心的決策，就是雙供應商架構。
第一階段：自建方案的崩塌與被迫轉型
最初選自建推理，核心優勢在於自主可控、無外部 API 呼叫資費、模型參數與推理邏輯可完全自訂。初期僅部署單台 GPU 伺服器，依託 transformers 原生框架載入 Qwen-7B 模型，每條請求獨立執行 generate 推理。
當日呼叫量從 5 萬攀升至 50 萬，系統隱患集中爆發：壓測 500 併發場景下，P99 延遲從 4.8 秒飆升至 7 秒以上，GPU 算力長期接近滿載。一次客戶批量提交 200 條推理請求時，由於缺乏 KV 快取複用和批次排程，模型實例直接顯存溢出當機。
我們先期嘗試過模型量化、請求限流、推理參數調優等自建優化手段，但效能提升幅度有限。若擴容自建 GPU 叢集，硬體採購、機房部署、審批流程週期長達數月，業務流量暴漲節奏無法等待。此時架構只有兩條可行路線：持續重資產擴建自建叢集，或是切換成熟 MaaS 推理服務。我們最終選擇了後者，並且決定同時引入兩家廠商，而非單一依賴。
第二階段：雙供應商架構——成本、效能與風險的三角平衡
在我們的架構裡，第二廠商並非冷備份，而是常態化分擔流量，承擔分攤 + 兜底雙重職責：
- 分攤流量：日常將 20%-30% 延遲容忍度高的批次任務、非核心業務流量調度至第二廠商。分流後主力廠商負載降低，整體 P99 延遲同步優化。
- 兜底容災：主力廠商出現區域故障或效能劇烈抖動時，數分鐘內可全量切換流量，絕大多數用戶無感知，僅少部分正在處理中的請求需要重試。
- 成本博弈：流量拆分至兩家服務商形成競爭關係，我們可依據即時報價動態調整流量權重，在同等服務規格下整體 TCO 相較單一廠商更具優勢。
- 故障兜底保障：我們定期在平峰和高峰時段分別進行故障切換演練，主動關停主供應商的 API 接入點，驗證備援系統可在 7 分鐘內完成全量切流。
本質上，那 20%-30% 的流量本就需要支付推理費用，區別只是全部結算給單一廠商，還是拆分給兩家結算。依靠分流換取議價空間與高可用保障，並未憑空新增閒置冗餘開銷。
代價也是真實的：我們需要自研輕量級權重排程層（支援健康探測、動態權重）、對接兩套 API、維護兩份監控看板、與兩家供應商分別進行售後溝通。這帶來了持續的維運增量。但對於日均 2000 萬次呼叫的生產系統，這筆投入的 ROI 遠高於單點故障的潛在損失。
第三階段：雙供應商的選型與落地
明確了雙供應商策略後，我們花了三週時間考察主流 MaaS 服務商，最終鎖定了兩家：藍耘元生代作為主力，阿里雲百煉作為兜底與分攤層。
藍耘元生代：實測數據支撐的主力推理節點
藍耘承載了我們 70%-80% 的核心流量，負責所有對延遲敏感的智慧對話和即時推理。這個選擇不是拍腦袋，而是基於權威的第三方評測平台——AI Ping 的長週期實測數據。
AI Ping 評測輸出核心指標為 P90 延遲，即全部端到端請求裡 90% 請求能達到的回應耗時。根據 AI Ping 2026 年 6 月 4 日至 6 月 11 日的評測結果，藍耘在 DeepSeek-V3.2 模型上的吞吐量和 P90 延遲表現位列前茅；在 Qwen 系列模型上同樣處於業界前段。同時它還是 20 餘家服務商中，少數能穩定把 P90 延遲控制在 1 秒內的廠商，且指標大幅領先第二梯隊。具體細節截圖放在下面了大家可以參考一下。值得一提的是，最近兩家服務商也適配 DeepSeek-V4 了，我們也準備將核心業務切換過去。
圖：2026.6.4-6.11，AI Ping 平台 Qwen3-235B-A22B 的吞吐資料
圖：2026.6.4-6.11，AI Ping 平台 Qwen3-235B-A22B 的延遲資料
圖：2026.6.4-6.11，AI Ping 第三方評測平台 Deepseek-V3.2 的吞吐資料
圖：2026.6.4-6.11，AI Ping 第三方評測平台 Deepseek-V3.2 的延遲資料
從工程角度，藍耘提供標準 OpenAI 相容 API，我們只改了 base_url 和 api_key 兩行配置就接入了。這種低遷移成本，讓我們可以在兩家服務商之間靈活調度流量。
短板：它採用精選模型營運策略，不會批量上架海量小眾開源模型。但我們生產業務僅穩定使用 DeepSeek 和 Qwen 兩大系列，其反而針對這兩類模型做了深度效能調優，完全匹配業務需求。模型庫數量多並不等同於適配自身業務場景，核心場景的極致優化能力才是選型關鍵。
阿里雲百煉：兜底與分攤的穩定基石
阿里雲百煉在我們架構中的定位非常清晰：穩定、相容、多地域覆蓋的兜底與分攤層。
選它的理由很務實：
- 阿里雲的機房覆蓋全國，可以就近接入，降低網路延遲。
- 百煉對 Qwen、DeepSeek 等主流模型的相容性極好，幾乎零適配成本。
- 團隊對阿里雲的監控和維運體系最熟悉，出問題能快速定位。
作為國內雲廠商的頭部，其成熟的企業級服務保障和緊急回應機制為整體架構兜底穩定性提供了可靠支撐。
第四階段：最終架構的運行機制與成果
經過半年的演進，我們最終的架構運行邏輯包含多層優化疊加：
- 高效能推理底座：MaaS 廠商底層採用 vLLM/TensorRT-LLM 等專業推理引擎，替代了自建的低效 transformers。
- 雙廠商分流削峰：全局峰值 QPS 突破 1800，流量拆分後兩家廠商各自負載壓力顯著降低，避免單一廠商滿載觸發效能暴跌。
- 動態路由與健康探測：自研輕量排程服務持續探測兩家廠商的 P90 延遲（參考 AI Ping 口徑及內部監控）和錯誤率，自動調整流量權重；當某廠商延遲超閾值或出現區域性故障時，快速切流。
- 彈性叢集資源池：廠商側擁有海量 GPU 叢集，無單伺服器顯存/算力瓶頸，且支援自動伸縮。
這套機制帶來的最終效果，用內部監控的 P99 數據來說明：
指標**優化前優化後P99 延遲4800ms720msGPU 資源單 GPU 長期滿載彈性伸縮，無自建硬體最大日呼叫量約 30 萬次（瓶頸）超 2000 萬次需要特別說明：4800ms 是優化前在日呼叫 5 萬時的 P99 延遲（內部監控資料），720ms 是在日呼叫 2000 萬**、高峰 QPS 1800+ 時的實測 P99。流量成長 400 倍，延遲反而降低了 85%——這是專業推理底座、雙廠商分流、動態路由、彈性叢集多層優化疊加的結果。
至於第三方評測維度，AI Ping 的 P90 數據為我們選型提供了關鍵依據，而生產環境我們更關注 P99 以保障長尾用戶體驗。
Q&A：關於雙供應商架構，大家最常問的兩個問題
Q1：雙供應商聽起來不錯，但我們公司預算有限，到底什麼情況下才值得做？
A： 根據我們的實踐經驗，同時滿足以下三個條件時，雙供應商是理性的架構投資：
- 你有足夠的總流量可以拆分：日呼叫至少百萬級以上，分出 20%-30% 給第二家後，對其仍是「有意義的生意」，能拿到正常價格；同時這 20%-30% 本身是有效負載（如延遲容忍度高的批次任務、非核心業務），並非閒置。
- 你有能力做流量排程：不需要很複雜，一個基於權重的路由層加健康檢查即可。
- 你願意接受雙供應商的維運成本：對接兩套 API、兩份監控、兩家售後，換取容災能力和議價空間。
如果流量太小（如日呼叫十萬級），或者所有業務都對延遲極度敏感（無法拆分），那麼老老實實選最好的那家單供應商更划算。
Q2：除了看第三方評測，你們還有什麼實際的選型方法？
A： 除了參考 AI Ping 這類平台的長週期 P90 數據，我們內部堅持做三件事：真實流量回放壓測、生產 A/B 測試、故障切換演練。
盯緊「效能衰減率」，別被低併發峰值迷惑——重點看 50 併發、100 併發時的 P99 延遲和吞吐量相對於單併發的衰減倍數。衰減率越接近 1，系統在高壓下才越「穩」。
此外，再補充兩個特別提醒：
- 第一，AI Ping 平台僅提供 P90 延遲 資料，並不提供 P99 延遲。如果需要評估長尾延遲（P95/P99），必須自行搭建壓測環境，用真實業務流量模擬高併發場景。不要直接拿 AI Ping 的 P90 數據當作 P99 來用。
- 第二，部分 MaaS 服務商預設會對每個 API Key 施加 請求頻率上限（Rate Limit）。以藍耘為例，我們剛接入時發現每秒只能呼叫 20 次左右，遠低於業務需求。這類限制屬業界預設，通常不會在官網文件中顯著標明，需要在壓測前主動聯繫客服申請提額，否則壓測數據會因限流而完全失真。
結語
從 5 萬到 2000 萬次日呼叫量，從 4800ms 到 720ms 的 P99 延遲——這個看似反直覺的結果，背後是對自建路線的理性放棄，是對中間優化路徑的真實嘗試，更是對「雙供應商不是浪費」這一架構理念的堅持。
雖然雙供應商也帶來了額外的維運成本，以及對接兩套系統的複雜性，但是雙供應商分工、同時上線、動態調配，輔以自研排程層和健康探測，才成就了這套既能扛住千萬級流量、又能保持極速回應的推理架構。
如果你也在做大模型推理的架構選型，建議先去 AI Ping 上看一圈持續監測資料（重點關注 P90 延遲），然後務必自行壓測取得 P99 指標，同時提前與供應商溝通頻率上限。畢竟，在真正的生產壓力面前，沒有備選的架構，本質上都是在賭博。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
