文章目录
本节内容介绍
在本节中,我们一起来使用one-api来模拟openai,给应用提供对应的sk;并尝试使用各种方式来使用本地的大模型,尤其是最近deepseek爆火,你更需要学习使用ollama上面提供的多个deepseek模型了
集中接入:将大模型统一管理起来
集中接入,就是把大模型的接入统一到一个地方管理起来,下面这张图可以很好地帮我们理解集中接入:
从这个图上,你已经看出来了,所谓的集中接入,其实就是构建了一个代理,我们后面就称它为大模型代理。
到这里,你可能产生这样的疑问:我直接用大模型不好吗?为什么还要在中间加上一层代理呢?
集中接入是一种架构上的调整,顾名思义,我需要是一个服务,才会有架构调整的说法。如果只是像前面几讲,如果在本地就可以运行起来的一些程序,确实没有必要在中间加入一层。但在真实的项目中,我们往往是要构建一个服务,这时集中接入的价值就体现出来了。
之所以要有一个中间层,最直接的一个问题就是限流问题。大模型服务本身资源消耗很大,提供大模型服务的供应商为了保证尽可能多的用户享受到正常的服务,所以,它对单用户实施了限流。以 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:123456741852q@+@tcp(101.42.44.178:2881)/oneapi" -e TZ=Asia/Shanghai -v /home/zeng/soft/data/one-api:/data justsong/one-api
在实际使用中,我们会根据自己的实际情况修改数据库配置(SQL_DSN),如果配置了 SQL_DSN,One-API 会使用 MySQL 作为数据库。此外需要调整的配置就是映射目录,这个目录里存放的是数据和日志:
-v /home/zeng/soft/data/one-api:/data
启动之后,访问对应的地址,比如,在本地启动就是访问 http://localhost:3000/,你就会看到它的界面。要想看到更多的配置项,需要进行登录。
这里面的重点是渠道,这对应的就是我们前面提到的服务供应商。我们可以添加新的渠道(使用root/123456登录后才可配置渠道),这里主要的几个选项是:
- 类型:它决定了在转发过程中采用什么 API