企业官网建设流程全解析

大模型网关这个词，最近半年在云原生圈子里被反复提起。我所在的平台团队从去年开始接手公司内部大模型应用的接入工作，选型这件事被推到了面前：多个模型服务需要统一对外暴露，API Key 要管理，Token 费用要记账，流式响应要稳定，还要支持按业务线做限流。这些都是传统 API 网关没有系统化解决的问题。于是我把市面呼声最高的三个方向——Higress、Kong、Envoy/Istio——逐一拉了实跑测试，又结合线上场景做了近两个月的灰度验证。今天这篇算是一份相对完整的选型复盘，覆盖调研思路、实测结论、踩坑记录和最终推荐，适合正在做类似技术选型的后端与平台工程师。

先说结论之一：这三者不是在同一个层面竞争的，Higress 更像“AI 应用网关”，Kong 是“传统 API 管控体系 + AI 插件”，Envoy/Istio 阵营则是“未来流量基础设施”。如果只看横向功能列表，很容易选错。

1. 为什么大模型场景需要“新物种”网关

1.1 传统API网关的认知边界

大多数团队手里的 API 网关，不管是 Kong、Nginx、Spring Cloud Gateway，还是云厂商的 API 服务，设计之初都是为微服务通信服务的。它们对“接口”有极强的控制力：根据 Path、Method、Header 做路由，对 QPS 做限流，对调用方做身份认证，再挂上监控告警。这一套在传统的同步 RPC 场景里非常成熟，但大模型应用进来了之后，第一个不适感就出现在抽象粒度上。

网关只能区分“/v1/completions”和“/v1/chat/completions”这种接口，却无法感知“这条请求想要调用哪个模型”“这个模型可能要输出多少 Token”。它也没有合适的位置去管理 API Key 轮换、模型级降级、Token 额度控制这些 AI 特有的资源概念。结果就是很多团队只能把 AI 网关的逻辑塞进业务代码里，每个服务写一套，重复又难维护。

另外要看到，大模型流量的并发模型和传统 API 完全不同。一次流式请求在网关层是长连接，网关的连接数、内存、日志格式都要重新评估。我见过有团队用 Nginx 把 SSE 流量做透明代理，结果连接一多 worker 连接数被打满，问题排查了三天，最后只能上专门的 AI 流量层。

1.2 AI流量的四个“反常规”特征

• 连接模式变了。一次 LLM 调用，尤其是流式输出，在网关层维护的是一个持续十秒甚至几十秒的长连接，期间需要不断把后端返回的数据分块转发给客户端。传统网关虽然也能转发 SSE，但在连接保持、缓冲控制、异常断流上的处理逻辑完全不同。

• 计费单位变了。传统限流按请求数/QPS，大模型按输入的 prompt token 和输出的 completion token 计费。同一次请求，提示词越长成本越高，模型越大单价越大，网关必须有能力按 token 做计量和限流，才能真正把成本管住。

• 路由维度变了。同一个大模型接口后面可能挂着多个模型：便宜的、快的、推理能力强的、专业领域的。路由不能只看路径，得看消息内容，甚至要在输入提示词里识别用户的意图。这在传统网关上根本没法做，需要引入语义路由能力。

• 故障模型变了。大模型服务的故障形态不是简单的“挂掉”，而是“变慢”“被限流”“返回异常内容”。如果网关只是机械地转发，无法把“上游限流”和“降级模型”联动起来，用户体验会非常差。

这四点叠在一起，决定了网关必须被重新设计，不是打几个补丁就能覆盖。这也是我写这篇对比文章的初衷。

1.3 大模型网关的四大能力模型

我习惯把一个合格的大模型网关注入四层能力。后面做对比选型时，也基本只盯着这四个层面看。

第一层，流量接入与协议转换。OpenAI 兼容协议已经是事实标准，网关需要统一对外暴露，并且能接入 OpenAI、Azure OpenAI、国内大模型平台以及私有化部署的模型服务，把各家差异在网关层抹平。第二层，语义路由与模型调度。能根据请求中的模型字段、提示词内容、用户维度做策略分配，比如普通问答走小模型，代码生成走大模型，一旦某个模型限流还能自动切换到备选模型。第三层，资源与成本治理，包括 Token 级限流、API Key 池管理与轮换、按业务线分账、超额封顶等。第四层，可观测性与审计，记录每一轮请求的 prompt、模型、Token 使用量、延迟和费用，异常时能回溯到具体某条 prompt。要是网关做不到这层，AI 应用的治理基本无从谈起。

2. 选手背景与AI原生演进路线

2.1 Higress：从“流量网关”到“AI应用网关”的快速转身

Higress 是阿里云开源的高性能网关，数据面跑的是 Envoy，控制面兼容 Kubernetes Ingress 和 Gateway API。也就是说，它出生在云原生基础设施上，天然能融入 K8s 应用平台。真正引起我注意的是它在 AI 场景上的节奏。2024 年以来，Higress 围绕大模型场景构建了一批 Wasm 插件，比如 ai-proxy、ai-token-ratelimit、ai-statistics、ai-semantic-router、ai-prompt-decorator，几乎把前面说的四层能力都覆盖了。

这些插件基于 WebAssembly 扩展，好处很直接：发版不需要重启网关，插件可以热加载，性能损耗又比传统脚本扩展低。我实测过在 Higress 里配一个 ai-proxy 插件，后端接 DashScope 的 qwen-plus，前端统一暴露成 OpenAI 格式。整个过程只需要在请求头里带上网关分配的身份信息，网关负责把用户体系映射到平台侧的模型 Key，费用隔离和 Key 权限就在这一层闭合了。这个思路非常适合多业务线共用同一个大模型账号的场景。

更关键的是，Higress 把“AI 应用网关”的落地体验做得比较完整。官方提供 mock 模型方案，业务方可以先和网关流程联调，后面再把真实模型服务接进来。这在多团队并行开发的时候省了很多不必要的等待，也让网关能力的验证可以提前到业务上线之前。

2.2 Kong：企业级API管理的AI化改造

Kong 在传统 API 网关领域体量很大，很多企业用它做内外网 API 的统一入口。从 3.6 版本开始，Kong 官方的 AI 插件家族逐渐成型，ai-proxy、ai-prompt-template、ai-prompt-guard、ai-prompt-decorator 等插件覆盖了模型代理、Prompt 模板化、内容安全等场景。Kong 的思路不是重造一个 AI 网关，而是把 AI 能力作为插件体系的一部分，塞进既有 API 管理里面，依靠它成熟的 Admin API 和 Manager 界面来落地上层策略。

需要客观说的是，Kong 的 AI 插件目前偏“接入编排”，语义路由和成本治理还处在比较初级的阶段。但它有一个传统优势是另两家短期追不上的：企业级 API 治理和审计体系成熟。官网对已有插件体系的文档沉淀也比较扎实，适合已经有大量存量 API、需要统一治理的团队。如果公司本来就在用 Kong，让现有网关快速具备 AI 接入能力，成本非常低，这也是我不否定它价值的原因。

2.3 Envoy与Istio：从服务网格平行演进

Envoy 和 Istio 严格来说不是“一个网关”，而是一套云原生流量基础设施。Envoy 是数据面，Istio 是它的控制面。在这条技术栈上，2024 年下半年出现了一个值得长期关注的动向：Envoy 社区和 Istio 社区共同推动的 AI Gateway 项目（后续已进入 CNCF 沙箱），试图用 Gateway API 的模型来抽象 LLM 服务。它的核心思路是把大模型供应商抽象成 K8s 里的资源对象，用声明式的方式管理模型、密钥、路由、Token 计量。

Istio 方向上，社区把 AI 流量当成 mTLS、鉴权、可观测性需要覆盖的一种新工作负载，同时通过 Ambient Mesh 演进 L7 策略。这个位置更底层，更偏平台能力，而不是开箱即用的业务网关。所以我把 Envoy/Istio 阵营定位成“长线基建”，适合有自研能力的平台团队，不适合指望开箱即用的小团队。对平台工程师来说，这条路的吸引力在于：最终所有流量（普通微服务和 AI 服务）会收敛到同一套基础设施里，运维心智统一，而不是再维护一套独立的 AI 网关。

3. 三大阵营正面硬刚：核心能力对比

3.1 AI流量处理能力：流式转发、SSE与长连接

做网关的都知道，流式转发看着简单，真要做好坑很多。我重点测了三个点：SSE 分块转发是否正确、是否支持连接断掉后的释放、网络抖动时网关能不能快速把上游断流的连接清理掉。

Higress 的数据面本身就是 Envoy，对 HTTP/1.1、HTTP/2 和 SSE 的支持是内核级的。实测跑 Ollama 的流式输出，客户端收到的数据块没有丢失或乱序，网关自身的 CPU 占用也低。在 200 并发流式请求的压力下，Higress 的连接保持和内存表现都比较稳定，符合我对 Envoy 内核的预期。

Kong 基于 OpenResty，在流式场景做了不少适配，Kong 3.6 之后的 AI 插件可以透传 SSE，但配置回调、节点连接池这类细节上比 Envoy 内核的方案要更小心。尤其在长连接密集的场景下，需要预留足够连接资源，否则会出现连接数被打满后新请求饿死的情况。Envoy 内核在边缘网关场景已经被大量验证，流式转发不用过多担心。但 Envoy AI Gateway 相比前两者还是新项目，接口稳定性需要观察，我把它推荐给愿意和项目一起成长的团队。

3.2 LLM路由与多模型调度：语义路由实战

这一项是三家里差距最明显的。Higress 的语义路由插件，实际上是把向量化或关键词分类逻辑跑在网关层。调用方发来一段自然语言请求，网关先通过预设的规则或模型判断意图，再把请求转发给不同的大模型。比如客服机器人场景，“查订单”走企业私有小模型，“写周报”走通用大模型。两边的费用和延迟差异非常大，语义路由带来的成本优化是实打实的。

我给团队的建议是，先用关键词规则跑通，再逐步引入语义判断，不要一上来就把网关搞成“又多了一层 AI 依赖”的东西。关键词版本可控可解释，效果不够好再上向量模型，这样的节奏踩坑最少。

Kong 目前主要基于请求头或路径来做模型选择，AI 插件支持通过 Service 或 Route 绑定不同的模型供应商。也就是说，它是通过传统路由的“变形”来实现多模型调度，能够满足基本的模型分流和灰度需求，但还没有做到 Higress 那种天然为语义设计的程度。Envoy AI Gateway 还在早期 API 演进阶段，Backend 资源管理了模型端点，调度策略的丰富程度比较有限，语义路由也没有进入实装阶段。不过它的模型路由是声明式的，资源模型上已经考虑到了多模型组织的方向，后续值得跟踪。

3.3 Token级限流与计量：从QPS到Token

大模型网关和传统网关最大的分水岭，就在这一条。我整理了对比表，读者可以直接保存参考。

这部分我重点压测过 Higress 的多 Key 轮换。网关会按健康状态挑选 Key，被平台限流的 Key 自动踢掉，过一段时间再探活恢复，再回到 Key 池。这个能力对线上成本控制很重要。因为模型平台的 Key 一旦被限流，整条链路的表现就是请求超时和报错，只靠客户端重试根本撑不住。切 Key 动作如果放在业务代码里，每个服务都要做，放在网关层才是合理位置。

3.4 可观测性：Prompt、Trace与成本关联

可观测性方面，三家思路差异也比较大。Higress 的 ai-statistics 会把模型、Token、延迟这些维度以日志形式送出去，配合 Prometheus 或 Grafana 可以做成 AI 维度的监控大盘。Kong 本身以日志插件见长，把 AI 插件产生的请求日志接到 Elasticsearch 或 Loki 并不困难。Envoy AI Gateway 继承了 Envoy 的访问日志体系，同时把 token usage 设计为可扩展策略，将来可以在控制面直接汇总。

我在调研中特别建议团队把“prompt 级日志”作为最低要求：谁问了什么内容，用的什么模型，消耗了多少 token，最终效果如何。没有这层记录，出问题连排查的入口都没有。但也要注意数据安全，prompt 往往带着用户隐私，日志必须做脱敏、告警和权限控制一起上。这也是可观测性设计的一部分，越早上越好，后面补成本高。

4. 实操环节：关键配置与踩坑实录

4.1 Higress AI网关接入实践

先说安装。如果集群里已经有 Helm，一条命令可以拉起 Higress：

helm repo add higress.io https://higress.io/helm-charts helm install higress -n higress-system --create-namespace higress.io/higress

装完之后，数据面和控制面都在 higress-system 命名空间。接下来我把一个本地运行的 Ollama 服务（模型 llama3）接到 Higress 后面。为了验证 OpenAI 兼容协议，我用 ai-proxy 插件把 Ollama 的 /api/chat 映射成 OpenAI 的 /v1/chat/completions 格式。插件配置写在 K8s 的 WasmPlugin 资源里，大致如下：

apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: ai-proxy namespace: higress-system spec: defaultConfig: provider: "ollama" model: "llama3" inferenceEndpoint: "http://ollama-api:11434"

然后创建一个 Ingress 指向 Higress，把 /v1/chat/completions 路径交给插件处理。验证时用 curl 发一个流式请求，能看到 SSE 正常返回。这里有一个比较隐蔽的坑：Ollama 默认返回的字段结构和 OpenAI 不完全一致，ai-proxy 会做字段转换。我测试时先关掉了流式，确认普通 JSON 结构没问题，再开流式，避免把两类问题混在一起排查。

随后我又配了 ai-token-ratelimit 插件，按每分钟 token 数限制某个测试业务线的用量。配置时注意一个点：token 数是插件估算，还是从模型返回的实际 usage 中统计。两种配置行为差异很大。我用的实际返回值统计，准确度高，但不返回 usage 的模型服务就会失效，这个坑要提前发现。

4.2 Kong Manager节点主动健康检查配置实录

调研期间我专门把“Kong Manager 节点主动健康检查配置”完整测了一遍。Kong Manager 是 Kong 的控制台入口，配置主动健康检查一般在“API Gateway -> Upstreams”下，选中某个 Upstream 后，在 Target 页签里打开 Health Checks。

主动健康检查的含义是：Kong 的负载均衡器按设定间隔，主动向上游节点发起探测请求，比如 GET /healthz，只有成功次数达到阈值，节点才被标记为健康并进入负载池。与之对应的是被动健康检查，它不主动发请求，只通过已有业务请求的成功/失败状态来判定节点状态。生产环境建议两者一起开，主动检查能快速发现半死不活的节点，被动检查能捕捉到只在真实流量下才出现的故障。

我在测试环境配置了一组参数，可以作为默认起点：

健康检查路径和业务监控接口不是一个接口行不行？行，但我建议单独做一个轻量的 /healthz，不要让它承担复杂业务逻辑。否则节点明明活着，只是健康检查接口因为某种原因变慢了，就会造成整个 Upstream 被误判为不可用。这是我在生产环境踩过的坑。

如果走 Admin API，对应请求可以这样写，具体字段以你所用版本的文档为准：

curl -sS -X PATCH http://localhost:8001/upstreams/{upstream_id}/healthchecks \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'active.type=http' \ --data-urlencode 'active.http_path=/healthz' \ --data-urlencode 'active.healthy.interval=10' \ --data-urlencode 'active.healthy.successes=2' \ --data-urlencode 'active.unhealthy.tcp_failures=5' \ --data-urlencode 'active.unhealthy.http_failures=5'

注意，Kong Manager 界面保存后，最终会落到 Admin API 的这组配置上，理解底层 API 结构对排查问题非常有用。我用这种方式在同一条 Upstream 下挂了两个后端节点，关闭其中一个节点后，Kong 在 30 秒内完成了摘流，恢复后又在健康检查通过后自动放量，整体逻辑符合预期。

4.3 Envoy/Istio AI Gateway的全托管K8s路径

Envoy Gateway 安装同样走 Helm：

helm install eg oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

安装后，先创建 GatewayClass 和 Gateway 资源，再用 Envoy AI Gateway 引入的 Backend 资源抽象模型端点。我配置时使用的资源大致如下，但不同版本字段会有调整，务以官方文档为准：

apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: eg spec: controllerName: gateway.envoyproxy.io/gatewayclass-controller --- apiVersion: aigateway.envoyproxy.io/v1alpha1 kind: Backend metadata: name: openai spec: provider: name: openai model: gpt-4o credentialsRef: name: openai-secret --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: ai-route spec: parentRefs: - name: eg rules: - matches: - path: type: PathPrefix value: /v1 backendRefs: - name: openai group: aigateway.envoyproxy.io kind: Backend

这段配置要表达的核心是：AI 模型、模型厂商密钥、路由规则全是 K8s 资源，平台工程师可以用 GitOps 的方式管理。但 Envoy AI Gateway 的控制器和 CRD 还在快速演进期，我建议在测试环境跑通功能后，生产环境第一个版本不要引入太多定制，尽量贴近官方示例。我们团队在这条路径上投入了不少时间，也算为后续“全流量统一基础设施”做准备。

5. 选型决策工具箱：到底该选哪个？

5.1 团队画像与场景匹配速查表

把结论放到最前面，这是我给团队做的最终选型判断：

这里的“推荐”是相对优先级，不是绝对答案。选型最终还要结合团队对开源项目的掌控能力，以及组织对云厂商的依赖程度。

5.2 迁移代价、生态绑定与长线演进

选型往往不是比一堆功能的加减法，而是盘一张长期的账。Kong 的传统优势是生态和文档，但它的 AI 原生能力从插件演进而来，底层抽象依然是“接口”，这决定了它做语义路由、Token 治理这类能力时，往往事倍功半。Higress 的 AI 能力是奔着“AI 应用网关”设计的，插件之间配合度高，但它开源社区的周边内容和文档数量，短期还没法和 Kong 比。Envoy/Istio 的 AI Gateway 更像基础设施层的一块新拼图，能否站稳脚要看后续半年到一年社区推进速度，适合有平台工程能力的团队提前卡位。

有一点值得单独强调：无论选哪个，网关层不要绑死某一家云厂商。模型厂商在变，接口协议在趋同，网关要有足够的抽象能力去对接多模型。这是我最后选择 Higress 作为主力方案的重要原因，它在不改业务代码的前提下，可以通过插件替换或组合模型供应商，留出后面做多模型切换的空间。当然，这个选择建立在团队愿意拥抱新项目的前提下，如果你的组织更看重稳定文档和成熟生态，Kong 的体系会更容易过评审。

6. 实测心得与最后建议

6.1 两个月的选型实测心得

跑这两个月，我最深的一个体会是：大模型网关的选型难点不在“选哪个”，而在于“把需求描述清楚”。很多团队还在拿传统网关的维度去比较 AI 网关，比 QPS、比并发，结果忽略了 Token 计量、语义路由、Key 管理这些更关键的能力。如果需求都拆不对，选出来的东西自然没法用。所以做选型之前，先把你们公司的接入场景、成本控制、安全边界列一个清单，带着清单去测，会比盲目看功能列表有效得多。

另一个体会是，这类开源项目迭代太快，不能只看 README 就下结论。我这次调研里，Kong 的 AI 插件、Higress 的语义路由、Envoy AI Gateway 的 API 都在测试期间更新过版本。如果你正在做选型，建议一定用真实的模型服务案例和集群环境去跑一轮，哪怕只压一个场景，也比读十篇对比文章有用。

6.2 给后来者的一条实用建议

最后再分享一个小建议：一定要在网关层先把 API Key 的安全边界做好。模型厂商的 Key 不要下放到每个业务服务里，让网关统一持有和管理，业务方只能用网关分配的身份信息。听起来像常识，但很多团队直到账号被盗刷才发现自己把 Key 写在配置中心里。另外，健康检查、Token 限流这些看起来不性感的能力，才是 AI 网关上线后最影响稳定性的部分，建议优先级排在语义路由前面。

我这次把 Higress 作为主力方案，并不是说它完美，而是它在当前阶段最贴合我们团队的需求。技术选型没有标准答案，仔细看清楚自己的处境，再对照这篇文章里的判断维度，你大概率能找到适合的答案。