用同一套 OpenAI 接口调通 100 大模型LiteLLM AI Gateway 快速上手指南【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm你的服务同时调用 OpenAI、Bedrock 和 Anthropic 时要维护三套 SDK、请求格式和错误码换一次模型就改一次代码。LiteLLM 是一个开源 AI Gateway用一套 OpenAI 格式的接口调通 100 多个 LLM附带成本跟踪、负载均衡和防护栏guardrails适合个人 Python 开发者和需要集中管理模型访问的团队。下面从安装、跑通第一次调用讲到生产部署。它是什么一个接口接通 100 LLMLiteLLM 有两种形态Python SDK 直接嵌进你的代码代理服务器AI Gateway则自托管成为团队统一的模型入口两者共用同一套路由和成本核算逻辑。它做的事很集中你的代码面向 OpenAI 协议编写切换 Anthropic、Bedrock、Gemini 或自部署的 vLLM 时只需改model字段。代理侧再补上虚拟密钥、预算、限流和管理界面团队成员不需要各自持有上游密钥。项目用 Rust 核心实现官方基准在 1000 RPS 下 P95 延迟为 8ms。快速上手安装与首次运行 SDK 安装一行完成uv add litellm当前版本为 1.100.0用pip install litellm同样可以。第一次调用只需 6 行代码from litellm import completion response completion( modelopenai/gpt-4o, messages[{role: user, content: 打个招呼}], ) print(response.choices[0].message.content)代理的安装和启动也只要两条命令服务监听 4000 端口uv tool install litellm[proxy] litellm --model gpt-4o之后现有的 OpenAI 客户端不用改结构只换base_urlimport openai client openai.OpenAI(api_keyanything, base_urlhttp://0.0.0.0:4000) client.chat.completions.create(modelgpt-4o, messages[{role: user, content: hi}])三个高频使用场景多厂商模型在同一代码里统一调用任务是产品同时用 GPT 和 Claude代码里不能出现 if/else 分支。关键做法是模型名加厂商前缀同一个completion函数通吃completion(modelanthropic/claude-sonnet-4-20250514, messagesmessages)注意各厂商支持的参数并不一致建议在配置里开启drop_paramsLiteLLM 会自动丢弃目标模型不支持的参数而不是直接报错。接入自部署的 vLLM 或 Ollama 模型任务是团队已有本地推理服务希望流量走同一个网关。关键做法是使用custom_openai前缀并指定api_basecompletion( modelcustom_openai/llama-3.1-8b, api_basehttp://localhost:8000/v1, messages[{role: user, content: hi}], )注意自部署模型不在 LiteLLM 的内置价格表里需要成本核算时在model_list对应条目手动填写input_cost_per_token和output_cost_per_token。用代理管理密钥与花费任务是团队共享上游密钥同时想知道每个成员各花了多少钱。关键做法是在 config.yaml 里声明model_list并配置 master key 后给每个成员发放虚拟密钥model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY general_settings: master_key: sk-1234注意os.environ/前缀表示从环境变量读取密钥不要把上游密钥明文写进 yaml。走向生产部署、观测与成本 生产部署直接用仓库自带的 docker-compose.yml内置 PostgreSQL 数据库并通过/health/liveliness做容器健康检查。多实例场景在router_settings里选用 usage-based-routing-v2 这类路由策略配合 Redis 共享限流与花费状态即可横向扩展。观测挂在litellm_settings的 callback 上prometheus导出指标供 Grafana 使用langfuse等 tracing 回调则能按调用查看延迟、token 数和成本。成本侧有三个抓手用max_budget和budget_duration给整体支出设上限给虚拟密钥配置单项预算和 rpm/tpm 限流开启响应缓存让完全相同的第二次请求不再计费。三者叠加价格表后你可以按天回答哪个密钥在哪个模型上花了多少钱。避坑清单与延伸阅读配置文件里的密钥一律用os.environ/从环境变量读取避免明文入库。非流式与流式超时是两个参数request_timeout与stream_timeout只设一个会在长流式请求上出怪问题。本地 OpenAI 兼容端点要用custom_openai加api_base否则请求不会按预期路由。大批量放开流量前先用代理的/health端点确认每个上游模型可达。PDF 等文本提取的实现位于 litellm/rag/ingestion/含 pdf_parser 与多种云端 ingestion 实现。一份完整的代理配置样例见 proxy_server_config.yaml覆盖回调、预算与透传路由。SDK 侧装完即可用团队服务从单实例代理加预算限流起步最稳。下一步建议本地 docker compose 起一套代理建两个虚拟密钥把一天的真实流量从网关打过去再把花费报表和上游账单对一遍差异会告诉你该收紧哪条限流。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考