企业官网建设流程全解析

2024 年之前，我从来没想过"大模型网关"会成为一个单独的技术品类。当时我们团队只是给内部工具接了个 OpenAI 兼容接口，用 Spring Cloud Gateway 转发请求，觉得网关么，路由转发、限流、鉴权，三板斧砍完就结束了。等业务方从十几个涨到一百多个，模型从一家扩展到三家，日调用量从几千涨到几十万，原来的网关在 token 成本、流式响应、模型降级这些场景里接连出问题的时候，我才意识到这一整套逻辑是全新的。

那段时间我把大模型网关的主流路线都过了一遍：阿里开源的 Higress、老牌 API 网关 Kong、以及服务网格背景的 Envoy/Istio。三条路都做了实际的部署和压测，也踩了不少文档里不会写的坑。这篇把整个决选过程、背后的技术逻辑和最终的选型建议完整复盘，给正在做同样决策的团队一个参考。文章里提到的参数和配置都是我实际跑过的，不保证版本永远适用，但思路和坑是通用的。

1. 为什么大模型网关值得单独研究：AI 流量是另一种流量

1.1 传统 API 网关的三板斧在 LLM 面前为什么会失效

传统 API 网关几十年就干三件事：路由、限流、鉴权。这三板斧放在普通 API 上没毛病，但放在大模型请求上，每一条都会失效。

先说限流。传统网关的限流维度是 QPS、并发数、带宽，设计前提是"每个请求的成本大致相同"。LLM 请求完全打破这个前提：同一个接口，prompt 短的请求几百 token 就完事，长的可能几万 token，token 数直接决定上游计费和执行时长。按 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 和 header，AI 场景要看 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 到 WasmPlugin：Istio 落地 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 能力差距

把三条路线放在一起，按我实际用下来的体验打分，这张表可以直观反映差异：

这张表的逻辑很清楚：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 抽象做在网关层，至于网关本身选哪家，反而是次要问题了。