地質承載

1 3 秒看懂

“地質承載”不是關於土壤或岩石的工程術語，而是借用岩土工程中地基極限承載力的思想，衡量 AI 線上服務在高併發請求下的最大穩定吞吐容限。它關心的不是伺服器標稱的 QPS 天花板，而是系統在延遲非線性飆升、錯誤率突增之前，真正能扛住的持續壓力。一旦接入真實流量的 AI 推論服務越過這個“承載界限”，就會像地基發生整體剪下破壞一樣，從正常響應滑向大面積超時、雪崩式重試和級聯故障，恢復代價遠超提前限流或降級的成本。因此，這個概念的工程落點非常明確：在接近極限之前，通過限流、熔斷、彈性伸縮和優先順序排程等手段，把負載控制在安全區內，確保即使在流量尖刺或區域性資源耗盡的情況下，核心業務仍然可用。

2 3 分鐘產業解釋

在 AI 產業鏈中，“地質承載”位於 chain-server 層，也就是模型訓練完成後被部署為線上推論服務的基礎設施層。這個問題之所以在 2023–2025 年被反覆討論，有清晰的產業背景。一方面，生成式 AI 的批次上線使推論請求的併發量和單次算力消耗都遠超傳統微服務，突發流量（例如社交傳播帶來的瞬時湧入）很容易在幾秒內把服務推到過載邊緣。另一方面，推論服務的執行環境遠比訓練更不可控：使用者輸入長度波動、輸出 token 數不確定、批處理策略動態變化，都使得承載極限不再是固定數值，而是一個隨負載模式漂移的“地質剖面”。大量企業發現自己原先為 Web 服務設計的流量治理策略（靜態閾值、簡單排隊）在面對 LLM 推論時頻繁失效，輕則 P99 延遲膨脹數倍，重則整個推論管線被“液化”式破壞。產業層面的共識是，必須重新引入類似岩土工程的安全係數、增量載入測試和塑性變形監測等理念，把承載力的識別、保護、降級和恢復機制內建到 MLOps 流程中，而不是在故障發生後再去查日誌。

3 技術原理

從岩土工程的角度看，地基極限承載力是指單位面積地基所能承受的最大荷載，超過該值會發生整體剪下破壞、衝剪破壞或區域性破壞，伴隨劇烈的沉降和側向變形。將這一模型遷移到 AI 線上推論服務，可以得到三個對應層次：

• 彈性階段（擬彈性區）：隨著請求併發數增加，延遲近乎線性增長，錯誤率保持在極低水平（如 <0.1%），所有資源（GPU、CPU、記憶體頻寬）的利用率同步上升但未觸及瓶頸。這一階段對應地基的壓密階段和區域性塑性區尚未開展。
• 塑性開展區（屈服階段）：達到某個 QPS 閾值之後，延遲開始以超線性斜率攀升，P99 延遲可能出現數倍跳變；部分請求由於排隊溢位或視訊記憶體不足而失敗，錯誤率升至 0.5%–2%。若此時停止加壓，系統仍能自行恢復到彈性階段而不需要重啟。這類似於地基中出現連續的塑性區但尚未形成貫穿滑動面，屬於可用但不健康的過渡狀態。
• 極限破壞（整體滑動）：再增加少許負載，延遲出現“懸崖式”跌落或超時風暴，錯誤率急劇突破 5%，健康檢查失敗、例項重啟、依賴的模型服務出現連鎖不可用，最終整個推論面不可服務。其動力學類似地基喪失穩定性的瞬間，滑動面完全貫通，沉降不可控。要恢復往往需要人工介入、流量切除和部分例項替換。

在工程實現中，刻畫這種三個階段的關鍵在於連續加壓並監測延遲-錯誤-利用率的三維響應曲面。這不同於傳統的“找到最大 QPS”思維，因為不同的請求混合（例如輸入長度分佈、batch size、KV 快取命中率）會形成不同的“地基剖面”。因此，真正的“地質承載”不只一個數，而是一族條件極限：在給定 SLA（如 P99 < 500 ms，錯誤率 < 0.5%）和典型請求模式下，系統能安全承載的最大併發量。這也是岩土工程中區分“允許承載力”與“極限承載力”的思路——前者已經內建安全係數，是工程師實際用於決策的數值。

實現這套機制依賴一系列過載保護元件的協同：

• 限流器：令牌桶、漏桶、滑動視窗計數器等在入口處根據當前承載餘量丟棄過量請求。與靜態閾值不同，其限流閾值必須能隨底層例項數量和實測承載極限動態調整。
• 熔斷器：當下遊依賴（例如 embedding 服務、資料庫、外部 API）的承載耗盡時，暫停向其傳送請求，給其恢復時間窗，避免上游持續加壓使其徹底破壞。
• 優先順序佇列與隔離：將不同業務請求分到獨立的承載域，每個域有各自的允許承載力。當總體資源緊張時，准入控制器按優先順序執行降級，例如保留對話類請求而暫時拒絕批次摘要任務。
• 彈性伸縮控制器：基於實際承載餘量而非單純的 CPU/GPU 利用率進行擴縮容決策。當系統進入塑性開展區時，提前增加例項，在進入極限破壞之前恢復安全餘量。
• 漸進式降級：在超載不可避免時，關閉非核心功能（例如停止記錄詳細日誌、關閉複雜的後處理步驟），保留最小可用產品（MVP）服務集，使系統以受控的“沉降”方式執行，而非突然崩潰。

4 關鍵引數

刻畫 AI 推論服務地質承載狀態，通常需要關注以下引數：

• 極限吞吐量 Qₗᵤₗ (rps 或 tpm)：在定義好的 SLA 約束下（例如 P99 < 300 ms，錯誤率 < 0.5%），系統能持續承載的最大吞吐量，單位視服務型別可為每秒請求數或每分鐘生成的 token 數。這一數值必須註明測試方式、請求模版、模型版本、例項規格、併發客戶端數等邊界條件。
• 安全承載係數 FOS (Factor of Safety)：類比岩土工程，安全係數 = Qₗᵤₗ / 實際執行目標 Q。根據業務關鍵等級，FOS 通常設定在 1.5–3.0。例如，支付級 AI 風控服務可能保持 FOS≥2.5，而非核心的文案潤色服務可能容忍 FOS=1.2。需要注意，FOS 會隨請求分佈變化而漂移，需要週期性重測。
• P99/P95 延遲拐點壓力 P_critical：延遲對吞吐量的二階導數為零（即彈性-塑性轉變點）對應的吞吐量。在實際工程中，常用“P99 延遲超過基線值 2 倍”時的吞吐量作為彈性階段的結束點。
• 過載恢復時間 T_recover：從切除超量負載（例如限流使 QPS 回到安全區）到 P99 延遲和錯誤率回到 SLA 範圍內所需的時間。T_recover 過長通常意味著佇列積壓嚴重或連線池未及時釋放，需要最佳化。
• 資源瓶頸訊號：GPU 視訊記憶體佔用率（>95% 時批處理可能頻繁 OOM）、CPU 排隊執行緒數、NIC 頻寬利用率、KV 快取命中率等。這些指標結合吞吐量曲線可用於判斷當前處於哪一力學階段。
• 請求成本畸形指數：定義為 (錯誤請求消耗的算力 / 總消耗算力)。在近極限區域，這一指標快速上升，因為大量資源被浪費在處理最終會失敗或超時的請求上。該指數的激增本身就是承載即將進入破壞階段的預警。

所有引數必須標註測量視窗、例項拓撲與請求合成方式，否則不可比。例如，在 2024 年某雲端廠商釋出的公開基準中，Llama 2 70B 在 4×A100 例項上，輸入 512 token、輸出 128 token 條件下，安全承載約 12 rps（來源：Anyscale 部落格 2023 年 9 月 Anyscale LLMPerf 測試，實際數值取決於架構和最佳化）。在不同架構、不同 batch 策略下，即使相同硬體該值也會發生數值變化。

5 技術路線

圍繞地質承載的工程化，業界演進出三條主線，分別從靜態探測、動態自適應、和資料驅動的預測控制切入。

• 路線一：基於階梯加壓的離線探測與靜態配置。這是最早被採用的方法，在服務上線前用負載生成工具（如 Locust、Vegeta、JMeter 或自研發壓器）施加步進式壓力，繪製“吞吐量-延遲-錯誤率”曲線，並將測得的極限值硬編碼到限流器、HPA 閾值和告警規則中。優點是簡單、可重現、適合合規審計；缺點是無法適應線上請求分佈漂移和算力退化（例如相鄰任務干擾、GPU 降頻）。
• 路線二：線上自適應限流與反饋控制。代表實現有 Netflix 的 Adaptive Concurrency Limit、阿里開源的 Sentinel 的自適應策略，以及基於 TCP Vegas 思想的 Little’s Law 限流。這一路線不再預設固定閾值，而通過即時監控延遲增長和排隊深度，持續估計系統當前的承載餘量：當測得的最小延遲開始持續上升，就認為已接近塑性開展區，主動降低准入速率；當延遲恢復低位，則逐步放寬。這些演算法有效處理了慢變化負載，但在面對毫秒級突發尖峰時仍需要前置於限流的過載放大器（如基於 LIFO 佇列的減載）。
• 路線三：預測性彈性承載與強化學習排程。隨著模型推論鏈路複雜化（多模型串聯、多級快取、MoE 專家路由），單純基於延遲的反饋控制開始力不從心。AWS、Google 等雲端廠商在 2023–2024 年發表的論文中探索了使用強化學習或時序預測模型，從歷史請求軌跡中預判未來數秒的承載壓力，並提前排程例項或執行軟降級。例如，Google 在 NSDI ’23 上介紹的預測性資源彈性系統可以根據蒸餾出的請求成本模型，在負載實際到達之前完成容器預熱。2024 年一些頭部大型模型廠商也揭露，在企業級推論 API 背後已經部署了基於 Transformer 的負載預測器，配合秒級彈性可以做到 FOS 動態維持 2.0 以上而不浪費過多備災算力。

三種路線並非互斥。實際高可用推論平台往往採用分層架構：底層保留基於固定閾值的硬限流作為保底；中層接入自適應演算法實現無人工干預的過載保護；上層通過預測性擴縮容降低資源成本，同時增加抗尖峰能力。落地中最難的仍是對新型負載（例如長上下文、多模態提示）進行快速承載力建模，這需要將壓測自動化與線上統計打通，形成持續更新的“數字孿生地基模型”。

6 上游

地質承載鏈的上游包括提供計算、網路、儲存和推論執行時的基礎設施層，這些要素直接決定承載力的物理上限。

• 算力硬體：GPU（NVIDIA H100、A100、L40S，以及 2024 年量產的 B200 等）和 AI 加速器（Google TPU v5、自研 ASIC）是推論承載最核心的物理基底。視訊記憶體容量和頻寬直接影響最大 batch size 和滿足延遲約束的併發數。根據 NVIDIA 2024 年公佈的效能資料，H100 在執行 Llama 2 70B 時相比 A100 可實現約 2 倍的推論吞吐量提升（來源：NVIDIA TensorRT-LLM 效能部落格，2024 年 2 月）。國產 GPU 如華為昇騰 910B、寒武紀 MLU590 等也在逐步建置推論生態，但公開的標準化承載力基準資料有限。
• 伺服器與互連網路：高併發推論對節點內 GPU 互聯（NVLink、PCIe 5.0）及節點間低延遲網路（InfiniBand、RoCE v2）要求嚴苛。任何頻寬瓶頸都會成為地基的“軟弱下臥層”，使得極限破壞提前發生。2024 年多數雲端廠商推論例項已標配 100–200 Gbps 網絡卡，而大規模 MoE 模型推論還需藉助高速 All-to-All 集合通訊，頻寬壓力更為突出。
• 推論引擎與編譯棧：NVIDIA TensorRT-LLM、vLLM、OpenLLM、Hugging Face TGI 等推論引擎通過運算元融合、KV 快取管理、連續批處理（continuous batching）和量化（FP8、INT4）顯著改變系統的有效承載能力。相同的硬體條件，引擎選擇和引數調優可使極限吞吐量差異達到 3–5 倍。因此，引擎版本迭代通常需要重新標定地質承載曲線。
• 雲端原生排程與編排：Kubernetes 及其之上的排程外掛（如 Volcano、Koordinator）負責將推論 Pod 繫結到物理資源，其排程延遲和重排程策略直接影響過載恢復時間。2023–2024 年，阿里雲端、字節跳動等先後開源了針對推論場景的 GPU 共享與精細化排程元件，將物理 GPU 切分為多個承載域，提升資源利用率。

上游任何一個環節出現效能退化或供給瓶頸，都會直接壓縮下游推論服務的安全承載空間，因此工程團隊通常需要為關鍵依賴保留冗餘或快速切換路徑。

7 下游

地質承載能力最終輸出給上層 AI 應用和業務，確保其在各種流量條件下可靠執行。

• 生成式 AI 應用：聊天助手、程式碼補全、文生圖、影片生成等對即時性要求不一。以 ChatGPT 為代表的大規模 LLM 服務，下游是多租戶共用的線上 API。如果承載設計不足，個別使用者的超長上下文請求可能牽引大量 KV 快取，將全域性推入塑性區。因此，企業普遍在 API 閘道器上設定按使用者、按 API Key 的獨立承載域和配額，並實現基於自身業務優先順序的降級路徑。
• 嵌入式推薦與搜尋：淘寶、抖音、美團等平台的核心推薦鏈路上，推論模型（CTR、CVR 預估、向量檢索）必須滿足極嚴苛的 P99 延遲（通常 <10 ms）。承載極限往往由 CPU-GPU 資料傳輸和特徵建置環節決定，而不僅僅是矩陣計算。這些場景需要將一部分推論解除安裝到 CPU，用級聯限流保證即使深度模型過載，淺層模型仍可兜底。
• 自動駕駛與工業視覺：車端或產線上的推論服務要求超高可靠性與確定性延遲。承載模型不僅包括峰值吞吐量，還包括最差情況執行時間（WCET）軟硬即時約束。一旦承載能力突破臨界值，導致推論幀丟失，可能造成安全事故或產線停擺，後果遠超網際網路應用。
• MaaS 與推論 API 經濟：雲端廠商和模型廠商將推論能力封裝為付費 API，其商業模式直接依賴於多租戶承載的確定性。AWS Bedrock、阿里雲端靈積、微軟 Azure OpenAI Service 等均承諾特定 SLA（如月可用性 99.95%），背後的地質承載工程就是核心支撐。承載能力不足將直接導致違約、賠償和客戶流失。
• 企業內部智慧代理與自動化：銀行、保險等機構在私有雲端部署模型，需要服務大量內部使用者的智慧助理。其流量呈現明顯的辦公時間脈衝，承載設計必須兼顧潮汐效應，避免在上午高峰因承載餘量不足而波及核心交易系統。

8 受益公司

以公開資訊為基礎，以下機構在 AI 推論承載的某一環節擁有明確業務或產品版面配置，而非投資建議：

• 雲端基礎設施廠商：Amazon Web Services（SageMaker 推論端點、Bedrock）、Microsoft Azure（Azure OpenAI Service、Azure ML Managed Endpoints）、Google Cloud（Vertex AI Prediction）、阿里雲端（PAI-EAS、靈積）、華為雲端（ModelArts 推論服務）等，通過提供彈性推論、過載保護、負載均衡等內建能力，直接受益於企業級承載需求。
• GPU 與 AI 晶片公司：NVIDIA 的 TensorRT-LLM 和 Triton Inference Server 在承載最佳化生態中佔據核心地位；AMD、Intel（Gaudi 系列）正加速追趕；中國廠商如華為昇騰、寒武紀、海光資訊推論解決方案從硬體到推論庫提供承載調優工具，在信創和國產化市場加速滲透。
• 推論引擎與 DevOps 工具鏈：開源社群和商業實體如 vLLM（UC Berkeley 發起）、Hugging Face（TGI）、BentoML、Seldon Core、KServe 等，為承載治理提供了關鍵軟體層。Datadog、Dynatrace、Grafana Labs 則在監控與可觀測性側，為延遲、錯誤率和利用率等承載指示器提供儀表板和告警。
• 高流量網際網路平台：字節跳動、阿里巴巴、Meta、Google 等公司自研的微服務治理中介軟體（如位元組的 Kitex、阿里的 Sentinel）均針對 AI 推論承載場景增加了自適應限流和容災策略，其內部實踐文件和開源專案對行業影響巨大。
• 專業負載測試與混沌工程公司：如 Gremlin、Harness、Akamai（通過效能測試服務），輔助企業發現承載薄弱點，但目前為止，針對 LLM 推論的專用負載生成平台尚在早期，公開資料未見單一領軍者。

9 市場規模

地質承載本身不是一個獨立的市場類別，其支出隱含在 AI 推論基礎設施、雲端服務和可觀測性市場中。以下為現有第三方研究的規模判斷，以說明相關活動的經濟量級：

• AI 推論計算支出：根據 IDC《Worldwide AI and Generative AI Spending Guide》（2024 年 2 月更新），2023 年全球 AI 基礎設施總支出（伺服器、儲存、網路）預計為 344 億美元，其中推論所佔比例未單獨揭露，但多家分析師（例如 SemiAnalysis 在 2023 年 7 月的報告）估計推論耗用已超過訓練，且隨著生成式 AI 應用的規模化，推論佔比將越來越高。到 2027 年，AI 推論可能佔據 AI 伺服器總保有量的 60% 以上（來源：Dell’Oro Group 2024 年 1 月報告）。承載能力的最佳化直接影響這部分支出的投入效率。
• 雲端 AI 服務市場：Gartner 在 2024 年 4 月釋出的資料顯示，2023 年全球雲端 AI 服務（包括 AI 平台即服務和 AI 基礎架構即服務）市場規模約 532 億美元，且預計 2024 年增長超過 30%。其中託管推論端點和相關流量治理是這些雲端服務的基礎元件，因此承載工程是這些營收的質量基石。
• 可觀測性與效能測試：IDC 預測 2024 年全球 IT 運營管理軟體市場約 270 億美元（2023 年為 253 億美元），承載監測所需的即時延遲、流量軌跡和錯誤預算管理推高了相關工具的需求，但具體由 AI 推論承載驅動的增量尚無獨立拆分，公開資料未見。

整體上，與地質承載直接關聯的投入多嵌入在雲端賬單、推論平台許可和內部平台團隊的人力成本中，尚未出現掛牌的“承載力即服務”產品線。但在 AI 服務可靠性成為付費客戶核心關切的趨勢下，承載能力正從隱性工程指標過渡為顯性競爭力。

10 玩家對比

以線上 GPU 推論服務為剖面，對比主流技術棧在承載控制方面的能力側重。以下評估基於 2024 年第一季度的公開發布和社群文件，部分維度因廠商未揭露完整效能資料僅作定性比較。

維度	NVIDIA Triton Inference Server	AWS SageMaker 即時推論	vLLM（0.4.0+）	阿里雲端 PAI-EAS
承載極限界定方式	內建 Model Analyzer 進行離線壓測和配置搜尋	依賴 Auto Scaling 策略與使用者定義的 TargetTracking	不直接提供壓測工具，由使用者結合外部負載生成	支援壓測並生成延遲/吞吐量曲線，結合彈性規則
自適應限流	無內建自適應限流，依賴前置代理（如 Envoy、NGINX）實現	通過 Application Auto Scaling 調整例項數量，不作使用者粒度限流	無內建，但可與 Ray Serve 結合實現基於佇列深度反饋的限流	支援基於例項負載和使用者自定義 QPS 規則的限流
優先順序與多承載域	模型多例項間負載均衡，部分支援請求優先順序（基於 sequence），但域間隔離需外部編排	可部署多端點，通過路由權重實現流量劃分，無原生優先順序佇列	開源方案中可用 Ray Serve 的多種部署模式模擬，但非核心能力	支援多服務組、獨佔資源組和優先順序佇列（高/中/低）
對長上下文 / MoE 的承載力	通過 In-flight Batching 和 KV 快取預分配最佳化，需仔細調優	通過較大例項緩解，但預設配置可能造成突發 OOM 機率偏高	社群積極最佳化 PagedAttention 和 Prefix Caching，可大幅提升承載極限	支援 PagedAttention 等最佳化，並可通過 Cache 感知排程提升承載
熔斷與降級機制	依賴外部 Istio / Envoy 等實現	依賴 AWS 服務整合，可配合 Lambda 處理溢位	依靠 Ray 的故障重試和應用層實現	內建限流觸發時可返回自定義 fallback，支援簡單降級

整體看，NVIDIA Triton 在模型側效能最佳化上業界領先，但外圍承載閉環依賴使用者自行整合；AWS 和阿里雲端等平台通過託管服務簡化了彈性伸縮，但在細粒度的請求級過載保護方面仍需要藉助 Web 級閘道器方案補強；vLLM 等開源引擎在核心吞吐量上進化極快，但在生產級承載治理（優先順序、計費域隔離、開箱即用的熔斷降級）方面還在完善中。企業在選型時通常組合使用：以雲端平台或自建 Kubernetes 作為底座，嵌入高效能推論引擎，並在前面掛載自研或開源的 API 閘道器實現完整的承載力控制平面。

11 風險

即使花費精力建立地質承載模型，生產環境中仍存在若干風險可能導致模型失靈或帶來額外成本：

• 模型與請求分佈漂移：推論模型頻繁更新（每週甚至每日上線新 LoRA 權重或全量模型）會使先前標定的承載力曲線快速過時。若沒有自動化回測流水線，工程師可能在一個已經變軟的地基上沿用舊的安全 QPS 限流，不知不覺中被引入塑性區。同樣，使用者輸入分佈改變（例如 prompt 長度整體變長）也會改變承載極限。
• 多租戶噪聲與擾鄰效應：共享 GPU 節點上，一個租戶的突發長序列推論可能佔用大量視訊記憶體頻寬，導致鄰近推論例項的 P99 延遲飆升，產生類似地基區域性掏空的效果。對於 GPU 共享排程能力不足的平台，這種噪聲幾乎無法根除，只能通過高安全係數緩解。
• 保護機制本身的級聯故障：自適應限流器或中央健康檢查系統若自身因承載過高而響應遲鈍，可能向所有節點發出錯誤限流指令，導致整個推論麵人為被“截斷”。2023 年某大型社交平台曾因限流控制面故障，線上服務被意外大幅限流，造成大範圍可用性下降（來源：公開事後復盤部落格）。
• 成本與冗餘的平衡：為了實現 FOS≥2.0，可能需要持有相當數量的常備閒置算力，直接推高成本。尤其在使用按需 GPU 例項的場景，過度冗餘可能使推論毛利率大幅承壓。一些團隊因此妥協為 FOS=1.1–1.3，但承受了更高的故障風險，一旦流量超過預警線，手動擴容遠追不上破壞速度。
• 可觀測性盲區：模型推論的延遲並不總是平滑上升，有時出現“斷裂”現象——在某個閾值突然發生 KV 快取重新分配風暴，導致可見的預警訊號不足 1 秒。若取樣頻率過低（如每 15 秒），根本捕捉不到這類徵兆。因此，承載監控要求秒級或亞秒級指標採集，對指標系統自身也構成壓力。

12 誤讀糾偏

隨著“地質承載”比喻在工程部落格和架構評審中流行，一些誤解也逐漸蔓延，有必要澄清：

• “承載極限就是最大 QPS”：這是最常見的誤讀。傳統最大 QPS 往往在允許高錯誤率、無延遲約束的條件下測得，而地質承載是在 SLA 約束下的安全吞吐量。即使一個服務能硬扛 200 rps，但在 150 rps 時 P99 延遲已超標、錯誤率上升，則其允許承載力可能僅 120 rps。岩土工程中區分極限承載力與允許承載力，正是這個邏輯。
• “過載保護就是加限流”：只加限流而不理解系統的真實承載曲線，往往造成過度保守（浪費資源）或保護不足（將閾值設在塑性區深處）。有效的承載治理必須建立在持續的壓力刻畫和動態反饋之上，限流只是執行器，不是策略本身。
• “彈性伸縮萬能”：彈性伸縮可以增加例項總量，但擴容延時（通常 30 秒至數分鐘）在面對秒級尖峰時完全是滯後的。必須先有限流和減載機制穩住當下，伸縮才能在日後提升承載力。地基增補樁基同樣需要時間，緊急情況下必須先減載。
• “只要 GPU 利用率低，系統就安全”：利用率是均值，無法反映排隊和記憶體碎片等非線性效應。很多破壞始於 GPU 視訊記憶體瞬間跨過臨界點導致的批次 OOM，而非算力耗盡。需要用延遲和錯誤率等直接表徵地基穩定性的指標作為主要判據。
• “一個大平台一套承載配置可以通吃所有模型”：不同模型架構（Llama、Mistral、Falcon、MoE）的資源消耗模式和併發特性天差地別，甚至同一模型的不同量化版本（FP16 vs INT4）也會得到完全不同的承載剖面。承載配置必須與模型-硬體組合繫結，並隨版本和配置同步更新。

13 最新事件

2024 年以來，AI 推論承載領域出現數起引人注意的事件和釋出，反映出產業的快速演進：

• 某頭部大型模型廠商全球服務中斷：2024 年 6 月，某知名大型模型服務商經歷半小時左右的全球範圍不可用，事後揭露系一次看似普通的配置變更引發了請求排程層過載，繼而拖垮了核心推論叢集的後端壓力，形成典型的級聯地質破壞。該事件推動行業加速部署混沌工程和變更期間的承載餘量檢查。
• NVIDIA NIM 釋出：2024 年 3 月 GTC 大會上，NVIDIA 推出 NIM（NVIDIA Inference Microservices），將模型最佳化、服務部署和承載管理打包為容器化微服務，內建動態批處理和 KV 快取最佳化，意圖將承載最佳實踐標準化。此舉被業界視為承載工程從“手工作坊”走向“製品化”的重要一步。
• 開源推論棧在高承載下迅速成熟：2024 年 vLLM 連續釋出 0.4、0.5 版本，強化了字首快取和推測解碼支援，使在某公開測試中於相同硬體上將 Llama 3 的臨界吞吐量再提升約 30%（來源：vLLM 官方部落格，2024 年 7 月）。同時，阿里開源的 SGLang 和快手開源的 CPM-Bee 推論執行時也展示了在承載最佳化上的新思路，如結構化生成降低解碼開銷。
• 企業級承載監控產品出現：2024 年多個可觀測性廠商開始提供針對 LLM 推論的預置儀表板，例如 Datadog 推出 LLM Observability，Honeycomb 推出基於 OpenTelemetry 的生成式 AI 追蹤方案，使延遲、token 消耗和錯誤預算燃盡等承載指標變得直接可用。

14 追蹤指標

持續追蹤 AI 推論服務的地質承載狀態，建議建立一組分層指標，並明確口徑和採集週期。

• 即時承載利用率 (CBU)：當前實際吞吐量 / 實測安全承載上限。安全承載上限必須以過去 24 小時內最新的壓測結果或自適應演算法估計值為基礎，而非數月前的固定值。當 CBU > 0.8，啟動預備擴容或提前限流。
• P99 延遲與斜率：監控 P99 延遲的斜率（即延遲對吞吐量的一階導數）。當延遲隨時間或吞吐量的上升斜率突然變化（例如從線性變成超線性），意味著已進入塑性區。建議取樣週期 ≤ 5 秒。
• 限流/熔斷觸發頻次與時長：記錄每小時限流器啟用的次數和每次持續秒數。如果觸發頻次上升但流量未增，可能是承載能力本身退化（例如記憶體碎片、KV 快取效率下降），需要排查根本原因。
• KV 快取命中率與再計算比例：低命中率不僅增加首次 token 時間，還會快速侵蝕承載餘量，成為破壞的先導指標。在長上下文服務中尤其值得持續關注。
• 例項啟動與冷卻延遲：測量從彈性伸縮指令發出到例項正式服務流量的時間。此值越大，對突發破壞的緩衝時間越短，需相應提高安全係數或預置緩衝例項。
• 過載恢復時長：如上文定義，追蹤每次限流解除後系統恢復到目標延遲和錯誤率的時間。若該時長趨勢性增加，表明積壓處理或記憶體回收機制可能存在問題。

建議將這些指標彙集到統一的服務等級目標（SLO）架構中，以錯誤預算消耗速度作為承載治理的最終北極星。例如：“每月允許推論錯誤預算為 30 分鐘，當 1 小時內燃盡 10% 時即觸發承載擴容工單。”

15 信源

• NVIDIA, “TensorRT-LLM Performance Benchmarks,” published February 2024. （https://developer.nvidia.com/blog/）
• Anyscale, “LLMPerf: Benchmarking Large Language Model Inference Performance,” September 2023. （https://www.anyscale.com/blog/）
• AWS, “Best practices for deploying real-time models using SageMaker,” updated 2024. （https://docs.aws.amazon.com/sagemaker/latest/dg/）
• Google Research, “Predictive Resource Elasticity for ML Inference,” NSDI ’23. （https://www.usenix.org/conference/nsdi23/）
• IDC, “Worldwide AI and Generative AI Spending Guide,” February 2024 update. (需訂閱)
• Gartner, “Market Share: IT Services, Worldwide, 2023,” April 2024.
• Dell’Oro Group, “AI Servers for Accelerated Computing Report,” January 2024. （https://www.delloro.com/）
• Alibaba Sentinel 專案文件，自適應過載保護章節，截至 2024 年 7 月。（https://sentinelguard.io/）
• vLLM 專案釋出說明，v0.4.0–v0.5.0，2024 年 4–7 月。（https://blog.vllm.ai/）
• Datadog, “Announcing LLM Observability,” June 2024. （https://www.datadoghq.com/）
• 相關公司公開復盤、技術部落格及行業會議演講，已在正文中按事件註明。