1.背景

隨著 AI 技術(shù)快速發(fā)展，業(yè)務(wù)對 AI 能力的渴求日益增長。當(dāng) AI 服務(wù)面對處理大規(guī)模請求和高并發(fā)流量時，AI 網(wǎng)關(guān)從中扮演著至關(guān)重要的角色。AI 服務(wù)通常涉及大量的計算任務(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)、配額計費(fèi)、負(fù)載均衡、API 路由等）集中放置在 AI 網(wǎng)關(guān)層，可以降低系統(tǒng)整體復(fù)雜度并提升可維護(hù)性。

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

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

圖片

整體架構(gòu)

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

圖片

實際上 AI 網(wǎng)關(guān)就是衍生于之前微服務(wù)團(tuán)隊的 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)實時下發(fā)至數(shù)據(jù)面節(jié)點。數(shù)據(jù)面節(jié)點識別配置有更新后在運(yùn)行時會動態(tài)切換代理引擎至新的代理邏輯下，并保證老的代理邏輯會處理完當(dāng)下被分配的請求。

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

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

鑒權(quán)認(rèn)證

在鑒權(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ǔ)上我們只需要實現(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ào)度至這些自建模型。

模型負(fù)載均衡

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

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

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

多租戶隔離

業(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)。

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

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

圖片

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

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

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

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

2）通用文本向量（EMBEDDING）

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

3）提示詞模板（CHAT_TEMPLATE）

提示詞模板是一種結(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)容：

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


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


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

提示詞模版接口實際上是基于對話接口的一種高效對接模式。眾所周知，自 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é)果。

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

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'

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

- 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 獲取相應(yīng)環(huán)境的服務(wù)日志信息
          args:
          - name: env
            description: 應(yīng)用部署環(huán)境
            type: string
            default_value: "uat"
            position: query
          - name: appid
            description: 應(yīng)用名稱，也稱為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”，專門用來提供各種服務(wù)和資源的接入入口?？梢宰寴I(yè)務(wù)通過這個平臺輕松獲取、整合、使用這些資源，使業(yè)務(wù)對接更加地簡單。

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

圖片

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

• /sse，是一個 Events 長連接通知協(xié)議，用于實時通知資源信息的變更。
• /message，用于 JSONRPC 通信端點，能夠以 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，因為在 MCP 協(xié)議中，會先連接到 /sse 端點，再返回對應(yīng)的 /message 端點信息，所以請求路徑需要保持跟網(wǎng)關(guān)一致。

5.總結(jié)

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