企业官网建设流程全解析

做过应用接入大模型这摊事的人，多半都被同一批问题磨过：模型供应商各有各的接口格式，切换模型要动业务代码，某个厂商突然限流超时，排查起来想摔键盘。前两年我们接了三四个模型之后，调用逻辑已经膨胀到没人敢随手改，当时我就意识到，必须有一个统一的接入层把所有模型请求收口。对比了一圈方案之后，我们选了 litellm，把它作为全公司所有模型请求的唯一入口，这个问题才算真正根治。

litellm 本质上是一个大模型接入网关：对上层业务暴露统一调用接口，对下层兼容多家主流供应商协议；中间帮你承担路由转发、负载均衡、成本统计、密钥管理这些脏活累活。最讨喜的一点是它足够轻，既可以作为独立服务部署，也可以当作一个 Python 包直接塞进现有项目，不用改变太多架构。这篇文章不会复述官方文档，而是把我们自己从选型、部署、上线，到排坑调优的完整过程写出来，包括配置示例、参数取舍和实际踩过的坑，希望对正在选型或已经入坑的朋友有所启发。

1. litellm 到底解决了什么：统一接入与痛点梳理

1.1 多模型接入时代，最让人头疼的几个场景

先说一个很常见的场景：你所在的项目要支持几家不同模型供应商的模型，A 家的接口字段和 B 家不完全一样，C 家还要求走完全不同的鉴权方式。最粗暴的做法是在业务代码里写一大堆 if-else，根据模型名分发到不同客户端。这套逻辑刚写的时候挺爽，等到新增一个供应商、或者某个供应商升级了 SDK 之后，你就会发现：

• 每次模型版本升级，都要排查原有 SDK 的兼容性。
• 不同供应商的错误码、限流策略、超时行为完全不一致，业务侧被各种异常细节污染。
• 想给某个项目单独算成本，只能靠人工记账，月底对账对到怀疑人生。
• 一个供应商限流了，没有自动切流的能力，用户直接看到白屏或报错。
• 密钥散落在各个应用的配置里，运维和安全审计很被动。

我们当时的真实感受是，模型本身的调用逻辑占不了多少代码量，真正耗时间的全是这些“外围琐事”。业务团队不应该反复去处理不同供应商的协议细节，这些事应该收敛到一个平台上统一解决。如果把大模型接入比作水电煤，业务方只关心“开水龙头出水”，不关心背后的供水管道是哪家修的。litellm 就是那个统一的水表箱。

1.2 litellm 的职责范围：做什么、不做什么

litellm 的核心能力可以归纳成四块：统一接口、统一路由、统一观测、统一治理。

统一接口是指它对外提供一套符合主流聊天补全接口规范的服务，业务侧只需要按照这一套标准方式调用，底层模型是哪个供应商、哪个版本，全部由配置决定。统一路由是我个人最看重的能力，它可以把一个抽象模型名映射到多个供应商的实际模型上，实现负载均衡与故障回退，比如“内部聊天主力模型”这个名字后面挂三个厂商的模型，某个厂商掉线时，请求自动转到下一个可用的。统一观测指的是 token 消耗、请求延迟、错误分布等数据都会汇总到网关层，方便做成本分析和链路排查。统一治理则涵盖了 API 密钥管理、按团队/项目配额、访问控制、模型能力开关等操作。

但它不是什么都能干。litellm 不是模型训练框架，它不碰模型本身的训练和微调流程；也不是业务编排引擎，像 agent 的多步推理、工具调用循环这类业务逻辑还是放在自己的应用层实现。还有一个容易踩的误区是，它不适合替代你的私有化模型管理平台，如果你有自建的推理集群，litellm 可以帮你统一暴露出去的接口，但集群本身的调度、显存管理并不需要也没必要交给它。

1.3 哪些技术团队适合引入 litellm

从我们自己在不同项目里的使用体验来看，下面几类情况非常适合引入 litellm：

第一类是业务中接入了多个供应商模型，并且切换频繁的团队。今天用 A 厂商的大参数模型，明天想换成 B 厂商的同级别模型，有这个网关在，只需要调整配置，业务代码一行都不用动。

第二类是有成本核算和租户隔离诉求的团队。不管是内部多个项目共享一套模型接口，还是要对客户按调用量计费，litellm 内置的按 tag、用户、项目的统计能力会省掉大量开发时间。

第三类是单模型并发压力大，需要做负载均衡和故障容灾的团队。如果一个模型服务扛不住流量或者经常超时，可以通过网关把流量分摊到多个实例或多个供应商，降低单点故障风险。

第四类是希望保留自主可控迁移能力的团队。今天用厂商 X，明天想换厂商 Y，或者想从云端模型迁到私有化部署，只要底层接口符合统一规范，切换代价就极小。

当然，如果你的场景非常单一，比如只用某一个供应商且完全没有多模型需求，那引入 litellm 是有点重了，直接用官方 SDK 反而更直接。工具没有好坏，匹配需求才关键。

2. 为什么最终选 litellm：与自研方案的对比复盘

2.1 自研一套模型接入层，成本到底藏在哪里

在决定引入 litellm 之前，我们认真评估过自研一套统一接入层。表面上看，不就是封装一层 HTTP 转发再加个路由嘛，似乎工作量不大。但真正梳理需求之后，我们发现隐性成本相当客观。

首先是供应商 SDK 的持续跟进。模型服务商的接口调整、鉴权方式变化、新模型上线，都需要一次次适配，这意味着每一项改动都要投入开发和测试资源。其次是错误语义的归一化，不同供应商的错误码长得完全不一样，有的返回 429，有的返回 500 却带着限流信息，有的超时了但请求实际上已经在服务端生效，这种“模糊地带”处理不好，轻则浪费钱，重则重复执行非幂等业务。接着是密钥管理，自研方案很容易把供应商密钥散落在各应用的环境变量里，轮换密钥的时候想死。最后是观测与计费，token 统计、成本分摊、调用链路追踪，这些如果都要从零开始搭，工程量和维护成本远超想象。

我们列过一个粗略评估：自研最小可用版本至少要几周时间，达到抗限流、有统计、有权限管理这些基本要求要按季度计，之后还要有人持续维护。相比之下，litellm 把绝大多数这些能力直接内置了，我们只需要聚焦在业务配置上。

2.2 轻量方案与重量级框架的取舍

在选型对比阶段，我们也看过一些更重的模型编排类框架。这类框架通常自带 agent、记忆、工具调用等能力，功能更丰富，但也带来了几个问题。

第一是心智负担更大，它一旦绑定你的应用架构，后续想绕开它会很别扭。第二是定制灵活性反而下降，业务逻辑被框架约定束缚，很多内部特殊需求实现起来事倍功半。第三是升级风险，这类框架迭代速度快，接口变动频繁，长期维护成本高。

litellm 的定位明显更收敛，它更像一个“智能交换机”而不是“应用操作系统”。它管的是怎么把请求安全可靠地送到合适的模型那里，至于业务怎么用这个请求，那是你自己的事。这种边界感让我们决定以 litellm 作为接入底座，在它之上再用自己的代码编排业务流程。下面用一张表整理了几类方案的差异：

最终我们选了 litellm，理由很务实：它能覆盖我们 80% 的共性需求，剩下 20% 的定制逻辑完全可以在它外面自己写。这个边缘非常清晰。

2.3 我们采用的部署形态：库模式与网关模式并行

litellm 有两种主要使用形态，我们最终是并行使用的。

一种是库模式，直接把 litellm 当 Python 包装进应用里，在代码里调用litellm.completion()这种函数。这种模式的优点是极轻量，适合对延迟敏感、并且不想多一跳网络转发的场景，模型路由逻辑跑在应用进程内。另一种是网关模式，独立部署一个 litellm 服务，统一暴露模型 API 入口，各业务通过 HTTP 调用它。这种模式的优点是可以集中治理密钥、做全局限流、按租户统计成本，并且业务层完全不需要感知底层 litellm 依赖。

我们内部的做法是，非核心但需要管理的业务统一走网关；个别对延迟极其敏感、并且没有多租户诉求的脚本任务，直接用库模式嵌入，省去网络开销。双模式并存并不冲突，litellm 仓库里也明确支持这种混合用法，只要注意环境变量的统一管理就行。

2.4 数据安全与私有化部署的注意事项

引入任何一个中间件，都要先过一遍数据安全这一关。litellm 本身只是一层请求转发和路由层，prompt 和模型返回内容在一次请求生命周期里会经过它，因此你需要确认：请求体是否需要加密或专属网络传输；日志里是否包含脱敏后的数据，prompt 内容能不能被记录进访问日志；以及密钥如何安全保存。

我们内部的做法是，网关部署在专有网络内部，只有内网服务可以访问；对外一律不直接暴露网关端口。prompt 内容默认不写日志，只记录请求长度、token 数等元数据。如果需要 debug，临时开启详细模式，但会加访问权限控制。供应商密钥统一存放在密钥管理系统的环境变量里，litellm 配置里只引用环境变量的名字，不写明文。还有一个容易被忽略的细节：私有化部署时，要确认 litellm 不会默认向外部上报任何遥测数据。这类配置项在首次安装后要手动核对一遍。

3. litellm 安装与核心配置速通

3.1 两步完成安装，跑通第一个模型调用

安装 litellm 其实很简单，Python 环境要求 3.8 以上，直接通过 pip 安装即可：

pip install litellm

装完之后，最简单的模型调用是这样的：

import litellm response = litellm.completion( model="vendor-a/chat-large", messages=[ {"role": "user", "content": "你好，介绍一下你自己"} ] ) print(response.choices[0].message.content)

这里vendor-a/chat-large是我们给某个供应商模型起的逻辑名称。litellm 内置了大量模型厂商的适配器，只要你配置了对应的密钥环境变量，它就能把这种统一的调用方式翻译成对方服务认识的格式。跑通这一步之后，你会立刻体会到统一接入口的爽感：换模型只需要改model参数，请求结构完全不变。

不过要注意，这里我用的示例模型名是占位符，实际使用时需要替换成 litellm 支持的具体模型标识，并确认对应的密钥环境变量已配置。每个供应商的 key 名不太一样，文档里的环境变量表就是干这个用的。

3.2 模型映射与模型组：配置文件的“骨架”

当你只有一两个模型时，直接在代码里传模型名是没问题的。一旦模型多了，或者需要故障切换和负载均衡，就必须用配置文件来统一管理。litellm 的核心配置文件是 YAML 格式，里面最关键的概念有两个：模型映射和模型组。

模型映射解决的是“逻辑名如何对应到实际供应商模型”的问题。举个例子，业务方希望永远不要改代码，只通过“chat-main”这个名字访问对话模型。那么在配置里，你可以把chat-main映射到多个供应商的实际模型上，litellm 会在这些实际模型之间做负载均衡。

模型组则是把具备相同或相似能力的模型归为一组，litellm 在内部对组内成员做健康检查、优先级排序和故障切换。你可以把“内部对话主力模型”“快速轻量模型”“长上下文模型”分别设置为不同的组，各个业务按自己的需求选用不同的组。

配置文件里还有一个重要的字段是model_info，你可以给每个模型标注是否支持函数调用、是否支持视觉输入、最大上下文长度是多少等元数据。这些元数据会在请求进来时参与能力校验，避免请求发给一个根本不支持 tools 的模型，白浪费一次调用。

3.3 网关模式启动：从命令行到 Docker 容器

配置文件准备好了之后，启动网关模式非常直接。先准备好config.yaml，然后这样跑：

litellm --config /path/to/config.yaml --port 8080

生产环境我们更推荐用 Docker 方式部署，用 Compose 管理会比较省心：

services: llm-gateway: image: your-registry/llm-gateway:v1 ports: - "8080:8080" volumes: - ./config.yaml:/app/config.yaml environment: - LITELLM_MASTER_KEY=your_master_key - DATABASE_URL=postgres://user:pass@pg-host:5432/llm_gateway command: ["--config", "/app/config.yaml", "--port", "8080"]

启动后，业务方就可以直接通过http://llm-gateway:8080/chat/completions这类标准接口调用模型了。为什么生产环境要配数据库？因为 litellm 要持久化请求日志、成本统计和密钥数据，默认的 SQLite 在单机小流量下能用，但多实例部署或需要长期查询时，建议换成 PostgreSQL。这里我们内部用的是 PostgreSQL，主要考虑到团队已经比较熟悉，并且并发和备份方案都成熟。

3.4 密钥管理：环境变量、租户隔离与最小化权限

密钥管理是网关配置里最容易偷懒又最危险的一环。litellm 支持把各供应商的密钥写到环境变量里，由网关统一使用，这样业务应用就不需要持有任何上游密钥了。这是一个非常大的安全红利：即使某业务应用被打穿，攻击者拿到的也只是 litellm 网关颁发的临时令牌，而不是能直接调用模型的长期密钥。

我们内部的做法是这样：供应商原始密钥只在网关环境变量里存在，业务应用统一使用 litellm 网关签发的虚拟密钥。每个虚拟密钥可以绑定指定的模型组、设置每分钟请求数上限、总额度限制、过期时间，还可以关联到某个项目或团队。哪个 key 泄漏了，直接单点吊销，其他业务完全不受影响。这比自研方案里到处塞环境变量的做法强太多。

租户隔离也是靠这套 key 体系实现的：不同项目组拿不同的虚拟密钥，litellm 会自动打上元数据，后续按这个维度统计费用和用量即可。如果你连密钥管理都不想自己操心，litellm 也支持对接外部密钥管理服务，不过那是另外一个话题了，先把最基本的隔离机制用熟更实在。

4. 实战构建高可用接入层：配置与代码全拆解

4.1 YAML 核心配置：负载均衡、故障回退与重试

先看一段我们在生产环境上用过的精简版 YAML 配置，它把负载均衡、故障回退和重试策略都串起来了：

model_list: - model_name: chat-main litellm_params: model: vendor-a/chat-large api_key: os.environ/VENDOR_A_KEY model_info: supports_function_calling: true max_input_tokens: 8192 - model_name: chat-main litellm_params: model: vendor-b/chat-medium api_key: os.environ/VENDOR_B_KEY model_info: supports_function_calling: false max_input_tokens: 4096 - model_name: chat-fast litellm_params: model: vendor-c/chat-fast api_key: os.environ/VENDOR_C_KEY litellm_settings: drop_params: true num_retries: 3 request_timeout: 30 fallbacks: [{ "chat-main": ["chat-main", "chat-fast"] }] retry_policy: AuthenticationError: max_retries: 0 RateLimitError: max_retries: 2 Timeout: max_retries: 1

这段配置里几个关键点值得展开说。fallbacks的意思是：当chat-main组内所有模型都不可用时，自动把请求降级到chat-fast组。这个配置在真实场景里非常有价值，比如两个主力模型同时被上游限流，请求不至于直接 500，而是自动切换到更轻量的模型继续服务，业务体验受到的冲击会小很多。

retry_policy控制了不同错误类型的重试次数。这里我的思路是：鉴权类错误不重试，因为大概率是配置问题，重试只会浪费请求；限流类错误重试两次，因为限流通常是瞬时的；超时类错误只重试一次，因为很多超时是上游已接收但响应慢，重试可能造成重复扣费。设置num_retries和retry_policy时要注意，重试次数不是越多越好，每次重试背后都对应真金白银的成本和额外延迟。

drop_params这个参数容易被忽略。它表示当某个模型不支持某个参数时，自动剔除再请求，而不是直接报错。比如你的业务统一传了temperature、max_tokens、tools等字段，但下游某个模型不支持 tools，开启这个开关能避免大量调用失败。不过要小心，drop 参数也可能掩盖一些业务误传问题，所以我们在测试环境会开着详细日志观察一阵子再上生产。

4.2 成本追踪：按团队、项目、标签做分账

成本追踪是所有接入模型供应商的团队都绕不开的刚需。litellm 在这块内置了完整的按用量计费和成本统计能力，支持按用户、按项目、按自定义标签三个维度拆分。

在配置里，可以给不同业务分配不同的虚拟密钥，并在请求头上带上项目标识。litellm 会在网关层自动记录每次请求的 token 消耗，并结合供应商的单价估算成本。查询时可以直接调用内置的接口，比如：

curl -X GET "http://llm-gateway:8080/spend/tags" \ -H "Authorization: Bearer your_master_key"

这个接口会返回按标签汇总的费用明细。我们内部会要求每个业务在请求头里必须携带x-litellm-tags，里面写清楚项目名和用途，比如project=internal-chat,env=prod。这样月底复盘时，可以直接按项目拉出每个团队的模型花费，再也不用靠人工翻账单。

如果你的团队还需要更细粒度的用户级别统计，litellm 也支持在请求中传用户 ID，按用户维度输出报告。对于做用户侧计费的产品来说，这是很实用的一块能力。不过我要提醒一点：成本统计依赖供应商返回的用量信息，如果供应商经常不返回 prompt_tokens 或 completion_tokens，就会导致统计偏差。具体怎么处理，我在后面踩坑部分详细说。

4.3 Python SDK 集成：从同步到异步调用

除了 HTTP 网关，很多内部服务更喜欢直接在代码里调用 litellm 的函数式接口，因为它能减少一次网络跳转。下面是我们内部一个服务实际用过的异步调用示例：

import asyncio from litellm import Router router = Router( model_list=[ { "model_name": "chat-main", "litellm_params": {"model": "vendor-a/chat-large"}, }, { "model_name": "chat-main", "litellm_params": {"model": "vendor-b/chat-medium"}, }, ], fallbacks=[{"chat-main": ["chat-fast"]}], set_verbose=False, ) async def main(): response = await router.acompletion( model="chat-main", messages=[{"role": "user", "content": "用一句话总结今天的进度"}], request_timeout=20, ) print(response.choices[0].message.content) asyncio.run(main())

Router 对象的好处是它在进程内就能完成模型调度，不用再走一遍 HTTP 网关，延迟更低。对于 Python 后端服务来说，异步接口是标配，litellm 也提供了完善的 async 支持。有一点经验是，不要把 Router 对象在每次请求时都新建一遍，应该做成模块级单例，复用连接池，否则并发起来之后你会发现开销全浪费在创建对象上。

另外，代码集成时另一个实用技巧是给请求统一注入通用的 system prompt 或安全规则。这可以在请求进入模型前由业务侧自己拼装，也可以借助 litellm 的请求预处理钩子实现。我们倾向于在业务代码里直接拼装，因为可读性更强，也不容易出隐性问题。

4.4 可观测性：监控指标与告警上报

网关层一旦变成所有模型请求的必经之路，它的可观测性就直接决定你的排障效率。litellm 自带了不少常用中间件信号的暴露能力，比如请求数量、请求延迟分布、token 消耗、错误率等，也支持把指标对接主流监控系统。

我们在收集这些指标时重点关注的是三类告警：模型错误率突然上升，这通常意味着某家供应商出现问题或模型版本有异常；请求 P95 延迟明显增高，可能是某条链路上有慢请求或者重试过多；每日成本超过预设阈值，需要及时排查是否出现异常消耗或配置错误。基于这些指标，我们在监控系统里配置了几条告警规则，比之前靠用户反馈发现问题要轻松太多。

还有一个容易被忽视的观测项是“请求是否命中了 fallback”。我们会在日志里把 fallback 命中事件单独标记出来，一旦某天 fallback 数量明显增多，基本可以断定主供应商正在经历不稳定期，这时就需要调整流量分配或者联系供应商处理。litellm 的日志输出中会带上这些路由信息，关键是提前把日志采集和检索系统准备好。

5. 上线后的踩坑记录与排查技巧

5.1 上游限流引发的“熔断”如何绕过

上线初期我们遇到的最典型的坑是上游限流引发的连锁熔断。某个主力模型厂商对大流量限流很凶，返回 429 的频率一下就上来了。当时我们配置的 fallback 策略是失败后切到备用供应商，但问题在于 fallback 是“每请求”级别的，流量高峰时大量请求几乎同时触发 fallback，备用供应商紧接着也被打爆，然后两个供应商一起限流，网关层大量请求排队超时。

后来我们调整了三个地方：一是给每个供应商单独设置并发上限和连接池大小，从源头限制打到单家供应商的流量；二是对限流错误增加退避延迟，让网关在收到 429 后稍微等一下再重试，避免瞬间风暴；三是细化 fallback 策略，不仅按模型组切换，还要结合冷却时间。litellm 支持在配置里调这些参数，我们的经验是一开始先保守一点，宁可多容忍几次失败，也别让所有流量都冲到一个备用模型上。

另外，配置num_retries时要注意，重试并不能解决容量问题。如果上游限流已经持续了几分钟，你再怎么重试都是徒劳，反而会放大压力。正确的做法是结合限流响应的 Retry-After 头部来决定重试时机，如果没有这个机制，就固定一个较大的退避窗口。

5.2 模型能力差异造成的兼容性问题

多模型接入之后，第二个高频问题来自模型能力的差异。最典型的是上下文长度不一致：同一个 prompt，在 A 模型上成功返回，切到 B 模型后直接报“超出最大长度”。我们的处理方式是在 litellm 的model_info里标注每个模型的最大输入长度，同时在业务代码里根据模型组动态调整发送给模型的提示词长度。

tools 能力不一致也很折腾。某些老版本模型不支持函数调用，但业务层已经统一加了 tools 定义。这时候 litellm 的drop_params开关能帮忙，但更好的方案是按模型能力分组：支持 tools 的放一组，不支持的放另一组，业务侧调用时明确指定使用哪组。依赖自动丢弃参数来掩盖差异，短期能跑，长期一定埋雷。

还有一个容易被忽略的差异是返回格式。有些模型原生支持结构化输出，有些模型只能靠强约束提示词来控制。如果业务很依赖结构化返回，建议在选择模型组时就直接限定到支持结构化输出的模型上，而不是把所有模型一股脑加进同一个组。这个决定应该在模型分组阶段做，而不是等上线后发现返回格式不对再来补救。

5.3 成本统计与供应商账单对不上的原因

成本统计是我们在生产上挠头最多的问题之一。一开始我们发现 litellm 统计的日消耗和供应商后台的账单总是差一点，排查下来主要有几个原因。

第一个是供应商返回的 token 数字与计费时的口径不一致。部分供应商计费会把缓存命中的输入 token 打折甚至计为 0，但 API 返回的用量里不一定细分。如果直接把接口返回的 token 数乘以单价，自然对不上。第二个是重试带来的重复计费。有些超时场景请求实际上已经打到模型并计费了，但客户端没收到响应，litellm 或业务代码重试后又调用了一次，这部分成本不会出现在正常响应日志里。第三个是 prompt 缓存，很多厂商对命中缓存的请求有特殊计费规则。

我们的应对思路是不要追求“分毫不差”，而是做到“可解释的差异”。litellm 的成本报表主要用于内部摊分和趋势观察，最终对账单还是以供应商后台为准。月底对账时，我们会把重试导致的额外调用、缓存导致的折扣差异单独标识出来，做到每一条差异都能还原到具体请求，这样就足够满足财务和项目管理需求了。

5.4 高并发场景下的连接与吞吐瓶颈

当网关从单条测试变成生产核心链路后，高并发下的性能瓶颈会逐渐暴露。我们遇到过两个典型表现：一是在高峰期偶尔出现请求超时，但检查上游供应商的监控却没发现明显异常；二是网关所在实例 CPU 并不高，但连接数却打到上限。

正常情况下，litellm 使用同一套底层 HTTP 连接池向供应商发起请求。如果连接池大小配置得太小，高并发时大量请求都在等待空闲连接，延迟自然就上来了。解决办法是调大连接池、设置合理的连接超时和读取超时，并且确保单个网关实例有足够的多线程/协程能力处理并发请求。另外一个更隐蔽的问题是，当网关使用 SQLite 记录请求日志时，写库会成为瓶颈，因为 SQLite 对并发写支持比较有限。我们当时把日志存储切到 PostgreSQL 后，高并发下的吞吐量有了立竿见影的提升。

如果并发规模确实很大，那就需要考虑多实例部署了。litellm 支持多实例共享同一个数据库，前面再挂一层负载均衡把流量分发到不同实例。这里需要确认的是，多实例之间会话和密钥的管理依赖数据库同步，数据库本身不能成为新的瓶颈，建议单独评估数据库的连接数和读写性能。

5.5 常见问题速查表

最后把我们在生产环境里遇到频率最高的一批问题整理成一个速查表，供大家直接参考。

6. 一点个人心得与后续规划

最后聊点我们内部的使用心得。litellm 在我们的技术栈里已经是模型接入的事实标准，所有外部模型的访问都会经过它，包括内部实验项目、线上业务、数据分析脚本。它给我最大的感受是，接入层这件事真的应该被当成基础设施来对待，而不是每个项目各自造轮子。有了统一网关之后，新技术验证的成本变得很低：官方发布了新模型，只需要在配置里加上一行映射，第二天就可以让团队试用对比效果，不用等任何开发排期。

还有一个小技巧想分享给大家：模型命名一定要从一开始就规范化。我们使用的是“用途-优先级”的命名模式，比如chat-main、chat-fast、embed-default，而不是直接把供应商模型名暴露给上层。这样当供应商调整模型版本或价格时，上层业务完全无感，改配置就好。一开始多花一点时间做命名设计，后面会省下无数沟通成本。

后续我们打算重点投入的方向有两个。一个是把文件上传和多模态调用也统一收口到网关里，现在模型服务的多模态接口差异比较大，希望凭 litellm 的能力把这部分也统一掉。另一个是把网关的访问控制做得更细，比如按内部团队的月预算自动熔断，防止某条业务线大量消耗预算而别人毫不知情。如果你也在做类似的模型接入治理，建议先从一个最小可用的网关配起来，把成本统计和密钥管理做扎实，再慢慢扩展路由策略和自动化能力。模型接入这趟水很深，但有一个统一入口之后，至少不会让你每天都过得像救火队员。