1. 背景：业务问题与引入动机

我所在的零售集团数据智能部，负责为集团 12 条业务线提供 AI 能力，包括智能客服、商品描述生成、订单地址解析、营销文案等。到 2025 年底，各业务线已先后接入了 6 家大模型厂商的 10 个模型实例（GPT-4o、Claude 3.5 Sonnet、通义千问 Max、文心 4.0、DeepSeek-V3 等），日均调用量约 320 万次。

我们最初接触「多模型聚合网关」这个技术，是被一个具体的业务痛点逼出来的：每条业务线各自直连厂商 API，接入规范、密钥、故障处理完全失控。有的业务线走 OpenAI 兼容格式，有的走厂商原生 SDK；12 个业务线共持有 40+ 个 API Key，无法统一轮换；某厂商限流时，各业务线各自重试，互相叠加形成雪崩。最典型的一次事故：大促期间某厂商因负载过高返回 429，6 条业务线同时重试，把网关出口带宽耗尽，核心客服链路 P99 延迟从 800ms 飙到 6.2s，持续 37 分钟。这次事故直接推动了统一接入方案的立项。

2. 踩坑与现状：直连模式的三层失控

事故复盘后，我们把直连模式的痛点归纳为三层，这也是后续选型的核心约束：

1. 协议层碎片化：每家厂商的请求/响应结构、错误码语义、超时行为都不一样。业务代码里充斥着if (provider == "openai") {...} else if (provider == "qwen") {...}这类分支，维护成本极高。
2. 流量治理缺失：没有统一的限流、熔断、重试策略。各业务线各自为政，重试策略层层叠加，形成重试风暴——这正是 429 雪崩的直接原因。
3. 可观测性为零：没有统一的日志、指标、链路追踪。故障发生时，只能靠各业务线人工上报，定位问题耗时以小时计。

这三层痛点，决定了我们需要的不是一个「转发代理」，而是一个能统一协议、治理流量、输出可观测性的聚合网关。

3. 方案：两套候选对比与选型

基于上述痛点，我们评估了两套方案：

选型依据：我们最终选择方案 B（LiteLLM Proxy），理由有三：一是集团要求 3 个月内上线，自研方案工期不可控；二是 LiteLLM 的厂商适配层已经过社区大量验证，比自研更稳；三是它支持自定义custom_auth和call_hook，能满足集团统一鉴权和审计需求。自研方案仅作为后续深度定制时的备选。

4. 实操步骤：基于 LiteLLM Proxy 的统一接入

4.1 环境与版本

• 服务器：4 台 8C16G 云主机，Kubernetes 1.28
• LiteLLM Proxy：1.40.5（Docker 镜像ghcr.io/berriai/litellm:main-v1.40.5）
• Redis 7.0（用于限流计数与缓存）
• Prometheus 2.45 + Grafana 10

4.2 核心配置：统一模型路由

在config.yaml中定义模型与厂商映射，业务侧只需感知一个统一的模型名gpt-4o-unified：

model_list:-model_name:gpt-4o-unifiedlitellm_params:model:openai/gpt-4oapi_key:os.environ/OPENAI_API_KEYrpm:2000# 每分钟 2000 次tpm:1000000# 每分钟 100 万 token-model_name:claude-unifiedlitellm_params:model:anthropic/claude-3-5-sonnet-20241022api_key:os.environ/ANTHROPIC_API_KEYrpm:1500litellm_settings:drop_params:trueset_verbose:falsenum_retries:3request_timeout:30general_settings:master_key:os.environ/LITELLM_MASTER_KEYdatabase_url:os.environ/DATABASE_URLredis_host:os.environ/REDIS_HOSTredis_port:6379

4.3 统一鉴权与审计

通过custom_auth实现集团统一 SSO 鉴权，并记录每次调用的业务线、模型、token 消耗：

# custom_auth.pyfromlitellm.proxy.auth.auth_utilsimportget_bearer_tokenasyncdefcustom_auth(request):token=get_bearer_token(request)# 调用集团 SSO 校验 token，返回用户信息user_info=awaitverify_sso_token(token)ifnotuser_info:raiseException("Invalid token")returnuser_info

4.4 预期运行结果

启动后，业务线只需把 base_url 指向网关（http://llm-gateway:4000），用统一的gpt-4o-unified模型名即可。网关自动完成厂商路由、限流、重试与审计。我们压测验证：单网关实例 QPS 稳定在 850，P99 延迟 1.2s（含上游模型耗时），限流触发时返回标准的 429 响应。

5. 踩坑记录：三个真实问题与排错

5.1 坑一：重试风暴导致上游 429 雪崩

报错日志：

litellm.proxy.proxy_server: ERROR: Retrying request to openai/gpt-4o, attempt 2/3 openai.RateLimitError: 429 Too Many Requests

排查：num_retries: 3是全局配置，所有请求都会重试 3 次。大促流量高峰时，重试请求叠加到上游，反而加剧了上游的限流压力。

解决：改为按模型差异化配置，并对重试增加指数退避：

litellm_settings:num_retries:1retry_policy:RateLimitError:retries:2min_time_in_ms:1000max_time_in_ms:5000

5.2 坑二：Redis 限流计数漂移

现象：压测时发现限流阈值形同虚设，实际放行量超出配置的 2 倍。

排查：LiteLLM 的限流依赖 Redis 的滑动窗口计数，但我们的 Redis 是单实例，且未开启持久化。压测期间 Redis 内存被打满触发淘汰策略，部分计数 key 被 LRU 淘汰，导致计数丢失。

解决：Redis 改为 3 节点 Cluster 部署，并设置maxmemory-policy noeviction，确保限流计数 key 不被淘汰。

5.3 坑三：流式响应超时误判

现象：客服场景使用流式输出，但网关在 30s 超时后主动断开，前端收到不完整回复。

排查：request_timeout: 30是整体超时，但流式场景下首 token 延迟可能超过 30s（上游排队），导致误判。

解决：区分流式与非流式超时：

litellm_settings:request_timeout:30streaming_request_timeout:300

6. 验证数据与效果

上线 4 周后，对比接入前后的核心指标：

7. 权衡与总结：适用边界与代价

引入网关的代价：网关本身是新的单点，必须做高可用部署（至少 2 副本 + 健康检查）；LiteLLM 的 Python 实现有约 30~40ms 的自身开销，对延迟极度敏感的场景不友好；Redis 是限流与缓存的命脉，务必集群化并关闭淘汰策略；升级 LiteLLM 版本前需先在测试环境回归厂商适配层，避免上游 API 变更导致兼容性问题。

适用场景：多厂商、多模型、多业务线接入的企业；对统一鉴权、审计、限流有强诉求；团队希望快速上线、不愿重复造轮子。

不适用场景（不要照搬）：单一厂商、单一模型的极简场景（引入网关反而增加一跳延迟）；对延迟极度敏感、要求网关自身开销 <5ms 的场景；需要深度定制协议、现有插件机制无法满足的场景。这类场景自研或直连反而更合适。