為什么要集中接入？

集中接入，就是把大模型的接入統(tǒng)一到一個(gè)地方管理起來，下面這張圖可以很好地幫我們理解集中接入：

圖片

從這個(gè)圖上，你已經(jīng)看出來了，所謂的集中接入，其實(shí)就是構(gòu)建了一個(gè)代理，我們后面就稱它為大模型代理。

到這里，你可能產(chǎn)生這樣的疑問：我直接用大模型不好嗎？為什么還要在中間加上一層代理呢？

我在前面說過，集中接入是一種架構(gòu)上的調(diào)整，顧名思義，我需要是一個(gè)服務(wù)，才會(huì)有架構(gòu)調(diào)整的說法。如果在本地就可以運(yùn)行起來的一些程序，確實(shí)沒有必要在中間加入一層。但在真實(shí)的項(xiàng)目中，我們往往是要構(gòu)建一個(gè)服務(wù)，這時(shí)集中接入的價(jià)值就體現(xiàn)出來了。

之所以要有一個(gè)中間層，最直接的一個(gè)問題就是限流問題。大模型服務(wù)本身資源消耗很大，提供大模型服務(wù)的供應(yīng)商為了保證盡可能多的用戶享受到正常的服務(wù)，所以，它對(duì)單用戶實(shí)施了限流。以 OpenAI API 為例，下面就是它的限流標(biāo)準(zhǔn)，其中 RPM 是 requests per minute（每分鐘請(qǐng)求數(shù)），TPM 是 tokens per minute（每分鐘 Token 數(shù)）。

圖片

如果我們是一個(gè)人或是規(guī)模比較小的服務(wù)，這個(gè)限流標(biāo)準(zhǔn)大概是夠用的，但如果我們要對(duì)外提供服務(wù)，這個(gè)標(biāo)準(zhǔn)大概率是不夠用的。解決這個(gè)問題最簡(jiǎn)單的辦法就是多申請(qǐng)一些賬號(hào)，形成一個(gè)號(hào)池，這樣限流標(biāo)準(zhǔn)對(duì)我們來說就大幅度提高了，但隨之而來的一個(gè)問題就是如何管理號(hào)池。

稍微仔細(xì)想一下，你就會(huì)發(fā)現(xiàn)，實(shí)現(xiàn)一個(gè)還不錯(cuò)的號(hào)池管理還是比較麻煩的。比如，按什么方式在不同的賬號(hào)之間進(jìn)行選擇，怎樣管理失效的賬號(hào)等等。真的要實(shí)現(xiàn)好一個(gè)號(hào)池，就等于實(shí)現(xiàn)了一個(gè)完整的運(yùn)維工具，可是，你的應(yīng)用目標(biāo)是做一個(gè) AI 應(yīng)用。與其自己實(shí)現(xiàn)這么一套完整的功能，還不如用已有的工具來完成這個(gè)目標(biāo)。是的，已經(jīng)有一些現(xiàn)成的工具可以完成這個(gè)目標(biāo)。

當(dāng)使用了大模型代理

我們先來看看如果把接入管理獨(dú)立出來之后，會(huì)產(chǎn)生怎樣的變化。

首先肯定是解決了多賬號(hào)管理的問題。所有的賬號(hào)都配置在這個(gè)代理上，而對(duì)于我們自己的應(yīng)用而言，只配置一個(gè)賬號(hào)就好。這個(gè)大模型代理通常會(huì)采用 OpenAI 兼容的 API，也就是說，你完全可以用 OpenAI API 的使用方式使用它，一般來說，我們只要替換一下 API_BASE 和 API_KEY，而其它的代碼可以完全保持不變。這也是我們代理能夠平滑接入的原因。

有了大模型代理之后，我們還可以有一些其它的變化。一個(gè)典型的應(yīng)用場(chǎng)景就是接入不同的供應(yīng)商。雖然我們一直在講 OpenAI API，但由于眾所周知的原因，我們并不能直接訪問 OpenAI API。

一個(gè)常見的解決辦法是，通過一些供應(yīng)商來進(jìn)行訪問。一般來說，我們并不會(huì)依賴于一家供應(yīng)商，所以，配置多個(gè)供應(yīng)商也是很常見的。有了大模型代理之后，這些復(fù)雜性就從我們的應(yīng)用中剝離出去了。

圖片

不同的供應(yīng)商上提供的 API 可能會(huì)有所差異。比如，微軟的 Azure 也提供了 OpenAI 的服務(wù)，但接口略有差異。如果是自己的代碼，我們就需要自己管理這種差異。有了大模型代理，我們就可以把這種復(fù)雜性交給代理，而讓我們的代碼采用統(tǒng)一的接口進(jìn)行訪問。

前面討論的還都是 OpenAI 的模型。既然有了大模型代理，我們完全可以再進(jìn)一步，通過它訪問不同的模型。事實(shí)上，很多供應(yīng)商就提供了類似的能力，比如 OpenRouter 就提供了許多不同模型的訪問能力，而它們都是基于 OpenAI 兼容接口的。通過大模型代理，我們也可以訪問不同的大模型。

不僅僅是使用別人的服務(wù)，我們甚至可以訪問自己本地部署的大模型。后面我們講到本地部署大模型時(shí)，我們會(huì)談到如何利用大模型代理訪問本地大模型。

總之，有了大模型代理之后，各種接入問題的復(fù)雜度就完全交給它了。在應(yīng)用端來看，接入就完全簡(jiǎn)化成一個(gè) OpenAI 的接入接口。這也是我們前面重點(diǎn)介紹 OpenAI API 接口的原因。另外，我們前面說過，LangChain 在一些場(chǎng)景下是不適用的，其中的一個(gè)原因就是它提供的一些抽象在某些情況下是失效的。有了大模型代理，LangChain 提供的模型抽象就顯得沒有必要了。

大模型代理示例

能夠提供大模型代理的工具有很多，下面我以 One-API 為例介紹一下基本的用法。One-API 就是一個(gè)典型的大模型代理，它提供了以 OpenAI API 接口訪問各種大模型的能力。我們常見的一些大模型在 One-API 中都得到了支持，比如，GPT、Claude、文心一言、通義千問等等。它在行業(yè)內(nèi)得到了很廣泛地使用，所以，它在能力上也得到了很多擴(kuò)展，比如，計(jì)費(fèi)管理、渠道管理等等。

安裝 One-API 最簡(jiǎn)單的方式是使用 Docker，比如：

docker run --name one-api -d --restart always -p 3000:3000 -e SQL_DSN="root:123456@tcp(localhost:3306)/oneapi" -e TZ=Asia/Shanghai -v /home/ubuntu/data/one-api:/data justsong/one-api

在實(shí)際使用中，我們會(huì)根據(jù)自己的實(shí)際情況修改數(shù)據(jù)庫配置（SQL_DSN），如果配置了 SQL_DSN，One-API 會(huì)使用 MySQL 作為數(shù)據(jù)庫。此外需要調(diào)整的配置就是映射目錄，這個(gè)目錄里存放的是數(shù)據(jù)和日志：

-v /home/ubuntu/data/one-api:/data

啟動(dòng)之后，訪問對(duì)應(yīng)的地址，比如，在本地啟動(dòng)就是訪問 http://localhost:3000/，你就會(huì)看到它的界面。要想看到更多的配置項(xiàng)，需要進(jìn)行登錄。

圖片

這里面的重點(diǎn)是渠道，這對(duì)應(yīng)的就是我們前面提到的服務(wù)供應(yīng)商。我們可以添加新的渠道，這里主要的幾個(gè)選項(xiàng)是：

類型：它決定了在轉(zhuǎn)發(fā)過程中采用什么 API 接入到后端的模型上，比如，OpenAI 就會(huì)采用 OpenAI API。

模型：這個(gè)渠道支持的模型，比如，gpt-4o-mini。每個(gè)渠道可以配置很多的模型。

連接信息：接入地址（代理）和 API Key（密鑰），如果是同一個(gè)供應(yīng)商的多個(gè)賬號(hào)，可以采用批量創(chuàng)建的方式，輸入多個(gè) API Key。

圖片

在這個(gè)配置里，有一個(gè)比較有意思的配置是模型重定向，就是把一個(gè)模型名稱轉(zhuǎn)換成另外一個(gè)模型的名稱。一種典型的用法是，把一個(gè)比較昂貴的模型用另外一個(gè)便宜的模型代替。比如，早期的 GPT-4 價(jià)格是很高的，而后期的 GPT-4o 價(jià)格就要便宜不少，而且性能會(huì)更強(qiáng)大。我們就可以在這里做一個(gè)映射，讓應(yīng)用請(qǐng)求過來的 GPT 4，而真正請(qǐng)求到后端都是 GPT-4o。

還有一種用法是，給模型起一個(gè)新名稱。這樣一來，我們的應(yīng)用提供給用戶的是一個(gè)自定義的名稱，請(qǐng)求到代理上之后，再轉(zhuǎn)成真正的模型發(fā)出去，以此屏蔽掉后端真正的模型。我們?cè)诓簧賾?yīng)用上見到的所謂自己的模型，都可以這么實(shí)現(xiàn)出來。

如果配置了多個(gè)渠道之后，我們可以在渠道列表看到后面截圖里的選項(xiàng)。

圖片

在這里我們可以做一些運(yùn)維類的工作，比如，禁用失效的渠道。還有一個(gè)點(diǎn)是優(yōu)先級(jí)，它是用來確定訪問順序的。比如，多個(gè)渠道都提供了 gpt-4o-mini 這個(gè)模型，我們會(huì)訪問優(yōu)先級(jí)高的渠道。

設(shè)置了模型之后，我們還需要添加 API Key，也就是這里的令牌。我們可以根據(jù)自己的需要設(shè)置相應(yīng)的權(quán)限。

圖片

具體的 API Key 是自動(dòng)生成的。我們創(chuàng)建好令牌之后，可以在令牌列表中找到。只要在這里復(fù)制就可以得到所需的 API Key 了。

后面的操作我們都很熟悉了，就是把 One API 的訪問地址和 API Key 配置到我們的代碼里，和平時(shí)使用 OpenAI API 是一樣的。

總結(jié)

我們討論了一種需要在架構(gòu)上做調(diào)整的工程實(shí)踐：集中接入。在這個(gè)實(shí)踐中，我們引入了一個(gè)大模型代理，將所有與接入有關(guān)的復(fù)雜度都放到了這個(gè)代理上，比如：

它可以解決多賬號(hào)的管理，從而解決了大模型服務(wù)的限流問題；

通過多供應(yīng)商的管理，我們就不必依賴于某家特定的供應(yīng)商；

大模型代理可以屏蔽不同的供應(yīng)商之間的差異；

它還可以統(tǒng)一地接口訪問不同的模型；

應(yīng)用只通過 OpenAI API 訪問統(tǒng)一到接口，將大幅度簡(jiǎn)化應(yīng)用端代碼的編寫，甚至可以讓 LangChain 構(gòu)建的一些抽象都失效。

我們以 One API 為例介紹了大模型代理的設(shè)置過程，主要就是渠道和令牌的管理。除了大模型代理的基本功能，One API 還提供了模型重定向能力，它可以在運(yùn)行時(shí)對(duì)應(yīng)用端請(qǐng)求的模型進(jìn)行修改，實(shí)現(xiàn)一些特殊的功能。

如果今天的內(nèi)容你只能記住一件事，那請(qǐng)記住，集中接入將接入的復(fù)雜度轉(zhuǎn)到了大模型代理上，簡(jiǎn)化了應(yīng)用端代碼的編寫。