譯者 | 崔皓

審校 | 重樓

開篇

大型語言模型（LLMs）隨處可見，從日常應用到高級工具都可以看到他們的身影。雖說使用起來很容易，但如果要運行自己的模型就是另外一回事了。比如對模型進行微調并處理了一些隱私敏感數據，復雜性就會增加。在這篇文章中，我們將分享在構建我們自己的 LLM 推理系統時所學到的知識。我們將涵蓋存儲和部署模型、設計服務架構以及解決路由、流式傳輸和管理微服務等現實問題。這個過程涉及挑戰，但最終，我們建立了一個可靠的系統，并獲得了值得分享的經驗教訓。

介紹

大型語言模型 (LLMs) 正在為各類應用提供強大支持，覆蓋范圍從聊天機器人、流程代理到智能自動化工具。盡管檢索增強生成（RAG）、工具調用以及多代理協作機制非常重要，但它們都依賴于一個核心引擎：基礎 LLM。

許多項目依賴于外部提供商（如 OpenAI、Gemini 或 Anthropic），對于大多數應用場景而言，這已能滿足需求。然而，對于某些特定應用，這種方式可能很快會遇到問題。例如：若提供商服務中斷該怎么辦？若需要完全掌控延遲、定價或系統可用性又該如何應對？最關鍵的是，若企業重視隱私，無法將用戶數據發送給第三方，該如何處理？
此時，自托管的重要性便凸顯出來。使用預訓練或微調模型進行自托管，不僅能獲得完全控制權、提升安全性，還能針對特定業務需求定制模型功能。構建這樣的自托管系統并不需要龐大的團隊或資源投入。實際上，我們僅依靠有限的預算、一個小型團隊和少量服務器節點便成功構建了系統。這種資源限制影響了我們的架構設計思路，迫使我們聚焦于實用性與效率。

在接下來的章節中，我們將詳細闡述項目遇到的挑戰、所實施的解決方案，以及在此過程中汲取的經驗教訓。

總體概述

上文我們提到的自托管系統，下面我們會針對構成系統核心架構的關鍵組件，給大家做逐一介紹。

• 格式與編碼跨服務采用統一的數據格式至關重要，包括一致的請求 / 響應結構、參數生成規則、對話歷史格式，以及從前端到后端再到模型運行器的通用序列化方案。
• 流式處理與路由系統需要高效處理多模型、多請求類型及主機優先級，因此路由策略必須精準。我們將解析用戶請求的流轉路徑 —— 從初始入口到目標工作節點，以及如何返回流式響應。
• 模型存儲與部署模型如何存儲？如何優化以適應生產環境？
• 推理與驗證我們將探討關鍵測試流程，確保模型的穩定性和可靠性。
• 可觀測性如何判斷系統運行狀態？我們將介紹核心監控指標、故障排查方法，以及保障系統健壯性的探針機制。
• 數據模式與編碼選擇高效的數據傳輸模式是核心任務。統一的跨服務格式能簡化集成、減少錯誤并提升擴展性。我們的目標是讓系統無縫兼容自托管模型與第三方服務，同時向用戶隱藏底層差異。

為什么模式設計很重要

當前 LLM 領域的數據交換缺乏統一標準。雖然 OpenAI 的模式被多數服務商采用，但 Claude、Gemini 等平臺仍存在關鍵性差異。部分服務商通過兼容層（如 Anthropic 的 OpenAI 適配 SDK、Gemini 的兼容接口）提供近似支持，但往往存在功能限制。OpenRouter 等項目則嘗試統一這些差異，將其封裝為標準化接口。

采用單一服務商的標準模式具有以下優勢：

• 獲得經過充分驗證的穩定 API。
• 兼容現有成熟的 SDK 和工具鏈。

但同時也存在明顯弊端：

• 導致供應商鎖定，難以支持多服務商接入。
• 缺乏擴展性，無法靈活適應業務需求或數據科學團隊的特殊要求。
• 面臨不可控的 API 變更或廢棄風險。
• 傳統架構約束限制了精細化控制能力。

為此，我們決定建立專屬的內部數據模型 —— 這是一個完全根據業務需求設計的架構體系，可靈活映射到各類外部格式。

內部模式設計

在解決具體問題前，我們需要明確設計目標和預期效果：

• 雙向兼容性：能輕松轉換為外部服務商所需格式，也能反向轉換。
• 功能完整性：全面支持業務需求和數據科學團隊的特殊功能。
• 可擴展性：模式設計需預留未來升級空間。

我們首先分析了主流 LLM 服務商的數據模式，重點研究了消息結構、參數定義和輸出格式。通過對比分析，我們提煉出以下核心領域實體，這些實體在大多數系統中通用：

• 消息（包括提示語、對話歷史等）。
• 生成參數（如溫度值、top_p、最大 token 數等）。

同時，我們發現部分參數（如服務層級、元數據字段、推理模式等）屬于各服務商特有的內部配置項。這些非通用元素被歸類為可選擴展項。只有當某項功能被廣泛采用或對互操作性至關重要時，我們才會考慮將其納入核心模式。

我們的輸入模式主要由四大組件構成：

• 模型標識：作為路由鍵，指引系統將請求分發到正確的工作節點。
• 生成參數：核心模型配置（溫度值、top_p、max_tokens 等）。
• 消息內容：包含對話歷史和提示信息。
• 工具定義：模型可調用的工具說明。

基于以上設計，我們構建了類似 Pydantic 的結構化模式（為簡化說明，部分實現細節在此省略）。

class ChatCompletionRequest(BaseModel):
    model: str  # Routing key to select the appropriate model or service
    messages: list[Message]  # Prompt and dialogue history
    generation_parameters: GenerationParameters  # Core generation settings
    tools: list[Tool]  # Optional tool defenitions

class GenerationParameters(BaseModel):
    temperature: float
    top_p: float
    max_tokens: int
    beam_search: BeamSearchParams
    # Optional, non-core fields specific to certain providers
    provider_extensions: dict[str, Any] = {}
    ...
    # Other parameters

我們刻意將生成參數（如溫度值、top-p 等模型配置）設計為獨立的嵌套字段，而非直接置于根層級。這種架構設計實現了關鍵區分：

• 靜態參數：固定配置項（模型設置、生成參數等）。
• 動態組件：可變內容（消息內容、工具定義等）。

這種分離設計契合實際需求：多數團隊會將這些靜態參數存儲在外部配置系統中，結構分層既符合工程實踐，也便于系統維護。

在GenerationParameters類中，我們特別添加了provider_extensions字段。該字段用于處理各 LLM 服務商特有的差異化參數，其數據驗證和解釋邏輯交由專門的模型推理模塊處理 —— 該模塊知曉如何與具體服務商對接。這種設計帶來兩大優勢：

• 避免因跨服務重復驗證導致的冗余耦合。
• 保持核心模式的簡潔性與通用性。

為保障向后兼容性，新增功能均通過顯式可選字段實現：

• 這些字段實質上是功能開關，用戶必須主動啟用才能獲得特定行為。
• 核心模式保持穩定，新功能通過漸進式擴展實現。

典型應用：僅當請求中明確啟用時，系統才會在輸出中包含推理追蹤數據。

所有模式定義均封裝在共享 Python 庫中，確保各服務模塊在處理請求和響應時遵循統一規范。

與第三方供應商合作

雖然我們主要依賴內部平臺，但在某些場景下仍需與第三方模型服務商對接：

• 為數據科學團隊提供合成數據生成能力，支持原型設計和實驗。
• 處理通用任務時，某些現成的專有模型表現更優。
• 適用于隱私要求低、延遲不敏感或無需嚴格基礎設施控制的非核心業務。

與外部服務商的交互流程如下：

• 專用 LLM-Gateway 服務接收符合內部標準的用戶請求。
• 將請求轉換為目標服務商特定格式（含 provider_extensions 等擴展字段）
• 外部服務商處理請求并返回響應。
• LLM-Gateway 將響應轉換回標準化內部格式。

注：此為高層架構概覽，實際涉及更多微服務協作。流式響應格式等實現細節將在后續章節展開說明。

流式格式

LLM 響應采用逐令牌生成方式，并通過數據塊（chunks）聚合實現高效傳輸。為確保終端用戶在不同平臺（瀏覽器 / 移動應用 / 終端）上獲得流暢體驗，必須采用低延遲的實時流式傳輸機制。

當前主流實現方案有兩種：

• WebSockets：支持全雙工通信，允許客戶端與服務器持續雙向交互。
• SSE（服務器發送事件）：基于 HTTP 的單向流式傳輸協議，廣泛用于實時更新

我們最終選擇 SSE 方案，主要基于以下考量：

• 技術適配性：SSE 是 LLM 推理場景的主流選擇，尤其兼容 OpenAI 等標準 API。
• 實現優勢：

a.基于標準 HTTP 協議，無需特殊協商機制。

b.主流瀏覽器原生支持，無需額外依賴庫。

c.天然匹配 LLM 單向輸出特性。

d.完美兼容 HTTP 代理等基礎設施。

SSE 特別適合文本類即時流式響應場景。但對于需要雙向交互的復雜用例（如實時語音轉錄），WebSockets 仍是更優選擇 —— 這也是 OpenAI 實時 API 在服務間通信采用該方案的原因。

鑒于我們系統主要處理文本交互，為保持技術簡潔性與兼容性，最終采用與流式模型最匹配的 SSE 方案。

響應流內容

確定傳輸層后，需要規范流式數據的結構設計。高效的流式傳輸不僅要傳遞原始文本，還需包含結構化元數據和上下文信息，以支持客戶端 UI 和自動化工具等下游消費場景。流式響應必須包含以下核心要素：

• 頭部元數據包含請求 ID 等基礎標識信息。
• 內容塊主體

a.核心輸出內容（模型生成的 token 或字符串）。

b.采用序列化分塊傳輸（如 n=2、n=4 等并行序列）。

c.每個序列獨立生成，通過增量塊流式傳輸。

• 用量與細粒度元數據包含生成 token 數、時間戳等基礎指標，以及可選的診斷信息（如對數概率、推理跟蹤），用于計費、調試和模型評估非功能性設計要求在滿足基礎功能外，流式架構還需保證：
• 結構化：清晰劃分內容類型與事件邊界。
• 可擴展：支持靈活添加元數據字段，保持向前兼容。
• 健壯性：容錯處理格式異常、延遲或數據缺失多序列處理機制在并排比較、多樣性采樣等場景中，單個生成請求可能包含多個并行序列。參考 OpenAI API 規范：
• 每個數據塊的choices數組可包含多個序列更新。
• 即使當前實現中單塊通常只含單個增量，設計仍需保留多序列擴展能力。
• 官方 Python SDK 等工具已原生支持此結構。

為保持生態兼容性，我們采用相同結構設計。下圖示例展示了包含 3 個序列、分 6 個數據塊傳輸的完整流程：

• 片段 1—— 生成開始。這個片段標志著整個生成過程的開始。它不包含實際內容，但包含共享的元數據，如生成 ID、時間戳和角色（例如 "助手"）。
• 片段 2—— 序列開始（綠色和紫色）。兩個序列同時開始流動，每個序列都帶有唯一標識符以區分其他序列。
• 片段 3—— 序列開始（藍色）和序列增量。第三個序列（藍色）開始，同時前兩個序列（綠色和紫色）通過增量事件流式傳輸新增內容。
• 片段 4—— 中途更新和完成（紫色）。綠色和藍色序列繼續傳輸增量內容，而紫色序列完成，包含結構化的完成原因（如停止、達到長度等）。
• 片段 5—— 剩余序列完成。綠色和藍色序列都已完成。每個序列的生命周期現在都有明確的開始和結束標記。
• 片段 6—— 生成完成。這個片段結束整個生成過程，可能包含全局使用統計數據、最終標記計數、延遲信息或其他診斷信息。

為了使數據流更健壯且易于解析，我們選擇顯式標記整體生成和每個序列的開始與結束事件，而不是依賴隱式機制（如空值檢查、EOF 或特殊標記）。這種結構化方法簡化了下游解析，特別是在多個結果并行流式傳輸時，還提升了調試能力和運行時的故障隔離能力。

此外，我們引入了專門的錯誤片段，包含結構化的故障信息。像格式錯誤或授權問題這類錯誤可以通過標準 HTTP 響應代碼直接返回。但如果錯誤發生在生成過程中，我們有兩個選擇：突然終止 HTTP 流，或發送格式正確的 SSE 錯誤事件。我們選擇后者，因為突然關閉連接會讓客戶端難以區分是網絡問題還是模型 / 服務故障。通過專用錯誤片段，我們能更可靠地檢測和傳遞流中的問題。

后端服務和請求流程

系統的核心是單一入口點 ——LLM-Gateway。它負責處理以下基礎功能：身份驗證、使用跟蹤與配額控制、請求格式化，以及根據指定模型進行路由分發。雖然網關看似承擔了多項職責，但每個功能都經過精心設計，保持簡單和模塊化。

對于外部服務商，網關會將請求適配到它們的 API 規范，并將響應轉換回統一格式。對于自托管模型，請求則直接路由到內部系統，使用我們自有的標準化模式。這種設計通過統一的接口，實現了對外部服務和內部模型的無縫支持。

自托管模型

如之前提到的，服務器發送事件 (SSE) 非常適合向終端用戶推送流式響應，但不適合內部后端通信。當請求到達系統時，需要將其路由到合適的工作節點進行模型推理，并將結果以流式方式返回。雖然有些系統采用鏈式 HTTP 代理和基于標頭的路由方案，但根據我們的實踐經驗，隨著業務邏輯復雜度提升，這種方案會變得難以維護和擴展。

我們的內部基礎設施需要支持以下核心功能：

• 優先級感知調度：能夠區分請求的緊急程度（如交互式請求 vs 批處理任務），確保高優先級任務優先執行。
• 硬件感知路由：根據節點硬件配置智能路由，優先使用高性能 GPU 節點，普通節點作為備用資源。
• 模型特定分發：每個工作節點僅部署部分模型，基于硬件兼容性和資源限制進行分配

為滿足這些需求，我們采用消息代理來解耦任務路由和結果傳遞。這種架構設計在不同負載和路由條件下展現出更好的靈活性和健壯性。雖然 RabbitMQ 是我們的實現選擇（考慮到其成熟度和與現有工具的兼容性），但根據具體的延遲要求、吞吐量需求和運維偏好，其他消息代理也是可行的替代方案。

下面讓我們具體看看這個系統是如何實現的：

我們為每個模型使用專用隊列，以便根據模型兼容性和節點能力來路由請求。流程如下：

• 客戶端發送請求LLM-Gateway 服務（表示為用戶）發起 HTTP 請求以觸發文本生成任務。調度器服務啟動一個新的請求處理程序來管理此請求。
• 通過調度器服務進行任務路由調度器處理請求，根據請求的模型選擇適當的隊列（在圖中標記為綠色）并將消息附加到其中。
• 工作節點接收任務合適的推理工作節點（為簡化只顯示一個，但實際上有很多）訂閱隊列并接收任務開始處理。該工作節點在本地運行所選模型。
• 流式傳輸響應工作進程將響應逐個塊地流式傳輸到響應隊列，請求處理的調度器副本已訂閱該隊列。
• 接收響應塊調度器監聽回復隊列，并在響應塊到達時接收它們。
• SSE 流式傳輸將這些塊轉換為 SSE 格式，并流式傳輸到客戶端。

處理大型有效載荷的方法，為了避免消息代理過載：

• 不直接將大型輸入或輸出數據嵌入任務中，而是上傳到外部 S3 兼容存儲。
• 任務元數據中包含引用（如 URL 或資源 ID）。
• 工作者在需要時檢索實際內容。

應用 RabbitMQ 設計

在路由和消息發布處理中，每個請求隊列都是專門針對單一模型類型的標準 RabbitMQ 隊列。要實現優先級感知調度，可以通過消息優先級機制實現 —— 高優先級值的消息會優先于低優先級消息被傳遞和處理。對于硬件感知路由（需要將消息優先導向性能最優的節點），可采用消費者優先級機制：只要高優先級消費者處于活動狀態，就會優先接收消息；僅當高優先級消費者阻塞或不可用時，低優先級消費者才會接收消息。

若需確保消息零丟失，必須配置以下機制：

• 發布者確認：確保代理已接收并存儲消息。
• 持久化設置：啟用持久隊列和持久消息，保障重啟后數據不丟失。
• 仲裁隊列：提供更強健的持久性，并支持 RabbitMQ 4.0 + 的簡化消息和消費者優先級功能。

關于任務發布已討論完畢，接下來探討流式響應的處理方案。首先需要理解 RabbitMQ 臨時隊列的工作原理。代理支持 "獨占隊列" 概念，這類隊列具有以下特性：

• 綁定到單一連接。
• 連接關閉時自動刪除。
• 完美契合我們的使用場景。

我們為每個調度器服務副本創建獨占隊列，確保副本關閉時自動清理。但這帶來新的挑戰：雖然每個服務副本對應一個 RabbitMQ 隊列，但需要同時處理大量請求。

解決方案是將 RabbitMQ 隊列作為傳輸層，負責將響應路由到正確的調度器副本。具體實現：

• 為每個用戶請求分配唯一標識符，并嵌入每個響應塊。
• 調度器內部維護內存路由層，包含臨時內存隊列（每個活動請求對應一個）。
• 根據標識符匹配傳入塊并轉發到對應內存隊列。
• 請求完成后自動丟棄內存隊列，而 RabbitMQ 隊列持續到服務副本生命周期結束。

示意圖如下：

調度程序內的中央調度程序將塊分派到適當的內存隊列，每個隊列由專用處理程序管理。然后處理程序使用 SSE 協議將塊流式傳輸給用戶。

推理

目前有幾個成熟的框架可用于高效的 LLM 推理，例如 vLLM 和 SGLANG。這些系統設計用于并行處理多個序列并實時生成響應標記，通常具備連續批處理和 GPU 內存優化等功能。在我們的架構中，我們使用 vLLM 作為核心推理引擎，并進行了以下自定義修改：

• 自定義波束搜索實現：以更好地適應我們的生成邏輯并支持結構化約束。
• 支持結構化輸出模式：允許模型返回符合特定業務格式的輸出通過實踐，我們發現，即使是微小的庫更新也可能顯著影響模型行為 - 無論是在輸出質量、確定性還是并發性能方面。因此，我們建立了嚴格的測試流程：
• 壓力測試：發現并發問題、內存泄漏或穩定性退化。
• 確定性測試：確保固定種子和參數集下輸出一致。
• 參數網格測試：覆蓋廣泛的生成參數范圍但不過度。

存儲和部署

大多數現代系統運行在容器化環境中 - 無論是云環境還是 Kubernetes (K8s)。雖然這種配置對典型后端服務很有效，但在模型權重存儲方面會帶來挑戰。LLM 模型大小可能達到數十甚至數百 GB，直接將模型權重嵌入 Docker 鏡像會帶來問題：

• 構建緩慢：即使使用多階段構建和緩存，傳輸大型模型文件仍會顯著增加 CI 時間。
• 部署緩慢：每次部署都需要拉取大型鏡像，可能需要幾分鐘，導致停機或延遲。
• 資源效率低：Docker 注冊表和 Kubernetes 節點都沒有針對超大鏡像優化，導致存儲膨脹和帶寬緊張。

為解決這個問題，我們將模型存儲與 Docker 鏡像生命周期分離。我們的模型存儲在外部 S3 兼容對象存儲中，在推理服務啟動前獲取。為提高啟動速度并避免重復下載，我們還使用本地持久卷 (PVCs) 在每個節點上緩存模型權重。

可觀測性

這樣一個基于流處理、消息隊列和實時標記生成的系統，需要強大的可觀測性來確保規模化時的可靠性和性能。

除了標準服務級別指標 (CPU、內存、錯誤率等)，我們發現以下監控至關重要：

• 隊列深度、消息積壓和消費者數量：監控待處理消息數、當前隊列大小和活躍消費者數有助于檢測任務分發瓶頸和工作負載不均衡。
• 標記 / 塊吞吐量：跟蹤每秒生成的標記或響應塊數有助于識別延遲或吞吐量下降。
• 分布式追蹤：準確定位請求在網關、代理、工作節點等組件中的失敗或停滯位置。
• 推理引擎健康檢查：由于推理過程可能在極少數情況下崩潰 (如錯誤輸入或極端參數)，主動監控活躍性和就緒性至關重要。

未來改進

雖然我們的系統已達到生產就緒狀態，但仍存在重要挑戰和優化機會：

• 使用分布式 KV 緩存提升推理性能。
• 支持請求取消以在輸出不再需要時節省計算資源。
• 為數據科學團隊創建簡化的模型交付流水線。

結論

雖然構建一個可靠且獨立于供應商的 LLM 服務系統初看很復雜，但并不需要從頭造輪子。每個組件通過 SSE 進行流傳輸、通過消息代理進行任務分發、由 vLLM 等運行時處理推理 都有明確目的，并基于現有且得到良好支持的工具。通過正確架構，可以創建滿足生產需求、可維護且適應性強的系統，而不會引入不必要的復雜性。

譯者介紹

崔皓，51CTO社區編輯，資深架構師，擁有18年的軟件開發和架構經驗，10年分布式架構經驗。

原文標題：Behind the Scenes of Self-Hosting a Language Model at Scale，作者：Shimovolos Stas