大規模可靠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處理器。