大模型网关选型：Higress、Kong与Envoy/Istio深度对比

上个月朋友公司半夜出过一档子事：他们在好几个平台接了大模型API，给不同业务线的产品用。某天大促流量突然上来，直连OpenAI的链路先超时，业务方切到备用Key，结果那个Key早被别的脚本批量调用打爆，两三条业务线同时报错，开发互相问“你用的不是另一个Key吗”，一查账单，谁都说不清谁在用什么Key调了什么模型。财务拿着月度成本报表来问：为什么才几天，预算已经超了两倍？

这种混乱，是所有开始规模化使用大模型的公司迟早会撞上的墙。把各家模型供应商的入口收口到一个统一网关，让路由、限流、计费、观测这些事从“每个业务自己搬砖”变成“平台集中治理”，就是大模型网关存在的意义。现在这个赛道里，Higress、Kong、Envoy/Istio这三派被提得最多。今天结合我平时搭建和运维这类网关的实际经验，把它们的AI原生能力、扩展方式和适用场景拉出来做一次深度横向对比，想直接抄作业的可以直接跳到第4部分看选型建议。

1. 大模型网关为什么成为刚需：从一次线上事故说起

1.1 传统API网关在大模型流量面前的三个断层

传统API网关的核心是围绕“URL路径、请求方法、调用方身份”做路由、鉴权和限流。一个请求进来，按路径匹配到后端服务，按调用方配额限流，记录请求数和延迟。这套模型在微服务体系里被验证了很多年，非常成熟。但大模型API的流量特征，和普通HTTP API有本质差异。

第一个断层是流式响应。LLM的响应是流式的，一次对话请求可能持续十几秒甚至更久，SSE（Server-Sent Events）把内容一段段吐出来。传统网关往往按“完整请求+完整响应”来统计，在流式场景下要么等全部结束才记录，要么只能记录不完整的响应。更麻烦的是超时、缓冲、断流的处理逻辑，普通网关默认按“短请求”来设计，直接套到SSE上会出现各种诡异问题。

第二个断层是计费单位。传统网关按请求次数计费，但大模型按token数计费。两个请求的URL完全一样，一个只问“你好”可能花几十个token，另一个让它写一篇万字长文可能花几千甚至上万个token。如果限流还按QPS做，一个写长文的用户能把成本烧穿，却根本不会触发任何限流规则。

第三个断层是供应商多样性。业务方今天接OpenAI，明天换国产模型，后天又要做A/B对比，这些切换如果发生在每个业务代码里，改造成本和出错概率都很高。更麻烦的是，大模型供应商的稳定性并不比普通微服务可靠，出现故障时怎么降级切换，传统网关里根本没有“模型供应商”这个抽象概念。

1.2 大模型网关的核心能力清单：照着这张表去选型

这么多需求，落到具体选型时，我习惯先拉一张能力清单，拿清单去卡候选方案。你可以直接抄这份清单，立项时逐项打勾：

• 多模型统一接入：用一套OpenAI兼容API暴露给下游，背后路由到任意供应商，应用侧不需要知道模型在哪。
• 动态路由与容灾：支持按权重、按规则路由到不同模型，供应商故障时可自动迁移，新模型能灰度放量。
• Token级限流与配额：对调用方按token设定额度，支持分钟、小时、天多个时间窗口，能对单模型单独治理。
• 成本计量与分账：记录每次调用的token数，折算成成本，按业务线、应用、调用方做汇总，给财务出报表。
• 流式请求处理：正确解析和转发SSE流，支持流式场景下的超时、取消、错误码透传，客户端不会收到半截内容。
• 语义缓存：对相似问题直接返回历史答案，减少重复调用，降低成本和延迟，适合FAQ类场景。
• 安全与合规：阻止特定提示词、敏感内容过滤、脱敏、审计日志，Prompt往往带用户上下文甚至企业内部数据。
• 可观测性：请求延迟、token用量、错误码、供应商可用性都要能监控，出问题能快速定位是网关还是模型的问题。

这张清单每一项，三家方案的支持程度都不一样。下面把三个方案各自的基因拆开看。

2. 三家方案架构基因解读：Higress、Kong、Envoy/Istio

2.1 Higress：从Istio生态里长出来的AI原生网关

Higress是阿里云开源出来、后来进入CNCF的云原生API网关。底层数据面是Envoy，控制面是自研控制器，早期深度绑定Istio生态。如果你用过Istio，再看Higress会有一种眼熟感，但它不是单纯的服务网格，而是非常彻底地朝着“API网关”方向在做。

它在AI场景上的态度非常“原生”，不是把AI插件缝缝补补挂上去，而是从核心就把模型供应商、token计量、语义缓存当成一等公民来设计。Higress提供了一批专门处理LLM流量的Wasm插件，包括ai-proxy、ai-token-limit、ai-statistics、ai-cache、ai-content-security等，全部开箱即用。

我个人理解，Higress最大的优势有两个。第一，Wasm插件机制让数据面扩展可以热更新，不用重新编译、不用重启Pod，这在生产环境里非常重要。第二，内置的provider适配层非常全，从OpenAI、Anthropic这些国外厂商到国内的百炼、DeepSeek、Moonshot等，基本都是配置化接入，不需要在每个插件里重复写鉴权和协议转换。

但Higress也不是没有成本：它和Kubernetes绑定得比较深。如果团队不打算用K8s，部署和运维Higress本身就变成一件需要投入的事，这一点要放在前期评估里。

2.2 Kong：老牌网关用插件补课的AI转型路线

Kong是最老牌的现代化API网关之一，商业版本叫Kong Gateway，开源部分基于OpenResty（Nginx加Lua）。它几乎见证了API网关从“Nginx配置模板”到“插件化生态”的整个进化过程，插件市场极其丰富，社区积累深厚。

面对AI浪潮，Kong的选择是推出一系列AI插件，集中在AI Proxy、AI Rate Limiting、AI Request/Response Transformer、AI Prompt Guard、AI Semantic Cache这套体系里。AI Proxy同样支持多供应商统一转发，OpenAI、Azure OpenAI、Anthropic、Cohere等主流平台都有适配，国内厂商适配进度会相对慢一些。

Kong的基因优势在于“插件生态的老练”。技术栈是Lua加OpenResty，插件机制非常成熟，文档和社区问答都是老牌项目的范儿。企业版有Kong Manager图形化界面，还有Konnect托管平台。对已经有Kong存量部署的团队来说，平滑升级是最现实的路径。

它也有明显短板。插件多不代表深度够，不少AI插件在企业版才完整开放，开源版的AI能力做了取舍。另外，Lua插件虽然轻快，但稍微复杂的AI逻辑，比如语义缓存、向量化匹配，基本都是调外部服务实现，部署架构会比Higress那种内置方案重不少。

2.3 Envoy/Istio：底子最硬但什么都要自己造轮子

Envoy是云原生时代的L7代理，C++实现，Istio默认构建在它之上。严格来说，Envoy/Istio不是“一个大模型网关产品”，而是一套可以拿来构建网关的“地基”。

如果采用Envoy Gateway项目，能得到一个基于Envoy的、带控制面的API网关骨架，支持Gateway API标准。但LLM专属能力基本要自己造轮子。想在Istio的服务网格里加AI流量治理，WasmPlugin接口允许加载自研Wasm过滤器，但这同样意味着开发和维护一条比较深的技术路线。

为什么对比大模型网关还要提它？因为很多对性能和灵活度有极端要求的团队，真的会选择在Envoy上自己实现AI网关。Envoy的C++扩展能达到最高的转发性能，路由、重试、熔断、限流这些底层能力非常扎实。另外，如果公司已经深度采用Istio作为服务网格，希望网关和服务间流量用同一套数据面管理，那走Envoy/Istio路线本身就是“顺便把AI流量也纳入治理”。

它的代价也最明显：AI原生能力最弱，LLM相关逻辑几乎都要自己开发，对团队的C++、Rust、Wasm开发能力要求很高。用行业里的一句话讲，这是“给能造桥的人用的桥墩”。

2.4 对照表：控制面、扩展能力与运维复杂度

选型时很多人只看功能列表，但我更建议看“基因”——这个项目的核心开发者在为谁写代码。Higress的基因是“云原生加K8s加AI原生”，社区和发布节奏都在围绕大规模AI应用的痛点转；Kong的基因是“传统API网关的延续”，想把所有历史能力平滑带到AI时代，步伐稳健但很多能力仍然偏传统；Envoy/Istio的基因是“基础设施”，目标从来不是替你做业务决策，而是提供足够强的底层能力让你做任何决策。这个差异在复杂需求下会非常明显：同样一个“A部门可以用GPT-4，B部门只能用国产模型，超预算自动发提醒”的需求，Higress可以靠配置和插件在半天内完成，Kong可能要配合企业版功能和外部脚本，Envoy/Istio路线可能要先写两个Filter。

3. 六个高频需求逐一拆解：三家分别怎么做

3.1 多模型统一接入：是配置项还是开发量

先看最基础的需求：让下游业务方只面对一个固定的OpenAI兼容入口，网关背后自由切换多家供应商。

Higress的做法是配置ai-proxy插件，声明下游要用的provider列表。我线上用过的配置大致长这样：

provider: - name: openai type: openai apiTokens: - env: OPENAI_TOKEN model: gpt-4o-mini - name: qwen type: dashscope apiTokens: - env: DASHSCOPE_TOKEN model: qwen-plus

配置完成后，业务方照常以OpenAI的协议发请求，网关按规则选择provider，API Token统一在网关侧管理，应用代码里不再散落任何供应商Key。以后换新模型，只改网关配置，业务方零感知。

Kong这边，AI Proxy插件同样支持配置多个provider，并允许通过请求头字段切换目标模型。这个设计灵活，但如果业务方不看文档乱发Header，也容易造成路由混乱，需要配合上游访问控制规则一起使用。Kong对国内大模型厂商的适配速度比Higress慢，如果主力供应商是国内模型，要提前确认版本支持情况。

Envoy/Istio路线则没有开箱即用的provider抽象，多半要自己写Wasm过滤器或用自定义路由逻辑，按Header参数转发，供应商API协议差异由自己处理。好处是把协议转换做得比任何现成插件都克制，坏处是实打实的开发工作量。

3.2 Token级限流与成本分账：网关必须算得清账

我见过太多团队，上线AI功能时只看“能调通”，上线后成本失控才回来补齐限流。Token级限流和成本管理，是最不该省的选型投入。

Higress的ai-token-limit插件可以直接按用户维度、按模型维度限制token消耗量。它和ai-statistics插件配合，会把每次请求的prompt/completion token数记录并聚合。我实际部署时会先给每个业务线设一个“月配额告警阈值”，再在网关侧设一个硬上限，双保险，防止某个异常程序一夜之间把预算跑光。

Kong的AI Rate Limiting插件支持基于token的限流，成本计量也会在日志和统计接口中体现。但注意，Kong的AI高级插件在企业版里才能解锁全部能力，开源版能用的AI限流相对基础。如果你的组织对License比较敏感，这一点要在立项时就确认。

Envoy/Istio路线的token级限流只能自己实现tokenizer计算逻辑，中文等多语言场景的token计数不同模型还不一样，并且要在Envoy扩展里做聚合统计，工程量不小。

关于token计数有一个绕不开的坑：网关统计的token和模型提供方账单上的token往往对不上，各家tokenizer算法和计费口径不同。所以成本管理更务实的做法不是追求分毫不差，而是趋势可见：网关侧统计同一个数量级、能按业务方拆分，就已经能解决绝大部分成本分账问题。

3.3 语义缓存：省钱利器也是踩坑重灾区

语义缓存是AI网关特有的功能，原理是给请求的prompt做向量化，在缓存里按向量相似度查找历史答案，相似度超过阈值就直接返回，不再调用模型。对重复性高、问题模式固定的内部客服类应用，效果格外明显。

Higress的ai-cache插件把这件事做成了开箱即用形态，可以配置向量化服务和Redis等缓存存储。线上实践下来，在FAQ型AI问答场景里缓存命中率能做到40%以上，成本和延迟都能肉眼可见地下降。

Kong的AI Semantic Cache插件原理类似，但定位更偏企业级功能。部署时同样需要一套向量存储和嵌入服务。如果已有Kong企业版，这是加分项；如果没有，要掂量License成本。

Envoy/Istio路线实现语义缓存，需要自己处理向量化、相似度检索、缓存写入全链路，通常做法是接入外部向量数据库，用Filter在转发前查缓存，技术上都可行，但维护成本高。

我的实操建议：语义缓存不是选型第一优先级。先把路由、限流和可观测性做好，等业务量上来再迭代加。过早引入语义缓存，你会先遇到“缓存住了脏回答”“相似度误伤”这些比收益更头疼的问题。

3.4 灰度路由与容灾切换：模型挂了不能让全站一起挂

多供应商存在的意义，不只是多一种选择，更是多一条命。网关需要在某个模型不可用或质量下降时自动切换。

Higress的多provider路由本身就支持按优先级和故障自动切换，也能配合权重做灰度。比如新模型先放5%流量跑几天，观察成本和质量指标再逐步放大。这在线上AI应用里是非常常用的操作，我甚至会在每周例会上例行问一句“这周有模型要灰度吗”。

Kong的AI插件体系里，AI Retry和故障转移能力可以实现对一次失败请求的二次路由。但它更偏请求级重试，对“模型连续故障后自动把后续流量切走”这类状态感知能力，需要在上层配合更多脚本或监控规则。

Envoy/Istio路线的优势在于重试、熔断、超时这些基础能力非常扎实，可以复用到AI流量。但要注意LLM流式场景的容灾和普通HTTP不同：客户端可能已经收到了一半的流式响应，这时后端故障，网关重发会让客户端拿到重复内容。我的经验是：流式请求的重试要慎用，优先做“下一跳切走”，而不是“当前这一跳重发”。

3.5 安全合规与Key管理：容易被忽略的一层

大模型网关还要处理Prompt安全和密钥管理，这个需求在选型时经常被忽略，上线后追悔莫及。

先说Key管理。没有网关时，每个业务方都拿着自己的供应商Key，Key泄露了也没人知道。有了网关，业务方只认一个网关出口，供应商Key全部沉淀到网关侧。这样可以做统一的Key轮转，一旦怀疑泄露，在网关侧更换即可，不用通知所有业务方改配置，爆炸半径小很多。Higress和Kong都支持从环境变量或密钥管理服务读取API Token，不做Key明文落盘。

再说内容安全。带用户输入和业务数据的Prompt，需要做敏感词过滤、脱敏、审计留痕。Higress有专门的ai-content-security插件，Kong企业版有AI Prompt Guard，Envoy/Istio路线依然要自己写Filter。我的建议是至少把“审计日志”做扎实：谁在什么时间问了什么问题，这个日志在排查问题时价值极高。

4. 选型决策指南：不同团队怎么选最合适

4.1 四类团队场景对应的推荐路线

每个团队的技术栈、存量系统、团队能力都不一样，我不可能给一个万能答案。下面按实际接触过的团队类型给四组建议。

• 团队已经在K8s上跑业务、追求快速上线AI能力：优先考虑Higress。它和K8s生态结合紧密，AI能力开箱即用，遇到问题能在文档和社区Issue里找到答案。这个组合的“最小实现成本”最低。
• 团队已经是Kong的重度用户，有大量存量插件和流程：不建议立刻推翻重来，用Kong的AI插件做平滑扩展最划算。API网关迁移本身就是高风险动作，AI场景刚起步时没必要同时上两个变革。
• 团队有强自研基因，或对转发性能有极端要求：Envoy/Istio路线更适合，可以带来最大自由度，但请做好“AI能力全部自建”的预算评估，至少要留一两个能写Wasm或C++的人。
• 团队同时管理传统微服务流量和AI流量，不想维护两套网关：可以考虑用Higress或Kong统一收口，Envoy/Istio路线适合把两种流量都纳入服务网格，但复杂度同步提升。

注意，上面的建议都默认你有一个独立的平台或基础设施团队来运维网关。如果没有，先别急着自建，优先用云厂商的托管网关产品或商业版，把业务跑通再说。

4.2 三个性能与成本的隐性陷阱

第一，插件链性能损耗。网关的AI插件往往要处理流式响应、tokenizer、向量化交互，这些逻辑放在请求关键路径上，对CPU和内存的消耗比普通API网关大不少。Higress的Wasm插件有热更新优势，但Wasm沙箱有开销；Kong的Lua插件在复杂逻辑下要小心阻塞事件循环；Envoy原生C++扩展性能最好，但开发成本最高。选型时要做一次压测，不是压纯转发QPS，而是压“带全套AI插件时的QPS和P99延迟”。

第二，流式响应占内存。SSE长连接配合大响应体，网关缓冲区配置不当，很容易出现内存水位飙升甚至OOM。不同方案内存模型不同，但“流式转发时是否逐段透传而非整体缓冲”这个细节，一定要在前期确认清楚。

第三，License和商业化的隐性成本。Kong企业版功能与开源版有明显边界，业务发展后要用更高级AI能力，成本曲线可能比预想陡峭。Higress和Envoy/Istio路线通常没有License问题，但可能把成本转嫁到人力上。天下没有免费的午餐，要么花License钱，要么花工程师时间。

4.3 混合多云旧系统共存时的补充判断

如果公司不是从零起步，而是有大量已有系统和多云的现状，选型还要加一个维度：网关能不能和现有身份体系、监控体系、发布流程对接。

Kong在非K8s环境、与旧系统共存方面经验最丰富，适合“一个网关管所有流量”的传统企业数字化场景。Higress在K8s和云原生环境内集成度最好，但旧系统不在K8s里的话，需要单独做网络打通。Envoy/Istio路线面对混合环境也有成熟方案，但同样要靠团队自建控制面能力。

一个实用技巧：选型时做一份“环境矩阵”，列出网关要管理的所有流量类型、所在环境、身份认证方式、监控系统，逐项验证候选方案能否接入。很多选型翻车都不是功能不够，而是“接不进现有运维体系”。

5. 线上踩坑与排查实录

5.1 流式响应中断，不是模型的问题

第一次上线在Higress后面接了DeepSeek，客户端反馈“回答到一半突然停了”。查了一圈发现是网关的流式响应空闲超时配置太短。大模型生成长文时，两次“吐字”之间的间隔可能超过普通HTTP请求的空闲阈值，需要单独调大读写超时，并区分“空闲超时”和“总超时”。这个坑在Kong和Envoy同类场景下同样存在。

5.2 token统计永远对不上账单的真相

某月成本周报出来，网关统计token消耗比供应商账单少了15%。排查下来有两层原因：一是网关统计的是转发层看见的token，供应商账单里可能有缓存、重试等额外消耗；二是统计插件对某些多语言内容的tokenizer口径不同。我给团队的建议是：不要把网关token数当成对外结算依据，它定位就是内部趋势和分账工具。

5.3 Wasm插件内存缓慢上涨

在Higress上跑过一段自定义Wasm过滤器，上线两天后Pod内存缓慢上探，最后定位到是无意在过滤器里缓存了太多请求级别的对象，GC来不及回收。Wasm插件虽然方便，写的时候要带着“这是长驻内存”的心态，别把应该在请求结束后销毁的临时数据留在全局。

5.4 灰度模型“偶尔犯病”的定位

有次新模型灰度到5%流量时，业务方反馈“偶尔会有很奇怪的回答”。查下来不是网关转发问题，而是新模型在特定任务上质量不稳。网关能在路由层面做权重调整，但“模型质量”的判断需要业务侧加一层自动化评估。这件事说明：大模型网关解决的是“能不能调、怎么调度”，而“哪些结果算好”仍然是应用层的课题。

5.5 常见问题速查表

写到最后，聊点个人体会。大模型网关这个领域远没到赢家通吃的阶段，三派各有各的适用土壤。我见过在Higress上半天就把AI能力收口好的团队，也见过在Envoy上折腾一个月做自定义路由的团队，两者其实都对，区别在于手里的牌不一样。如果让我给一条最通用的经验，那就是：先用网关把统一入口、信令管控、可见分账这三件事做扎实，再谈更高级的语义缓存和智能插件。最后分享一个小技巧，把网关侧的供应商Key做成定时轮转，往下游统一暴露一个Key，既理清了业务依赖，也让Key泄露时的爆炸半径小很多。希望这些对比和踩坑记录，能帮你在选型和落地时少走几个弯路。