本文來自嗶哩嗶哩通用技術團隊分享，下文進行了排版優化和修訂。

1、引言

隨著 AI 技術快速發展，業務對 AI 能力的渴求日益增長。當 AI 服務面對處理大規模請求和高并發流量時，AI 網關從中扮演著至關重要的角色。AI 服務通常涉及大量的計算任務和設備資源占用，此時需要一個 AI 網關負責協調這些請求來確保系統的穩定性與高效性。因此，與傳統微服務架構類似，我們將相關 API 管理的功能（如流量控制、用戶鑒權、配額計費、負載均衡、API 路由等）集中放置在 AI 網關層，可以降低系統整體復雜度并提升可維護性。

本文要分享的是B站在大模型時代基于多模型AI的網關架構設計和實踐總結，希望能帶給你啟發。

* 相關閱讀：《全民AI時代，大模型客戶端和服務端的實時通信到底用什么協議？》

技術交流：

（本文已同步發布于：http://www.52im.net/thread-4831-1-1.html）

2、系列文章

1. 《長連接網關技術專題(一)：京東京麥的生產級TCP網關技術實踐總結》
2. 《長連接網關技術專題(二)：知乎千萬級并發的高性能長連接網關技術實踐》
3. 《長連接網關技術專題(三)：手淘億級移動端接入層網關的技術演進之路》
4. 《長連接網關技術專題(四)：愛奇藝WebSocket實時推送網關技術實踐》
5. 《長連接網關技術專題(五)：喜馬拉雅自研億級API網關技術實踐》
6. 《長連接網關技術專題(六)：石墨文檔單機50萬WebSocket長連接架構實踐》
7. 《長連接網關技術專題(七)：小米小愛單機120萬長連接接入層的架構演進》
8. 《長連接網關技術專題(八)：B站基于微服務的API網關從0到1的演進之路》
9. 《長連接網關技術專題(九)：去哪兒網酒店高性能業務網關技術實踐》
10. 《長連接網關技術專題(十)：百度基于Go的千萬級統一長連接服務架構實踐》
11. 《長連接網關技術專題(十一)：揭秘騰訊公網TGW網關系統的技術架構演進》
12. 《長連接網關技術專題(十二)：大模型時代多模型AI網關的架構設計與實現》（* 本文）

3、AI網關技術概覽

AI 網關是一個用于統一接入和調度大語言模型（LLM）服務的系統，支持多供應商、多模型、負載均衡調度的管理。同時具備統一鑒權、Token 配額管理、安全審計與可觀測能力，確保 API 調用的安全性和穩定性。負載均衡模塊，能夠根據提供商多線路、多模型 和 API Key 進行靈活路由，并適用于多模型接入、多租戶等復雜場景。

4、整體架構設計

AI 網關的整體架構和傳統 API 網關及其類似，在數據面和控制面上有幾乎相同的設計。

實際上 AI 網關就是衍生于之前微服務團隊的 API Gateway，我們在 API Gateway 的基礎上做了一些針對 AI 業務接口的特性優化，如無緩沖區的請求代理，支持域名、服務發現等混合調度，AI 超長響應時間請求的優雅退出等功能。

在此基礎上我們使用于 API Gateway 相類似的數據面、控制面分離的架構，控制面會將變更后的網關配置準實時下發至數據面節點。數據面節點識別配置有更新后在運行時會動態切換代理引擎至新的代理邏輯下，并保證老的代理邏輯會處理完當下被分配的請求。

在數據面中，我們對請求過濾器有兩種模式的抽象：請求過濾器和模型過濾器。請求過濾器作用于用戶的原始請求，這類過濾器往往被設計用于處理鑒權、限流等邏輯。而模型過濾器作用于請求被轉發至該模型時，常用于模型 API 的兼容邏輯。比如模型發展中目前對深度思考 <think> 的標簽處理，推理引擎自定義參數的兼容修正等。

除此之外控制面也會提供 OpenAPI 供 AI 模型供給團隊上架模型，新增 API Key 等日常運營能力。模型提供方可以在上架模型時支持為模型配置相應的 RPM、TPM 上限，并根據模型的推理引擎選擇相應的兼容策略。也可以通過 OpenAPI 為單個 API Key 授權相應模型等功能。

5、鑒權認證

在鑒權機制中，采用目前主流 OpenAI SDK 兼容的 API Key 認證方案。

Authorization: Bearer <YOUR_API_KEY>

在 API Key 的認證基礎上還提供細粒度的權限控制功能，允許為每個 API Key 配置可訪問的模型范圍，以及對不同模型的設置不同的配額。

另外支持靈活的 API Key 有效期配置，用戶可根據需求設置 API Key 的 過期時間 或 不過期。

6、配額管理

在配額管理體系里可以限制模型消費者的調用速率，在這里主要參考了 OpenAI 的配額策略： RPM（每分鐘請求數）和 TPM（每分鐘 Tokens 數）。

在這里可以按照為每個用戶分配不同模型的 Token 配額，或指定單位時間的請求數限制，以確保 AI 服務的高效運行并防止超出預算。

同時我們還支持月維度的 Token 配額，業務按自然月進行預算申請，超過預算時請求將被限制。對于接入 AI 能力而言，每個業務都需要提前申請預算額度，避免帶來難以負擔的成本。

7、多模型訪問

目前版本僅支持基于 OpenAI API 的協議轉發。以目前推理引擎發展和在線 AI 云服務而言，兼容 OpenAI API 協議已經成為業界共識，在此基礎上我們只需要實現根據用戶需求的模型名，擇優選擇一個相應模型的上游 API 提供商（公司自建 IDC或公有云），并替換成相應服務商的 API Key 和 Upstream 域名就可以進行負載均衡。

對于公司 IDC 自建的模型服務而言，我們繼續沿用基于 discovery 等服務發現技術來發現推理引擎節點，直接將請求包裝調度至這些自建模型。

8、模型負載均衡

LLM API 的負載均衡和傳統實時 API 的模式有很大的不同。

傳統 API 開發中：一次請求往往被設計成會極大概率地命中一塊結果緩存，且緩存 Key 的計算都比較簡單，因此很多負載均衡都簡單基于請求相應時間、連接數等等。

在 LLM 推理場景下：每個推理請求都會帶來網關本身難以評估的計算時間和設備資源占用，此時基于 RPS、TTFB、連接數等負載均衡策略將不再適用。

在 AI 網關的默認負載均衡策略中：我們主要基于單模型服務節點處理 Token 的吞吐和時延能力，在黑盒模式下評估節點的飽和度。除此之外，推理引擎自身和顯卡其實也暴露了許多和執行隊列相關的指標，綜合這些指標同樣預計能獲得比傳統負載均衡更有效的體驗。

另外：基于 Prefix Cache 的節點選擇同樣會是一個相當有效的調度策略，但 Prefix Cache 的計算能力往往需要外部服務來進行，因此 AI 網關同樣支持接入外置的負載均衡算法，通過前置的 RPC 來讓外置服務選擇最合適的模型節點。

9、多租戶隔離

業務主要通過 域名 + API Key 進行訪問大模型推理，可以通過域名進行管理對接的接口路由，進行配置轉發到指定 Model Provider 服務。如果需要進行多業務隔離，只需要通過不同的域名訪問并配置不同的轉發目標。

10、可觀測能力

從業務視角，主要分為 Gateway、 Domain、Consumer、Provider、UserModel、UpstreamModel 維度，進行查詢和觀察請求接口的可用率，以及 QPS、Latency、5xx、Quota 等指標。

11、支持的API協議

11.1 概述

在 AI 網關中，我們主要以 OpenAI 提供的 API 作為基礎協議，讓開發者基于 OpenAI SDK 實現各種業務場景對接。

目前支持的 API 協議有：

• 1）對話式模型交互（CHAT_COMPLETION）；
• 2）通用文本向量接口（EMBEDDING）；
• 3）提示詞模板（CHAT_TEMPLATE）；
• 4）模型上下文協議（MODEL_CONTEXT_PROTOCOL） 。

業務可以根據自己不同的場景進行選擇對應的協議。

11.2 對話式模型交互（CHAT_COMPLETION）

對話式模型交互是最基礎的協議，用于構建具有復雜邏輯的對話交互。同時 API 支持上下文感知的對話，使得模型能夠理解和響應多輪交流，并在對話中保持合理的邏輯和語境一致性。

對話接口是 LLM 與現實世界溝通的重要渠道，大量 AI 需求實際上就是在與模型進行一輪或多輪對話實現的。

例如業務希望通過 LLM 排查線上故障的潛在原因，簡單來說就是將應用的各項可觀測指標、故障期間的日志記錄或應用上下游的變更記錄以對話形式告知 LLM，并讓 LLM 輸出一段便于程序理解的結果表達模式，讓 LLM 從模型數據中計算出符合直覺潛在故障原因。

11.3 通用文本向量（EMBEDDING）

通用文本向量（EMBEDDING）接口的核心功能是將文本轉化為高維向量，捕捉其語義特征。這在需要進行大規模信息檢索、匹配和知識管理的場景中尤為關鍵。

11.4 提示詞模板（CHAT_TEMPLATE）

提示詞模板是一種結構化的對話生成方式，允許業務通過設置預定義的模板來生成系統化的回復。這種方式將語言模型的生成能力與模板化結構相結合，使業務能夠以普通 API 的方式進行請求交互，并可以更集中化地控制生成內容的樣式和格式。

同時我們也支持內嵌函數，以方便在提示詞模板進行處理內容：

• 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

以評論內容翻譯的場景：

- 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: |

        你的任務：以下給定文本是一個B站視頻的相關文本信息，可能為標題、簡介、彈幕或評論，請你將給定的文本逐條翻譯成英文。輸入為一個json格式，key為序號，value為待翻譯的彈幕，一共有{{ len .reply_list }}個文本。示例如下:

        輸入: {"1": "xxx", "2": "xxx"}

 

        輸出: {"1": "xxx", "2": "xxx"}

 

        注意，用{dyn:xxx}符號包裹的是圖片引用，不需要翻譯，直接保留。用[xxx]包裹的是表情符號，不需要翻譯，直接保留。現在請根據上述要求完成如下片段的翻譯，輸出一共{{ len .reply_list }}個翻譯后的結果，直接輸出翻譯后的英文，不要進行任何解釋。

 

        輸入: {{ jsonify (slice_to_index_map .reply_list 1) }}

 

        輸出:

提示詞模版接口實際上是基于對話接口的一種高效對接模式。眾所周知，自 OpenAI 發布 ChatGPT 后，提示詞工程（Prompt Engineering）本身被當作一種技術路線而提出。提示詞工程主要關注提示詞開發與優化，幫助用戶將大語言模型用于各場景和研究領域。研究人員可利用提示工程來提升大語言模型處理復雜任務場景的能力，如問答和算術推理能力。

對于接入 LLM 的業務研發而言，他可能本身不具備很強的提示詞工程能力；甚至提示詞的優化本身也取決于模型的迭代更新。因此對于解決特定領域的業務場景，AI 工程師往往會基于最優模型寫出最精準的提示詞，通過 AI 網關的提示詞模版接口發布。業務提交簡單 JSON KV 對后，渲染出最有效的完整提示詞，LLM 基于有效提示詞輸出最精確的結果。

11.5 模型上下文協議（MODEL_CONTEXT_PROTOCOL）

MCP (Model Context Protocol，模型上下文協議) 是由 Anthropic 在 2024 年底推出的一種開放協議，旨在讓大型語言模型（LLM）能夠以標準化的方式連接到外部數據源和工具。該協議抽象并標準化了 Resources、Prompts、Tools 等資源及其接入方式，允許 LLM Client 應用以一致的方式連接到各種數據源和工具，如文件、數據庫、API 等。

配置轉發到注冊中心的 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'

- 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'

12、MCP市場與API接入

MCP 市場其實就是一個公司內部的資源共享和協作平臺。簡單來說，它可以看作是企業內的小型“App Store”，專門用來提供各種服務和資源的接入入口?？梢宰寴I務通過這個平臺輕松獲取、整合、使用這些資源，使業務對接更加地簡單。

用戶可以把自己的 MCP 服務快速發布到市場上，并且接入到 MCP Gateway 后即可使用。

當前的 MCP 協議中主要有兩個端點：

• 1）/sse：是一個 Events 長連接通知協議，用于實時通知資源信息的變更；
• 2）/message：用于 JSONRPC 通信端點，能夠以 JSONRPC 方式進行通信交互。

而我們在 MCP Gateway 中，我們在企業內部將通過統一的域名進行提供業務接入，并且進行管理每一個 MCP服務的接口，例如：https://mcp.example.com/logging-mcp。

同時在 MCP服務中，需要使用相同的根路徑 /logging-mcp，因為在 MCP 協議中，會先連接到 /sse 端點，再返回對應的 /message 端點信息，所以請求路徑需要保持跟網關一致。

13、本文小結

AI 網關通過統一接入、鑒權、配額管理 和 模型調度支持，為大模型提供了高效、安全、定制的連接能力。同時，支持了 OpenAI 協議、提示詞模板 和 MCP 市場等功能，進一步擴展了 AI 技術在企業中的應用場景，為業務接入和資源整合提供了極高的便利性。

14、相關資料

[1] Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE

[2] SSE技術詳解：一種全新的HTML5服務器推送事件技術

[3] 網頁端IM通信技術快速入門：短輪詢、長輪詢、SSE、WebSocket

[4] 搞懂現代Web端即時通訊技術一文就夠：WebSocket、socket.io、SSE

[5] 全民AI時代，大模型客戶端和服務端的實時通信到底用什么協議？

（本文已同步發布于：http://www.52im.net/thread-4831-1-1.html）