本文來自嗶哩嗶哩通用技術(shù)團(tuán)隊(duì)分享，下文進(jìn)行了排版優(yōu)化和修訂。
隨著 AI 技術(shù)快速發(fā)展，業(yè)務(wù)對 AI 能力的渴求日益增長。當(dāng) AI 服務(wù)面對處理大規(guī)模請求和高并發(fā)流量時，AI 網(wǎng)關(guān)從中扮演著至關(guān)重要的角色。AI 服務(wù)通常涉及大量的計(jì)算任務(wù)和設(shè)備資源占用，此時需要一個 AI 網(wǎng)關(guān)負(fù)責(zé)協(xié)調(diào)這些請求來確保系統(tǒng)的穩(wěn)定性與高效性。因此，與傳統(tǒng)微服務(wù)架構(gòu)類似，我們將相關(guān) API 管理的功能（如流量控制、用戶鑒權(quán)、配額計(jì)費(fèi)、負(fù)載均衡、API 路由等）集中放置在 AI 網(wǎng)關(guān)層，可以降低系統(tǒng)整體復(fù)雜度并提升可維護(hù)性。
本文要分享的是B站在大模型時代基于多模型AI的網(wǎng)關(guān)架構(gòu)設(shè)計(jì)和實(shí)踐總結(jié)，希望能帶給你啟發(fā)。
* 相關(guān)閱讀：《全民AI時代，大模型客戶端和服務(wù)端的實(shí)時通信到底用什么協(xié)議？》
《長連接網(wǎng)關(guān)技術(shù)專題(一)：京東京麥的生產(chǎn)級TCP網(wǎng)關(guān)技術(shù)實(shí)踐總結(jié)》
《長連接網(wǎng)關(guān)技術(shù)專題(二)：知乎千萬級并發(fā)的高性能長連接網(wǎng)關(guān)技術(shù)實(shí)踐》
《長連接網(wǎng)關(guān)技術(shù)專題(三)：手淘億級移動端接入層網(wǎng)關(guān)的技術(shù)演進(jìn)之路》
《長連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實(shí)時推送網(wǎng)關(guān)技術(shù)實(shí)踐》
《長連接網(wǎng)關(guān)技術(shù)專題(五)：喜馬拉雅自研億級API網(wǎng)關(guān)技術(shù)實(shí)踐》
《長連接網(wǎng)關(guān)技術(shù)專題(六)：石墨文檔單機(jī)50萬WebSocket長連接架構(gòu)實(shí)踐》
《長連接網(wǎng)關(guān)技術(shù)專題(七)：小米小愛單機(jī)120萬長連接接入層的架構(gòu)演進(jìn)》
《長連接網(wǎng)關(guān)技術(shù)專題(八)：B站基于微服務(wù)的API網(wǎng)關(guān)從0到1的演進(jìn)之路》
《長連接網(wǎng)關(guān)技術(shù)專題(九)：去哪兒網(wǎng)酒店高性能業(yè)務(wù)網(wǎng)關(guān)技術(shù)實(shí)踐》
《長連接網(wǎng)關(guān)技術(shù)專題(十)：百度基于Go的千萬級統(tǒng)一長連接服務(wù)架構(gòu)實(shí)踐》
《長連接網(wǎng)關(guān)技術(shù)專題(十一)：揭秘騰訊公網(wǎng)TGW網(wǎng)關(guān)系統(tǒng)的技術(shù)架構(gòu)演進(jìn)》
《長連接網(wǎng)關(guān)技術(shù)專題(十二)：大模型時代多模型AI網(wǎng)關(guān)的架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)》（* 本文）
AI 網(wǎng)關(guān)是一個用于統(tǒng)一接入和調(diào)度大語言模型（LLM）服務(wù)的系統(tǒng)，支持多供應(yīng)商、多模型、負(fù)載均衡調(diào)度的管理。同時具備統(tǒng)一鑒權(quán)、Token 配額管理、安全審計(jì)與可觀測能力，確保 API 調(diào)用的安全性和穩(wěn)定性。負(fù)載均衡模塊，能夠根據(jù)提供商多線路、多模型 和 API Key 進(jìn)行靈活路由，并適用于多模型接入、多租戶等復(fù)雜場景。
AI 網(wǎng)關(guān)的整體架構(gòu)和傳統(tǒng) API 網(wǎng)關(guān)及其類似，在數(shù)據(jù)面和控制面上有幾乎相同的設(shè)計(jì)。
實(shí)際上 AI 網(wǎng)關(guān)就是衍生于之前微服務(wù)團(tuán)隊(duì)的 API Gateway，我們在 API Gateway 的基礎(chǔ)上做了一些針對 AI 業(yè)務(wù)接口的特性優(yōu)化，如無緩沖區(qū)的請求代理，支持域名、服務(wù)發(fā)現(xiàn)等混合調(diào)度，AI 超長響應(yīng)時間請求的優(yōu)雅退出等功能。
在此基礎(chǔ)上我們使用于 API Gateway 相類似的數(shù)據(jù)面、控制面分離的架構(gòu)，控制面會將變更后的網(wǎng)關(guān)配置準(zhǔn)實(shí)時下發(fā)至數(shù)據(jù)面節(jié)點(diǎn)。數(shù)據(jù)面節(jié)點(diǎn)識別配置有更新后在運(yùn)行時會動態(tài)切換代理引擎至新的代理邏輯下，并保證老的代理邏輯會處理完當(dāng)下被分配的請求。
在數(shù)據(jù)面中，我們對請求過濾器有兩種模式的抽象：請求過濾器和模型過濾器。請求過濾器作用于用戶的原始請求，這類過濾器往往被設(shè)計(jì)用于處理鑒權(quán)、限流等邏輯。而模型過濾器作用于請求被轉(zhuǎn)發(fā)至該模型時，常用于模型 API 的兼容邏輯。比如模型發(fā)展中目前對深度思考 <think> 的標(biāo)簽處理，推理引擎自定義參數(shù)的兼容修正等。
除此之外控制面也會提供 OpenAPI 供 AI 模型供給團(tuán)隊(duì)上架模型，新增 API Key 等日常運(yùn)營能力。模型提供方可以在上架模型時支持為模型配置相應(yīng)的 RPM、TPM 上限，并根據(jù)模型的推理引擎選擇相應(yīng)的兼容策略。也可以通過 OpenAPI 為單個 API Key 授權(quán)相應(yīng)模型等功能。
在鑒權(quán)機(jī)制中，采用目前主流 OpenAI SDK 兼容的 API Key 認(rèn)證方案。
Authorization: Bearer <YOUR_API_KEY>
在 API Key 的認(rèn)證基礎(chǔ)上還提供細(xì)粒度的權(quán)限控制功能，允許為每個 API Key 配置可訪問的模型范圍，以及對不同模型的設(shè)置不同的配額。
另外支持靈活的 API Key 有效期配置，用戶可根據(jù)需求設(shè)置 API Key 的 過期時間 或 不過期。
在配額管理體系里可以限制模型消費(fèi)者的調(diào)用速率，在這里主要參考了 OpenAI 的配額策略： RPM（每分鐘請求數(shù)）和 TPM（每分鐘 Tokens 數(shù)）。
在這里可以按照為每個用戶分配不同模型的 Token 配額，或指定單位時間的請求數(shù)限制，以確保 AI 服務(wù)的高效運(yùn)行并防止超出預(yù)算。
同時我們還支持月維度的 Token 配額，業(yè)務(wù)按自然月進(jìn)行預(yù)算申請，超過預(yù)算時請求將被限制。對于接入 AI 能力而言，每個業(yè)務(wù)都需要提前申請預(yù)算額度，避免帶來難以負(fù)擔(dān)的成本。
目前版本僅支持基于 OpenAI API 的協(xié)議轉(zhuǎn)發(fā)。以目前推理引擎發(fā)展和在線 AI 云服務(wù)而言，兼容 OpenAI API 協(xié)議已經(jīng)成為業(yè)界共識，在此基礎(chǔ)上我們只需要實(shí)現(xiàn)根據(jù)用戶需求的模型名，擇優(yōu)選擇一個相應(yīng)模型的上游 API 提供商（公司自建 IDC或公有云），并替換成相應(yīng)服務(wù)商的 API Key 和 Upstream 域名就可以進(jìn)行負(fù)載均衡。
對于公司 IDC 自建的模型服務(wù)而言，我們繼續(xù)沿用基于 discovery 等服務(wù)發(fā)現(xiàn)技術(shù)來發(fā)現(xiàn)推理引擎節(jié)點(diǎn)，直接將請求包裝調(diào)度至這些自建模型。
LLM API 的負(fù)載均衡和傳統(tǒng)實(shí)時 API 的模式有很大的不同。
傳統(tǒng) API 開發(fā)中：一次請求往往被設(shè)計(jì)成會極大概率地命中一塊結(jié)果緩存，且緩存 Key 的計(jì)算都比較簡單，因此很多負(fù)載均衡都簡單基于請求相應(yīng)時間、連接數(shù)等等。
在 LLM 推理場景下：每個推理請求都會帶來網(wǎng)關(guān)本身難以評估的計(jì)算時間和設(shè)備資源占用，此時基于 RPS、TTFB、連接數(shù)等負(fù)載均衡策略將不再適用。
在 AI 網(wǎng)關(guān)的默認(rèn)負(fù)載均衡策略中：我們主要基于單模型服務(wù)節(jié)點(diǎn)處理 Token 的吞吐和時延能力，在黑盒模式下評估節(jié)點(diǎn)的飽和度。除此之外，推理引擎自身和顯卡其實(shí)也暴露了許多和執(zhí)行隊(duì)列相關(guān)的指標(biāo)，綜合這些指標(biāo)同樣預(yù)計(jì)能獲得比傳統(tǒng)負(fù)載均衡更有效的體驗(yàn)。
另外：基于 Prefix Cache 的節(jié)點(diǎn)選擇同樣會是一個相當(dāng)有效的調(diào)度策略，但 Prefix Cache 的計(jì)算能力往往需要外部服務(wù)來進(jìn)行，因此 AI 網(wǎng)關(guān)同樣支持接入外置的負(fù)載均衡算法，通過前置的 RPC 來讓外置服務(wù)選擇最合適的模型節(jié)點(diǎn)。
業(yè)務(wù)主要通過 域名 + API Key 進(jìn)行訪問大模型推理，可以通過域名進(jìn)行管理對接的接口路由，進(jìn)行配置轉(zhuǎn)發(fā)到指定 Model Provider 服務(wù)。如果需要進(jìn)行多業(yè)務(wù)隔離，只需要通過不同的域名訪問并配置不同的轉(zhuǎn)發(fā)目標(biāo)。
從業(yè)務(wù)視角，主要分為 Gateway、 Domain、Consumer、Provider、UserModel、UpstreamModel 維度，進(jìn)行查詢和觀察請求接口的可用率，以及 QPS、Latency、5xx、Quota 等指標(biāo)。
在 AI 網(wǎng)關(guān)中，我們主要以 OpenAI 提供的 API 作為基礎(chǔ)協(xié)議，讓開發(fā)者基于 OpenAI SDK 實(shí)現(xiàn)各種業(yè)務(wù)場景對接。
目前支持的 API 協(xié)議有：
1）對話式模型交互（CHAT_COMPLETION）；
2）通用文本向量接口（EMBEDDING）；
3）提示詞模板（CHAT_TEMPLATE）；
4）模型上下文協(xié)議（MODEL_CONTEXT_PROTOCOL） 。
業(yè)務(wù)可以根據(jù)自己不同的場景進(jìn)行選擇對應(yīng)的協(xié)議。
對話式模型交互是最基礎(chǔ)的協(xié)議，用于構(gòu)建具有復(fù)雜邏輯的對話交互。同時 API 支持上下文感知的對話，使得模型能夠理解和響應(yīng)多輪交流，并在對話中保持合理的邏輯和語境一致性。
對話接口是 LLM 與現(xiàn)實(shí)世界溝通的重要渠道，大量 AI 需求實(shí)際上就是在與模型進(jìn)行一輪或多輪對話實(shí)現(xiàn)的。
例如業(yè)務(wù)希望通過 LLM 排查線上故障的潛在原因，簡單來說就是將應(yīng)用的各項(xiàng)可觀測指標(biāo)、故障期間的日志記錄或應(yīng)用上下游的變更記錄以對話形式告知 LLM，并讓 LLM 輸出一段便于程序理解的結(jié)果表達(dá)模式，讓 LLM 從模型數(shù)據(jù)中計(jì)算出符合直覺潛在故障原因。
通用文本向量（EMBEDDING）接口的核心功能是將文本轉(zhuǎn)化為高維向量，捕捉其語義特征。這在需要進(jìn)行大規(guī)模信息檢索、匹配和知識管理的場景中尤為關(guān)鍵。
提示詞模板是一種結(jié)構(gòu)化的對話生成方式，允許業(yè)務(wù)通過設(shè)置預(yù)定義的模板來生成系統(tǒng)化的回復(fù)。這種方式將語言模型的生成能力與模板化結(jié)構(gòu)相結(jié)合，使業(yè)務(wù)能夠以普通 API 的方式進(jìn)行請求交互，并可以更集中化地控制生成內(nèi)容的樣式和格式。
同時我們也支持內(nèi)嵌函數(shù)，以方便在提示詞模板進(jìn)行處理內(nèi)容：
1）len(v any) string
2）jsonify(v any) string
3）make_json_object(v ...any) map[string]any
4）slice_to_index_map(v any, startBy int) map[int]any
以評論內(nèi)容翻譯的場景：
- path: /v1/reply-to-en
protocol: HTTP
timeout: 300s
middlewares:
- name: v1_chat_template
options:
'@type': type.googleapis.com/infra.gateway.middleware.llm.v1.contrib.ChatTemplateConfig
provider: bilibili
model_name: index
prompt_template: |
你的任務(wù)：以下給定文本是一個B站視頻的相關(guān)文本信息，可能為標(biāo)題、簡介、彈幕或評論，請你將給定的文本逐條翻譯成英文。輸入為一個json格式，key為序號，value為待翻譯的彈幕，一共有{{ len .reply_list }}個文本。示例如下:
輸入: {"1": "xxx", "2": "xxx"}
輸出: {"1": "xxx", "2": "xxx"}
注意，用{dyn:xxx}符號包裹的是圖片引用，不需要翻譯，直接保留。用[xxx]包裹的是表情符號，不需要翻譯，直接保留。現(xiàn)在請根據(jù)上述要求完成如下片段的翻譯，輸出一共{{ len .reply_list }}個翻譯后的結(jié)果，直接輸出翻譯后的英文，不要進(jìn)行任何解釋。
輸入: {{ jsonify (slice_to_index_map .reply_list 1) }}
輸出:
提示詞模版接口實(shí)際上是基于對話接口的一種高效對接模式。眾所周知，自 OpenAI 發(fā)布 ChatGPT 后，提示詞工程（Prompt Engineering）本身被當(dāng)作一種技術(shù)路線而提出。提示詞工程主要關(guān)注提示詞開發(fā)與優(yōu)化，幫助用戶將大語言模型用于各場景和研究領(lǐng)域。研究人員可利用提示工程來提升大語言模型處理復(fù)雜任務(wù)場景的能力，如問答和算術(shù)推理能力。
對于接入 LLM 的業(yè)務(wù)研發(fā)而言，他可能本身不具備很強(qiáng)的提示詞工程能力；甚至提示詞的優(yōu)化本身也取決于模型的迭代更新。因此對于解決特定領(lǐng)域的業(yè)務(wù)場景，AI 工程師往往會基于最優(yōu)模型寫出最精準(zhǔn)的提示詞，通過 AI 網(wǎng)關(guān)的提示詞模版接口發(fā)布。業(yè)務(wù)提交簡單 JSON KV 對后，渲染出最有效的完整提示詞，LLM 基于有效提示詞輸出最精確的結(jié)果。
MCP (Model Context Protocol，模型上下文協(xié)議) 是由 Anthropic 在 2024 年底推出的一種開放協(xié)議，旨在讓大型語言模型（LLM）能夠以標(biāo)準(zhǔn)化的方式連接到外部數(shù)據(jù)源和工具。該協(xié)議抽象并標(biāo)準(zhǔn)化了 Resources、Prompts、Tools 等資源及其接入方式，允許 LLM Client 應(yīng)用以一致的方式連接到各種數(shù)據(jù)源和工具，如文件、數(shù)據(jù)庫、API 等。
配置轉(zhuǎn)發(fā)到注冊中心的 MCP 服務(wù)：
- path: /example-mcp/*
protocol: HTTP
timeout: 300s
middlewares:
- name: v1_mcp_server
options:
'@type': type.googleapis.com/infra.gateway.middleware.llm.v1.contrib.MCPServerConfig
proxy:
name: example-mcp
upstreams:
- url: 'discovery://infra.example.example-mcp'
- path: /example-mcp/*
protocol: HTTP
timeout: 300s
middlewares:
- name: v1_mcp_server
options:
'@type': type.googleapis.com/infra.gateway.middleware.llm.v1.contrib.MCPServerConfig
proxy:
name: example-mcp
upstreams:
- url: 'discovery://infra.example.example-mcp'
MCP 市場其實(shí)就是一個公司內(nèi)部的資源共享和協(xié)作平臺。簡單來說，它可以看作是企業(yè)內(nèi)的小型“App Store”，專門用來提供各種服務(wù)和資源的接入入口?？梢宰寴I(yè)務(wù)通過這個平臺輕松獲取、整合、使用這些資源，使業(yè)務(wù)對接更加地簡單。
用戶可以把自己的 MCP 服務(wù)快速發(fā)布到市場上，并且接入到 MCP Gateway 后即可使用。
當(dāng)前的 MCP 協(xié)議中主要有兩個端點(diǎn)：
1）/sse：是一個 Events 長連接通知協(xié)議，用于實(shí)時通知資源信息的變更；
2）/message：用于 JSONRPC 通信端點(diǎn)，能夠以 JSONRPC 方式進(jìn)行通信交互。
而我們在 MCP Gateway 中，我們在企業(yè)內(nèi)部將通過統(tǒng)一的域名進(jìn)行提供業(yè)務(wù)接入，并且進(jìn)行管理每一個 MCP服務(wù)的接口，例如：https://mcp.example.com/logging-mcp。
同時在 MCP服務(wù)中，需要使用相同的根路徑 /logging-mcp，因?yàn)樵?MCP 協(xié)議中，會先連接到 /sse 端點(diǎn)，再返回對應(yīng)的 /message 端點(diǎn)信息，所以請求路徑需要保持跟網(wǎng)關(guān)一致。
AI 網(wǎng)關(guān)通過統(tǒng)一接入、鑒權(quán)、配額管理 和 模型調(diào)度支持，為大模型提供了高效、安全、定制的連接能力。同時，支持了 OpenAI 協(xié)議、提示詞模板 和 MCP 市場等功能，進(jìn)一步擴(kuò)展了 AI 技術(shù)在企業(yè)中的應(yīng)用場景，為業(yè)務(wù)接入和資源整合提供了極高的便利性。（本文已同步發(fā)布于：http://www.52im.net/thread-4831-1-1.html）
[1] Web端即時通訊技術(shù)盤點(diǎn)：短輪詢、Comet、Websocket、SSE
[2] SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)
[3] 網(wǎng)頁端IM通信技術(shù)快速入門：短輪詢、長輪詢、SSE、WebSocket
[4] 搞懂現(xiàn)代Web端即時通訊技術(shù)一文就夠：WebSocket、socket.io、SSE
[5] 全民AI時代，大模型客戶端和服務(wù)端的實(shí)時通信到底用什么協(xié)議？
