集中接入：將大模型統(tǒng)一管理起來，你覺得怎么樣？

作者：greencoatman 2024-12-27 08:27:27

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

為什么要集中接入？

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

圖片

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

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

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

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

圖片

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

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

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

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

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

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

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

圖片

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

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

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

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

大模型代理示例

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

安裝 One-API 最簡單的方式是使用 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í)際使用中，我們會根據(jù)自己的實(shí)際情況修改數(shù)據(jù)庫配置（SQL_DSN），如果配置了 SQL_DSN，One-API 會使用 MySQL 作為數(shù)據(jù)庫。此外需要調(diào)整的配置就是映射目錄，這個目錄里存放的是數(shù)據(jù)和日志：

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

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

圖片

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

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

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

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

圖片

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

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

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

圖片