1. 背景业务问题与引入动机我所在的零售集团数据智能部负责为集团 12 条业务线提供 AI 能力包括智能客服、商品描述生成、订单地址解析、营销文案等。到 2025 年底各业务线已先后接入了 6 家大模型厂商的 10 个模型实例GPT-4o、Claude 3.5 Sonnet、通义千问 Max、文心 4.0、DeepSeek-V3 等日均调用量约 320 万次。我们最初接触「多模型聚合网关」这个技术是被一个具体的业务痛点逼出来的每条业务线各自直连厂商 API接入规范、密钥、故障处理完全失控。有的业务线走 OpenAI 兼容格式有的走厂商原生 SDK12 个业务线共持有 40 个 API Key无法统一轮换某厂商限流时各业务线各自重试互相叠加形成雪崩。最典型的一次事故大促期间某厂商因负载过高返回 4296 条业务线同时重试把网关出口带宽耗尽核心客服链路 P99 延迟从 800ms 飙到 6.2s持续 37 分钟。这次事故直接推动了统一接入方案的立项。2. 踩坑与现状直连模式的三层失控事故复盘后我们把直连模式的痛点归纳为三层这也是后续选型的核心约束协议层碎片化每家厂商的请求/响应结构、错误码语义、超时行为都不一样。业务代码里充斥着if (provider openai) {...} else if (provider qwen) {...}这类分支维护成本极高。流量治理缺失没有统一的限流、熔断、重试策略。各业务线各自为政重试策略层层叠加形成重试风暴——这正是 429 雪崩的直接原因。可观测性为零没有统一的日志、指标、链路追踪。故障发生时只能靠各业务线人工上报定位问题耗时以小时计。这三层痛点决定了我们需要的不是一个「转发代理」而是一个能统一协议、治理流量、输出可观测性的聚合网关。3. 方案两套候选对比与选型基于上述痛点我们评估了两套方案维度方案 A自研轻量网关基于 Spring Cloud Gateway 自研适配层方案 B引入开源聚合网关LiteLLM Proxy 1.40协议统一需自研 6 家厂商适配器约 2 人月内置 100 厂商适配开箱即用流量治理需自研限流/熔断/重试约 1 人月内置限流、重试、熔断、预算控制可观测性需自研埋点 对接 Prometheus内置 Prometheus 指标 日志定制灵活性高可完全按集团规范定制中需通过插件机制扩展运维成本高需自研高可用部署低官方提供 Docker/K8s 部署选型依据我们最终选择方案 BLiteLLM Proxy理由有三一是集团要求 3 个月内上线自研方案工期不可控二是 LiteLLM 的厂商适配层已经过社区大量验证比自研更稳三是它支持自定义custom_auth和call_hook能满足集团统一鉴权和审计需求。自研方案仅作为后续深度定制时的备选。4. 实操步骤基于 LiteLLM Proxy 的统一接入4.1 环境与版本服务器4 台 8C16G 云主机Kubernetes 1.28LiteLLM Proxy1.40.5Docker 镜像ghcr.io/berriai/litellm:main-v1.40.5Redis 7.0用于限流计数与缓存Prometheus 2.45 Grafana 104.2 核心配置统一模型路由在config.yaml中定义模型与厂商映射业务侧只需感知一个统一的模型名gpt-4o-unifiedmodel_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:63794.3 统一鉴权与审计通过custom_auth实现集团统一 SSO 鉴权并记录每次调用的业务线、模型、token 消耗# custom_auth.pyfromlitellm.proxy.auth.auth_utilsimportget_bearer_tokenasyncdefcustom_auth(request):tokenget_bearer_token(request)# 调用集团 SSO 校验 token返回用户信息user_infoawaitverify_sso_token(token)ifnotuser_info:raiseException(Invalid token)returnuser_info4.4 预期运行结果启动后业务线只需把 base_url 指向网关http://llm-gateway:4000用统一的gpt-4o-unified模型名即可。网关自动完成厂商路由、限流、重试与审计。我们压测验证单网关实例 QPS 稳定在 850P99 延迟 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:50005.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:3006. 验证数据与效果上线 4 周后对比接入前后的核心指标指标接入前接入后业务线接入新模型平均耗时3~5 天2~4 小时API Key 数量40 个散落1 个网关主 Key SSO 鉴权429 导致的业务故障每月 3~4 次0 次故障定位平均耗时2~3 小时15 分钟网关自身 P99 延迟不含上游—38ms7. 权衡与总结适用边界与代价引入网关的代价网关本身是新的单点必须做高可用部署至少 2 副本 健康检查LiteLLM 的 Python 实现有约 30~40ms 的自身开销对延迟极度敏感的场景不友好Redis 是限流与缓存的命脉务必集群化并关闭淘汰策略升级 LiteLLM 版本前需先在测试环境回归厂商适配层避免上游 API 变更导致兼容性问题。适用场景多厂商、多模型、多业务线接入的企业对统一鉴权、审计、限流有强诉求团队希望快速上线、不愿重复造轮子。不适用场景不要照搬单一厂商、单一模型的极简场景引入网关反而增加一跳延迟对延迟极度敏感、要求网关自身开销 5ms 的场景需要深度定制协议、现有插件机制无法满足的场景。这类场景自研或直连反而更合适。