為什么要集中接入？

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

圖片

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

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

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

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

圖片

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

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

當使用了大模型代理

我們先來看看如果把接入管理獨立出來之后，會產生怎樣的變化。

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

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

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

圖片

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

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

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

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

大模型代理示例

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

安裝 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

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

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

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

圖片

這里面的重點是渠道，這對應的就是我們前面提到的服務供應商。我們可以添加新的渠道，這里主要的幾個選項是：

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

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

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

圖片

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

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

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

圖片

在這里我們可以做一些運維類的工作，比如，禁用失效的渠道。還有一個點是優先級，它是用來確定訪問順序的。比如，多個渠道都提供了 gpt-4o-mini 這個模型，我們會訪問優先級高的渠道。

設置了模型之后，我們還需要添加 API Key，也就是這里的令牌。我們可以根據自己的需要設置相應的權限。

圖片

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

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

總結

我們討論了一種需要在架構上做調整的工程實踐：集中接入。在這個實踐中，我們引入了一個大模型代理，將所有與接入有關的復雜度都放到了這個代理上，比如：

它可以解決多賬號的管理，從而解決了大模型服務的限流問題；

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

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

它還可以統一地接口訪問不同的模型；

應用只通過 OpenAI API 訪問統一到接口，將大幅度簡化應用端代碼的編寫，甚至可以讓 LangChain 構建的一些抽象都失效。

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

如果今天的內容你只能記住一件事，那請記住，集中接入將接入的復雜度轉到了大模型代理上，簡化了應用端代碼的編寫。