開(kāi)篇

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

介紹

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

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

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

總體概述

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

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

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

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

采用單一服務(wù)商的標(biāo)準(zhǔn)模式具有以下優(yōu)勢(shì)：

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

但同時(shí)也存在明顯弊端：

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

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

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

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

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

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

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

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

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

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

基于以上設(shè)計(jì)，我們構(gòu)建了類似 Pydantic 的結(jié)構(gòu)化模式（為簡(jiǎn)化說(shuō)明，部分實(shí)現(xiàn)細(xì)節(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è)計(jì)為獨(dú)立的嵌套字段，而非直接置于根層級(jí)。這種架構(gòu)設(shè)計(jì)實(shí)現(xiàn)了關(guān)鍵區(qū)分：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

流式格式

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

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

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

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

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

a.基于標(biāo)準(zhǔn) HTTP 協(xié)議，無(wú)需特殊協(xié)商機(jī)制。

b.主流瀏覽器原生支持，無(wú)需額外依賴庫(kù)。

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

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

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

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

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

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

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

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

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

c.每個(gè)序列獨(dú)立生成，通過(guò)增量塊流式傳輸。

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

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

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

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

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

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

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

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

自托管模型

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

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

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

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

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

我們?yōu)槊總€(gè)模型使用專用隊(duì)列，以便根據(jù)模型兼容性和節(jié)點(diǎn)能力來(lái)路由請(qǐng)求。流程如下：

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

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

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

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

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

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

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

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

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

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

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

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

示意圖如下：

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

推理

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

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

存儲(chǔ)和部署

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

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

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

可觀測(cè)性

這樣一個(gè)基于流處理、消息隊(duì)列和實(shí)時(shí)標(biāo)記生成的系統(tǒng)，需要強(qiáng)大的可觀測(cè)性來(lái)確保規(guī)?；瘯r(shí)的可靠性和性能。

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

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

未來(lái)改進(jìn)

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

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

結(jié)論

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

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開(kāi)發(fā)和架構(gòu)經(jīng)驗(yàn)，10年分布式架構(gòu)經(jīng)驗(yàn)。

原文標(biāo)題：??Behind the Scenes of Self-Hosting a Language Model at Scale??，作者：Shimovolos Stas