大模型用得越多,越容易陷入一种混乱状态。
- 这个项目用 OpenAI
- 那个服务接 Dashscope(Qwen)
- 测试环境还跑着本地 vLLM 或 Ollama
- 电脑里配置着一堆 API Key
刚开始问题不大,大家还能靠“记得住”来维持。
但只要项目一多、人数一多,麻烦立刻显现出来:
费用开始失控、模型切换成本极高、权限越来越乱、出了问题也很难排查。
于是,越来越多团队开始引入一个概念:
大模型网关(LLM Gateway)。
在目前的开源方案里,LiteLLM 是非常实用、也非常容易真正落地的一种。
我们按下面这条路线,一步步把它跑起来:
为什么要用 → Docker Compose 部署 → 模型与 Key 管理 → 权限与预算 → 实际调用 → 真实使用场景
一、LiteLLM 是什么?它解决的不是“能不能用”,而是“怎么管”
先说清楚一件事:
LiteLLM 本身不是模型。
它更像是一个统一的大模型代理层,或者你也可以理解为:
所有大模型的 统一入口 + 管理中枢
对外,它暴露的是 OpenAI 兼容 API;
对内,它可以接入各种不同来源的大模型,包括:
- OpenAI / Azure OpenAI
- Anthropic / Gemini / Dashscope
- HuggingFace
- 本地 vLLM、Ollama
- 甚至多家模型同时存在
最终的效果是:
应用侧只需要认一个地址、一个 Virtual Key。
至于后面到底用的是哪家模型、怎么调度、怎么限额,全部交给 LiteLLM 处理。
二、Docker Compose 部署(生产环境强烈推荐)
如果只是本地玩一玩,直接起一个 Docker 容器也可以。
但只要你是长期使用或多人使用,Docker Compose 是最稳妥的方式。
它有几个明显好处:
1️⃣ 准备目录结构
- litellm/
- ├── docker-compose.yml
- └── .env
复制代码 保持简洁,后面所有东西都围绕这两个文件来。
2️⃣ 编写 docker-compose.yml
- services:
- litellm:
- build:
- context: .
- args:
- target: runtime
- image: docker.litellm.ai/berriai/litellm:main-stable
- #########################################
- # Uncomment these lines to start proxy with a config.yaml file #
- # volumes:
- # - ./config.yaml:/app/config.yaml
- # command:
- # - "--config=/app/config.yaml"
- ##############################################
- ports:
- - "4000:4000"
- environment:
- DATABASE_URL: "postgresql://llmproxy:dbpassword9090@db:5432/litellm"
- STORE_MODEL_IN_DB: "True"
- env_file:
- - .env
- depends_on:
- - db
- healthcheck:
- test:
- - CMD-SHELL
- - python3 -c "import urllib.request; urllib.request.urlopen('http://localhost:4000/health/liveliness')"
- interval: 30s
- timeout: 10s
- retries: 3
- start_period: 40s
- db:
- image: postgres:16
- restart: always
- container_name: litellm_db
- environment:
- POSTGRES_DB: litellm
- POSTGRES_USER: llmproxy
- POSTGRES_PASSWORD: dbpassword9090
- ports:
- - "5432:5432"
- volumes:
- - /home/data/litellm/postgres/data:/var/lib/postgresql/data
- healthcheck:
- test: ["CMD-SHELL", "pg_isready -d litellm -U llmproxy"]
- interval: 1s
- timeout: 5s
- retries: 10
复制代码提醒一句:
记得把 db 的 volumes 路径改成您自己机器上的真实路径。
3️⃣ 环境变量 .env
- LITELLM_MASTER_KEY=sk-1234
- STORE_MODEL_IN_DB=True
复制代码 这里的 LITELLM_MASTER_KEY,就是后面登录后台用的密码。
4️⃣ 启动服务
- docker compose -p litellm up -d
复制代码 5️⃣ 访问管理界面
浏览器打开:
- 用户名:admin
- 密码:.env 里配置的 LITELLM_MASTER_KEY
三、如何管理模型?从 Virtual Key 开始
LiteLLM 的核心设计之一,就是用 Virtual Key 来统一管理、隔离使用者和模型资源。
1️⃣ 添加模型(以 Ollama 为例)
在 Models + Endpoints 页面中,选择 Add Model。
2️⃣ 创建 Virtual Key
- Key 的拥有者可以是你自己、某个服务账号,或者具体成员
- 可以绑定一个或多个模型
- 可以设置预算、速率限制
注意:生成的 Key 只显示一次,一定要保存好。
3️⃣ 在线验证是否可用
- 粘贴刚创建的 Virtual Key
- 选择允许使用的模型
- 直接测试请求
四、权限管理(多人协作非常重要)
当开始多人使用时,这一部分非常关键。
创建团队(Team)
用于统一管理成员和资源。
邀请内部用户(Internal User)
访问组(Access Groups)
通过访问组来控制:
谁能用哪些模型、哪些 Key。
预算管理(Budgets)
如果你接的是收费模型,这一步非常有用。
五、可观测性:终于知道钱花哪了
请求消耗统计
请求日志
六、应用如何调用?几乎不用改代码
Python 示例
- from langchain_openai import ChatOpenAI
- llm = ChatOpenAI(
- name="ollama",
- model="qwen3:8b",
- base_url="http://192.168.31.242:4000",
- api_key="sk-Rj-rnKC9lgaohyI7bxKVkg"
- )
- response = llm.invoke("你是谁?")
- print(response)
复制代码 核心只有三点:
- 地址指向 LiteLLM
- Key 使用你创建的 Virtual Key
- 模型名来自你在后台定义的模型
七、真实使用场景
场景一:公司级 AI 中台
- 前端、后端、脚本工具
- 全部只接一个 Gateway
- 模型升级对业务透明
场景二:多项目成本可控
- 每个项目一个 Key
- 超额直接拒绝
- 成本一眼就能看清
场景三:模型策略随时调整
今天 GPT-4
明天 Gemini
后天本地模型
只改配置,不动业务代码。
写在最后
很多人刚接触大模型时,最关心的是效果;
真正用久了才发现,最难的是管理、成本和稳定性。
LiteLLM 并不会让模型变聪明,
但它能让你:
如果你已经不满足“能跑就行”,
那这个网关,确实值得你认真搭一套。
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |