企业如何统一使用 AI？用 LiteLLM 管理多部门、模型权限与费用

企业统一使用 AI，可以由 IT 团队部署 LiteLLM 作为内部网关，按部门和应用发放独立密钥，再通过 Crazyrouter 接入模型 API。这样，业务团队共用一套上游接入体系，企业仍能分别管理谁可以调用、能用哪些模型、允许花多少，以及费用归谁承担。¹²

Crazyrouter 是多模型 API 接入服务，可作为 LiteLLM 的上游，并导出模型与价格配置；本文核验了 4 个模型的配置导出。LiteLLM 负责企业内部的团队、密钥和预算策略。

这篇文章从一个常见场景展开：研发、市场和客服都开始使用 AI，公司希望统一采购和结算，同时保留部门权限与费用边界。

企业使用 AI，为什么会卡在账户、权限和费用管理上？#

试用阶段，一个人申请 Key，接上模型，能返回答案就算成功。

等到市场部批量生成文案、研发团队接入编程工具、客服系统开始自动总结工单，同一套做法就会暴露问题：某个脚本突然消耗大量额度，但没人说得清它属于哪个项目；员工离职了，公司不知道他是否还保存着可用密钥；某个部门只需要做文本分类，却能调用所有高成本模型。

企业需要把这些问题变成明确的管理动作。

LiteLLM 的虚拟密钥、团队预算和用量记录为这些管理动作提供基础；具体权限策略需要在企业部署中配置并验收。¹³⁴

一个 API Key，如何服务多个部门和多个模型？#

“一个 Key 接入多个模型”适合描述上游接入方式。落实到企业内部，还需要给不同调用方分发独立凭据。

建议采用下面的结构：

图中各部门调用企业自己的 LiteLLM 地址。上游 Key 由网关保管，业务应用使用 LiteLLM 签发的虚拟 Key。

三类密钥分别交给谁？#

研发的代码助手、市场的内容工作流、客服的工单机器人各有自己的 Key。某个应用需要停用时，可以处理对应凭据；上游配置变化则由平台团队集中维护。¹²

统一账户不等于所有人共用同一把密钥。 对大型企业，还可以按生产与测试环境、事业部或风险等级拆分上游凭据。共用上游账户能简化结算，也意味着账户余额、配额或故障可能影响多个部门，需要在容量与可用性设计中考虑。

先设计部门、账户和应用，再发 Key#

假设一家企业先让三个部门试点，下表可以作为配置讨论稿。预算为演示数值，不是套餐价格或使用量建议。

部门适合映射为 LiteLLM 的 Team；应用通常使用归属明确的服务凭据；需要个人归属时，再建立对应用户与成员关系。¹³

命名也应让人看懂。例如 marketing-copy-prod 表示市场文案生产应用，support-summary-test 表示客服摘要测试应用。每个 Key 记录负责人、用途、环境和复查时间，避免半年后留下几十把无人认领的密钥。

普通员工是否需要登录 LiteLLM？#

不一定。LiteLLM 主要承担网关与管理功能。普通员工可以在企业已有的聊天入口、知识库助手、办公自动化工具或业务系统里使用 AI，应用后端再调用 LiteLLM。

企业应分别设计两条链路：

• 员工使用链路：员工登录业务应用，应用检查身份和数据权限，再调用 AI。
• 平台管理链路：获授权的管理员管理模型、成员、Key、预算和报表。

如果所有员工请求都由同一个应用 Key 发起，网关首先识别到的是这个应用。要进一步统计到个人，需要应用后端传递经过验证的用户标识，并确认网关版本、功能与报表支持情况。不要把用户能自行填写的 user 或部门标签当作权限凭证。⁴

企业 AI 权限，至少要分成三层#

第一层：谁能管理账户和预算？#

建议平台管理员维护模型连接与全局配置，部门负责人处理本部门申请和预算，财务查看获授权的费用报表，普通成员使用分配的应用或凭据。

这是企业角色设计，不代表安装 LiteLLM 后上述分工会自动生效。SSO、SCIM、组织与团队管理员、审计日志等能力有版本和许可要求。核验时，LiteLLM 官方定价页将多项高级治理能力列在 Enterprise 中；SSO 文档另有小规模用户例外，应结合企业人数与采购方案逐项核对。⁵⁶

第二层：谁能调用哪些模型？#

模型授权应从具体任务出发。客服摘要只需要经过该业务评估的模型；研发需要代码工具调用，就验收对应能力后再开放；某个新模型先给试点项目使用，通过评估后再扩展。

在 LiteLLM 中，应用调用的是注册后的 model_name。设置团队、虚拟 Key 的模型范围时，要使用对应名称，并检查实际生效规则。¹

如果使用路由或 fallback，候选模型也要满足原任务的数据、能力和成本要求。允许调用一个业务别名，不应该意味着该别名可以被随意改到未经批准的模型。

第三层：谁能读取哪些企业数据？#

模型白名单控制“能调用什么模型”，业务系统还需要控制“能把什么数据交给模型”。

客服人员能使用摘要模型，并不意味着可以读取所有客户合同；员工能访问企业知识库助手，也不意味着能搜索其他部门的薪资资料。数据访问应在业务系统、检索层和工具执行层依据员工身份执行，不能只靠提示词要求模型遵守权限。

网关自托管也不等于推理完全留在企业内网。使用本文架构时，请求会经过企业 LiteLLM，再到 Crazyrouter 及实际模型服务链路。敏感数据是否适合发送，需要结合具体服务约定、数据分类和企业审批要求决定。

部门预算、应用限额和限流应该怎样配合？#

可以把控制措施理解为三个不同问题：

LiteLLM 官方文档提供团队、虚拟 Key 等预算及限流配置；预算依赖数据库中的用量信息。生产实施应配置 PostgreSQL 持久化，不能把一个无数据库代理当作已完成的预算系统。³

还要关注几个会影响结果的细节：

1. Key 必须归属正确的团队。 同一部门有多个应用 Key，应确认它们实际计入同一个 Team。
2. 不要假设所有层级限制都会叠加。 团队 Key、个人预算、团队成员预算的适用规则有区别，应按部署版本验证。³
3. 预算周期要与财务口径对齐。 budget_duration、多窗口预算、重置时间可能有不同语义；核对实际 budget_reset_at 和时区，不要仅看到 30d 就认为与财务自然月完全一致。
4. 告警和拒绝请求是两种行为。 80% 提醒、100% 暂停等规则可以作为管理设计，但必须配置对应功能，并测试通知与阻断。
5. 并发下要验证边界。 在途请求、成本预估、价格同步和多实例状态都会影响预算控制；不要承诺设置一个金额后就绝对不会多出一分钱。³⁴

对客户服务这类关键业务，预算告警还应有明确负责人和追加审批流程，避免系统停用后才发现无人处理。

如何按部门、项目和模型统计 AI 费用？#

企业月报至少应该回答：哪个部门用了多少、主要用在哪个应用、调用了哪些模型，以及这些调用带来了什么业务结果。

建议从下面的报表字段开始：

LiteLLM 可以记录 Key、用户和团队的费用，并提供调用日志；标签分析、报表和高级访问控制的可用范围应按版本与许可核对。业务采纳率等指标仍需要企业应用自己记录，再与调用信息关联。⁴⁵

能看到 token，为什么费用仍可能不准确？#

因为 token 数和金额之间还隔着一套价格规则。

输入、输出、缓存读取、缓存写入可能有不同价格；长上下文或不同时段可能使用不同档位；账户分组和折扣也可能影响实际结算。自定义模型如果没有正确价格信息，网关里的费用可能缺失、为零或偏离上游账单。²⁴⁷

因此，本方案接入时应同时导入模型连接和 model_info 价格信息。只拿到 /v1/models 列表，还没有完成费用统计配置。²

LiteLLM 统计和 Crazyrouter 账单分别用来做什么？#

LiteLLM 的费用数据用于内部归属、预算和趋势分析；Crazyrouter 的实际扣费记录用于上游结算核对。

价格快照更新延迟、特殊计费项、舍入、重试与时间边界等因素可能造成差异，不能默认两个系统逐笔金额永远相等。²

建议保留日期、时区、模型、用量、应用请求 ID 和可获得的上游请求 ID，先核对每日汇总，再排查差异较大的请求。如果多个应用共用一把上游 Key，而双方记录又无法逐笔关联，就不能宣称已经实现精确的应用级结算分摊。

用 LiteLLM 接入 api.crazyrouter.com 的实施步骤#

1. 确定模型与业务范围#

先从两个部门、两三个应用开始，准备实际业务样例，分别验收答案质量、必要功能、延迟和成本。

平台团队可以先查看 Crazyrouter 模型目录，再结合 模型 API 价格对比确定候选。需要 Claude 或 DeepSeek 时，可分别查看 Claude 系列说明与 DeepSeek 系列说明，最后以自己凭据返回的模型列表和业务实测为准。

2. 准备专用上游 Key，导出模型与价格配置#

OpenAI 兼容接入使用的 Base URL 为：

https://api.crazyrouter.com/v1

服务端先安全设置 CRAZYROUTER_API_KEY。下面的 Python 示例从本站获取四个模型的配置，只保存响应中的 config，并检查没有把真实密钥写入文件。依赖 requests，在新目录运行，已存在同名文件时会停止覆盖。²

import json
import os
from pathlib import Path
import requests

api_key = os.environ["CRAZYROUTER_API_KEY"]
response = requests.get(
    "https://api.crazyrouter.com/v1/litellm/config",
    headers={"Authorization": f"Bearer {api_key}"},
    params={
        "provider": "openai",
        "models": "claude-opus-5-5,gpt-6-astra,glm-5.3,deepseek-v4.1-flash",
    },
    timeout=30,
    allow_redirects=False,
)
if response.status_code != 200:
    raise SystemExit(f"Config export failed: HTTP {response.status_code}")

config = response.json()["config"]
if not config.get("model_list"):
    raise SystemExit("No models exported")

config.setdefault("general_settings", {})["master_key"] = (
    "os.environ/LITELLM_MASTER_KEY"
)
config["general_settings"]["database_url"] = "os.environ/DATABASE_URL"
output = json.dumps(config, ensure_ascii=False, indent=2)
if api_key in output:
    raise SystemExit("Refusing to write an API key into the config")

with Path("crazyrouter.config.json").open("x", encoding="utf-8") as file:
    file.write(output + "\n")
print("Saved config; review, import and reload LiteLLM explicitly.")

本次核验已确认上述四模型导出接口返回有效配置。企业部署还需要向 LiteLLM 进程或容器注入 CRAZYROUTER_API_KEY、LITELLM_MASTER_KEY 和真实 DATABASE_URL，完成数据库、认证及网络配置后显式加载配置。完整安装与验证流程见 Crazyrouter 的 LiteLLM 接入指南。

导出的 openai/<model> 表示 LiteLLM 使用 OpenAI 兼容适配器，不代表这些模型都来自 OpenAI。需要 Claude 原生协议时，应按指南单独导出对应配置，不能随意混用 API 路径。²

3. 建部门、发应用 Key，再接业务系统#

在带数据库的 LiteLLM 中，为试点部门建立 Team，再给应用创建归属于该团队的虚拟 Key，设置允许的模型、预算和速率限制。¹³

业务系统最终需要的连接信息可以整理成下面的交付单。这是配置示意，其中企业域名必须替换为实际部署地址：

内部 API 地址：https://ai-gateway.example.com/v1
业务调用密钥：该应用专用的 LiteLLM Virtual Key
允许模型：对应 Key 已授权的 model_name
费用归属：该 Key 绑定的 Team
负责人：应用维护人及部门预算负责人

企业应用使用内部网关地址；LiteLLM 的上游配置使用 https://api.crazyrouter.com/v1。各工具的具体字段和协议要求可以参考 接入指南目录，再验证它是否能够通过本企业网关调用。

4. 把权限拒绝和预算耗尽也纳入验收#

完成配置后，建议至少测试以下场景：

预算和吊销测试应使用专门的测试对象。生产上线前还要验证多实例状态、数据库备份与恢复，以及敏感日志的访问和保留规则。

本方案实际核验了哪些内容？#

2026 年 10 月 27 日，我们使用 https://api.crazyrouter.com 完成了模型列表、配置导出和一次直连推理核验。

本次直连请求为：

{
  "model": "glm-5.3",
  "messages": [{"role": "user", "content": "Reply with exactly OK."}],
  "max_tokens": 512
}

请求端点为 POST /v1/chat/completions，request ID 为 e6d9b321143a4367e53c9e697fa25f1a。返回输入 17 token、输出 56 token、合计 73 token；输出用量包含 54 个推理 token。正文虽然只有 OK，输出 token 仍不止两个字符对应的数量，这也是费用分析应读取 usage 的具体例子。

历史 LiteLLM 记录与本次直连检查是两组证据。本文没有将历史兼容性检查写成企业部门预算验收，也没有宣称覆盖全部模型、SSO、并发负载或故障切换。现有 Claude 接入指南还明确列出 json_object、强制工具选择等能力边界，应按实际业务逐项验证。²

企业推广 AI，可以从一张试点清单开始#

第一批业务不必覆盖所有部门。选择输入可控、结果容易评价、负责人明确的任务，例如客服工单摘要、市场文案初稿或研发测试用例生成。

为每个应用写清五件事：谁负责、用什么数据、允许哪些模型、预算多少、如何判断结果有用。把部门 Team、应用 Key 和统计字段同时建好，再让员工开始使用。

一轮试点结束后，用“完成一项任务的成本、结果采纳率、人工复核量和失败原因”决定是否扩大范围。模型调用次数增加，并不自动代表业务效果改善。

准备实施时，可以先创建 Crazyrouter 接入账户，由平台团队保管专用上游凭据，再在 LiteLLM 中建立第一个部门和应用 Key。上线标准应包括：正常调用可用、越权会被拒绝、预算规则生效、费用能够归属。

FAQ#

企业用户如何使用 AI，才能同时管理多个部门？#

让员工通过企业应用使用 AI，由内部网关集中处理调用，再按部门、应用和成员分配权限与费用归属。本文方案使用 LiteLLM 管理团队和虚拟 Key，通过 Crazyrouter 接入上游模型。¹²

一个 Crazyrouter API Key 可以给多个部门使用吗？#

可以由 LiteLLM 在服务端统一使用同一把上游 Key，但各部门和应用应使用独立的 LiteLLM 虚拟 Key。能调用哪些模型，还取决于上游凭据权限和网关自身配置。¹²

LiteLLM 能按部门设置预算吗？#

可以配置团队预算，并给团队下的应用 Key 设置相应限制。需要数据库、正确的团队归属与价格配置，而且应实测预算耗尽后的行为，不能仅凭配置页面认定已经生效。³

LiteLLM 的部门费用统计能直接当财务账单吗？#

应先用于内部归属和预算分析，再与上游实际扣费核对。价格快照、特殊计费项与记录关联方式会影响逐笔一致性，正式分摊前需要明确对账口径。²⁴

员工离职后，停用登录账户就够了吗？#

离职流程还应检查个人 Key、服务凭据和本人能够访问的密钥存储。登录账户与 API 凭据是不同对象，要验证相关 Key 已失效；业务共用凭据则应转移负责人，并按暴露情况决定是否轮换。

LiteLLM 是否可以替代企业知识库或聊天应用？#

在这套架构中，它负责模型网关和调用治理。员工使用界面、知识库检索、文档权限与业务审批仍由对应应用承担；模型权限不能代替业务数据权限。

SSO、审计和部门管理员是否安装后就都有？#

需要核对部署版本与许可。LiteLLM 官方将多项高级治理功能列为 Enterprise 能力，部分 SSO 场景另有小规模例外；采购前按人数、角色分工和审计要求确认。⁵⁶

换模型后，所有业务代码都不用改吗？#

统一接口能减少连接层改动，但不能保证模型行为一致。工具调用、结构化输出、上下文和多模态要求仍要重新验收，再决定是否切换。²

参考资料#

以下文档于 2026 年 10 月 27 日核对；官方在线文档可能继续更新，实施时应同时检查固定部署版本。