1.背景

隨著 AI 技術(shù)快速發(fā)展，業(yè)務(wù)對(duì) AI 能力的渴求日益增長(zhǎng)。當(dāng) AI 服務(wù)面對(duì)處理大規(guī)模請(qǐng)求和高并發(fā)流量時(shí)，AI 網(wǎng)關(guān)從中扮演著至關(guān)重要的角色。AI 服務(wù)通常涉及大量的計(jì)算任務(wù)和設(shè)備資源占用，此時(shí)需要一個(gè) AI 網(wǎng)關(guān)負(fù)責(zé)協(xié)調(diào)這些請(qǐng)求來確保系統(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ù)性。

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

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

圖片

整體架構(gòu)

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，我們?cè)?API Gateway 的基礎(chǔ)上做了一些針對(duì) AI 業(yè)務(wù)接口的特性優(yōu)化，如無緩沖區(qū)的請(qǐng)求代理，支持域名、服務(wù)發(fā)現(xiàn)等混合調(diào)度，AI 超長(zhǎng)響應(yīng)時(shí)間請(qǐng)求的優(yōu)雅退出等功能。

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

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

除此之外控制面也會(huì)提供 OpenAPI 供 AI 模型供給團(tuán)隊(duì)上架模型，新增 API Key 等日常運(yùn)營(yíng)能力。模型提供方可以在上架模型時(shí)支持為模型配置相應(yīng)的 RPM、TPM 上限，并根據(jù)模型的推理引擎選擇相應(yīng)的兼容策略。也可以通過 OpenAPI 為單個(gè) 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)限控制功能，允許為每個(gè) API Key 配置可訪問的模型范圍，以及對(duì)不同模型的設(shè)置不同的配額。

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

圖片

配額管理

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

圖片

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

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

多模型訪問

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

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

模型負(fù)載均衡

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

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

另外基于 Prefix Cache 的節(jié)點(diǎn)選擇同樣會(huì)是一個(gè)相當(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)行管理對(duì)接的接口路由，進(jìn)行配置轉(zhuǎn)發(fā)到指定 Model Provider 服務(wù)。如果需要進(jìn)行多業(yè)務(wù)隔離，只需要通過不同的域名訪問并配置不同的轉(zhuǎn)發(fā)目標(biāo)。

可觀測(cè)能力

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

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

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

圖片

1）對(duì)話式模型交互（CHAT_COMPLETION）

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

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

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

2）通用文本向量（EMBEDDING）

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

3）提示詞模板（CHAT_TEMPLATE）

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

同時(shí)我們也支持內(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

以評(píng)論內(nèi)容翻譯的場(chǎng)景：

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


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


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

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

對(duì)于接入 LLM 的業(yè)務(wù)研發(fā)而言，他可能本身不具備很強(qiáng)的提示詞工程能力；甚至提示詞的優(yōu)化本身也取決于模型的迭代更新。因此對(duì)于解決特定領(lǐng)域的業(yè)務(wù)場(chǎng)景，AI 工程師往往會(huì)基于最優(yōu)模型寫出最精準(zhǔn)的提示詞，通過 AI 網(wǎng)關(guān)的提示詞模版接口發(fā)布。業(yè)務(wù)提交簡(jiǎn)單 JSON KV 對(duì)后，渲染出最有效的完整提示詞，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ù)庫(kù)、API 等。

圖片

配置轉(zhuǎn)發(fā)到注冊(cè)中心的 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)罩镜牡燃?jí)
            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 市場(chǎng)與 API 接入

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

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

圖片

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

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

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

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

5.總結(jié)

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