几个应用共用模型，LiteLLM 帮你把密钥和用量管起来

客服助手、文案工具、内部检索各连一套模型，看上去只是三个小应用。等到要查用量、换密钥或处理某个模型故障，才发现配置散在几个项目里，同一把上游密钥也被复制了好几次。

LiteLLM 解决的是这类接入管理问题。它既提供 Python SDK，让不同模型来源沿用相近的调用方式，也提供可以自行部署的模型网关，把多个应用的请求集中起来。它不会让模型变聪明，但能让谁在用模型、如何路由、在哪里限制更容易管理。

统一入口，最先省的是接入工作

官方入门展示了同一套 completion() 接口调用不同提供方，网关则让已有客户端指向自己的代理地址。对应用开发者而言，模型连接方式不必散落在每一个业务页面里。

例如，一个中文内容系统既要提取稿件字段，也要做较复杂的文章编辑。这两项任务可以在应用层保留不同的模型配置，却通过同一个网关进入。以后调整某条路线时，修改接入配置，不必让所有业务调用都重新认识另一家服务商的 SDK。

但“接口相近”有边界。工具调用、结构化输出、多模态和特殊参数，仍要看具体模型及提供方支持情况。统一后的请求能发出去，不代表原先依赖的能力会原样保留；切换前应拿真实任务核对结果。

网关里的虚拟密钥，是更值得小团队关注的部分。管理员可以为不同用途发放不同的网关密钥，配置允许的模型、预算和速率等条件；应用通过网关请求，上游凭据由网关集中管理。这项虚拟密钥管理还需要配置 PostgreSQL 数据库与管理员密钥，不是只启动一个无状态转发代理即可。

一个给内部检索用的密钥，与一个给文章编辑用的密钥，便不必天然拥有相同的模型范围。哪个应用产生了调用，也更容易沿密钥回查。这里说的是官方支持的管理机制，不是已经替任何团队配置好的权限方案。

虚拟密钥文档还特别说明了密钥所有者、团队与管理权限之间的关系。权限继承并不是简单的“谁创建就归谁”，管理员创建密钥时也需注意所属用户。实际部署不能只测能否调用，还应测不该允许的模型是否真的被拒绝。

LiteLLM 可以按密钥、用户和团队记录花费，其计算依赖相应模型的价格配置和调用信息。这适合用来发现异常、分摊应用用量，但自定义模型或价格变化时，仍要检查配置；上游服务的正式账单不会被网关报表取代。

重试与备用路线同样需要选择。它们有助于应对部分请求故障，也可能带来额外调用。不要因为接了网关，就承诺应用永不失败或预算绝不会超出预期。

项目核心按 MIT 提供，仓库中的企业目录另有许可说明。自行部署还意味着要维护可用性、日志与凭据，而不是把所有管理责任交给一个开源项目。

如果只有一个人偶尔调用一个模型，直接连接通常更轻。等你真正开始管理几个应用、几种模型和几类使用者时，LiteLLM 才体现出价值：把原本藏在代码里的连接和用量，变成一个可以看清、调整和检查的入口。本文仅核对官方资料，未部署网关或核算实际账单。