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 年再看，维度已经完全不一样。

我梳理了一份能力矩阵，基本覆盖了大部分选型时会关心的点：

你会发现，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 分钟。

这里要说明一下，压测时的“延迟增量”是网关自身引入的额外延迟，不是模型响应延迟。开模型供应商侧的真实响应时间，一般都在 1-3 秒，所以网关那几十毫秒的增量在单次请求里感知不明显，但如果你有大量流式返回、需要网关逐 token 转发，那么延迟增量会被放大，压测时一定要测流式场景。

5.2 事故复盘：缓存穿透导致的高延迟

有一次线上事故让我印象非常深。某个新业务上线后，LiteLLM 的 Semantic Cache 命中率突然降到 12% 以下，并且大部分请求都走了向量化计算，网关的 CPU 一度跑满，最终导致 P95 延迟从 60ms 抖到了 1.8 秒。

根因是我们的向量化模型部署在与网关同一台节点上，平时流量小的时候没问题，但新业务上线后，大量语义缓存计算把 CPU 打满了，网关本身的转发性能被拖垮。复盘下来有三个教训：

1. 语义缓存的计算资源要独立部署，特别是向量化模型，不要和网关 CPU 争资源。
2. 缓存未命中的请求要走快速通道，不要因为计算缓存而阻塞正常转发。
3. 开启缓存前先评估业务的重复请求比例，如果大多请求是低重复性的，Semantic Cache 带来的收益有限，反而增加风险。

事故后我们把向量化模型挪到了独立节点，并给 Semantic Cache 增加了并发度限制和队列超时，CPU 使用率从 85% 降回 30%。

5.3 压测中最容易忽略的流式场景

如果你只想测一条，那一定要测流式。流式请求对网关的压力模型完全不同：网关要与上游保持长连接，逐 chunk 转发，并且要处理中断、半包、超时等异常。很多网关在非流式压测下表现优秀，一旦开启stream=true，性能直接打折。

我们的测试结论是：网关的流式吞吐瓶颈基本在连接数管理和逐 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，但却是决定成败的关键。