1.背景

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

2.AI 網(wǎng)關(guān)概覽

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

圖片

整體架構(gòu)

AI 網(wǎng)關(guān)的整體架構(gòu)和傳統(tǒng) API 網(wǎng)關(guān)及其類似，在數(shù)據(jù)面和控制面上有幾乎相同的設計。

圖片

實際上 AI 網(wǎng)關(guān)就是衍生于之前微服務團隊的 API Gateway，我們在 API Gateway 的基礎上做了一些針對 AI 業(yè)務接口的特性優(yōu)化，如無緩沖區(qū)的請求代理，支持域名、服務發(fā)現(xiàn)等混合調(diào)度，AI 超長響應時間請求的優(yōu)雅退出等功能。

在此基礎上我們使用于 API Gateway 相類似的數(shù)據(jù)面、控制面分離的架構(gòu)，控制面會將變更后的網(wǎng)關(guān)配置準實時下發(fā)至數(shù)據(jù)面節(jié)點。數(shù)據(jù)面節(jié)點識別配置有更新后在運行時會動態(tài)切換代理引擎至新的代理邏輯下，并保證老的代理邏輯會處理完當下被分配的請求。

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

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

鑒權(quán)認證

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

Authorization: Bearer <YOUR_API_KEY>

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

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

圖片

配額管理

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

圖片

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

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

多模型訪問

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

對于公司 IDC 自建的模型服務而言，我們繼續(xù)沿用基于 discovery 等服務發(fā)現(xiàn)技術(shù)來發(fā)現(xiàn)推理引擎節(jié)點，直接將請求包裝調(diào)度至這些自建模型。

模型負載均衡

LLM API 的負載均衡和傳統(tǒng)實時 API 的模式有很大的不同。傳統(tǒng) API 開發(fā)中，一次請求往往被設計成會極大概率地命中一塊結(jié)果緩存，且緩存 Key 的計算都比較簡單，因此很多負載均衡都簡單基于請求相應時間、連接數(shù)等等。在 LLM 推理場景下，每個推理請求都會帶來網(wǎng)關(guān)本身難以評估的計算時間和設備資源占用，此時基于 RPS、TTFB、連接數(shù)等負載均衡策略將不再適用。

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

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

多租戶隔離

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

可觀測能力

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

3.API 業(yè)務場景與應用對接

在 AI 網(wǎng)關(guān)中，我們主要以 OpenAI 提供的 API 作為基礎協(xié)議，讓開發(fā)者基于 OpenAI SDK 實現(xiàn)各種業(yè)務場景對接。目前支持的 API 協(xié)議有：對話式模型交互（CHAT_COMPLETION）、通用文本向量接口（EMBEDDING）、提示詞模板（CHAT_TEMPLATE）和 模型上下文協(xié)議（MODEL_CONTEXT_PROTOCOL） ，業(yè)務可以根據(jù)自己不同的場景進行選擇對應的協(xié)議。

圖片

1）對話式模型交互（CHAT_COMPLETION）

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

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

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

2）通用文本向量（EMBEDDING）

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

3）提示詞模板（CHAT_TEMPLATE）

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

同時我們也支持內(nèi)嵌函數(shù)，以方便在提示詞模板進行處理內(nèi)容：

• len(v any) string
• jsonify(v any) string
• make_json_object(v ...any) map[string]any
• 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: |
        你的任務：以下給定文本是一個B站視頻的相關(guān)文本信息，可能為標題、簡介、彈幕或評論，請你將給定的文本逐條翻譯成英文。輸入為一個json格式，key為序號，value為待翻譯的彈幕，一共有{{ len .reply_list }}個文本。示例如下:
        輸入: {"1": "xxx", "2": "xxx"}


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


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

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

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

4）模型上下文協(xié)議（MODEL_CONTEXT_PROTOCOL）

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

圖片

配置轉(zhuǎn)發(fā)到注冊中心的 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'

配置通過業(yè)務 API 進行轉(zhuǎn)發(fā)換 MCP 服務：

- path: /logging-mcp/*
  protocol: HTTP
  timeout: 300s
  middlewares:
  - name: v1_mcp_server
    options:
      '@type': type.googleapis.com/infra.gateway.middleware.llm.v1.contrib.MCPServerConfig
      apiOrchestrator:
        server:
          name: logging-mcp
        tools:
        - name: query-logs
          description: 通過 AppID 獲取相應環(huán)境的服務日志信息
          args:
          - name: env
            description: 應用部署環(huán)境
            type: string
            default_value: "uat"
            position: query
          - name: appid
            description: 應用名稱，也稱為AppID
            type: string
            required: true
            position: query
          - name: level
            description: 查詢?nèi)罩镜牡燃?            enum_values:
            - DEBUG
            - INFO
            - WARN
            - ERROR
            type: string
            required: true
            position: query
          - name: keyword
            description: 查詢?nèi)罩镜年P(guān)鍵字
            type: string
            required: true
            position: query
          request_template:
            upstream:
              url: http://api.exmaple.com/logging/query?env={{ .env }}&appid={{ .appid }}&level={{ .level }}&keyword={{ .keyword }}
            method: GET
          response_template:
            body: '{{ . }}'

4.企業(yè) MCP 市場與 API 接入

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

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

圖片

當前的 MCP 協(xié)議中主要有兩個端點：

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

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

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

5.總結(jié)

AI 網(wǎng)關(guān)通過統(tǒng)一接入、鑒權(quán)、配額管理 和 模型調(diào)度支持，為大模型提供了高效、安全、定制的連接能力。同時，支持了 OpenAI 協(xié)議、提示詞模板 和 MCP 市場等功能，進一步擴展了 AI 技術(shù)在企業(yè)中的應用場景，為業(yè)務接入和資源整合提供了極高的便利性。