其团队治理是开源网关里文档最全的：Organization / Team / Internal User / Virtual Key 四层，spend 同时归属 key、user、team、org，任一层超预算即拦截；Virtual Key 可带 models、max_budget + budget_duration、rpm_limit、tpm_limit、soft_budget（软预算告警）与 metadata 归属。对 LIN 专栏的价值是提供一套“预算要分层、告警要前置”的治理模板。
适用场景：团队在 LIN 的 Sub2API 站点上抱怨“额度要么不够用、要么月底爆表”，需要重构额度制度时。
LiteLLM 对照系统 Virtual Keys 团队预算 RBAC
操作步骤
- 按 LiteLLM 的分层思路列本团队的四层预算：总池 → 分组/项目 → 成员 → 单 Key。
- 在 Sub2API 里用已有机制逐层落地：总池看上游账号与站点余额，项目/人群用分组，成员用 user 余额/订阅，单 Key 用窗口/限流（条目 7-9）。
- 告警前置：LiteLLM 用 soft_budget + Slack/webhook 在烧穿前告警；Sub2API 侧若无等价告警，就用条目 16 的监控工具 + 定期导账人工补位，并把这个缺口如实写进专栏。
- Key 命名与 metadata 归属规范先行，否则分层预算无处落。
配置说明
LiteLLM 事实来源：官方 RBAC 文档（层级与拦截规则）、官方 Alerting 文档（soft_budget 与 spend report 配置）、仓库 https://github.com/BerriAI/litellm.git 。其 Organization 层与审计日志中的部分能力属 Enterprise，不要写成开源版标配。
注意事项
- ⚠️ 照搬 LiteLLM 的 API 字段（
/key/generate的参数）到 Sub2API 文里——两套 API 完全不同。 - ⚠️ 只设硬上限不设软告警：成员在关键时刻被硬停，体验事故比超支更伤团队信任。