2024 年之前我从来没想过大模型网关会成为一个单独的技术品类。当时我们团队只是给内部工具接了个 OpenAI 兼容接口用 Spring Cloud Gateway 转发请求觉得网关么路由转发、限流、鉴权三板斧砍完就结束了。等业务方从十几个涨到一百多个模型从一家扩展到三家日调用量从几千涨到几十万原来的网关在 token 成本、流式响应、模型降级这些场景里接连出问题的时候我才意识到这一整套逻辑是全新的。那段时间我把大模型网关的主流路线都过了一遍阿里开源的 Higress、老牌 API 网关 Kong、以及服务网格背景的 Envoy/Istio。三条路都做了实际的部署和压测也踩了不少文档里不会写的坑。这篇把整个决选过程、背后的技术逻辑和最终的选型建议完整复盘给正在做同样决策的团队一个参考。文章里提到的参数和配置都是我实际跑过的不保证版本永远适用但思路和坑是通用的。1. 为什么大模型网关值得单独研究AI 流量是另一种流量1.1 传统 API 网关的三板斧在 LLM 面前为什么会失效传统 API 网关几十年就干三件事路由、限流、鉴权。这三板斧放在普通 API 上没毛病但放在大模型请求上每一条都会失效。先说限流。传统网关的限流维度是 QPS、并发数、带宽设计前提是每个请求的成本大致相同。LLM 请求完全打破这个前提同一个接口prompt 短的请求几百 token 就完事长的可能几万 tokentoken 数直接决定上游计费和执行时长。按 QPS 限流的网关面对 10 token 的请求和 5 万 token 的请求一视同仁使用方只要把 prompt 无限加长就能把单次调用的成本推高一个量级网关毫无感知。这不是理论推演我们线上就真实出现过有人用脚本批量跑长文本生成把一个月的预算额度在三天内烧光的案例。再说鉴权。传统网关的 key 体系是接口级的这个 key 可以调 A 接口但不能调 B 接口大概就到底了。大模型场景需要回答的是更商业化的三个问题这个调用方这个月还能用多少 token、这个部门离预算上限还有多远、某个模型的价格变化之后配额要不要跟着调。这是成本治理和配额系统的问题单纯的 key 校验根本覆盖不了。然后是上游的失败模型。传统 API 的上游大多是我们自己部署的服务故障率低、失败形态简单一个健康检查加超时重试基本够用。LLM 供应商完全不是一个画风官方接口有 per-minute token 限制和并发上限国内模型厂商高峰期 429 和 5xx 率高得惊人而且各家限流策略还不一样。网关必须有模型级 failover和降级路由的能力当主供应商限流时自动把流量切到备用模型同时还要保证终端用户拿到的响应格式不变。这个需求在传统 API 网关里基本不存在你不可能把自己的核心服务做成自动切换到竞品服务。最后是流式响应。LLM 几乎都是 SSE 流式返回传统网关对响应要么整包缓冲要么无脑透传。整包缓冲会让用户等几十秒才看到第一个字无脑透传又绕过了网关的日志、限流和计量逻辑。更麻烦的是超时处理模型生成过程中停顿几秒是正常现象但传统网关的 idle timeout 会把这种停顿误判为连接空闲然后掐断。我们第一版用传统网关代理流式接口时用户经常反映响应快到结尾突然断了排查到最后就是超时参数在作怪。1.2 从 LLM 请求的五个特征反推网关能力清单所以大模型网关到底该有什么能力我不看厂商的功能列表直接从请求特征往前推。第一个特征是多供应商。调用方不应该在代码里写死某个模型厂商的 endpoint 和 key网关必须做一层 provider 抽象统一协议、统一鉴权、统一计量。这层抽象是所有 AI 治理能力的地基没有它模型灰度、双跑、降级全都是空谈。第二个特征是成本敏感。网关要能解析请求和响应实时估算 token 消耗按调用方、用户、租户维度做配额管理。这个 key 这个月最多 1000 万 token突发上限每分钟 5 万 token这类规则传统网关写不出来。第三个特征是上游不稳定。网关得能识别上游限流码、超时、连接异常自动执行 fallback。关键点是 fallback 之后响应格式不能变调用方无感知。第四个特征是流式优先。网关需要支持边收边转的流式转发并且为 SSE 单独设置超时参数不能拿传统请求的套路套流式。第五个特征是语义层面的需求。传统网关的缓存是按 URL 缓存AI 场景需要的是按语义相似度缓存两个 prompt 问的是同一件事直接返回历史响应传统网关的防火墙看 IP 和 headerAI 场景要看 prompt 内容里有没有注入攻击。这些都是新能力。把这五份清单摆出来再回头看大模型网关是不是传统网关换皮这个问题答案已经很清楚了如果只做了接一个 OpenAI 格式的上游那确实是换皮能把上面五件事做扎实这就是一个独立品类。下面依次看 Higress、Kong 和 Envoy/Istio 三条路是怎么做的。2. Higress把 AI 原生写进默认行为的网关新物种2.1 一个 Provider 抽象屏蔽所有大模型厂商Higress 是阿里开源的一款云原生网关底层是 Envoy控制面兼容 Istio 规范。它有两种用法在 K8s 里作为独立 API 网关部署也能作为服务网格的一部分以 Sidecar 形态运行。如果只是想要一个网关节点Helm 一条命令装完不需要拉整套 Istio 控制面这个轻量性对很多团队来说是加分项。Higress 在 AI 场景的核心是 AI Proxy 插件。它把各家大模型供应商收敛成统一的 provider 抽象支持 OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini以及国内的通义、智谱、DeepSeek 等。对调用方来说上游就是一套 OpenAI 兼容的/v1/chat/completions接口对网关来说每个 provider 单独配置 API key、base URL、模型名映射。业务代码里再也不用出现如果调用的是哪家模型就走哪个分支这种代码了换供应商只改网关配置。我实际做了一件事把三家模型接到同一个 endpoint 后面所有业务方的调用全部指向这一个新的统一入口散落在代码里的 provider 判断全部删除。这个收敛动作带来的价值比任何功能都大因为它让整个系统的 AI 接入方式从一个混沌状态变成了单一入口之后的权限、配额、成本追踪全部有了落脚点。如果你现在还没有做这层抽象那么不管选哪个网关第一步都应该干这件事。2.2 token 级限流、模型路由与语义缓存是怎么落地的Higress 的限流是真正按 token 算的。它拿到请求之后先估算 prompt 的 token 消耗拿到响应之后再根据 usage 统计输出 token然后按每分钟 token 数每天 token 数这类维度做限流限流 key 可以是调用方 API key、用户、租户或者任意请求头。这套逻辑和传统网关的 QPS 限流完全是两代东西。我们线上配置的是每人每天 20 万 token每分钟不能超过 3 万 token一旦超限返回 429 和具体的配额提示业务方看到提示就能明白是怎么触发的不再像以前一样对着一个笼统的 429 抓瞎。模型路由方面Higress 支持按请求参数模型名、请求头、客户端 IP把流量分发到不同 provider同一个模型名背后可以挂两家的灰度组权重从 0 调到 100也支持 failover主 provider 返回 429、5xx 或者超时时自动切到备用 provider。这个能力我直接当过安全垫用有一次某家厂商大规模限流线上调用没有出现用户看到错误提示的情况只是 P95 延迟从 1.2 秒涨到了 2.5 秒左右业务方完全没感知到异常。语义缓存是 Higress 的一个新特性。它的原理是把 prompt 做向量化用相似度判断这个请求之前有没有问过类似的问题命中就直接返回缓存的历史响应省成本也降延迟。我实测下来的结论是对带固定 system prompt、问法相对固定的内部知识问答场景命中率不错对高度个性化的对话场景命中率很低光算向量化的开销可能比缓存省下来的钱还多。所以我的建议是把它当优化手段而不是功能门槛先用普通 response cache 拿到基础收益语义缓存按需开启并且一定要设好相似度阈值别误命中。2.3 部署 Higress 时我踩过的三个实际坑第一个坑是 Wasm 插件的开发和交付。Higress 的插件体系基于 Wasm自研插件得装 TinyGo 或 Go 工具链编译产物是.wasm文件改了逻辑就要重新编译、重新发布。我当时想给一个限流逻辑加个维度发现官方仓库里都是编译好的产物想改只能自己搭工具链。建议是优先用官方插件把场景跑通自研插件控制数量并且提前把编译和发布流程做成 CI 的一部分不然每次改插件都是一次痛苦的体力活。第二个坑是流式转发的超时参数。第一版部署之后SSE 对话接口经常出现快结束时突然断开的现象。查了不少时间最后定位到是 Envoy 层的 idle timeout 在起作用模型生成过程中只要停顿超过阈值连接就被判定为空闲然后掐断。解决方式是给 AI 相关路由单独设置较大的 idle timeout并且确认 Higress 的 AI 插件对 streaming 模式不会启用整包缓冲。这类问题你在压测里很难发现因为压测脚本不会模拟真实的思考停顿一定要在联调阶段用真实对话反复测。第三个坑是版本迭代太快。Higress 的 AI 功能更新非常频繁GitHub 上的示例 YAML 和当前版本的字段经常对不上。我在部署时就遇到过照着最新 README 写配置结果参数名已经改了的尴尬。建议落地时把 Helm 图表版本、文档版本、插件版本全部固定并记录下来别一上来就抄最新文档。另外独立网关模式下只需要装网关本身整个 Istio 控制面是自带在 Higress 里的别被老教程误导去额外装一套 mesh。3. Kong成熟 API 网关上的 AI 插件集稳但看版本3.1 Kong 的 AI 能力到底在哪个版本、哪个包里Kong 是老牌 API 网关基于 Nginx/OpenResty生态成熟度很高。它在 AI 方向的答案是AI Gateway 插件集AI Proxy 负责对接各家 LLM、AI Rate Limiting Advanced 按 token 限流、AI Semantic Cache 做语义缓存、AI Prompt Guard 做提示词注入检测等。但这里第一个坑就是版本和产品线的分布。Kong 的 AI 插件不是都在开源版里。我实测下来开源版 Kong Gateway 能稳定跑的只有 AI Proxy 这类基础插件token 级限流、语义缓存这些更深的功能通常在 Enterprise 和 Konnect云托管版里。如果你冲着AI 网关去选 Kong第一步不是看功能清单而是确认公司能不能接受商业授权再对照授权方案评估功能千万别拿 OSS 的功能表做选型决策。Kong 的 AI Proxy 插件本身做得还算顺手配置一个 provider 就是一段 JSON支持 OpenAI 格式和多种国内模型。它对已有的 Kong 用户来说非常友好因为接入 AI 不需要改架构原来的 route、service、plugin 体系直接复用。这也是 Kong 做 AI 网关最大的优势存量体系平滑升级不需要推倒重来。3.2 节点主动健康检查配置Kong Manager 里最容易被忽略的地方最近kong manager 节点主动健康检查配置这个搜索很热我们也在这上面栽过跟头。Kong 的上游健康检查分主动和被动主动检查是 Kong 按固定间隔主动给上游节点发探活请求能在故障发生前就摘掉节点被动检查是从真实流量里统计失败率只能在故障已经影响流量之后才响应。生产环境必须两个都配只靠被动检查的话节点故障后的前几秒请求还是会被打过去产生一堆 5xx。关于主动健康检查最常见的配置了但没生效的坑是interval参数。Kong 的 healthchecks 配置里active.healthy.interval和active.unhealthy.interval是 0 时主动检查是关闭的必须显式设置大于 0 的秒数探活才会跑。很多人从文档里复制了一段配置发现节点挂了依然被请求一查就是 interval 还是 0。另一个典型的坑是http_path的探活路径。默认是/但很多服务的根路径返回 404 或者 3xx不在 healthy 状态码列表里导致健康节点被误判为不健康。要么配置一个上游确定返回 200 的轻量路径要么把实际状态码加进healthy.http_statuses。在 Kong Manager 里的操作路径是Upstreams → 选中 upstream → Targets 标签页 → Health Checks 配置区。但注意Kong Manager 只是管理控制台改的是声明配置最终通过 Admin API 写入数据库再通过 deck 同步。重要配置建议用 deck 文件维护而不是在 UI 里点否则下次deck sync会把 UI 里的手工改动覆盖掉。这个UI 改了但没生效的坑比健康检查参数本身还要隐蔽。还有一个 LLM 场景特有的问题对模型厂商做主动健康检查时探活请求一定要轻。不要真的去调/v1/chat/completions那既耗费成本又会触发厂商限流。我生产环境里给模型 provider 配的是一个简单的/health路径间隔设置在 15 秒以上效果稳定。3.3 什么团队适合继续选 Kong虽然我吐槽了 Kong 在 AI 功能上的版本分布但它的老本行依然过硬文档完整、插件生态大、商业支持体系完善、Nginx 系运维经验好找。我的判断是三类团队适合留在 Kong 上。第一类公司早就把 Kong 用成了基础设施存量 API 多、团队运维体系成熟。这种情况下换网关的成本远大于 AI 功能收益在现有 Kong 上叠加 AI 插件是正确选择不是盲目求新。第二类AI 场景很简单只需要一个 OpenAI 格式的统一代理不追求 token 级配额和高级语义能力Kong 开源版完全够用。第三类对商业支持、合规审计有硬要求的传统行业Konnect 的托管形态能显著降低运维人力。反过来如果团队是从零起步、环境是 K8s 原生、AI 流量占比会很快上升那 Kong 的 AI 能力本质上是在传统骨架上叠加插件越往后越会感觉它是补丁不是底座。很多 AI Agent 场景要的 MCP 网关能力、语义级路由、模型灰度编排对 Kong 来说都做得很别扭。这种情况我建议直接看原生支持 AI 的网关。4. Envoy/Istio用服务网格组装 AI 网关上限最高也最费人4.1 Envoy 自带的能力里哪些可以直接用于 AI 场景Envoy 是数据面的事实标准Higress 底层也是它。如果团队足够硬核直接用 Envoy/Istio 自己组装 AI 网关完全可行而且自由度最高。先说 Envoy 原生能力里哪些可以直接用。路由层面Envoy 支持按 header、path、query 参数做转发权重灰度是标配两个模型供应商之间的流量切分直接用 route weight 就能做。限流层面本地限流和全局限流都支持全局限流通过外部的 rate limit service 实现配合自定义维度可以做到按 API key 计数级别的限流。可观测层面Envoy 的 access log、metrics、trace 集成都非常成熟AI 调用的延迟、状态码、流量轨迹可以完整记录。这些传统能力在 AI 场景依然有效。扩展层面有两条路ext_proc 外部处理过滤器和 Wasm 过滤器。ext_proc 是把请求和响应转发给一个外部 gRPC 服务外部服务可以改 header、改 body、决定放行还是拒绝Wasm 过滤器是在 Envoy 进程里直接跑自定义逻辑性能更好但开发门槛更高。这两条路我都测试过后面细说。4.2 从 VirtualService 到 WasmPluginIstio 落地 AI 网关的三种模式在 Istio 体系里我把 AI 网关能力拆成三层来落。第一层是纯路由直接用 VirtualService 实现。比如同一个模型名背后挂两个 provider 的 Cluster用 header 或者权重做灰度。这一层不需要写代码一个 YAML 搞定。我们当时做过给内部用户走便宜模型、给外部用户走高质量模型的灰度就是这个思路。第二层是协议转换和语义处理用 EnvoyFilter 接 ext_proc。ext_proc 的处理模式有两种同步模式和流式模式。对 LLM 这种大 body 的请求我强烈建议用流式模式边收边处理不要等地步拿到完整 body 再返回否则内存和延迟都扛不住。我们把 prompt 安全检测和敏感信息过滤放在了 ext_proc 服务里效果不错但引入的额外延迟在 50-100ms 级别需要接受这个成本。第三层是 token 限流、语义缓存这类核心 AI 逻辑用 WasmPlugin 挂进 Envoy。Istio 的 WasmPlugin CRD 可以把自定义 Wasm 过滤器挂到网关或 Sidecar 上。这里有个现实问题Wasm 开发的调试成本非常高沙箱对网络、内存访问有限制写一个能正确统计 token 并执行限流的插件要花掉的时间远超在普通服务里写同样逻辑。我们当时评估过一个成熟的 infrastructure 工程师做 token 计数插件至少两周起。这三层模式的组合方案很灵活但也意味着你拥有了全部事情都要自己做的自由。4.3 网格方案的成本账能用但要会算用 Envoy/Istio 组装 AI 网关上限确实最高不受任何厂商的功能边界限制想要什么能力都能自己写。但这笔账必须算清楚你需要的不是一串 Envoy 配置而是一个完整的产品。产品是什么概念provider 抽象要自己设计token 计费模型要自己定模型路由要自己写控制逻辑成本报表要自己搭。这些在 Higress 里是开箱即用的在 Envoy/Istio 路线里全是待办项。我们当时粗略估算过一个方案一个三人小组把最核心的多模型路由 token 配额 基础语义缓存做出来大概要三个月还不包括后续的持续维护和迭代。而这三个人的投入放在业务上可能早就把 AI 功能做进好几个业务线了。所以我的结论很明确自建路线适合公司就是要打造自研 AI 基础设施平台并且已经拥有一支很强的 Envoy 和基础设施开发团队的场景。如果你只是业务团队需要尽快把大模型能力接进来这条路是成本最不划算的。网格给的是自由度不是效率。5. 横向对比、选型矩阵和我的最终建议5.1 一张表看三者的 AI 能力差距把三条路线放在一起按我实际用下来的体验打分这张表可以直观反映差异对比维度HigressKongEnvoy/Istio多供应商 Provider 抽象开箱即用插件原生支持AI Proxy 插件OSS/EE 功能有别完全自研token 级限流与配额原生支持按 token 计量需要高级插件多在 EE 版自研工作量大模型灰度与自动降级原生支持权重和 fallback 都有需要叠加配置可做但编排复杂语义缓存原生支持高级插件多在 EE 版自研流式响应处理针对 SSE 做了优化可用但需要手动调超时需要手动调优上手成本低Helm 一条命令中依赖 PostgreSQL 和传统运维体系高需要 Envoy 功底生态成熟度国内社区活跃迭代快全球生态成熟文档完善全球主流标准适合的团队技术底色K8s 云原生团队传统企业级 API 管理团队基础设施自研团队这张表的逻辑很清楚Higress 是AI 原生设计Kong 是传统骨架 AI 插件Envoy/Istio 是原材料自己加工。三者没有绝对的优劣只有匹配度的问题。5.2 三种团队画像对应的选型答案第一种画像从零起步环境是 K8s团队没有既往网关资产AI 流量预计会快速增长。这种团队我建议直接选 Higress。理由很简单AI 能力不用自己搭网关和 K8s 生态无缝集成Helm 一装就有完整的 provider 抽象、token 级限流、模型路由。先用最快速度跑通业务以后再考虑要不要更 deep 的自研。第二种画像公司早就把 Kong尤其是 Enterprise 版用成了基础设施存量 API 很多AI 只是新增的一小部分流量。这种团队留在 Kong 是对的。强行替换网关的成本太大了在 Kong 上叠加 AI Proxy 和健康检查配置足以覆盖大多数常规场景。等 AI 占比大到 Kong 撑不住的时候再考虑下一步。第三种画像公司要自建 AI 基础设施平台AI 能力本身是核心竞争力团队有很强的 Envoy 和基础设施研发能力。这种团队选 Envoy/Istio 自研是合理的因为只有完全控制数据面逻辑才能做出和别人有差异化的东西。第四种画像我也遇到过团队想要 AI 网关能力但不想背 Higress 这种迭代节奏快的开源项目的版本包袱又觉得 Kong 的授权费用不好谈自己也没能力做 Envoy 自研。这种情况我的建议是再评估一次大概率 Higress 还是综合成本最低的选择因为国产开源项目的中文文档和社区支持对国内团队友好很多。5.3 无论你选谁这几条经验先收好选型之外有几条经验是从这三个方案里横着踩出来的跟网关无关但跟 AI 流量治理强相关。第一Provider 抽象一定要做在网关上而不是业务代码里。不管你选哪个网关第一步就是把调用哪家模型这个决策收敛到网关层。做过一次你就知道之后所有模型切换、灰度、降级都会变得无比顺滑。第二token 级配额比 QPS 限流重要得多。QPS 限流治标token 配额治本。只要你的业务方有成本意识就一定会需要这个月还能用多少 token这个答案没有这个能力的网关注定走不远。第三语义缓存要谨慎配置。它动的是响应内容涉及数据合规。在开启语义缓存之前先确认哪些数据允许被缓存哪些不能客户敏感信息一旦被缓存命中就是事故。普通 response cache 也是一样要加 TTL 和数据范围限制。第四流式响应的超时参数必须单独设置。SSE 的空闲不是传统意义的空闲模型思考时停顿几十秒都正常。只要看到流式响应后端正常、但经过网关后总在某个时间点断开第一反应就应该是查 idle timeout。第五主动健康检查一定要配但探活目标要轻。主动健康检查能提前摘除故障的模型供应商避免请求被打到已经挂掉的上游但探活请求不要调真实的模型接口一个轻量/health路径就够了否则探活本身就在烧钱、触发限流。最后说点我个人的体会。大模型网关这个领域变化太快了我写这篇文章时的一些功能点可能过几个月就有更好的方案。但不管怎么变有一个原则不会变网关这种位置最重要的不是它现在有多少功能而是当你需要换掉一个供应商、换掉一种模型、换掉一套策略的时候它能不能让你轻松做到。我在 Higress 上花的时间大部分收益其实都落在这件事上。如果让我重新选一次我还是会在项目第一天就把 provider 抽象做在网关层至于网关本身选哪家反而是次要问题了。 
长河君 · 2026/10/31 9:14:45 · 阅读 1.2k 大模型网关选型实战：Higress、Kong与Envoy/Istio深度对比
2024 年之前我从来没想过大模型网关会成为一个单独的技术品类。当时我们团队只是给内部工具接了个 OpenAI 兼容接口用 Spring Cloud Gateway 转发请求觉得网关么路由转发、限流、鉴权三板斧砍完就结束了。等业务方从十几个涨到一百多个模型从一家扩展到三家日调用量从几千涨到几十万原来的网关在 token 成本、流式响应、模型降级这些场景里接连出问题的时候我才意识到这一整套逻辑是全新的。那段时间我把大模型网关的主流路线都过了一遍阿里开源的 Higress、老牌 API 网关 Kong、以及服务网格背景的 Envoy/Istio。三条路都做了实际的部署和压测也踩了不少文档里不会写的坑。这篇把整个决选过程、背后的技术逻辑和最终的选型建议完整复盘给正在做同样决策的团队一个参考。文章里提到的参数和配置都是我实际跑过的不保证版本永远适用但思路和坑是通用的。1. 为什么大模型网关值得单独研究AI 流量是另一种流量1.1 传统 API 网关的三板斧在 LLM 面前为什么会失效传统 API 网关几十年就干三件事路由、限流、鉴权。这三板斧放在普通 API 上没毛病但放在大模型请求上每一条都会失效。先说限流。传统网关的限流维度是 QPS、并发数、带宽设计前提是每个请求的成本大致相同。LLM 请求完全打破这个前提同一个接口prompt 短的请求几百 token 就完事长的可能几万 tokentoken 数直接决定上游计费和执行时长。按 QPS 限流的网关面对 10 token 的请求和 5 万 token 的请求一视同仁使用方只要把 prompt 无限加长就能把单次调用的成本推高一个量级网关毫无感知。这不是理论推演我们线上就真实出现过有人用脚本批量跑长文本生成把一个月的预算额度在三天内烧光的案例。再说鉴权。传统网关的 key 体系是接口级的这个 key 可以调 A 接口但不能调 B 接口大概就到底了。大模型场景需要回答的是更商业化的三个问题这个调用方这个月还能用多少 token、这个部门离预算上限还有多远、某个模型的价格变化之后配额要不要跟着调。这是成本治理和配额系统的问题单纯的 key 校验根本覆盖不了。然后是上游的失败模型。传统 API 的上游大多是我们自己部署的服务故障率低、失败形态简单一个健康检查加超时重试基本够用。LLM 供应商完全不是一个画风官方接口有 per-minute token 限制和并发上限国内模型厂商高峰期 429 和 5xx 率高得惊人而且各家限流策略还不一样。网关必须有模型级 failover和降级路由的能力当主供应商限流时自动把流量切到备用模型同时还要保证终端用户拿到的响应格式不变。这个需求在传统 API 网关里基本不存在你不可能把自己的核心服务做成自动切换到竞品服务。最后是流式响应。LLM 几乎都是 SSE 流式返回传统网关对响应要么整包缓冲要么无脑透传。整包缓冲会让用户等几十秒才看到第一个字无脑透传又绕过了网关的日志、限流和计量逻辑。更麻烦的是超时处理模型生成过程中停顿几秒是正常现象但传统网关的 idle timeout 会把这种停顿误判为连接空闲然后掐断。我们第一版用传统网关代理流式接口时用户经常反映响应快到结尾突然断了排查到最后就是超时参数在作怪。1.2 从 LLM 请求的五个特征反推网关能力清单所以大模型网关到底该有什么能力我不看厂商的功能列表直接从请求特征往前推。第一个特征是多供应商。调用方不应该在代码里写死某个模型厂商的 endpoint 和 key网关必须做一层 provider 抽象统一协议、统一鉴权、统一计量。这层抽象是所有 AI 治理能力的地基没有它模型灰度、双跑、降级全都是空谈。第二个特征是成本敏感。网关要能解析请求和响应实时估算 token 消耗按调用方、用户、租户维度做配额管理。这个 key 这个月最多 1000 万 token突发上限每分钟 5 万 token这类规则传统网关写不出来。第三个特征是上游不稳定。网关得能识别上游限流码、超时、连接异常自动执行 fallback。关键点是 fallback 之后响应格式不能变调用方无感知。第四个特征是流式优先。网关需要支持边收边转的流式转发并且为 SSE 单独设置超时参数不能拿传统请求的套路套流式。第五个特征是语义层面的需求。传统网关的缓存是按 URL 缓存AI 场景需要的是按语义相似度缓存两个 prompt 问的是同一件事直接返回历史响应传统网关的防火墙看 IP 和 headerAI 场景要看 prompt 内容里有没有注入攻击。这些都是新能力。把这五份清单摆出来再回头看大模型网关是不是传统网关换皮这个问题答案已经很清楚了如果只做了接一个 OpenAI 格式的上游那确实是换皮能把上面五件事做扎实这就是一个独立品类。下面依次看 Higress、Kong 和 Envoy/Istio 三条路是怎么做的。2. Higress把 AI 原生写进默认行为的网关新物种2.1 一个 Provider 抽象屏蔽所有大模型厂商Higress 是阿里开源的一款云原生网关底层是 Envoy控制面兼容 Istio 规范。它有两种用法在 K8s 里作为独立 API 网关部署也能作为服务网格的一部分以 Sidecar 形态运行。如果只是想要一个网关节点Helm 一条命令装完不需要拉整套 Istio 控制面这个轻量性对很多团队来说是加分项。Higress 在 AI 场景的核心是 AI Proxy 插件。它把各家大模型供应商收敛成统一的 provider 抽象支持 OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini以及国内的通义、智谱、DeepSeek 等。对调用方来说上游就是一套 OpenAI 兼容的/v1/chat/completions接口对网关来说每个 provider 单独配置 API key、base URL、模型名映射。业务代码里再也不用出现如果调用的是哪家模型就走哪个分支这种代码了换供应商只改网关配置。我实际做了一件事把三家模型接到同一个 endpoint 后面所有业务方的调用全部指向这一个新的统一入口散落在代码里的 provider 判断全部删除。这个收敛动作带来的价值比任何功能都大因为它让整个系统的 AI 接入方式从一个混沌状态变成了单一入口之后的权限、配额、成本追踪全部有了落脚点。如果你现在还没有做这层抽象那么不管选哪个网关第一步都应该干这件事。2.2 token 级限流、模型路由与语义缓存是怎么落地的Higress 的限流是真正按 token 算的。它拿到请求之后先估算 prompt 的 token 消耗拿到响应之后再根据 usage 统计输出 token然后按每分钟 token 数每天 token 数这类维度做限流限流 key 可以是调用方 API key、用户、租户或者任意请求头。这套逻辑和传统网关的 QPS 限流完全是两代东西。我们线上配置的是每人每天 20 万 token每分钟不能超过 3 万 token一旦超限返回 429 和具体的配额提示业务方看到提示就能明白是怎么触发的不再像以前一样对着一个笼统的 429 抓瞎。模型路由方面Higress 支持按请求参数模型名、请求头、客户端 IP把流量分发到不同 provider同一个模型名背后可以挂两家的灰度组权重从 0 调到 100也支持 failover主 provider 返回 429、5xx 或者超时时自动切到备用 provider。这个能力我直接当过安全垫用有一次某家厂商大规模限流线上调用没有出现用户看到错误提示的情况只是 P95 延迟从 1.2 秒涨到了 2.5 秒左右业务方完全没感知到异常。语义缓存是 Higress 的一个新特性。它的原理是把 prompt 做向量化用相似度判断这个请求之前有没有问过类似的问题命中就直接返回缓存的历史响应省成本也降延迟。我实测下来的结论是对带固定 system prompt、问法相对固定的内部知识问答场景命中率不错对高度个性化的对话场景命中率很低光算向量化的开销可能比缓存省下来的钱还多。所以我的建议是把它当优化手段而不是功能门槛先用普通 response cache 拿到基础收益语义缓存按需开启并且一定要设好相似度阈值别误命中。2.3 部署 Higress 时我踩过的三个实际坑第一个坑是 Wasm 插件的开发和交付。Higress 的插件体系基于 Wasm自研插件得装 TinyGo 或 Go 工具链编译产物是.wasm文件改了逻辑就要重新编译、重新发布。我当时想给一个限流逻辑加个维度发现官方仓库里都是编译好的产物想改只能自己搭工具链。建议是优先用官方插件把场景跑通自研插件控制数量并且提前把编译和发布流程做成 CI 的一部分不然每次改插件都是一次痛苦的体力活。第二个坑是流式转发的超时参数。第一版部署之后SSE 对话接口经常出现快结束时突然断开的现象。查了不少时间最后定位到是 Envoy 层的 idle timeout 在起作用模型生成过程中只要停顿超过阈值连接就被判定为空闲然后掐断。解决方式是给 AI 相关路由单独设置较大的 idle timeout并且确认 Higress 的 AI 插件对 streaming 模式不会启用整包缓冲。这类问题你在压测里很难发现因为压测脚本不会模拟真实的思考停顿一定要在联调阶段用真实对话反复测。第三个坑是版本迭代太快。Higress 的 AI 功能更新非常频繁GitHub 上的示例 YAML 和当前版本的字段经常对不上。我在部署时就遇到过照着最新 README 写配置结果参数名已经改了的尴尬。建议落地时把 Helm 图表版本、文档版本、插件版本全部固定并记录下来别一上来就抄最新文档。另外独立网关模式下只需要装网关本身整个 Istio 控制面是自带在 Higress 里的别被老教程误导去额外装一套 mesh。3. Kong成熟 API 网关上的 AI 插件集稳但看版本3.1 Kong 的 AI 能力到底在哪个版本、哪个包里Kong 是老牌 API 网关基于 Nginx/OpenResty生态成熟度很高。它在 AI 方向的答案是AI Gateway 插件集AI Proxy 负责对接各家 LLM、AI Rate Limiting Advanced 按 token 限流、AI Semantic Cache 做语义缓存、AI Prompt Guard 做提示词注入检测等。但这里第一个坑就是版本和产品线的分布。Kong 的 AI 插件不是都在开源版里。我实测下来开源版 Kong Gateway 能稳定跑的只有 AI Proxy 这类基础插件token 级限流、语义缓存这些更深的功能通常在 Enterprise 和 Konnect云托管版里。如果你冲着AI 网关去选 Kong第一步不是看功能清单而是确认公司能不能接受商业授权再对照授权方案评估功能千万别拿 OSS 的功能表做选型决策。Kong 的 AI Proxy 插件本身做得还算顺手配置一个 provider 就是一段 JSON支持 OpenAI 格式和多种国内模型。它对已有的 Kong 用户来说非常友好因为接入 AI 不需要改架构原来的 route、service、plugin 体系直接复用。这也是 Kong 做 AI 网关最大的优势存量体系平滑升级不需要推倒重来。3.2 节点主动健康检查配置Kong Manager 里最容易被忽略的地方最近kong manager 节点主动健康检查配置这个搜索很热我们也在这上面栽过跟头。Kong 的上游健康检查分主动和被动主动检查是 Kong 按固定间隔主动给上游节点发探活请求能在故障发生前就摘掉节点被动检查是从真实流量里统计失败率只能在故障已经影响流量之后才响应。生产环境必须两个都配只靠被动检查的话节点故障后的前几秒请求还是会被打过去产生一堆 5xx。关于主动健康检查最常见的配置了但没生效的坑是interval参数。Kong 的 healthchecks 配置里active.healthy.interval和active.unhealthy.interval是 0 时主动检查是关闭的必须显式设置大于 0 的秒数探活才会跑。很多人从文档里复制了一段配置发现节点挂了依然被请求一查就是 interval 还是 0。另一个典型的坑是http_path的探活路径。默认是/但很多服务的根路径返回 404 或者 3xx不在 healthy 状态码列表里导致健康节点被误判为不健康。要么配置一个上游确定返回 200 的轻量路径要么把实际状态码加进healthy.http_statuses。在 Kong Manager 里的操作路径是Upstreams → 选中 upstream → Targets 标签页 → Health Checks 配置区。但注意Kong Manager 只是管理控制台改的是声明配置最终通过 Admin API 写入数据库再通过 deck 同步。重要配置建议用 deck 文件维护而不是在 UI 里点否则下次deck sync会把 UI 里的手工改动覆盖掉。这个UI 改了但没生效的坑比健康检查参数本身还要隐蔽。还有一个 LLM 场景特有的问题对模型厂商做主动健康检查时探活请求一定要轻。不要真的去调/v1/chat/completions那既耗费成本又会触发厂商限流。我生产环境里给模型 provider 配的是一个简单的/health路径间隔设置在 15 秒以上效果稳定。3.3 什么团队适合继续选 Kong虽然我吐槽了 Kong 在 AI 功能上的版本分布但它的老本行依然过硬文档完整、插件生态大、商业支持体系完善、Nginx 系运维经验好找。我的判断是三类团队适合留在 Kong 上。第一类公司早就把 Kong 用成了基础设施存量 API 多、团队运维体系成熟。这种情况下换网关的成本远大于 AI 功能收益在现有 Kong 上叠加 AI 插件是正确选择不是盲目求新。第二类AI 场景很简单只需要一个 OpenAI 格式的统一代理不追求 token 级配额和高级语义能力Kong 开源版完全够用。第三类对商业支持、合规审计有硬要求的传统行业Konnect 的托管形态能显著降低运维人力。反过来如果团队是从零起步、环境是 K8s 原生、AI 流量占比会很快上升那 Kong 的 AI 能力本质上是在传统骨架上叠加插件越往后越会感觉它是补丁不是底座。很多 AI Agent 场景要的 MCP 网关能力、语义级路由、模型灰度编排对 Kong 来说都做得很别扭。这种情况我建议直接看原生支持 AI 的网关。4. Envoy/Istio用服务网格组装 AI 网关上限最高也最费人4.1 Envoy 自带的能力里哪些可以直接用于 AI 场景Envoy 是数据面的事实标准Higress 底层也是它。如果团队足够硬核直接用 Envoy/Istio 自己组装 AI 网关完全可行而且自由度最高。先说 Envoy 原生能力里哪些可以直接用。路由层面Envoy 支持按 header、path、query 参数做转发权重灰度是标配两个模型供应商之间的流量切分直接用 route weight 就能做。限流层面本地限流和全局限流都支持全局限流通过外部的 rate limit service 实现配合自定义维度可以做到按 API key 计数级别的限流。可观测层面Envoy 的 access log、metrics、trace 集成都非常成熟AI 调用的延迟、状态码、流量轨迹可以完整记录。这些传统能力在 AI 场景依然有效。扩展层面有两条路ext_proc 外部处理过滤器和 Wasm 过滤器。ext_proc 是把请求和响应转发给一个外部 gRPC 服务外部服务可以改 header、改 body、决定放行还是拒绝Wasm 过滤器是在 Envoy 进程里直接跑自定义逻辑性能更好但开发门槛更高。这两条路我都测试过后面细说。4.2 从 VirtualService 到 WasmPluginIstio 落地 AI 网关的三种模式在 Istio 体系里我把 AI 网关能力拆成三层来落。第一层是纯路由直接用 VirtualService 实现。比如同一个模型名背后挂两个 provider 的 Cluster用 header 或者权重做灰度。这一层不需要写代码一个 YAML 搞定。我们当时做过给内部用户走便宜模型、给外部用户走高质量模型的灰度就是这个思路。第二层是协议转换和语义处理用 EnvoyFilter 接 ext_proc。ext_proc 的处理模式有两种同步模式和流式模式。对 LLM 这种大 body 的请求我强烈建议用流式模式边收边处理不要等地步拿到完整 body 再返回否则内存和延迟都扛不住。我们把 prompt 安全检测和敏感信息过滤放在了 ext_proc 服务里效果不错但引入的额外延迟在 50-100ms 级别需要接受这个成本。第三层是 token 限流、语义缓存这类核心 AI 逻辑用 WasmPlugin 挂进 Envoy。Istio 的 WasmPlugin CRD 可以把自定义 Wasm 过滤器挂到网关或 Sidecar 上。这里有个现实问题Wasm 开发的调试成本非常高沙箱对网络、内存访问有限制写一个能正确统计 token 并执行限流的插件要花掉的时间远超在普通服务里写同样逻辑。我们当时评估过一个成熟的 infrastructure 工程师做 token 计数插件至少两周起。这三层模式的组合方案很灵活但也意味着你拥有了全部事情都要自己做的自由。4.3 网格方案的成本账能用但要会算用 Envoy/Istio 组装 AI 网关上限确实最高不受任何厂商的功能边界限制想要什么能力都能自己写。但这笔账必须算清楚你需要的不是一串 Envoy 配置而是一个完整的产品。产品是什么概念provider 抽象要自己设计token 计费模型要自己定模型路由要自己写控制逻辑成本报表要自己搭。这些在 Higress 里是开箱即用的在 Envoy/Istio 路线里全是待办项。我们当时粗略估算过一个方案一个三人小组把最核心的多模型路由 token 配额 基础语义缓存做出来大概要三个月还不包括后续的持续维护和迭代。而这三个人的投入放在业务上可能早就把 AI 功能做进好几个业务线了。所以我的结论很明确自建路线适合公司就是要打造自研 AI 基础设施平台并且已经拥有一支很强的 Envoy 和基础设施开发团队的场景。如果你只是业务团队需要尽快把大模型能力接进来这条路是成本最不划算的。网格给的是自由度不是效率。5. 横向对比、选型矩阵和我的最终建议5.1 一张表看三者的 AI 能力差距把三条路线放在一起按我实际用下来的体验打分这张表可以直观反映差异对比维度HigressKongEnvoy/Istio多供应商 Provider 抽象开箱即用插件原生支持AI Proxy 插件OSS/EE 功能有别完全自研token 级限流与配额原生支持按 token 计量需要高级插件多在 EE 版自研工作量大模型灰度与自动降级原生支持权重和 fallback 都有需要叠加配置可做但编排复杂语义缓存原生支持高级插件多在 EE 版自研流式响应处理针对 SSE 做了优化可用但需要手动调超时需要手动调优上手成本低Helm 一条命令中依赖 PostgreSQL 和传统运维体系高需要 Envoy 功底生态成熟度国内社区活跃迭代快全球生态成熟文档完善全球主流标准适合的团队技术底色K8s 云原生团队传统企业级 API 管理团队基础设施自研团队这张表的逻辑很清楚Higress 是AI 原生设计Kong 是传统骨架 AI 插件Envoy/Istio 是原材料自己加工。三者没有绝对的优劣只有匹配度的问题。5.2 三种团队画像对应的选型答案第一种画像从零起步环境是 K8s团队没有既往网关资产AI 流量预计会快速增长。这种团队我建议直接选 Higress。理由很简单AI 能力不用自己搭网关和 K8s 生态无缝集成Helm 一装就有完整的 provider 抽象、token 级限流、模型路由。先用最快速度跑通业务以后再考虑要不要更 deep 的自研。第二种画像公司早就把 Kong尤其是 Enterprise 版用成了基础设施存量 API 很多AI 只是新增的一小部分流量。这种团队留在 Kong 是对的。强行替换网关的成本太大了在 Kong 上叠加 AI Proxy 和健康检查配置足以覆盖大多数常规场景。等 AI 占比大到 Kong 撑不住的时候再考虑下一步。第三种画像公司要自建 AI 基础设施平台AI 能力本身是核心竞争力团队有很强的 Envoy 和基础设施研发能力。这种团队选 Envoy/Istio 自研是合理的因为只有完全控制数据面逻辑才能做出和别人有差异化的东西。第四种画像我也遇到过团队想要 AI 网关能力但不想背 Higress 这种迭代节奏快的开源项目的版本包袱又觉得 Kong 的授权费用不好谈自己也没能力做 Envoy 自研。这种情况我的建议是再评估一次大概率 Higress 还是综合成本最低的选择因为国产开源项目的中文文档和社区支持对国内团队友好很多。5.3 无论你选谁这几条经验先收好选型之外有几条经验是从这三个方案里横着踩出来的跟网关无关但跟 AI 流量治理强相关。第一Provider 抽象一定要做在网关上而不是业务代码里。不管你选哪个网关第一步就是把调用哪家模型这个决策收敛到网关层。做过一次你就知道之后所有模型切换、灰度、降级都会变得无比顺滑。第二token 级配额比 QPS 限流重要得多。QPS 限流治标token 配额治本。只要你的业务方有成本意识就一定会需要这个月还能用多少 token这个答案没有这个能力的网关注定走不远。第三语义缓存要谨慎配置。它动的是响应内容涉及数据合规。在开启语义缓存之前先确认哪些数据允许被缓存哪些不能客户敏感信息一旦被缓存命中就是事故。普通 response cache 也是一样要加 TTL 和数据范围限制。第四流式响应的超时参数必须单独设置。SSE 的空闲不是传统意义的空闲模型思考时停顿几十秒都正常。只要看到流式响应后端正常、但经过网关后总在某个时间点断开第一反应就应该是查 idle timeout。第五主动健康检查一定要配但探活目标要轻。主动健康检查能提前摘除故障的模型供应商避免请求被打到已经挂掉的上游但探活请求不要调真实的模型接口一个轻量/health路径就够了否则探活本身就在烧钱、触发限流。最后说点我个人的体会。大模型网关这个领域变化太快了我写这篇文章时的一些功能点可能过几个月就有更好的方案。但不管怎么变有一个原则不会变网关这种位置最重要的不是它现在有多少功能而是当你需要换掉一个供应商、换掉一种模型、换掉一套策略的时候它能不能让你轻松做到。我在 Higress 上花的时间大部分收益其实都落在这件事上。如果让我重新选一次我还是会在项目第一天就把 provider 抽象做在网关层至于网关本身选哪家反而是次要问题了。