做过企业级 AI 助手的基础设施之后，我对"大模型网关"这四个字有了完全不一样的感受。客户端一多，你就会发现从业务服务到大模型服务之间这层东西，如果只是临时拿 Nginx 顶一顶，早晚要吃大亏。这一年多来，市面上被反复拿来对比的三个候选是 Higress、Kong 和 Envoy/Istio。我自己在生产环境里深度用过其中两个，也帮朋友的团队评估过另一个的迁移路径。这篇文章不打算把三个方案的文档重新抄一遍，只想把我选型时的判断逻辑、实际落地踩过的坑、以及在 LLM 流量下健康检查和限流这些细节一次性说清楚。
1. 为什么传统 API 网关在大模型流量下开始"卡壳"
1.1 大模型流量和传统流量的三个本质差异
传统 API 网关是为"请求发出、几百毫秒返回、连接立刻释放"这类流量设计的。无论是电商下单、支付回调，还是内容查询，后端的响应时间相对稳定，连接占用时间短，网关用连接池加 keepalive 就能扛住非常大的 QPS。
大模型流量完全反过来。LLM 接口单个请求的响应时间普遍在 2 到 10 秒，流式生成时连接甚至会持续半分钟以上。这带来第一个差异：连接占用时间从"毫秒级"变成"秒级到十秒级"。同样是 1000 并发，传统 API 场景下一台网关用少量工作线程就能处理完；而 LLM 场景下每一次通话都长时间占着一个上游连接，文件描述符和 TCP 连接数会以极快的速度耗尽。
第二个差异是超时模型。普通业务接口默认 5 秒、10 秒超时可能就够了，但大模型接口经常要容忍 30 秒甚至更长的首字延迟。如果网关在客户端和上游之间共用一套超时配置，几乎必然出问题。
第三个差异是错误语义。LLM 接口的 5xx 错误，很多时候不是服务挂了，而是上游排队、GPU 过载、上下文过长触发限流，这些情况往往几秒后就能恢复。传统网关面对 5xx 时通常会简单粗暴地重试，但重试一次就是一份 token 费用，而且重试时间窗口内模型大概率还在过载。
这三个差异叠加起来，传统 API 网关那套"短连接、低延迟、确定性超时"的模型，在 AI 场景里就变得非常别扭。
1.2 token 限流、语义路由、流式转发：AI 网关的三张必修课
传统网关限流看 QPS，AI 网关限流必须看 token。原因很简单：不同模型单次请求的消耗量可以差一个数量级。一个小模型一次请求消耗 200 token，一个大模型一次可能就要 2000 token。如果按请求数限流，小模型的配额很容易被大模型请求吃掉；反过来，如果只按总 token 限流，你可能发现某个 API Key 发起的请求数并不多，但费用已经失控了。
这个层级的限流，网关必须能读懂请求体里的 messages 内容，实时估算或统计输入输出 token，再按模型的计价维度做配额扣减。所以你能看到 Higress 和 Kong 都推出了专门的"AI 限流"插件，而不是复用传统限流器。
语义路由则把"URL 路径匹配"升级成了"请求内容匹配"。传统路由只看 /api/v1/image 这种路径，AI 网关则需要根据 prompt 内容把流量导到不同的模型上。典型例子：翻译类请求走通用模型，代码生成类请求走代码模型。如果全靠业务代码做这层判断，每次新增模型都要发一次版，非常被动。
流式转发是第三个关键能力。LLM 接口通常支持 stream=true，网关遇到这种请求时必须在内容生成的过程中逐 chunk 转发，而不是等全部生成完再一次性返回。这里牵扯到背压处理、chunk 的缓存策略、客户端断连时的表现。不少自己写转发脚本的团队在这里翻过车：客户端已经断开了，网关还在傻等上游生成，最后直接浪费掉整轮 token。
1.3 一次生产故障教会我的事：通用网关做不了"半关闭连接"
我自己遇到过一次很典型的故障。当时线上用了自研转发层加 Nginx，某个晚上用户大面积投诉"越到晚上越卡"。排查了很久才发现，Nginx 的 access log 里堆了大量 499 状态码。
499 表示客户端主动断开了连接，但 Nginx 没有立刻取消上游请求。用户等不到 LLM 首字返回，先关掉了页面或者重试了一次，而 Nginx 还继续从上游拉数据，连接和文件描述符都被这些半关闭连接占着，最后导致正常的健康请求也进不来。
这类问题在传统网关里非常难处理，因为传统网关对"客户端断连"和"上游继续执行"之间的关系不敏感。真正的 AI 网关会主动检测客户端断开，然后向上游发送取消信号，让模型尽早停止生成。可别小看这个能力，在高峰期每多停一秒生成，都是一笔真实成本。
这也让我确定了一件事：AI 网关不是传统 API 网关加两个插件那么简单，它从连接模型到错误处理逻辑，都需要针对大模型流量重新设计。
2. Higress：从 Envoy 底座长出来的 AI 原生体
2.1 设计逻辑：Kubernetes 里的"第二层网络"
Higress 是阿里巴巴开源的一个云原生网关，底层跑的是 Envoy 和 Istio 的成熟组件。它没有把自己包装成一个让你觉得陌生的新体系，而是坚持做"Kubernetes 生态里的数据面"：通过 Ingress 或者 HTTPRoute 这类 CRD 管理路由，网关实例以 Deployment 的方式跑在 K8s 集群里。
我在 K8s 环境下使用 Higress 的一个直观感受是：接入成本确实低。只要集群里有 Helm，一条命令就能把网关部署起来。更重要的是它可以同时从 Kubernetes Service、Nacos、DNS 等多个来源做服务发现，这对那种"一部分服务在 K8s、一部分服务还在传统虚机上"的团队比较友好。
从 AI 原生角度来说，Higress 的思路不是让你自己去 Envoy 上写过滤器，而是把大模型流量治理的能力直接做成插件。你打开它的插件市场，能看到 AI 相关的插件已经沉淀了一批，这也是很多人愿意拿它跟 Kong 对比的原因。
2.2 token 级限流、多模型路由、语义缓存，我实际配过的一个链
Higress 里我真正在生产环境用过的 AI 插件有三个，组合起来可以覆盖最常见的需求：
- ai-token-ratelimit：按模型、API Key 维度做 token 级限流；
- ai-proxy：一个协议适配器，把 OpenAI 风格的请求转发给不同的模型供应商；
- ai-cache：语义缓存，命中相同语义的问题时直接返回缓存结果，省钱效果非常明显。
我当时配过一个非常典型的插件链：请求先进 ai-token-ratelimit 做配额校验，然后交给 ai-cache 查缓存，没命中再到 ai-proxy 转发到具体的 LLM 服务。ai-proxy 帮我省掉了业务侧多套 SDK 的麻烦，因为不管上游是闭源厂商的 API，还是内部部署的 vLLM 服务，业务方看到的都是兼容 OpenAI 格式的接口。
token 限流插件的配置逻辑大致是这样：先定义 key 的提取方式，比如从 Authorization header 解析出调用方身份，然后按分钟或按天给每个 key 一个 token 额度。额度不足时插件可以直接返回 429 和提示信息，不用等到请求真的打到模型上才被拒绝。
这里有一个非常关键的坑我要提醒：流式场景下，token 统计回调往往在 stream 结束阶段才触发。如果客户端在生成过程中断连，统计回调可能根本不执行，那配额记账就会出现偏差。我们的做法是不把限流插件的统计结果直接当账单用，额外开审计日志，从访问日志里的 token 字段做补偿核对。
2.3 什么时候不要选 Higress
Higress 虽然香，但它有明显的边界。如果你们团队的微服务体系是纯 Spring Cloud / Dubbo，而且短期没有把服务迁到 K8s 的想法，那么 Higress 的 CRD 和 K8s 原生配置方式对你来说学习成本不低。你为了用它，等于要先补一套 K8s 运维能力。
另外，部分 AI 插件的默认配置关联了阿里云上的模型服务，比如语义缓存里的向量化模型默认指向百炼的 embedding 接口。你在本地私有化部署时，需要把这些依赖替换成自己的向量化服务。这个替换本身不难，但如果你希望开箱即用、不想折腾默认配置，可能会觉得被"绑定"了。
说到底，Higress 特别适合已经在 K8s 里跑业务、想要快速接入多种模型、并且愿意让网关分担一部分业务路由决策的团队。它是最接近"AI 原生网关"这个定位的选项。
3. Kong：老牌网关的 AI 转身速度
3.1 从插件基因到 AI Gateway 的演化
Kong 在 API 网关领域是老资格了，它的核心优势一直很明确：插件生态极其丰富，部署形态灵活，生态成熟度高。2024 年 Kong 正式强化了 AI Gateway 方向，社区版也加入了 ai-proxy、ai-rate-limiting-advanced、ai-prompt-guard 等插件，并不是只在企业版里做宣传。
Kong 的 ai-proxy 插件定位和 Higress 的 ai-proxy 有类似之处，都是做"统一协议接入"。你把 OpenAI 格式的请求发给 Kong，它帮你转发到 Anthropic、Azure OpenAI 或者其他兼容服务，并且可以在多个 provider 之间做负载均衡。这点对不想绑定单一厂商的团队来说非常实用。
Kong 的一个差异化优势是部署形态。它可以跑在裸机的 Docker 容器里，可以跑在 K8s 里，也可以直接用 Kong Konnect 这样的云管理面。这种灵活性让它非常适合那种"基础设施还没有完全云端化"的团队。
我在实际测试中的感受是：Kong 的插件机制依然很强大，几乎什么需求都能找到现成插件或者写一个自定义插件。但它的 AI 能力迭代节奏确实比 Higress 要稳一点、慢一点，很多进阶能力（例如语义缓存）出现在企业版里的时间会早于社区版。
3.2 Kong Manager 主动健康检查：LLM 上游"活但不健康"的高频坑
这里展开讲一个很多人问过我的点：Kong Manager 里节点的主动健康检查到底怎么配，才适合 LLM 场景。
先说背景。LLM 服务有个典型状态叫"活但不健康"：进程明明还活着，但 GPU 显存被打满，推理队列越排越长，响应时间从 500ms 涨到 20 秒。如果你只依赖被动健康检查（passive health check），只有当某个节点真实发生请求失败时才会被标记为不健康，这在高并发队列场景下太滞后了。
主动健康检查（active health check）能让 Kong 定时主动探测上游节点的健康端点，提前发现问题。配置上核心是这些：
- active.http_path 设置成专门为探针准备的路径，比如 /health/probe；
- 探测间隔不要设太短，建议 15 秒起，因为 LLM 服务启动慢、恢复也慢，太频繁的探测反而会干扰正常服务；
- healthy.successes 设置为连续成功 3 次再恢复健康，避免节点刚恢复就被立刻打满流量。
我当时踩过的一个具体坑是：K8s 里的 LLM Pod 通过 ClusterIP Service 暴露给 Kong，而 Service 后面所有 Pod 的 /health/probe 路径都被服务的鉴权中间件拦截了，导致 Kong 把明明健康的节点误判为不健康。后来我们为探针单独开了一个端口和路径，不在鉴权范围内，问题才解决。
另一个细节是：探针请求绝对不能携带真实业务 payload。LLM 服务的健康检查最好只做"系统存活"级别的轻量探测，如果探测逻辑里带上模型推理，一次探测本身就会占用 GPU，探测太频繁等于额外消耗算力。
3.3 Kong 的取舍：稳定大于激进
Kong 给我的总体印象是：稳定、可控、适合已有 Kong 架构的团队平滑扩展。如果你现在线上已经用 Kong 管理了成百上千条路由，现在要把大模型流量也纳进去，那继续用 Kong 是成本最低的路径，不需要再引一套新网关。
缺点是，如果你是一个想要最新 AI 特性的团队，社区版 Kong 会让你觉得有些功能要等很久。而且 Kong 的很多 AI 能力深度绑定企业版的插件，企业版的授权费用不是每个团队都能接受。我对它的评价是：不是最激进的 AI 网关，但是最不容易出错的 AI 网关之一。
4. Envoy/Istio：把通用数据面改造成 AI 流量底座
4.1 数据面与控制面视角下的重新定位
Envoy 和 Istio 本来不是为 AI 专门设计的，但它们在大模型网关这个话题里始终绕不开。一个重要原因是 Higress 自己就是从 Envoy 和 Istio 这套体系里长出来的，这说明 Envoy 的数据面能力完全能够承载 AI 流量治理。另一个原因则是，很多重度使用 Istio 的团队会问：我们已经有一套服务网格了，为什么还要再单拎一个 AI 网关出来？
从架构视角看，Envoy 是数据面，负责实际转发流量；Istio 是控制面，负责下发路由和策略。这套组合的优势是自由度高。你想在请求 Header 之外读取 Body 里的 prompt 做内容审核，传统做法是写 Nginx 模块或者在业务代码里处理，而在 Envoy 体系里，你可以写一个 Filter，挂到过滤器链上，直接读取 Body。
这也是 Envoy/Istio 和 Higress、Kong 最大的区别：后两者把能力封装成插件，你开箱即用；Envoy/Istio 给你的是工具集，你可以自己造轮子，造出来的轮子还可能比通用插件更贴合自己的场景。
4.2 用 Envoy Filter 和 WASM 实现 prompt 审核与 token 统计
我在一个项目里实际做过类似的事：需要对每个 prompt 做敏感词检测，又不希望检测逻辑拖慢业务服务。当时的方案是使用 Envoy 的 external authorization 过滤器，把请求先发给一个独立的审核服务，审核通过再继续转发到 LLM。这个方案的精妙之处在于，如果审核服务在高峰期偶发超时，Envoy 侧可以配置成降级透传，宁可让请求通过也不能在 LLM 调用前引入额外故障点。
如果你有 C++ 或 Rust 的工程能力，还可以用 WASM 插件直接在 Envoy 内部做 token 计数。相比 external auth 再回调一步，WASM 的方式性能更好，毕竟它在数据面本地执行。我合作过的团队里有一家就是这么干的，他们在 WASM 里读取请求体 messages，估算 token 数量，把结果作为请求头附加到上游请求，这样模型服务端看到的是一个预先预估的 token 数，可以提前做拒绝，避免后端在被限流时还硬着头皮跑推理。
但我要泼一盆冷水：WASM 插件方案只建议在有专门平台工程团队的条件下选。因为它的调试和迭代流程比普通插件复杂很多，一个半路接手的团队如果不懂 Envoy 内部处理逻辑，排障成本会非常高。
4.3 Envoy/Istio 真正适合的 AI 架构场景
如果你们整个微服务体系已经重度接入 Istio，每个服务都在网格里，那专门引一套 AI 网关会多出一个独立入口和一套认证体系，运维上反而割裂。这种时候，直接在 Existing Gateway 上挂一条 VirtualService，把对大模型服务的流量也纳入网格治理，我认为是更自然的选择。
Envoy/Istio 适合的典型场景是：AI 服务不是一个独立对外产品，而是你现有平台里的一个能力模块。比如一个企业内部系统，除了普通 CRUD 接口，还提供一个问答机器人能力，这部分流量完全可以在同一个网格入口里被管理。
反过来，如果 AI 是你们的核心平台产品，需要频繁切换模型供应商、做精细化的 token 配额管理、计算每个用户的模型费用，那 Envoy/Istio 给你的自由度反而变成了负担。因为这些能力在通用网关上并没有内置，你都要自己写。一句话总结就是：自由度很高，但你需要足够的时间和人手去消耗这个自由度。
5. 三套方案决选：不同团队怎么落地
5.1 能力对比表：不看宣传，看场景
我习惯把评估维度压缩到团队实际情况能对上的几项，而不是去比谁的功能清单更长。下面是我自己常用的一个对比视角：
| 评估维度 | Higress | Kong | Envoy/Istio |
|---|---|---|---|
| AI 专属插件 | 丰富，内置 token 限流、语义缓存、多模型适配 | 有官方 AI 插件，但社区版迭代节奏慢 | 无内置，需基于 Filter/WASM 自研 |
| 部署与运维 | K8s 友好，CRD 配置 | 裸机/Docker/K8s/云服务均可 | K8s 网格模式，运维复杂度高 |
| 流式请求支持 | 好，专门针对 LLM 做过适配 | 好，通过插件支持 | 底层支持，但要自己搭 |
| 多模型供应商切换 | 内置协议适配 | 内置协议适配 | 基本靠自研 |
| 健康检查 | 有基本能力，依赖 K8s 探针 | 主动/被动健康检查很成熟 | 功能完善但配置偏复杂 |
| 生产稳定性 | 中上，迭代活跃 | 高，老牌验证充分 | 高，但复杂度也高 |
| 适合谁 | 云上 K8s 团队，快速接入多模型 | 已在用 Kong 的团队，平滑演进 | 强自研平台团队，追求极致治理 |
这张表不是让你按分数加起来选，而是提醒你注意自己最不能妥协的那一行。比如你的核心诉求是"团队小、要快速上线"，那 Envoy/Istio 自研路线基本可以直接划掉。
5.2 决策思路：先看你们是接 API 还是接长连接
我做选型时有个很朴素的判断方式：先分清你要接的是"普通 API 调用"还是"长连接/流式交互"。
如果业务方的模型调用就是发一个完整请求、拿到完整回复，重点是限流、防超支、切换供应商，那么 Higress 是当前落地效率最高的选项，插件链一挂就能跑。
如果你们的业务形态是智能客服、实时语音、Agent 这类强交互场景，长连接和流式输出占比很高，那么你需要非常关注网关在"客户端断开时取消上游"这个能力。Kong 在这个场景下也很稳，因为它的插件系统已经经过大量生产验证，而 Higress 的流式统计还偶尔需要审计日志做补偿。
如果你们团队已经把 K8s 和 Istio 玩得很透彻，并且有多条业务线共用一套基础设施，那 Envoy/Istio 是值得重仓的方向。长期来看，你们可以用一套控制面管理所有流量，不需要为 AI 单独维护一套孤儿网关。
5.3 落地过程中最容易忽略的三个细节
第一个细节是超时策略必须分两段设置：客户端到网关的超时，和网关到上游模型的超时，绝对不能共用一套配置。我在线上见过很多配置模板只调了前者，导致网关回 504 时模型还在生成，钱白花了。建议把 client_timeout 调成略大于 upstream_timeout，同时开启"客户端断开即取消上游请求"。
第二个细节是 token 限流的统计口径和计费口径必须分离。网关限流插件统计的 token 数，在流式断连场景下会偏小，不适合直接作为账单依据。更稳妥的方法是让网关只做执行和记录，计费用独立的日志管道从访问日志里提取 token 用量。Kong 可以用 Prometheus 插件加自定义 metrics，Higress 可以从访问日志里的 AI token 字段读取，两者都能做到不计漏。
第三个细节是模型供应商的认证差异。别看都是"填一个 API Key"，有的供应商要求在 Header 里放静态密钥，有的要求 OAuth token 动态刷新，有的需要你在请求体里指定 model 参数。如果网关不能把这层抽象掉，你就要写很多自定义逻辑。因此选型之前，最好先把你要接的供应商列表列清楚，如果里面有本地 vLLM 又有云端闭源服务，优先选协议适配能力强的方案，Higress 的 ai-proxy 在这点上帮我省了不少事。
最后说点个人体会。大模型网关这个品类变数还很大，今天的最佳选择半年后可能就不是了，所以选型时我会有意避免和某个特定厂商绑定死。我的做法是：先抽象出团队最核心的三个诉求，然后花一周时间做最小验证，把一条真实生产流量的模型调用切到候选网关，重点盯着限流是否准确、超时是否可控、客户端断连时是否还会产生额外费用这三个指标。Higress、Kong、Envoy/Istio 没有绝对的优劣，只有和你的团队现状、业务阶段合不合适。希望这篇对比能帮你少走一点弯路。
