为什么要集中接入？
集中接入，就是把大模型的接入统一到一个地方管理起来，下面这张图可以很好地帮我们理解集中接入：
图片
从这个图上，你已经看出来了，所谓的集中接入，其实就是构建了一个代理，我们后面就称它为大模型代理。
到这里，你可能产生这样的疑问：我直接用大模型不好吗？为什么还要在中间加上一层代理呢？
我在前面说过，集中接入是一种架构上的调整，顾名思义，我需要是一个服务，才会有架构调整的说法。如果在本地就可以运行起来的一些程序，确实没有必要在中间加入一层。但在真实的项目中，我们往往是要构建一个服务，这时集中接入的价值就体现出来了。
之所以要有一个中间层，最直接的一个问题就是限流问题。大模型服务本身资源消耗很大，提供大模型服务的供应商为了保证尽可能多的用户享受到正常的服务，所以，它对单用户实施了限流。以 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 还提供了模型重定向能力，它可以在运行时对应用端请求的模型进行修改，实现一些特殊的功能。
如果今天的内容你只能记住一件事，那请记住，集中接入将接入的复杂度转到了大模型代理上，简化了应用端代码的编写。
