企业级 AI 底层搭建详解：网关选型、部署与治理

企业级 AI 底层搭建详解：网关选型、部署与治理

前言Agent 基座系列第三篇。前两篇讲的是单兵作战，一个 Agent、一个 MCP Server；这篇开始搭企业底座。起因很实际：团队里用 AI 的人从两三个变成几十个之后，问题全冒出来了——key 不知道在谁手里，账单不知道谁花的，有人离职了 key 还在外飘着。这篇讲我怎么用一套网关把这些问题一起收掉的：选型逻辑、部署过程、治理怎么落地。搭好的这套虚拟 key 体系，也是后面所有 AI 应用的身份地基。—### 一、企业 AI 底层要解决什么问题个人用 AI，一个账号一把梭；企业规模化使用，墙是一堵堵撞上来的。最先撞的是接入散：Claude 用 Anthropic 格式，GPT 用 OpenAI 格式，国产模型各有 SDK，每个应用各自对接一遍。然后是 key 失控：真实凭证散落在个人手里，离职回收靠自觉，泄露了没法定位到人。接着成本开始盲：不知道总花费、不知道谁在花、不知道花在哪，预算审批只能拍脑袋。安全团队也来了：代码和数据的出域路径不受控，一票否决。最后还有可用性：单一渠道限流或故障，全公司一起断粮。这些问题看着各不相同，指向的是同一个答案：在用户和模型之间架一层统一网关。—### 二、架构总览用户侧 治理层 模型渠道──────── ──────── ────────Claude Code / IDE 插件 → → Anthropic API自研应用 / Chat 前端 → LiteLLM 网关 → Azure / Bedrock / Vertex脚本 / 定时任务 → 鉴权·路由·限流·预算·审计 → 国产模型 / 内部模型 ↓ 用量数据库 + 看板 + 告警整套架构里网关是所有流量的唯一入口，虚拟 key 体系是治理的地基；渠道层对接各家模型，同名多渠道做故障切换；用量数据库给每次调用留痕，是成本报表和审计的数据源；看板和告警回答「花多少钱、谁在花」，是预算治理的依据。—### 三、网关选型：候选对比与结论选型时我把主流候选都摆上桌比过一轮：| 方案 | 本质 | 优势 | 短板 | | — | — | — | — ||LiteLLM Proxy| 全功能 LLM 网关 | 虚拟 key、预算、团队、审计、多渠道路由、缓存，治理能力最全 | Python 技术栈，重 ||One API / New API| 轻量渠道网关 | Go 单二进制部署极简，渠道管理清晰 | 预算/团队/精细审计弱一档 ||Sub2API| 订阅账号转 API | 把 Claude Pro/Max 订阅额度转成 API 用，成本极低 | 违反 ToS 有封号风险；无治理能力；稳定性不可控 ||Kong AI / APISIX| API 网关+AI 插件 | 适合已有 Kong 体系的大厂 | 为 AI 场景引入整套 API 网关，过重 ||Portkey / Helicone 等 SaaS| 托管观测/网关 | 零运维 | 数据出境，国内企业基本不可行 |结论是主干用 LiteLLM。企业底座的硬需求是治理——key 生命周期、预算、审计、路由——LiteLLM 是开源方案里这块最完整的，而且 Python 生态方便二次开发。如果团队规模小、只要渠道聚合不需要预算治理，退而选 One API 也行，部署轻得多。Sub2API 要单独说一句。订阅转 API 的成本优势确实诱人，我一开始也动过心，但三个问题绕不过去：违反服务商条款，账号随时可能封禁；没有虚拟 key、预算、审计任何治理能力；通道稳定性依赖订阅账号状态，没法运营。所以它只配做非核心流量的补充渠道——测试、个人尝鲜可以走它，主干流量必须走正规 API 渠道。主干上出事，影响的是全公司。—### 四、实战：LiteLLM 网关搭建部署就一条 Docker 命令：bashdocker run -d --name litellm \ -p 4000:4000 \ -v $(pwd)/config.yaml:/app/config.yaml \ -e DATABASE_URL=postgres://... \ -e LITELLM_MASTER_KEY=sk-master-xxx \ ghcr.io/berriai/litellm:main-stable \ --config /app/config.yaml --port 4000master key 是网关的管理员凭证，只放环境变量或密管系统，绝不写进配置文件、不进代码库。渠道配置这样做故障切换：yaml# config.yamlmodel_list: - model_name: claude-opus # 对外统一暴露名 litellm_params: model: anthropic/claude-opus-5-5 api_key: os.environ/ANTHROPIC_KEY - model_name: claude-opus # 同名第二条 = 自动故障切换 litellm_params: model: azure/claude-opus # 主渠道挂了自动切 Azure api_key: os.environ/AZURE_KEY - model_name: default # 日常默认：便宜模型 litellm_params: model: anthropic/claude-haiku-4-5 api_key: os.environ/ANTHROPIC_KEYlitellm_settings: drop_params: true # 客户端参数差异自动兼容 num_retries: 2 request_timeout: 120general_settings: master_key: os.environ/LITELLM_MASTER_KEY database_url: os.environ/DATABASE_URL应用侧全部指向网关的 OpenAI 兼容端点（http://网关:4000），用暴露名调用——换模型、换渠道，应用零改动。然后是整套体系里最关键的一步，虚拟 key。给张三发一把 key：bashcurl -X POST http://gw:4000/key/generate \ -H "Authorization: Bearer $LITELLM_MASTER_KEY" \ -H "Content-Type: application/json" \ -d '{ "key_alias": "zhangsan-dev", "max_budget": 100, "models": ["default", "claude-opus"], "rpm_limit": 60 }'四个字段各有分工：key_alias是身份主键，用量统计、离职回收全靠它反查到人；max_budget是个人预算；models限定可用模型——普通用户只给便宜模型，贵模型按申请开；rpm_limit挡异常高频调用。—### 五、治理能力落地key 生命周期要挂进人事流程。入职流程里加一步「发 key」（alias 用工号或姓名拼音），离职流程里加一步「吊销 key」。真实凭证只在网关侧，人员变动从此没有回收死角。虚拟 key 建议季度性全量轮换一次。预算我分了档。个人软预算超限只告警不切断——先观察是重度使用还是滥用；团队预算做部门分摊依据；全局熔断是防失控的最后防线。硬切断要慎用：一刀切断正在跑的 Agent 任务，用户的信任掉得比成本快，这笔账不划算。用量看板直接从 LiteLLM 的spend表出，按key_alias聚合出总成本趋势、按人和团队的排行、按模型的分布三张报表。这里有个统计口径的坑我踩过：人数统计必须按 key_alias 去重，直接数 key 条数或数请求数，得到的活跃度都是失真的。高可用靠前面配置里示意的同名多渠道 fallback，加上渠道健康检查；规模再大就上多实例加 Redis。网关是全公司 AI 的单点，它的可用性 SLA 要按核心系统对待，不是随便跑个容器就完事。—### 六、安全合规数据不出域是自建方案的根子。所有请求经过自己控制的服务器，代码和提示词不经过第三方 SaaS——这是自建相对托管产品的根本优势，也是安全团队最关心的一条。网关日志的敏感度容易被忽略：日志里会有提示词正文，而提示词里可能是公司代码。要明确三件事——保留多久、谁能查、是否脱敏落库。我的默认策略是用量与路由信息全量落库，请求正文默认不落，排查问题时临时开启并限时关闭。凭证收敛是最后一块。全公司真实模型凭证只存在于网关配置或密管系统一处，凭证泄露的爆炸半径从「全公司」收敛到「单个虚拟 key」，而且可以秒级吊销。—### 七、踩坑清单版本要锁死。LiteLLM 迭代很快，追最新版容易踩配置格式变更，锁main-stable，升级走灰度。alias 不规范，统计全盘失真。key_alias 随手填（test、123、空值），月底按人出报表就对不上号了。发 key 走流程化工具，alias 格式强制校验，这条越早立越好。上游限流会雪崩。高峰期上游 429，没配 retry 加 fallback 的话全公司同时报错。num_retries和同名多渠道是必配项，不是可选项。用量数据库是隐形单点。预算、审计、报表全押在这套库上，它挂了网关跟着降级。备份和高可用要和网关本身同等对待。最后一条不算坑，算提醒：只搭基建不发场景，是这类项目最常见的死法。网关搭好只是开始，接入文档、示例代码、场景示范都要跟上。基建的价值以「多少人稳定地在用」计，不以「搭了多完善」计。—### 参考资料-LiteLLM Proxy 文档- LiteLLM Virtual Keys- One API- 本系列第一篇：《从零手写 Agent 基座》