企業(yè)級語言模型自托管優(yōu)秀實踐原創(chuàng)

發(fā)布于 2025-6-20 08:16

瀏覽

0收藏

開篇

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

介紹

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

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

在接下來的章節(jié)中，我們將詳細闡述項目遇到的挑戰(zhàn)、所實施的解決方案，以及在此過程中汲取的經(jīng)驗教訓(xùn)。

總體概述

上文我們提到的自托管系統(tǒng)，下面我們會針對構(gòu)成系統(tǒng)核心架構(gòu)的關(guān)鍵組件，給大家做逐一介紹。

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

為什么模式設(shè)計很重要

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

采用單一服務(wù)商的標準模式具有以下優(yōu)勢：

獲得經(jīng)過充分驗證的穩(wěn)定 API?。
兼容現(xiàn)有成熟的 SDK 和工具鏈?。

但同時也存在明顯弊端：

導(dǎo)致供應(yīng)商鎖定，難以支持多服務(wù)商接入?。
缺乏擴展性，無法靈活適應(yīng)業(yè)務(wù)需求或數(shù)據(jù)科學(xué)團隊的特殊要求?。
面臨不可控的 API 變更或廢棄風(fēng)險?。
傳統(tǒng)架構(gòu)約束限制了精細化控制能力?。

為此，我們決定建立專屬的內(nèi)部數(shù)據(jù)模型 —— 這是一個完全根據(jù)業(yè)務(wù)需求設(shè)計的架構(gòu)體系，可靈活映射到各類外部格式。

內(nèi)部模式設(shè)計

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

雙向兼容性：能輕松轉(zhuǎn)換為外部服務(wù)商所需格式，也能反向轉(zhuǎn)換?。
功能完整性：全面支持業(yè)務(wù)需求和數(shù)據(jù)科學(xué)團隊的特殊功能?。
可擴展性：模式設(shè)計需預(yù)留未來升級空間?。

我們首先分析了主流 LLM 服務(wù)商的數(shù)據(jù)模式，重點研究了消息結(jié)構(gòu)、參數(shù)定義和輸出格式。通過對比分析，我們提煉出以下核心領(lǐng)域?qū)嶓w，這些實體在大多數(shù)系統(tǒng)中通用：

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

同時，我們發(fā)現(xiàn)部分參數(shù)（如服務(wù)層級、元數(shù)據(jù)字段、推理模式等）屬于各服務(wù)商特有的內(nèi)部配置項。這些非通用元素被歸類為可選擴展項。只有當(dāng)某項功能被廣泛采用或?qū)ゲ僮餍灾陵P(guān)重要時，我們才會考慮將其納入核心模式。

我們的輸入模式主要由四大組件構(gòu)成：

模型標識：作為路由鍵，指引系統(tǒng)將請求分發(fā)到正確的工作節(jié)點?。
生成參數(shù)：核心模型配置（溫度值、top_p、max_tokens 等）。?
消息內(nèi)容：包含對話歷史和提示信息?。
工具定義：模型可調(diào)用的工具說明?。

基于以上設(shè)計，我們構(gòu)建了類似 Pydantic 的結(jié)構(gòu)化模式（為簡化說明，部分實現(xiàn)細節(jié)在此省略）。

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

我們刻意將生成參數(shù)（如溫度值、top-p 等模型配置）設(shè)計為獨立的嵌套字段，而非直接置于根層級。這種架構(gòu)設(shè)計實現(xiàn)了關(guān)鍵區(qū)分：

靜態(tài)參數(shù)：固定配置項（模型設(shè)置、生成參數(shù)等）。?
動態(tài)組件：可變內(nèi)容（消息內(nèi)容、工具定義等）。?

這種分離設(shè)計契合實際需求：多數(shù)團隊會將這些靜態(tài)參數(shù)存儲在外部配置系統(tǒng)中，結(jié)構(gòu)分層既符合工程實踐，也便于系統(tǒng)維護。

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

避免因跨服務(wù)重復(fù)驗證導(dǎo)致的冗余耦合?。
保持核心模式的簡潔性與通用性?。

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

這些字段實質(zhì)上是功能開關(guān)，用戶必須主動啟用才能獲得特定行為?。
核心模式保持穩(wěn)定，新功能通過漸進式擴展實現(xiàn)?。

典型應(yīng)用：僅當(dāng)請求中明確啟用時，系統(tǒng)才會在輸出中包含推理追蹤數(shù)據(jù)

所有模式定義均封裝在共享 Python 庫中，確保各服務(wù)模塊在處理請求和響應(yīng)時遵循統(tǒng)一規(guī)范。

與第三方供應(yīng)商合作

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

為數(shù)據(jù)科學(xué)團隊提供合成數(shù)據(jù)生成能力，支持原型設(shè)計和實驗?。
處理通用任務(wù)時，某些現(xiàn)成的專有模型表現(xiàn)更優(yōu)?。
適用于隱私要求低、延遲不敏感或無需嚴格基礎(chǔ)設(shè)施控制的非核心業(yè)務(wù)?。

與外部服務(wù)商的交互流程如下：

企業(yè)級語言模型自托管優(yōu)秀實踐-AI.x社區(qū)

專用 LLM-Gateway 服務(wù)接收符合內(nèi)部標準的用戶請求?。
將請求轉(zhuǎn)換為目標服務(wù)商特定格式（含 provider_extensions 等擴展字段）?
外部服務(wù)商處理請求并返回響應(yīng)?。
LLM-Gateway 將響應(yīng)轉(zhuǎn)換回標準化內(nèi)部格式。

注：此為高層架構(gòu)概覽，實際涉及更多微服務(wù)協(xié)作。流式響應(yīng)格式等實現(xiàn)細節(jié)將在后續(xù)章節(jié)展開說明。

流式格式

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

當(dāng)前主流實現(xiàn)方案有兩種：

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

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

技術(shù)適配性：SSE 是 LLM 推理場景的主流選擇，尤其兼容 OpenAI 等標準 API?。
實現(xiàn)優(yōu)勢：?

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

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

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

d.完美兼容 HTTP 代理等基礎(chǔ)設(shè)施。

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

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

響應(yīng)流內(nèi)容

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

頭部元數(shù)據(jù)包含請求 ID 等基礎(chǔ)標識信息。
內(nèi)容塊主體

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

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

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

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

為保持生態(tài)兼容性，我們采用相同結(jié)構(gòu)設(shè)計。下圖示例展示了包含 3 個序列、分 6 個數(shù)據(jù)塊傳輸?shù)耐暾鞒蹋?/p>

企業(yè)級語言模型自托管優(yōu)秀實踐-AI.x社區(qū)

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

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

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

后端服務(wù)和請求流程

企業(yè)級語言模型自托管優(yōu)秀實踐-AI.x社區(qū)

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

對于外部服務(wù)商，網(wǎng)關(guān)會將請求適配到它們的 API 規(guī)范，并將響應(yīng)轉(zhuǎn)換回統(tǒng)一格式。對于自托管模型，請求則直接路由到內(nèi)部系統(tǒng)，使用我們自有的標準化模式。這種設(shè)計通過統(tǒng)一的接口，實現(xiàn)了對外部服務(wù)和內(nèi)部模型的無縫支持。

自托管模型

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

我們的內(nèi)部基礎(chǔ)設(shè)施需要支持以下核心功能：

優(yōu)先級感知調(diào)度：能夠區(qū)分請求的緊急程度（如交互式請求 vs 批處理任務(wù)），確保高優(yōu)先級任務(wù)優(yōu)先執(zhí)行?。
硬件感知路由：根據(jù)節(jié)點硬件配置智能路由，優(yōu)先使用高性能 GPU 節(jié)點，普通節(jié)點作為備用資源?。
模型特定分發(fā)：每個工作節(jié)點僅部署部分模型，基于硬件兼容性和資源限制進行分配?

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

下面讓我們具體看看這個系統(tǒng)是如何實現(xiàn)的：

企業(yè)級語言模型自托管優(yōu)秀實踐-AI.x社區(qū)

我們?yōu)槊總€模型使用專用隊列，以便根據(jù)模型兼容性和節(jié)點能力來路由請求。流程如下：

客戶端發(fā)送請求LLM-Gateway 服務(wù)（表示為用戶）發(fā)起 HTTP 請求以觸發(fā)文本生成任務(wù)。調(diào)度器服務(wù)啟動一個新的請求處理程序來管理此請求。?
通過調(diào)度器服務(wù)進行任務(wù)路由調(diào)度器處理請求，根據(jù)請求的模型選擇適當(dāng)?shù)年犃校ㄔ趫D中標記為綠色）并將消息附加到其中。?
工作節(jié)點接收任務(wù)合適的推理工作節(jié)點（為簡化只顯示一個，但實際上有很多）訂閱隊列并接收任務(wù)開始處理。該工作節(jié)點在本地運行所選模型。?
流式傳輸響應(yīng)工作進程將響應(yīng)逐個塊地流式傳輸?shù)巾憫?yīng)隊列，請求處理的調(diào)度器副本已訂閱該隊列。?
接收響應(yīng)塊調(diào)度器監(jiān)聽回復(fù)隊列，并在響應(yīng)塊到達時接收它們。?
SSE 流式傳輸將這些塊轉(zhuǎn)換為 SSE 格式，并流式傳輸?shù)娇蛻舳恕?

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

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

應(yīng)用 RabbitMQ 設(shè)計

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

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

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

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

綁定到單一連接?。
連接關(guān)閉時自動刪除?。
完美契合我們的使用場景?。

我們?yōu)槊總€調(diào)度器服務(wù)副本創(chuàng)建獨占隊列，確保副本關(guān)閉時自動清理。但這帶來新的挑戰(zhàn)：雖然每個服務(wù)副本對應(yīng)一個 RabbitMQ 隊列，但需要同時處理大量請求。

解決方案是將 RabbitMQ 隊列作為傳輸層，負責(zé)將響應(yīng)路由到正確的調(diào)度器副本。具體實現(xiàn)：

為每個用戶請求分配唯一標識符，并嵌入每個響應(yīng)塊?。
調(diào)度器內(nèi)部維護內(nèi)存路由層，包含臨時內(nèi)存隊列（每個活動請求對應(yīng)一個）。?
根據(jù)標識符匹配傳入塊并轉(zhuǎn)發(fā)到對應(yīng)內(nèi)存隊列?。
請求完成后自動丟棄內(nèi)存隊列，而 RabbitMQ 隊列持續(xù)到服務(wù)副本生命周期結(jié)束?。

示意圖如下：

企業(yè)級語言模型自托管優(yōu)秀實踐-AI.x社區(qū)

調(diào)度程序內(nèi)的中央調(diào)度程序?qū)K分派到適當(dāng)?shù)膬?nèi)存隊列，每個隊列由專用處理程序管理。然后處理程序使用 SSE 協(xié)議將塊流式傳輸給用戶。

推理

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

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

存儲和部署

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

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

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

可觀測性

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

除了標準服務(wù)級別指標 (CPU、內(nèi)存、錯誤率等)，我們發(fā)現(xiàn)以下監(jiān)控至關(guān)重要：

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

未來改進

雖然我們的系統(tǒng)已達到生產(chǎn)就緒狀態(tài)，但仍存在重要挑戰(zhàn)和優(yōu)化機會：

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

結(jié)論

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