LiteLLM 自建网关：密钥集中以后，数据库和维护谁来管？

两个应用共用供应商账户，一个做客服，一个做内容生成，月底账单涨了却说不清来自哪里。遇到这个问题，我会认真看看 LiteLLM Proxy：给应用分虚拟密钥，集中记录用量，确实比到处复制供应商密钥更容易管理。[1][2] 但自建之前，还要找出愿意长期维护这个入口的人。

代理能启动，不等于预算已经生效

虚拟密钥的官方设置要求 PostgreSQL 数据库连接和管理密钥。预算文档进一步提醒，预算依赖从数据库读取的花费；无数据库部署不会执行这些预算限制，设置全局 max_budget 也会跳过检查而继续服务。[2][3]

这个数据库条件很值得在动手前看明白。配置文件里出现一个预算数字，不能单独当作它正在限制账单的证据。供应商侧账单也需要另外对照，尤其是还有别的应用直接访问供应商时。

别把管理密钥发给每个应用

master key 是代理管理凭据，可以用于创建其他密钥。[2] 我的建议是让应用拿到自己的受限虚拟密钥，把管理凭据留在管理流程中。这样客服与写作工具的模型范围、用量和撤销动作才有机会分开处理；否则入口虽统一了，权限又混在了一起。

版本也要留记录。快速开始文档明确 LiteLLM 1.84及以上要求 Python 3.10或更高，旧解释器可能让安装落到旧版。[1] 参考教程时同时看代理版本和环境，省得用新文档排查旧服务。

自建的账单里，也有维护人的时间

如果团队已经维护数据库、监控和内部服务，LiteLLM 可以顺着这套流程做评估。先接一个应用，核对正常用量、拒绝行为和恢复方式，再接第二个，比一开始让所有项目都依赖它更容易收尾。

团队已有PostgreSQL、监控与服务维护流程，可以把LiteLLM纳入自建候选；只想接一个模型、没有维护人，则把托管入口一起比较。应用使用受限虚拟密钥，管理凭据留在管理流程，预算还必须有数据库花费记录支持。这里讨论部署条件，尚未实际部署验证拦截或恢复。