LiteLLM Proxy怎么用？从统一模型接口到虚拟密钥与调用日志的入门指南

先分清：SDK不是Proxy

LiteLLM Python SDK是在代码中调用的库；LiteLLM Proxy则是独立运行的HTTP服务。本文使用Proxy：内部演示应用只连接网关地址，通过不同模型别名选择上游服务，无须分别集成两套客户端。

统一接口不代表功能完全一致。工具调用、图片输入、结构化输出和流式字段是否可用，仍取决于上游模型及适配支持。

1. 配置两个模型入口

准备Python环境及两个提供商的有效密钥，安装Proxy依赖：

pip install 'litellm[proxy]'

在启动服务的同一终端设置环境变量。下面的占位值必须替换，管理密钥应使用足够长的随机值，不要提交到代码仓库。

export OPENAI_API_KEY='替换为OpenAI密钥'

export ANTHROPIC_API_KEY='替换为Anthropic密钥'

export LITELLM_MASTER_KEY='sk-替换为高强度随机字符串'

新建config.yaml。以下使用JSON形式表达配置，JSON也是有效的YAML：

{"model_list":[{"model_name":"demo-openai","litellm_params":{"model":"openai/gpt-4o-mini","api_key":"os.environ/OPENAI_API_KEY"}},{"model_name":"demo-anthropic","litellm_params":{"model":"anthropic/claude-sonnet-4-20250514","api_key":"os.environ/ANTHROPIC_API_KEY"}}],"general_settings":{"master_key":"os.environ/LITELLM_MASTER_KEY"}}

• model_name：客户端提交的别名，例如demo-openai。
• litellm_params.model：上游提供商前缀与实际模型标识。请确认账户有权访问；不可用时替换为该提供商当前可用的模型。
• api_key：从服务端环境变量读取上游密钥，不是把密钥字符串写进配置。
• api_base：需要自定义上游接口地址时使用，位置在litellm_params内；本例使用提供商默认地址，因此省略。它与客户端连接的网关地址不是一回事。

启动本机测试服务：

litellm --config config.yaml --host 127.0.0.1 --port 4000

此时客户端接口根地址为http://127.0.0.1:4000/v1。先保持仅本机可访问；开放给其他应用前，再配置网络访问限制与HTTPS。

2. 验证文本和流式响应

先用管理密钥做本机连通性测试：

curl -sS http://127.0.0.1:4000/v1/chat/completions -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H 'Content-Type: application/json' -d '{"model":"demo-openai","messages":[{"role":"user","content":"用一句话介绍模型网关。"}]}'

检查响应中的choices[0].message.content是否返回文本。将model改为demo-anthropic，验证第二个提供商；应用仍使用同一网关地址。

随后测试流式请求：

curl -N http://127.0.0.1:4000/v1/chat/completions -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H 'Content-Type: application/json' -d '{"model":"demo-openai","messages":[{"role":"user","content":"解释虚拟密钥的用途。"}],"stream":true}'

预期看到逐段到达的SSE数据，文本通常位于choices[0].delta.content。若报错，先检查网关返回的状态与错误内容，再核对别名、上游权限和余额；不要只凭客户端异常判断故障来源。

3. 给测试应用分配虚拟密钥

管理密钥用于管理操作，不应放进前端或分发给普通应用。虚拟密钥由网关签发，用于识别调用方；上游密钥继续留在网关服务端。

虚拟密钥管理需要数据库支持。连接PostgreSQL、设置DATABASE_URL，并按所用版本的官方部署说明完成数据库初始化后，重启Proxy，再尝试生成测试密钥：

curl -sS http://127.0.0.1:4000/key/generate -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H 'Content-Type: application/json' -d '{"models":["demo-openai","demo-anthropic"]}'

将返回的key安全保存，替换测试应用请求中的Bearer令牌。它不是OpenAI或Anthropic密钥。若应用已不再使用，应撤销对应虚拟密钥，而不是让多个应用长期共用同一个凭据。

4. 检查调用记录，同时控制敏感信息

单独发起一次成功请求和一次错误别名请求，检查已配置的调用日志或可观测性后端，确认能关联到测试密钥，并记录时间、模型别名、状态、延迟及可获取的token使用量。流式请求的使用量字段可能因上游支持和请求选项而异，不要把缺失值直接当作零。

启动终端里的访问日志不等于完整调用账本。需要持久记录时，应配置相应日志存储，并验证成功、失败请求各自保留了哪些字段。

默认以元数据排障，不保存原始提示词和回复；检查调试输出、回调及外部日志平台是否另行采集正文，并对Authorization、密钥和个人信息做脱敏。高级权限、预算、审计及管理界面的可用范围，应核对官方文档中的部署方式与授权条件，不能默认全部包含在开源部署中。