LiteLLM/One-Api 统一各种大模型接口通过OpenAi格式访问

1、背景

在我们调用其他大模型如Ollama,Gemini,OpenAi,Qwen等等,他们返回的格式都不太一样,这样每次接入这些接口相对都比较麻烦进行格式调整,LiteLLM统一了这些Api调用方式,通过配置,对应厂商的Api接口,都可以通过OpenAi接口的格式进行调用。

2、安装LiteLLM

GitHub - BerriAI/litellm: Python SDK, Proxy Server to call 100+ LLM APIs using the OpenAI format - [Bedrock, Azure, OpenAI, VertexAI, Cohere, Anthropic, Sagemaker, HuggingFace, Replicate, Groq]

项目可以直接提供了docker-compose一键部署

2、完成部署

打开链接http://localhost:4000/ui/?userID=admin

密码是环境变量设置的key账号是admin,进入页面添加一个开源的模型或者是其他厂商提供的模型

我这里添加了qwen2:72b

3、调用接口

直接调用标准的OpenAi接口就可以调用qwen2大模型了,模型的名称要跟你命名模型一致

curl -X POST "http://localhost:4000/v1/chat/completions" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer sk-1234" \
     -d '{
       "model": "qwen2:72b",
       "messages": [{"role": "user", "content": "你好,请介绍一下自己"}]
     }'

点击模型库也提供了具体的调用方式,可以说是非常方便调用以及使用

4、One-Api

这个开源项目是国内人开发的,可以整合国内的大模型。功能跟LiteLLM是类似的

GitHub - songquanpeng/one-api: OpenAI 接口管理 & 分发系统,支持 Azure、Anthropic Claude、Google PaLM 2 & Gemini、智谱 ChatGLM、百度文心一言、讯飞星火认知、阿里通义千问、360 智脑以及腾讯混元,可用于二次分发管理 key,仅单可执行文件,已打包好 Docker 镜像,一键部署,开箱即用. OpenAI key management & redistribution system, using a single API for all LLMs, and features an English UI.

可以通过docker一键安装

# 使用 SQLite 的部署命令:
docker run --name one-api -d --restart always -p 3000:3000 -e TZ=Asia/Shanghai -v /home/ubuntu/data/one-api:/data justsong/one-api
# 使用 MySQL 的部署命令,在上面的基础上添加 `-e SQL_DSN="root:123456@tcp(localhost:3306)/oneapi"`,请自行修改数据库连接参数,不清楚如何修改请参见下面环境变量一节。
# 例如:
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
docker run --name new-api -d --restart always -p 13022:3000 -v /data01/llm/one-api/data:/data -e TZ=Asia/Shanghai -e RELAY_PROXY=http://10.11.0.166:18080 one-api:latest

5、配置模型

打开页面后点击渠道添加模型

设置令牌就可以通过接口访问了

6、接口访问

接下来就可以把令牌复制下来设置好模型就可以通过接口访问了

curl -X POST "http://10.10.40.102:13000/v1/chat/completions" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer sk-8ztvXnUrPRucaOyiEe2c7dB4Cb6d40E0834c2d3f51207c6d" \
     -d '{
       "model": "deepseek-chat",
       "messages": [{"role": "user", "content": "你是谁"}]
     }'

7、new-api功能相同

查看官方部署方式页面,相比于one-api页面更加美观。功能也更加丰富

https://github.com/Calcium-Ion/new-api

docker logs docker-api-1 Running migrations 2025-03-08 03:22:24.919 INFO [MainThread] [utils.py:162] - NumExpr defaulting to 16 threads. /app/api/.venv/lib/python3.12/site-packages/opik/evaluation/metrics/heuristics/regex_match.py:8: SyntaxWarning: invalid escape sequence '\d' """ 2025-03-08 03:22:31.355 INFO [MainThread] [_client.py:1038] - HTTP Request: GET https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json "HTTP/1.1 200 OK" Preparing database migration... Database migration skipped [2025-03-08 03:22:38 +0000] [1] [INFO] Starting gunicorn 23.0.0 [2025-03-08 03:22:38 +0000] [1] [INFO] Listening at: http://0.0.0.0:5001 (1) [2025-03-08 03:22:38 +0000] [1] [INFO] Using worker: gevent [2025-03-08 03:22:38 +0000] [44] [INFO] Booting worker with pid: 44 2025-03-08 03:22:41.069 INFO [MainThread] [utils.py:162] - NumExpr defaulting to 16 threads. 2025-03-08 03:22:44.031 INFO [MainThread] [_client.py:1038] - HTTP Request: GET https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json "HTTP/1.1 200 OK" 2025-03-08 03:23:34.125 ERROR [Dummy-1] [app.py:875] - Exception on /console/api/setup [GET] Traceback (most recent call last): File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context self.dialect.do_execute( File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 941, in do_execute cursor.execute(statement, parameters) psycopg2.errors.UndefinedTable: relation "dify_setups" does not exist LINE 2: FROM dify_setups ^ The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request rv = self.dispatch_request() ^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request return
最新发布
03-09
<think>好的,我现在需要帮助用户解决在Docker容器中启动Flask应用时,SQLAlchemy报错“relation 'dify_setups' does not exist”的问题。这个问题看起来像是数据库迁移或初始化的问题,但需要仔细分析可能的原因和解决方案。 首先,用户提到参考了引用[1],其中提到Dify在Docker启动时遇到类似的问题。虽然具体应用不同,但数据库迁移失败导致表不存在的情况可能有共同的原因。我需要根据这些线索来推断可能的问题点。 第一步,我应该考虑数据库迁移是否成功执行。当使用SQLAlchemy时,通常需要运行flask db upgrade来应用迁移。但在Docker环境中,可能存在启动顺序的问题,比如应用容器在数据库容器完全准备好之前就尝试连接,导致迁移失败。这时候可能需要检查Docker Compose文件中的依赖设置,确保应用容器在数据库容器健康之后再启动。例如,在docker-compose.yml中使用depends_on和healthcheck来管理启动顺序。 第二步,检查数据库连接配置是否正确。如果应用的配置文件中数据库的URL、用户名、密码或主机名有误,SQLAlchemy就无法连接到正确的数据库,导致迁移失败。用户需要确认环境变量或配置文件中的数据库信息是否准确,特别是当使用Docker网络时,主机名可能不是localhost,而是数据库容器的服务名。 第三步,确认迁移脚本是否正确生成。如果用户手动修改了模型但没有生成迁移脚本,或者生成的脚本有错误,那么应用迁移时就会失败。这时候需要运行flask db migrate来生成新的迁移脚本,并检查脚本中的内容是否正确。 第四步,检查权限问题。数据库用户是否有权限创建表或修改数据库结构?有时候即使连接成功,权限不足也会导致表无法创建。用户需要确保数据库用户拥有足够的权限,比如CREATE、ALTER等。 第五步,查看应用启动时的初始化流程。是否在应用启动时自动执行了迁移命令?有些项目会在启动脚本中加入flask db upgrade,以确保每次启动时数据库都是最新的。如果用户的项目没有这样做,可能需要修改Dockerfile或启动脚本,添加迁移命令。 另外,还要考虑缓存或旧数据的影响。比如,如果之前有失败的迁移尝试,可能会导致数据库处于不一致的状态,这时候可能需要手动清理或重置数据库,再重新运行迁移。 还有可能的问题包括数据库扩展未安装,例如PostgreSQL的某些扩展需要在迁移前启用,或者模型定义与迁移脚本不一致。这时候需要仔细检查错误日志,看是否有更详细的报错信息,帮助定位问题。 总结可能的解决步骤: 1. 确保数据库容器已正确启动,并且应用容器等待数据库就绪。 2. 检查数据库连接配置是否正确。 3. 生成并应用最新的数据库迁移。 4. 验证数据库用户的权限。 5. 在Docker启动流程中加入自动迁移命令。 6. 清理旧的数据库数据并重新初始化。 用户可能需要按照这些步骤逐一排查,找到具体导致表不存在的原因。尤其是在Docker环境中,网络和依赖管理容易出现问题,需要仔细检查配置和日志。</think>### Docker容器中Flask应用启动时SQLAlchemy报错“relation 'dify_setups' does not exist”的解决方案 此问题通常由数据库迁移未正确执行或初始化流程异常导致。以下是逐步排查与解决方法: --- #### **1. 确认数据库迁移是否执行** - **问题原因**:若未运行数据库迁移命令,SQLAlchemy无法自动创建表结构。 - **解决方法**: 1. 在Docker容器启动时,手动执行迁移命令: ```bash docker-compose exec <app_service_name> flask db upgrade ``` 2. 或在Dockerfile或启动脚本中集成迁移命令(推荐): ```dockerfile CMD ["flask", "db", "upgrade", "&&", "flask", "run", "--host=0.0.0.0"] ``` 3. 若使用`docker-compose.yml`,添加健康检查与依赖控制: ```yaml services: app: depends_on: db: condition: service_healthy db: healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 5s retries: 5 ``` --- #### **2. 检查数据库连接配置** - **问题原因**:数据库URL、用户名或权限错误,导致迁移失败[^1]。 - **解决方法**: 1. 确认`SQLALCHEMY_DATABASE_URI`格式正确,例如: ```python postgresql://user:password@db:5432/database # "db"为数据库容器服务名 ``` 2. 验证数据库用户权限: ```sql GRANT ALL PRIVILEGES ON DATABASE database TO user; ``` --- #### **3. 手动初始化数据库** - **问题原因**:首次启动时未初始化数据库。 - **解决方法**: 1. 进入数据库容器创建数据库: ```bash docker-compose exec db psql -U postgres -c "CREATE DATABASE database;" ``` 2. 重新运行迁移命令: ```bash docker-compose exec app flask db upgrade ``` --- #### **4. 检查模型定义与迁移脚本** - **问题原因**:模型定义与迁移脚本不一致,导致表未生成。 - **解决方法**: 1. 重新生成迁移脚本: ```bash flask db migrate -m "initialize dify_setups table" ``` 2. 检查生成的迁移文件是否包含目标表的定义。 --- #### **5. 清理缓存或旧数据** - **问题原因**:残留的旧数据导致迁移冲突。 - **解决方法**: 1. 删除数据库并重建: ```bash docker-compose down -v # 清除数据卷 docker-compose up ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值