1. 为什么单靠一个 API Key 管不住多模型调用如果你手上同时有 OpenAI、Claude、Gemini、通义千问还有本地跑的 Ollama最开始的写法通常是每个项目里塞一堆 SDK 和 Key。项目少的时候还能忍一旦团队里三个人共用一套 Key问题立刻暴露谁在调哪个模型、这个月花了多少、某个 Key 泄露了怎么单独停掉全都说不清。LiteLLM 网关代理解决的正是这件事。它本身不是模型而是一个统一的大模型代理层对外暴露 OpenAI 兼容 API对内可以接各种来源的模型。应用侧只认一个地址、一个 Virtual Key后面用哪家模型、怎么限额、怎么调度全部交给 LiteLLM 处理。这篇就聚焦 LiteLLM 网关代理在多模型统一管理中的落地把 Base URL 指向 TaoToken用 Virtual Key 做团队级额度与权限隔离一次配置完成多模型统一调用与用量追踪。适合谁看正在做 AI 应用后端、需要给多个项目或多个成员分配模型额度的开发者已经用过 OpenAI 兼容 API、想加一层网关但不想改业务代码的人以及想把本地模型和云端模型混在一个入口里管理的团队。我试过最省事的做法就是让业务代码永远只连 LiteLLM 的 4000 端口模型名和 Key 全部在网关侧配置。这样模型升级、换供应商、调预算业务侧一行都不用动。2. TaoToken 前置准备拿到统一 Key 与 Base URLLiteLLM 要接模型得先有一个上游供应商。这里用 TaoToken 作为统一上游它提供 OpenAI 兼容 API一个 Key 就能覆盖多种模型正好和 LiteLLM 的定位对齐。第一步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录。进入控制台后找到 API Keys 页面创建一个新的 Key。这个 Key 就是后面 LiteLLM 配置里的上游凭证格式通常是sk-开头的一串字符。创建时建议按用途命名比如litellm-gateway方便以后区分。第二步确认 Base URL。TaoToken 的 OpenAI 兼容入口是 https://taotoken.net/api 注意这里不加任何查询参数。LiteLLM 在配置上游时需要把api_base指向这个地址而不是默认的 OpenAI 官方地址。第三步确认你要用的模型 ID。在模型对话页面或文档里可以看到当前支持的模型列表比如gpt-4o、claude-3-5-sonnet、deepseek-chat这类名称。记下你打算在 LiteLLM 里暴露的模型 ID后面写进 config.yaml。这里有个容易踩的坑TaoToken 的 Key 是上游凭证LiteLLM 自己还会生成一套 Virtual Key。两者不要混用。上游 Key 只出现在 LiteLLM 的配置或环境变量里业务侧拿到的永远是 LiteLLM 生成的sk-Virtual Key。这样即使业务侧的 Key 泄露你也能在 LiteLLM 后台单独吊销不影响上游账号。如果你还没决定用哪些模型可以先在模型对话里试几个确认响应正常再写进网关配置。接入细节可以参考接入文档里面有完整的参数说明。3. 可复制配置config.yaml 与 Virtual Key 创建这一节是全文的核心所有片段都可以直接复制。先建目录结构mkdir -p litellm cd litellm touch config.yaml .env docker-compose.yml3.1 config.yaml 指向 TaoTokenmodel_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY - model_name: claude-3-5-sonnet litellm_params: model: openai/claude-3-5-sonnet api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY - model_name: deepseek-chat litellm_params: model: openai/deepseek-chat api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY general_settings: master_key: os.environ/LITELLM_MASTER_KEY database_url: os.environ/DATABASE_URL litellm_settings: drop_params: true set_verbose: false关键点说明model_name是业务侧调用的名字可以自定义model字段用openai/前缀表示走 OpenAI 兼容协议api_base统一指向 TaoToken 的 API 地址api_key从环境变量读取避免明文写进文件。drop_params: true能过滤掉部分模型不支持的参数减少报错。3.2 .env 环境变量TAOTOKEN_API_KEYsk-你的TaoToken密钥 LITELLM_MASTER_KEYsk-1234 DATABASE_URLpostgresql://llmproxy:dbpassword9090db:5432/litellm STORE_MODEL_IN_DBTrueLITELLM_MASTER_KEY是登录管理后台的密码也是创建 Virtual Key 的管理凭证务必改掉默认值。DATABASE_URL指向 Postgres用于存储 Key、预算和用量日志。3.3 docker-compose.ymlservices: litellm: image: docker.litellm.ai/berriai/litellm:main-stable ports: - 4000:4000 volumes: - ./config.yaml:/app/config.yaml command: - --config/app/config.yaml environment: DATABASE_URL: postgresql://llmproxy:dbpassword9090db:5432/litellm STORE_MODEL_IN_DB: True env_file: - .env depends_on: - db db: image: postgres:16 restart: always container_name: litellm_db environment: POSTGRES_DB: litellm POSTGRES_USER: llmproxy POSTGRES_PASSWORD: dbpassword9090 ports: - 5432:5432 volumes: - ./postgres/data:/var/lib/postgresql/data把./postgres/data换成你机器上的真实路径。启动docker compose -p litellm up -d3.4 创建 Virtual Key服务起来后用 master key 创建 Virtual Key。下面这条命令创建一个只能调用gpt-4o、预算 10 美元的 Keycurl -X POST http://localhost:4000/key/generate \ -H Authorization: Bearer sk-1234 \ -H Content-Type: application/json \ -d { models: [gpt-4o], max_budget: 10, budget_duration: 30d, key_alias: team-frontend }返回的 JSON 里key字段就是 Virtual Key只显示一次保存好。models控制这个 Key 能用哪些模型max_budget和budget_duration控制额度周期。团队协作时给每个项目或每个人单独建 Key用量就能分开统计。4. 验证请求与成功结果curl 与 Python 实测配置写完必须验证否则很容易出现「网关起来了但调不通」的情况。先测健康检查curl http://localhost:4000/health/liveliness返回Im alive!说明服务正常。接着用 Virtual Key 发一次对话请求curl -X POST http://localhost:4000/v1/chat/completions \ -H Authorization: Bearer sk-你的VirtualKey \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: 用一句话介绍你自己}] }成功时返回标准的 OpenAI 格式 JSONchoices[0].message.content里是模型回复。如果返回 401说明 Virtual Key 不对或没带上如果返回 400 且提示模型不存在检查model字段是否和 config.yaml 里的model_name一致。Python 侧几乎不用改代码只换 base_url 和 keyfrom openai import OpenAI client OpenAI( base_urlhttp://localhost:4000, api_keysk-你的VirtualKey ) resp client.chat.completions.create( modelclaude-3-5-sonnet, messages[{role: user, content: 写一个二分查找}] ) print(resp.choices[0].message.content)LangChain 用户同理把base_url指向 LiteLLM 即可from langchain_openai import ChatOpenAI llm ChatOpenAI( modeldeepseek-chat, base_urlhttp://localhost:4000, api_keysk-你的VirtualKey ) print(llm.invoke(你是谁).content)实测下来只要 config.yaml 里模型配置正确切换模型只需要改model参数业务逻辑完全不动。用量数据会写进 Postgres在管理后台的 Logs 和 Usage 页面能看到每个 Virtual Key 的请求次数和花费。5. 本篇常见错排查401、local proxy failed 与 choices 报错排障部分按真实报错来对照遇到问题先看这里。401 Unauthorized。两种可能一是业务侧用了上游 TaoToken Key 而不是 Virtual Key二是 Virtual Key 被吊销或过期。检查请求头Authorization: Bearer后面的值确认是 LiteLLM 生成的sk-开头 Key。如果确认无误去后台 Keys 页面看这个 Key 的状态和预算是否已耗尽。local proxy failed / connection refused。通常是 LiteLLM 容器没起来或者端口没映射。先docker compose -p litellm ps看容器状态再docker compose -p litellm logs litellm看日志。如果日志里出现数据库连接失败检查DATABASE_URL和 db 服务是否健康。还有一种情况是 config.yaml 路径挂载错了容器里读不到配置日志会提示找不到文件。reading choices / KeyError choices。这个报错一般出现在上游返回了非标准结构时。常见原因是api_base写成了https://taotoken.net/api/带了多余斜杠或者模型 ID 拼错导致上游返回错误对象。把api_base改成不带尾斜杠的https://taotoken.net/api并核对模型 ID。另外drop_params: true能减少一部分参数不兼容导致的异常返回。OAuth / 认证相关报错。如果你在 LiteLLM 里配了 SSO 或 OAuth 登录后台报错通常和回调地址有关。本地调试阶段建议先用 master key 登录不要急着接 OAuth。等网关稳定后再配团队登录。模型能调通但用量不记录。检查STORE_MODEL_IN_DB是否为True以及DATABASE_URL是否可写。用量写入依赖数据库如果数据库没连上请求能过但日志为空。排查顺序建议固定为健康检查 → 容器日志 → Virtual Key 状态 → 上游 Base URL 与模型 ID。按这个顺序走大部分问题五分钟内能定位。6. 把网关用起来从单机到团队的统一入口配置跑通之后真正的价值在于长期使用。给每个项目建一个 Virtual Key绑定它需要的模型和预算业务代码里只保留一个 base_url 和一个 key。模型升级时改 config.yaml 里的model字段重启容器业务侧无感知。某个项目超支直接在后台把对应 Key 的预算调低或停用不影响其他人。对于需要长期编码和 Agent 场景的团队可以了解 Coding Plan把网关和编码工具链串起来。日常验证模型效果用模型对话快速试。接入过程中遇到参数问题接入文档里有完整说明。管理 Key 和查看用量在 API Keys 页面操作即可。一个实用技巧把 Virtual Key 按「环境 项目」命名比如prod-app-a、dev-app-b这样在用量报表里一眼就能看出哪个环境在烧钱。另外定期导出日志做归档Postgres 数据量大了之后查询会变慢提前规划好清理策略。最后提醒一句config.yaml 里的上游 Key 永远走环境变量不要提交到 Git。Virtual Key 只显示一次创建后立刻存进密码管理器。这两条守住网关的安全底线就有了。