基於Pingora、Envoy和Spanner的無伺服器伺服器路由

Modal近日釋出了其新型Serverless Servers服務，旨在為超低延遲應用（如大型語言模型推理）提供支援。該服務允許使用者在Modal上執行HTTP、WebSocket和gRPC伺服器，並實現區域化自動縮放。

與Modal已有的Web Functions不同，Servers採用了更輕量級的架構。Web Functions內建了排隊和重試機制，類似於TCP協議；而Servers則更接近UDP，犧牲了這些可靠性特性以換取更低的延遲。如果所有副本都不可用，客戶端將直接收到503錯誤，而不是等待佇列。這種設計對於LLM推理等對延遲極其敏感的應用場景尤為合適。

Modal團隊在構建Servers時遵循了兩條核心原則：最大化資源共享同時最小化干擾，以及確保請求路徑上沒有網路呼叫。這意味著路由層不能訪問後設資料儲存或鍵值儲存，配置資訊必須本地快取。團隊透過精細的微觀調整，將代理資源的使用與宏觀目標對齊，避免了因資源池化導致的干擾問題。

具體實現上，請求首先到達AWS NLB（四層負載均衡器），然後由Envoy代理終止TLS並統一轉換為HTTP/2流。接下來，Modal自研的fprs代理負責將域名對映到具體的Server應用，並在副本之間進行負載均衡。fprs基於CloudFlare的Pingora庫構建，利用Rust的Tokio執行時實現高效的流複用和資源隔離。團隊還解決了因域名頻繁更換導致的隱藏DNS解析問題，透過仔細快取來保證尾延遲。

配置資訊儲存在Google Spanner中，但fprs維護了一個記憶體快取，並透過Spanner的變更流保持同步，從而避免了熱路徑上的資料庫查詢。該層還負責向Modal自動縮放器傳送指標（每個容器的正在處理請求數），以及實現代理層身份驗證，防止大量無效請求觸發昂貴的GPU例項啟動。

Modal表示，雖然系統針對LLM推理進行了最佳化，但設計上並不侷限於這一場景。未來他們計劃在路由層新增可選的排隊和重試功能，讓使用者能夠根據需求在低延遲和可靠性之間取得平衡。