大規模可靠LLM推理

在Databricks，我們構建了一個獨特的推理平臺，服務於從Kimi、Qwen等開源模型到OpenAI、Gemini、Claude等專有模型的幾乎所有前沿模型。我們為全球一些最大的智慧體應用提供推理能力，包括Superhuman、Yipit Data、Fox Sports等。目前，我們每月處理超過120萬億個令牌。

大規模LLM推理的難點在於可靠性。隨著智慧體成為工作和生活的主要介面，推理需求呈指數級增長。我們觀察到極其尖峰的需求曲線，在工作時間達到峰值。

擴充套件LLM推理的挑戰 可靠的推理平臺意味著什麼？表面上，可用性是指請求能否被處理。但實際上，不同用例對延遲的要求差異很大，這影響了可用性。最先進的智慧體無法容忍p95首次令牌時間（TTFT）和每秒輸出令牌數（OPTS）的下降。在多租戶LLM服務系統中，同時實現可靠性和延遲是一項挑戰。

可靠性方面，前沿效能需要最新GPU和高頻寬互聯用於KV快取傳輸。這些計算設定本質上不如傳統CPU系統可靠，且成本高昂。由於需要全對全通訊，單個節點的故障需要重新配置多個其他節點。最高頻寬網路要求單個物理機架內的單脊連線（如NVL72系統）。這意味著單個資料中心機架內特定系統的故障可能導致大範圍中斷。分散式系統中的標準技巧（如多可用區或備用例項型別）意味著保持昂貴的備用GPU閒置，成本過高。過度配置是另一個經典技巧，但鑑於計算供應緊張，這極其昂貴且不切實際。因此，系統必須在重壓下保持執行。

同時，在這些約束下，交付速度必須保持高水平——我們的推理需求每年增長多個數量級，在保持增長的同時還要推出創新功能。影像、影片和安全分類等特性需要不同的預處理系統，這些系統都必須獨立擴充套件。

最後，實現最佳效能和支援新模型架構需要從自定義核心到專有推理引擎的各種最佳化。隨著架構微妙變化，新的低階軟體常常引入，這些軟體可能在大規模下以不透明的方式失敗，導致難以除錯的場景，如伺服器掛起或GPU崩潰。

延遲方面，在多樣化負載模式下控制延遲是一項挑戰。這是因為服務請求的成本高度可變且難以預先估計。即使是健康的伺服器在更重負載下也會更慢地處理所有請求，從而在吞吐量（因此成本效率）和產品所需的最快延遲之間做出權衡。這也可能表現為可靠性問題，因為基於分配給伺服器的請求組合，伺服器可能迅速進入不健康狀態。

此外，延遲主要受輸出令牌生成支配，但預先估計成本很困難，因為很難預測模型會輸出多少內容。因此，低延遲服務需要複雜的容量管理、負載均衡和請求優先順序系統。

整體架構 在資料平面，推理執行時（開源和專有內部引擎）部署在前沿GPU上。為了處理跨模型部署的流量，資料平面執行一個名為Axon的路由器，它在同一模型的副本之間平衡負載，以及一個自動縮放器來調整副本數量。在控制平面，請求在到達資料平面之前經過速率限制。基於請求指標，容量管理演算法確定每個工作負載獲得多少GPU容量，然後由自動縮放器強制執行。

掌控容量 我們需要大致推理容量——我們有多少、賣了多少以及客戶用了多少。為此，我們引入了一個稱為“模型單元”的抽象。如果我們假設一個副本每分鐘可以處理固定數量的模型單元（例如100個），我們可以做出以下假設：輸入或輸出較長的請求消耗更多模型單元，因為相同時間視窗內能完成的更少。預填充和解碼具有不同的吞吐特性，因此輸出長的請求比輸入長的請求成本更高。

因此，我們使用多維函式對請求成本建模，如：成本 = α × 輸入令牌數 + β × 輸出令牌數 + γ × 其他因素。係數α、β、γ透過每個模型在每個硬體型別上的自動基準測試確定。模型單元可以進一步為字首快取等最佳化進行調整，並且必須考慮多模態等特性。這種估計在結構上並不完美，但它幫助我們打破多租戶系統，使其更像可管理的雲虛擬機器。虛擬機器具有可預測效能並分配給特定客戶的可取屬性。對於生產級智慧體工作負載，提供低延遲和容量的保證很重要，沒有這樣的分配系統，我們只能提供“盡力而為”的容量，如果太多客戶使用系統，這種容量可能被收回。

基於成本的負載均衡和自動縮放 由於請求對伺服器的影響高度可變，做出近乎最優的路由決策至關重要。一般來說，負載均衡傾向於依賴統計方法，如P2C（兩種選擇的力量），它基於佇列大小估計負載並利用取樣來減少了解所有可能目標的記憶體和延遲開銷。然而，LLM延遲較高，伺服器數量少於橫向擴充套件的CPU系統，並且錯誤路由的代價很高。因此，LLM服務需要不同的方法。

目前，我們使用Databricks的自動分片器Dicer在工作負載之間動態路由。沒有負載感知的路由，長上下文請求會導致個別伺服器成為熱點，而其他伺服器利用率不足。我們將模型單元與Dicer整合，使路由決策基於伺服器負載（以模型單元為單位），而不是傳統的基於請求的啟發式。Dicer還提供有狀態會話，使請求路由具有粘性。一個工作負載的請求只發往一部分伺服器，這提高了快取命中率（對延遲敏感的編碼智慧體至關重要）並限制了爆炸半徑。

在自動縮放中也存在類似問題。待處理請求數量本身並不反映真實負載。長上下文請求的尖峰看起來與短請求的尖峰相同，CPU和記憶體指標也與實際GPU利用率不相關。使用模型單元，我們的自動縮放器可以根據模型單元利用率比率決定是否擴充套件或縮減。當推理引擎接近其最大模型單元的某個百分比（由硬體型別和工作負載形狀決定）時，它接近峰值吞吐量，觸發擴充套件。反之則觸發縮減。這種方法無需為每個模型手動調整自動縮放規則，實現了模型無關的縮放基礎設施。

基於LLM推理模式構建自動縮放使我們不必總是擴充套件到最大副本數。對於流量突發的模型，自動縮放將副本數保持在接近實際需求的水平，與靜態配置峰值相比，節省了80%以上的GPU。

執行時可靠性 智慧路由和縮放提供了良好的基礎，但並不能防止引擎級別的故障。無論我們部署哪種推理引擎（內部引擎或流行的開源引擎），在生產規模下都會出現邊緣情況和資源爭用。我們需要機制來自動檢測和恢復故障。

檢測和恢復靜默故障：我們遇到的一種故障模式是靜默掛起。涉及邊緣情況（結構化輸出、多模態輸入）的請求可能觸發推理引擎多程序架構中的未處理錯誤，導致伺服器停止響應而不顯示錯誤。我們透過定期黑盒健康檢查來檢測：當最近沒有實際請求完成時，傳送最小的端到端請求。如果健康檢查失敗，Kubernetes存活探針會重啟伺服器。這適用於所有引擎，無論內部實現如何。然而，在高負載下，健康檢查本身可能超時，導致存活探針殺死實際上健康的伺服器，這有級聯故障的風險。為了解決這個問題，我們賦予健康檢查請求最高排程優先順序，確保即使在重負載下也能完成。透過優先順序健康檢查，檢測到掛起、殺死不健康伺服器和恢復的完整週期不到5分鐘。誤報存活探針失敗從每週幾次降至零。

處理多模態請求帶來的意外負載：當大批多模態請求到達時，我們看到錯誤率和超時激增，來源完全不同。調查顯示，請求甚至沒有到達推理引擎的核心程序。服務影像請求比純文本請求消耗更多資源，不僅是因為額外的視覺編碼器在GPU上執行，還因為CPU密集型的影像處理。對於某些模型，影像處理非常慢，完全阻塞了事件迴圈。將阻塞操作移入單獨的執行緒和程序並沒有解決問題；在高影像負載下，請求仍然堆積。因此，我們分析了Python程序並發現：在所有CPU影像操作中，影像處理（調整大小和歸一化）比其他操作（如base64解碼）慢10倍。一些Hugging Face模型預設使用基於PIL的影像處理器，而其他模型使用更快的Torchvision處理器。