如何通过LiteLLM网关统一调度管理我的海量大模型？

大模型用得越多，越容易陷入一种混乱状态。 这个项目用 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️⃣ 访问管理界面 浏览器打开： http://localhost:4000 用户名：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 并不会让模型变聪明， 但它能让你： 用得更稳 管得更清楚 换得更从容 如果你已经不满足“能跑就行”， 那这个网关，确实值得你认真搭一套。