主流 LLM 网关调研报告2026 年 9 月我在 2026 年这轮 LLM 网关选型之前其实已经踩过好几次“随手套一个反向代理”的坑。最初只是给内部工具接两三个模型供应商用 FastAPI 写个转发层加上 API Key 管理感觉够了。等到团队把模型接入数量推到十几个、调用链路开始涉及多租户隔离、灰度发布、成本分配和故障转移时那个“够用”的转发层很快就变成了运维黑洞。于是我做了一轮比较系统的 LLM 网关调研从开源方案到商业产品都测了一遍记录下这份报告。它不是什么标准答案但应该能帮你少走一些弯路。1. 为什么到了 2026 年LLM 网关突然成了刚需1.1 从“调 API”到“管流量”需求变了前两年大家聊 LLM核心话题还是“哪个模型效果更好”“Prompt 怎么调”。到了 2026 年模型能力趋同真正的分水岭变成了“你接了多少个模型”“怎么让流量在模型之间平滑调度”“怎么让每个业务线的成本清晰可见”。这时候 LLM 网关就不再是可有可无的中间层而是整个企业级 LLM 应用的流量入口。举一个很实际的例子我们内部有一个综合问答产品要同时支持文本生成、图像理解、结构化输出、长文档分析等能力。早期选了一家综合能力强的供应商后来发现它在特定任务上的效果并不稳定而且单 QPS 成本偏高。于是我们把任务拆开基础 QA 走模型 A复杂推理走模型 B长文档处理走模型 C。这种架构下客户端直接调用任何一个模型都不可行必须有一个网关层来做路由、限流、审计、降级。1.2 2026 年 LLM 网关的核心能力矩阵这两年 LLM 网关的功能边界扩大得非常明显。2024 年你选网关可能只看“支持多少家供应商、能不能统一鉴权、有没有简单的 UI”2026 年再看维度已经完全不一样。我梳理了一份能力矩阵基本覆盖了大部分选型时会关心的点能力项说明重要性多供应商接入是否支持 OpenAI、Anthropic、Azure OpenAI、Gemini、国内主流模型服务等协议极高协议兼容度是否能将非 OpenAI 协议统一转换为 OpenAI 兼容格式极高动态路由按模型能力、成本、延迟、可用性做路由高多租户与权限支持 Key 隔离、用户维度额度管理、审计日志高成本观测按项目、按用户、按模型拆分 token 消费高金丝雀发布新模型上线时按比例灰度中高缓存策略Semantic Cache 还是简单 KV 缓存中高故障转移主供应商挂掉时自动切到备用高数据合规是否支持私有化部署日志是否可审计视场景而定你会发现2026 年的 LLM 网关已经不太像“代理层”更像一个完整的 API 管理平台它不只是帮你转发请求还得帮你看懂流量、管住成本、守住数据边界。1.3 谁最需要 LLM 网关从我们调研接触的团队类型来看大概可以分为三类。第一类是“重度多模型使用者”典型画像是有 3 个以上模型供应商、内部多个业务线共享一套 API 出口。这一类是最刚需的没有网关基本无法做成本归因也无法在某个模型出现故障时快速整体切换。第二类是“有合规需求的平台方”比如做 2B 产品或金融、政务类应用需要完整审计链路的团队。这一类对开源、私有化、数据不落盘有硬性要求单纯的商业 SaaS 网关往往过不了安全评审。第三类是“被调用规模逼着转型的团队”早期是几百 QPS用 FastAPI 转发层勉强能撑当 QPS 过万、KV Cache 需要复用、需要多地域部署时转发层就顶不住了。如果你不属于上述任何一类说实话现阶段接一个单厂商 SDK 直连也能跑。但只要你预计未来半年会新增至少两个模型供应商那网关这件事就得提前考虑了不然后面迁移成本会非常高。2. 开源 vs 商业我实测后的适用边界2.1 开源网关灵活但“运维税”不低我在调研中重点测了三个开源项目LiteLLM、Helicone 的自建版本、Portkey Gateway 的开源版额外关注了 KubeAI 这类将网关与推理平台绑定的方案。如果说一句话总结就是开源方案的 API 接入能力已经非常成熟难的是落在自己机房里的运维与稳定性工程。LiteLLM目前是社区活跃度最高的通用网关配置文件走 YAML支持 100 多家模型供应商基本上面向 OpenAI 生态的模型都可以一键接入。它的好处是轻、灵活、社区问题库响应快坏处是你得自己处理高可用、限流数据的持久化、多实例部署时的配置同步。我们有两次线上抖动排查下来都是因为本地 SQLite 存储并发写导致的。Portkey Gateway开源版更偏“控制面板”风格自带简单的调用日志和缓存配置测试下来在请求转发层面比较稳定。它支持多租户下的 User ID 维度追踪这一点比 LiteLLM 默认能力好用。但开源版功能受到一定限制高级的缓存策略、Guardrails 集成都在商业版里。Helicone自建版的定位更像“可观测性网关”它把日志记录、token 统计、延迟分析这些做得很细。如果你已经有一套稳定的 API 网关不想引入一个重框架只想在 LLM 流量上加一层监控Helicone 是首选。在部署方式上开源方案基本都支持 Docker Compose 和 Kubernetes Helm Chart我们实测下来Helm Chart 部署要比 Docker Compose 稳定很多。Compose 适合单机试用或内部小范围使用一旦上到多副本建议直接上 K8s不然配置管理和日志采集都会很吃力。2.2 商业网关省事但要算清两笔账商业产品这一块我重点调研了 Azure API Management 的 LLM 网关能力、AWS Bedrock 的代理层以及 Kong AI Gateway、Apifox AI Gateway 等偏 API 管理侧的方案。商业方案最大的优势是“不需要自己维护基础设施”网关自带高可用、限流、日志、监控团队只需要管路由规则和 Key 发放。Azure 的 LLM 网关能力在 Azure OpenAI 环境下确实顺手限流和 DDoS 防护都是平台级能力但如果你的模型供应商里有非 Azure 厂商配置复杂度会上升。AWS Bedrock 的体验正好相反你只要在 Bedrock 生态里模型路由和权限管理是完整的但如果你想接 OpenAI 或者国内模型就得走一层自定义集成那商业方案的“省事”优势就打了折扣。Kong AI Gateway 我是比较看好的因为 Kong 本身就是老牌 API 网关LLM 相关的插件做得比较系统支持多供应商接入、动态模型路由、语义缓存等。测试中它的性能损耗非常低单实例转发延迟增加可以控制在 5ms 以内。当然商业方案有显而易见的成本问题。我算了一笔账按我们内部日均 300 万次请求、平均每次进出 8KB 来算公有云原生网关的流量费用和调用费用叠加每个月的增量成本大概是自建网关的 2 到 3 倍。这笔账不是说不值得花而是很多团队在选型时根本没预算进去等账单出来才开始后悔。2.3 哪个更适合你我给的决策建议很简单团队有 K8s 运维能力、模型供应商较多、成本敏感 → 优先开源方案LiteLLM 或 Portkey Gateway。团队在 Azure/AWS 生态内、模型高度绑定单一云厂商 → 优先云原生网关。团队已经有 Kong/APISIX 等 API 网关希望统一管理所有 API 与 LLM 流量 → 优先 Kong AI Gateway。合规要求严、必须私有化、但不想花人力维护开源网关 → 可以考虑商业版私有化部署。这里要额外提醒一句LLM 网关的选型不应该只看“网关”本身还得看你现有的 API 管理体系。如果你们公司本来就有统一的 API 网关那 LLM 网关要么是它的一个插件能力要么就独立部署但复用现有的可观测性系统两条腿走路千万别再引入第三套割裂的日志体系。3. 网关选型时最容易看走眼的五个细节3.1 供应商协议兼容别只看“列表支持”很多网关在宣传页上写着“支持 100 模型供应商”但你真去接的时候会发现所谓“支持”只是支持了某种协议转换。比如某家供应商的接口是 Anthropic 风格但返回的流式格式有细微差异网关如果没有针对性地做适配流式响应就会断。我建议的测试方法是不只测网关文档里列出来的那个 demo 模型而是把你真实用的两三个模型逐一跑通流式、非流式、多模态、工具调用四类场景。我们调研时发现有些网关在工具调用Function Calling/Tool Calling场景下兼容性非常差尤其是目标供应商返回的数据结构里带了额外字段时网关的 schema 校验会把请求直接拦掉。3.2 限流与额度管理的粒度限流这件事很多人以为网关只要有“每秒 X 次”就够。实际用下来真正的关键是额度管理的“维度”你能不能按项目限、按用户限、按模型限、按成本限。我们内部的场景是这样的A 业务线每天有 200 万 token 的预算B 业务线有 500 万如果网关只能做全局限流那 A 的流量冲上来时会把 B 的配额也打穿。好的网关应该支持多层级限额并且能够在限额到达前提前告警。测试时请重点关注配额统计的实时性——很多网关的配额统计是异步的延迟 5 分钟以上这种情况上限流基本等于亡羊补牢。3.3 缓存策略缓存命中的“副作用”缓存是降低成本最直接的手段但缓存策略选不好负面影响比收益更明显。简单 KV 缓存适用场景是“完全相同的 Prompt 反复请求”这在我们的实际业务里很少见。Semantic Cache 则会对请求做向量化把语义相似的请求命中缓存大幅提升命中率但代价是延迟增加和误命中风险。比如用户问“今天天气怎么样”和“今天天气如何”语义基本一样可以命中但“今天天气怎么样”和“明天的天气怎么样”如果向量距离不够远就容易被误命中返回一个过期的答案。我建议生产环境默认关闭 Semantic Cache或者在特定场景下如知识库问答谨慎开启并且对缓存设置较短的 TTL。不要为了节省那一点 token 成本牺牲了答案新鲜度。3.4 多租户隔离不止是“各用各的 Key”多租户隔离很容易被误解成“每个用户一个 API Key”。实际上真正的隔离包含三层身份隔离、配额隔离、数据隔离。身份隔离解决“谁是谁”配额隔离解决“谁可以用多少”数据隔离解决“A 的日志 B 不能看”。需要特别注意的是日志。很多团队在测试网关时只测了转发和鉴权忽略了日志权限。结果上线后所有租户的 Prompt 日志都进了同一个索引任何一个能查询日志的人都能看到所有用户的数据。这在金融、医疗类场景里是严重的合规事故。选型时务必确认日志是否支持租户维度隔离、是否支持脱敏、是否可以只关掉日志记录而保留调用统计。3.5 部署形态单机还是分布式我们一开始图省事用 Docker Compose 部署了单实例 LiteLLM一个月不到就碰到两个问题一是 SQLite 并发写导致配置更新偶发失败二是单点故障。如果你明确知道生产请求量会超过 100 QPS就不要考虑单机部署了。比较稳妥的方案是网关无状态化配置和日志存储外置到 Redis PostgreSQL网关实例可以水平扩容。另外网关后面接模型供应商时供应商侧的限流是另一个瓶颈。即使网关部署在高可用集群上如果它只是均匀地分发请求而某个供应商的账号限流比较严格那依然会出现大量 429。网关最好能感知每个供应商账号的余量。这个能力在开源方案里支持得不算好需要二次开发。4. 双网关策略我的落地参考架构4.1 为什么套两层网关你可能听过一个说法网关套网关是过度设计。但在 LLM 场景下我实测后认为“外层流量网关 内层 LLM 网关”的双层结构是企业级落地最稳的组合理由有三个。第一外层网关解决通用 API 治理问题包括 DDoS 防护、IP 白名单、OAuth2/JWT 鉴权、通用审计这些能力 LLM 网关能做但远不如专业 API 网关扎实。第二内层 LLM 网关解决模型路由、供应商故障转移、成本统计、语义缓存这一层不需要关心 API 通用治理可以做得非常专精。第三双层结构天然支持“多环境隔离”测试环境和生产环境可以在内层网关配置不同的供应商 Key 池。我们现在的生产架构是客户端 → Kong外层 → LiteLLM内层 → 多个模型供应商。4.2 配置数据与日志的流向设计双层网关的好处是职责清楚坏处是如果日志和配置没有设计好就会变成两套割裂的系统。我们最终的做法是Kong 负责记录“谁在什么时间调用了哪个 API”输出到统一日志平台LiteLLM 负责记录“这个请求最终路由到了哪个模型、消费了多少 token、缓存是否命中”同样输出到统一日志平台两边的日志关联字段是同一个RequestID由外层网关生成透传到内层网关最终带到模型供应商侧。有了这个RequestID当用户反馈某个回答有问题时我们可以从入口到模型响应全链路回溯——这在排障时极度有用。4.3 故障转移的配置细节故障转移这件事我提醒你别只配“全局 fallback”更合理的是“按模型能力分组 fallback”。举一个例子主供应商 A 的 GPT-4o 类模型挂了你希望流量切到供应商 B 的同类模型而不是切到供应商 C 的轻量模型。网关需要能区分“同一个语义模型在不同供应商下的等价关系”。目前开源网关的通用做法是在路由规则里配置model_group把不同供应商的等价模型归到同一组然后设定优先级。另外故障转移的触发条件也要仔细测。是连续 5 次 5xx 触发是平均延迟超过 3 秒触发还是供应商健康检查失败触发不同条件适用场景不一样。我们的配置是混合触发连续 10 次 5xx 或连续两分钟 P95 延迟超过 2 秒都会触发切换且在切换前会保留一个手动开关避免在供应商短暂抖动时频繁切换造成二次问题。5. 线上压测数据与一次事故复盘5.1 压测结果对比我们在同一批物理机上压测了 LiteLLM、Portkey Gateway、Kong AI Gateway使用相同的请求负载模型并发 200请求体平均 3.5KB响应平均 8KB持续压测 30 分钟。网关P95 延迟增量最大 QPS失败率备注LiteLLM 单实例12ms8200.02%随后出现配置更新延迟LiteLLM 三副本8ms21000.001%稳定Portkey Gateway15ms18000.005%日志开启时性能下降明显Kong AI Gateway5ms35000.0001%性能最好配置最复杂这里要说明一下压测时的“延迟增量”是网关自身引入的额外延迟不是模型响应延迟。开模型供应商侧的真实响应时间一般都在 1-3 秒所以网关那几十毫秒的增量在单次请求里感知不明显但如果你有大量流式返回、需要网关逐 token 转发那么延迟增量会被放大压测时一定要测流式场景。5.2 事故复盘缓存穿透导致的高延迟有一次线上事故让我印象非常深。某个新业务上线后LiteLLM 的 Semantic Cache 命中率突然降到 12% 以下并且大部分请求都走了向量化计算网关的 CPU 一度跑满最终导致 P95 延迟从 60ms 抖到了 1.8 秒。根因是我们的向量化模型部署在与网关同一台节点上平时流量小的时候没问题但新业务上线后大量语义缓存计算把 CPU 打满了网关本身的转发性能被拖垮。复盘下来有三个教训语义缓存的计算资源要独立部署特别是向量化模型不要和网关 CPU 争资源。缓存未命中的请求要走快速通道不要因为计算缓存而阻塞正常转发。开启缓存前先评估业务的重复请求比例如果大多请求是低重复性的Semantic Cache 带来的收益有限反而增加风险。事故后我们把向量化模型挪到了独立节点并给 Semantic Cache 增加了并发度限制和队列超时CPU 使用率从 85% 降回 30%。5.3 压测中最容易忽略的流式场景如果你只想测一条那一定要测流式。流式请求对网关的压力模型完全不同网关要与上游保持长连接逐 chunk 转发并且要处理中断、半包、超时等异常。很多网关在非流式压测下表现优秀一旦开启streamtrue性能直接打折。我们的测试结论是网关的流式吞吐瓶颈基本在连接数管理和逐 chunk 的转发实现上。有些网关为了兼容不同供应商的流式格式会在内部做缓冲导致首 token 延迟增加 200ms 以上。这个如果你不压测根本感知不到但在终端用户那里体感非常明显。所以选型时我建议你专门写一个流式压测脚本统计首 token 延迟TTFT和 token 间延迟ITL这两个指标才能真正反映用户体验而不是只看整体请求耗时。6. 实操建议从调研到落地的两个月路线图6.1 第一个月PoC 验证与场景清单不要上来就选型先列场景清单。我们归纳了七类必须验证的场景多模型负载均衡、供应商故障转移、流式兼容、工具调用兼容、多租户配额管理、语义缓存命中率、日志脱敏与审计。然后选定两个候选网关开源一个、商业一个在测试环境各跑两周。PoC 阶段就要把上面所有场景按优先级跑通不要只跑“标准 happy path”。比较重要的一点是PoC 阶段就要把日志接入你现有的监控系统不要用网关自带 UI 看两眼就完事。这能提前暴露出很多集成问题。6.2 第二个月生产灰度与切换灰度阶段的第一个动作是“影子流量”把生产流量的副本打到新网关上只记录不转发真实响应对比两边日志看路由规则是否符合预期、配额统计有没有偏差。影子流量跑稳后再切 5% 真实流量逐步放大到 20%、50%、100%。这里我要特别强调“回滚预案”。LLM 网关和普通 API 网关不一样换了网关之后客户端 SDK 的 base_url 也需要跟着变有些内部服务如果硬编码了旧的调用地址回滚时容易漏所以我们把回滚分为两层一是 DNS 或注册中心层面的入口回滚二是客户端 SDK 配置回滚。两层都要提前准备好。6.3 上线后必须盯住的三个指标上线不等于结束我认为前两周必须盯住三个指标任何一类出现异常都要立即介入端到端错误率趋势重点看 4xx 和 5xx 的分布变化尤其是 429。如果 429 增多往往是网关的限流策略与供应商侧配额没有对齐。按模型维度的成本趋势网关切流后某些模型的调用量可能会因为路由规则与预期不符而异常上涨成本趋势要在日级别做对比。缓存命中率与 Token 成本相关性确认缓存确实在帮你省钱命中率过低的场景要及时关掉或调整策略。这三个指标我们是在 Grafana 上做了单独的 Dashboard和普通业务指标分开避免被流量波动掩盖。6.4 最后的建议不要把网关当成“模型路由说明书”调研了一圈我最大的感受是LLM 网关本质上是一个“策略执行层”真正的策略必须由业务团队和大模型研发团队共同定义。网关能不能发挥作用取决于你对模型的理解有多深、对成本结构有多清楚、对故障场景有多敏感。如果你只是把一个开源网关部署上去把供应商 Key 一填那它顶多算一个高级的反向代理要想让它真正成为企业 LLM 基础设施的一部分还需要持续运营路由策略、排查故障、优化缓存、校准配额。这些功夫没有写进任何一个网关的 README但却是决定成败的关键。
2026 主流 LLM 网关调研报告：选型、架构与实战避坑
主流 LLM 网关调研报告2026 年 9 月我在 2026 年这轮 LLM 网关选型之前其实已经踩过好几次“随手套一个反向代理”的坑。最初只是给内部工具接两三个模型供应商用 FastAPI 写个转发层加上 API Key 管理感觉够了。等到团队把模型接入数量推到十几个、调用链路开始涉及多租户隔离、灰度发布、成本分配和故障转移时那个“够用”的转发层很快就变成了运维黑洞。于是我做了一轮比较系统的 LLM 网关调研从开源方案到商业产品都测了一遍记录下这份报告。它不是什么标准答案但应该能帮你少走一些弯路。1. 为什么到了 2026 年LLM 网关突然成了刚需1.1 从“调 API”到“管流量”需求变了前两年大家聊 LLM核心话题还是“哪个模型效果更好”“Prompt 怎么调”。到了 2026 年模型能力趋同真正的分水岭变成了“你接了多少个模型”“怎么让流量在模型之间平滑调度”“怎么让每个业务线的成本清晰可见”。这时候 LLM 网关就不再是可有可无的中间层而是整个企业级 LLM 应用的流量入口。举一个很实际的例子我们内部有一个综合问答产品要同时支持文本生成、图像理解、结构化输出、长文档分析等能力。早期选了一家综合能力强的供应商后来发现它在特定任务上的效果并不稳定而且单 QPS 成本偏高。于是我们把任务拆开基础 QA 走模型 A复杂推理走模型 B长文档处理走模型 C。这种架构下客户端直接调用任何一个模型都不可行必须有一个网关层来做路由、限流、审计、降级。1.2 2026 年 LLM 网关的核心能力矩阵这两年 LLM 网关的功能边界扩大得非常明显。2024 年你选网关可能只看“支持多少家供应商、能不能统一鉴权、有没有简单的 UI”2026 年再看维度已经完全不一样。我梳理了一份能力矩阵基本覆盖了大部分选型时会关心的点能力项说明重要性多供应商接入是否支持 OpenAI、Anthropic、Azure OpenAI、Gemini、国内主流模型服务等协议极高协议兼容度是否能将非 OpenAI 协议统一转换为 OpenAI 兼容格式极高动态路由按模型能力、成本、延迟、可用性做路由高多租户与权限支持 Key 隔离、用户维度额度管理、审计日志高成本观测按项目、按用户、按模型拆分 token 消费高金丝雀发布新模型上线时按比例灰度中高缓存策略Semantic Cache 还是简单 KV 缓存中高故障转移主供应商挂掉时自动切到备用高数据合规是否支持私有化部署日志是否可审计视场景而定你会发现2026 年的 LLM 网关已经不太像“代理层”更像一个完整的 API 管理平台它不只是帮你转发请求还得帮你看懂流量、管住成本、守住数据边界。1.3 谁最需要 LLM 网关从我们调研接触的团队类型来看大概可以分为三类。第一类是“重度多模型使用者”典型画像是有 3 个以上模型供应商、内部多个业务线共享一套 API 出口。这一类是最刚需的没有网关基本无法做成本归因也无法在某个模型出现故障时快速整体切换。第二类是“有合规需求的平台方”比如做 2B 产品或金融、政务类应用需要完整审计链路的团队。这一类对开源、私有化、数据不落盘有硬性要求单纯的商业 SaaS 网关往往过不了安全评审。第三类是“被调用规模逼着转型的团队”早期是几百 QPS用 FastAPI 转发层勉强能撑当 QPS 过万、KV Cache 需要复用、需要多地域部署时转发层就顶不住了。如果你不属于上述任何一类说实话现阶段接一个单厂商 SDK 直连也能跑。但只要你预计未来半年会新增至少两个模型供应商那网关这件事就得提前考虑了不然后面迁移成本会非常高。2. 开源 vs 商业我实测后的适用边界2.1 开源网关灵活但“运维税”不低我在调研中重点测了三个开源项目LiteLLM、Helicone 的自建版本、Portkey Gateway 的开源版额外关注了 KubeAI 这类将网关与推理平台绑定的方案。如果说一句话总结就是开源方案的 API 接入能力已经非常成熟难的是落在自己机房里的运维与稳定性工程。LiteLLM目前是社区活跃度最高的通用网关配置文件走 YAML支持 100 多家模型供应商基本上面向 OpenAI 生态的模型都可以一键接入。它的好处是轻、灵活、社区问题库响应快坏处是你得自己处理高可用、限流数据的持久化、多实例部署时的配置同步。我们有两次线上抖动排查下来都是因为本地 SQLite 存储并发写导致的。Portkey Gateway开源版更偏“控制面板”风格自带简单的调用日志和缓存配置测试下来在请求转发层面比较稳定。它支持多租户下的 User ID 维度追踪这一点比 LiteLLM 默认能力好用。但开源版功能受到一定限制高级的缓存策略、Guardrails 集成都在商业版里。Helicone自建版的定位更像“可观测性网关”它把日志记录、token 统计、延迟分析这些做得很细。如果你已经有一套稳定的 API 网关不想引入一个重框架只想在 LLM 流量上加一层监控Helicone 是首选。在部署方式上开源方案基本都支持 Docker Compose 和 Kubernetes Helm Chart我们实测下来Helm Chart 部署要比 Docker Compose 稳定很多。Compose 适合单机试用或内部小范围使用一旦上到多副本建议直接上 K8s不然配置管理和日志采集都会很吃力。2.2 商业网关省事但要算清两笔账商业产品这一块我重点调研了 Azure API Management 的 LLM 网关能力、AWS Bedrock 的代理层以及 Kong AI Gateway、Apifox AI Gateway 等偏 API 管理侧的方案。商业方案最大的优势是“不需要自己维护基础设施”网关自带高可用、限流、日志、监控团队只需要管路由规则和 Key 发放。Azure 的 LLM 网关能力在 Azure OpenAI 环境下确实顺手限流和 DDoS 防护都是平台级能力但如果你的模型供应商里有非 Azure 厂商配置复杂度会上升。AWS Bedrock 的体验正好相反你只要在 Bedrock 生态里模型路由和权限管理是完整的但如果你想接 OpenAI 或者国内模型就得走一层自定义集成那商业方案的“省事”优势就打了折扣。Kong AI Gateway 我是比较看好的因为 Kong 本身就是老牌 API 网关LLM 相关的插件做得比较系统支持多供应商接入、动态模型路由、语义缓存等。测试中它的性能损耗非常低单实例转发延迟增加可以控制在 5ms 以内。当然商业方案有显而易见的成本问题。我算了一笔账按我们内部日均 300 万次请求、平均每次进出 8KB 来算公有云原生网关的流量费用和调用费用叠加每个月的增量成本大概是自建网关的 2 到 3 倍。这笔账不是说不值得花而是很多团队在选型时根本没预算进去等账单出来才开始后悔。2.3 哪个更适合你我给的决策建议很简单团队有 K8s 运维能力、模型供应商较多、成本敏感 → 优先开源方案LiteLLM 或 Portkey Gateway。团队在 Azure/AWS 生态内、模型高度绑定单一云厂商 → 优先云原生网关。团队已经有 Kong/APISIX 等 API 网关希望统一管理所有 API 与 LLM 流量 → 优先 Kong AI Gateway。合规要求严、必须私有化、但不想花人力维护开源网关 → 可以考虑商业版私有化部署。这里要额外提醒一句LLM 网关的选型不应该只看“网关”本身还得看你现有的 API 管理体系。如果你们公司本来就有统一的 API 网关那 LLM 网关要么是它的一个插件能力要么就独立部署但复用现有的可观测性系统两条腿走路千万别再引入第三套割裂的日志体系。3. 网关选型时最容易看走眼的五个细节3.1 供应商协议兼容别只看“列表支持”很多网关在宣传页上写着“支持 100 模型供应商”但你真去接的时候会发现所谓“支持”只是支持了某种协议转换。比如某家供应商的接口是 Anthropic 风格但返回的流式格式有细微差异网关如果没有针对性地做适配流式响应就会断。我建议的测试方法是不只测网关文档里列出来的那个 demo 模型而是把你真实用的两三个模型逐一跑通流式、非流式、多模态、工具调用四类场景。我们调研时发现有些网关在工具调用Function Calling/Tool Calling场景下兼容性非常差尤其是目标供应商返回的数据结构里带了额外字段时网关的 schema 校验会把请求直接拦掉。3.2 限流与额度管理的粒度限流这件事很多人以为网关只要有“每秒 X 次”就够。实际用下来真正的关键是额度管理的“维度”你能不能按项目限、按用户限、按模型限、按成本限。我们内部的场景是这样的A 业务线每天有 200 万 token 的预算B 业务线有 500 万如果网关只能做全局限流那 A 的流量冲上来时会把 B 的配额也打穿。好的网关应该支持多层级限额并且能够在限额到达前提前告警。测试时请重点关注配额统计的实时性——很多网关的配额统计是异步的延迟 5 分钟以上这种情况上限流基本等于亡羊补牢。3.3 缓存策略缓存命中的“副作用”缓存是降低成本最直接的手段但缓存策略选不好负面影响比收益更明显。简单 KV 缓存适用场景是“完全相同的 Prompt 反复请求”这在我们的实际业务里很少见。Semantic Cache 则会对请求做向量化把语义相似的请求命中缓存大幅提升命中率但代价是延迟增加和误命中风险。比如用户问“今天天气怎么样”和“今天天气如何”语义基本一样可以命中但“今天天气怎么样”和“明天的天气怎么样”如果向量距离不够远就容易被误命中返回一个过期的答案。我建议生产环境默认关闭 Semantic Cache或者在特定场景下如知识库问答谨慎开启并且对缓存设置较短的 TTL。不要为了节省那一点 token 成本牺牲了答案新鲜度。3.4 多租户隔离不止是“各用各的 Key”多租户隔离很容易被误解成“每个用户一个 API Key”。实际上真正的隔离包含三层身份隔离、配额隔离、数据隔离。身份隔离解决“谁是谁”配额隔离解决“谁可以用多少”数据隔离解决“A 的日志 B 不能看”。需要特别注意的是日志。很多团队在测试网关时只测了转发和鉴权忽略了日志权限。结果上线后所有租户的 Prompt 日志都进了同一个索引任何一个能查询日志的人都能看到所有用户的数据。这在金融、医疗类场景里是严重的合规事故。选型时务必确认日志是否支持租户维度隔离、是否支持脱敏、是否可以只关掉日志记录而保留调用统计。3.5 部署形态单机还是分布式我们一开始图省事用 Docker Compose 部署了单实例 LiteLLM一个月不到就碰到两个问题一是 SQLite 并发写导致配置更新偶发失败二是单点故障。如果你明确知道生产请求量会超过 100 QPS就不要考虑单机部署了。比较稳妥的方案是网关无状态化配置和日志存储外置到 Redis PostgreSQL网关实例可以水平扩容。另外网关后面接模型供应商时供应商侧的限流是另一个瓶颈。即使网关部署在高可用集群上如果它只是均匀地分发请求而某个供应商的账号限流比较严格那依然会出现大量 429。网关最好能感知每个供应商账号的余量。这个能力在开源方案里支持得不算好需要二次开发。4. 双网关策略我的落地参考架构4.1 为什么套两层网关你可能听过一个说法网关套网关是过度设计。但在 LLM 场景下我实测后认为“外层流量网关 内层 LLM 网关”的双层结构是企业级落地最稳的组合理由有三个。第一外层网关解决通用 API 治理问题包括 DDoS 防护、IP 白名单、OAuth2/JWT 鉴权、通用审计这些能力 LLM 网关能做但远不如专业 API 网关扎实。第二内层 LLM 网关解决模型路由、供应商故障转移、成本统计、语义缓存这一层不需要关心 API 通用治理可以做得非常专精。第三双层结构天然支持“多环境隔离”测试环境和生产环境可以在内层网关配置不同的供应商 Key 池。我们现在的生产架构是客户端 → Kong外层 → LiteLLM内层 → 多个模型供应商。4.2 配置数据与日志的流向设计双层网关的好处是职责清楚坏处是如果日志和配置没有设计好就会变成两套割裂的系统。我们最终的做法是Kong 负责记录“谁在什么时间调用了哪个 API”输出到统一日志平台LiteLLM 负责记录“这个请求最终路由到了哪个模型、消费了多少 token、缓存是否命中”同样输出到统一日志平台两边的日志关联字段是同一个RequestID由外层网关生成透传到内层网关最终带到模型供应商侧。有了这个RequestID当用户反馈某个回答有问题时我们可以从入口到模型响应全链路回溯——这在排障时极度有用。4.3 故障转移的配置细节故障转移这件事我提醒你别只配“全局 fallback”更合理的是“按模型能力分组 fallback”。举一个例子主供应商 A 的 GPT-4o 类模型挂了你希望流量切到供应商 B 的同类模型而不是切到供应商 C 的轻量模型。网关需要能区分“同一个语义模型在不同供应商下的等价关系”。目前开源网关的通用做法是在路由规则里配置model_group把不同供应商的等价模型归到同一组然后设定优先级。另外故障转移的触发条件也要仔细测。是连续 5 次 5xx 触发是平均延迟超过 3 秒触发还是供应商健康检查失败触发不同条件适用场景不一样。我们的配置是混合触发连续 10 次 5xx 或连续两分钟 P95 延迟超过 2 秒都会触发切换且在切换前会保留一个手动开关避免在供应商短暂抖动时频繁切换造成二次问题。5. 线上压测数据与一次事故复盘5.1 压测结果对比我们在同一批物理机上压测了 LiteLLM、Portkey Gateway、Kong AI Gateway使用相同的请求负载模型并发 200请求体平均 3.5KB响应平均 8KB持续压测 30 分钟。网关P95 延迟增量最大 QPS失败率备注LiteLLM 单实例12ms8200.02%随后出现配置更新延迟LiteLLM 三副本8ms21000.001%稳定Portkey Gateway15ms18000.005%日志开启时性能下降明显Kong AI Gateway5ms35000.0001%性能最好配置最复杂这里要说明一下压测时的“延迟增量”是网关自身引入的额外延迟不是模型响应延迟。开模型供应商侧的真实响应时间一般都在 1-3 秒所以网关那几十毫秒的增量在单次请求里感知不明显但如果你有大量流式返回、需要网关逐 token 转发那么延迟增量会被放大压测时一定要测流式场景。5.2 事故复盘缓存穿透导致的高延迟有一次线上事故让我印象非常深。某个新业务上线后LiteLLM 的 Semantic Cache 命中率突然降到 12% 以下并且大部分请求都走了向量化计算网关的 CPU 一度跑满最终导致 P95 延迟从 60ms 抖到了 1.8 秒。根因是我们的向量化模型部署在与网关同一台节点上平时流量小的时候没问题但新业务上线后大量语义缓存计算把 CPU 打满了网关本身的转发性能被拖垮。复盘下来有三个教训语义缓存的计算资源要独立部署特别是向量化模型不要和网关 CPU 争资源。缓存未命中的请求要走快速通道不要因为计算缓存而阻塞正常转发。开启缓存前先评估业务的重复请求比例如果大多请求是低重复性的Semantic Cache 带来的收益有限反而增加风险。事故后我们把向量化模型挪到了独立节点并给 Semantic Cache 增加了并发度限制和队列超时CPU 使用率从 85% 降回 30%。5.3 压测中最容易忽略的流式场景如果你只想测一条那一定要测流式。流式请求对网关的压力模型完全不同网关要与上游保持长连接逐 chunk 转发并且要处理中断、半包、超时等异常。很多网关在非流式压测下表现优秀一旦开启streamtrue性能直接打折。我们的测试结论是网关的流式吞吐瓶颈基本在连接数管理和逐 chunk 的转发实现上。有些网关为了兼容不同供应商的流式格式会在内部做缓冲导致首 token 延迟增加 200ms 以上。这个如果你不压测根本感知不到但在终端用户那里体感非常明显。所以选型时我建议你专门写一个流式压测脚本统计首 token 延迟TTFT和 token 间延迟ITL这两个指标才能真正反映用户体验而不是只看整体请求耗时。6. 实操建议从调研到落地的两个月路线图6.1 第一个月PoC 验证与场景清单不要上来就选型先列场景清单。我们归纳了七类必须验证的场景多模型负载均衡、供应商故障转移、流式兼容、工具调用兼容、多租户配额管理、语义缓存命中率、日志脱敏与审计。然后选定两个候选网关开源一个、商业一个在测试环境各跑两周。PoC 阶段就要把上面所有场景按优先级跑通不要只跑“标准 happy path”。比较重要的一点是PoC 阶段就要把日志接入你现有的监控系统不要用网关自带 UI 看两眼就完事。这能提前暴露出很多集成问题。6.2 第二个月生产灰度与切换灰度阶段的第一个动作是“影子流量”把生产流量的副本打到新网关上只记录不转发真实响应对比两边日志看路由规则是否符合预期、配额统计有没有偏差。影子流量跑稳后再切 5% 真实流量逐步放大到 20%、50%、100%。这里我要特别强调“回滚预案”。LLM 网关和普通 API 网关不一样换了网关之后客户端 SDK 的 base_url 也需要跟着变有些内部服务如果硬编码了旧的调用地址回滚时容易漏所以我们把回滚分为两层一是 DNS 或注册中心层面的入口回滚二是客户端 SDK 配置回滚。两层都要提前准备好。6.3 上线后必须盯住的三个指标上线不等于结束我认为前两周必须盯住三个指标任何一类出现异常都要立即介入端到端错误率趋势重点看 4xx 和 5xx 的分布变化尤其是 429。如果 429 增多往往是网关的限流策略与供应商侧配额没有对齐。按模型维度的成本趋势网关切流后某些模型的调用量可能会因为路由规则与预期不符而异常上涨成本趋势要在日级别做对比。缓存命中率与 Token 成本相关性确认缓存确实在帮你省钱命中率过低的场景要及时关掉或调整策略。这三个指标我们是在 Grafana 上做了单独的 Dashboard和普通业务指标分开避免被流量波动掩盖。6.4 最后的建议不要把网关当成“模型路由说明书”调研了一圈我最大的感受是LLM 网关本质上是一个“策略执行层”真正的策略必须由业务团队和大模型研发团队共同定义。网关能不能发挥作用取决于你对模型的理解有多深、对成本结构有多清楚、对故障场景有多敏感。如果你只是把一个开源网关部署上去把供应商 Key 一填那它顶多算一个高级的反向代理要想让它真正成为企业 LLM 基础设施的一部分还需要持续运营路由策略、排查故障、优化缓存、校准配额。这些功夫没有写进任何一个网关的 README但却是决定成败的关键。