企业官网建设流程全解析

网关这事儿，放在传统 API 时代是个成熟得不能再成熟的中间件品类，但大模型时代把网关又拉回了聚光灯下。我最近大半年几乎每两周就要面对一次选型咨询，问题从“该用 Higress 还是 Kong”到“我们的 Istio 是不是该换了”都有。说实话，标题里这三个名字放在一起对比，本身就说明大家还没形成共识：AI 原生网关到底该长什么样。

先说结论：没有完美的 AI 网关，只有匹配你团队架构和运维能力的 AI 网关。Higress 在 AI 原生能力上走得最快，Kong 在传统企业级功能上依然能打，Envoy/Istio 则是“什么都能干但什么都要自己搭”的积木式路线。这篇文章我把三者的 AI 原生演进路径、关键机制和落地方案都掰开讲，还会给出一套可操作的选型决策框架，以及我在实战中踩过的坑。

1. AI 网关到底“新”在哪：传统 API 网关为什么不够用

很多人觉得“网关不就是转发吗，大模型请求也是 HTTP 请求，老网关一样能转发”。这个想法不算错，但只看到了最表层。大模型网关和传统网关的核心差异，在于它要处理的不再是“请求-响应”的简单对应关系，而是一整套围绕模型调用展开的治理逻辑。

1.1 传统网关缺失的五项核心能力

多模型接入与统一协议适配。传统网关后面挂的是你自己的微服务，接口协议你说了算。但 AI 网关后面挂的是 OpenAI、Anthropic、Google、各家国产模型，还有自建的开源模型服务。每个厂商的 API 协议都不完全一致，路径、鉴权头、请求体格式各有差异。如果没有网关层做协议归一，业务团队每接一个新模型就要写一套适配代码，这种成本是灾难性的。

模型级别的路由与调度。传统网关的路由维度是 URL、Host、Header，AI 网关的路由维度加上了“模型”和“意图”。同一条请求，是走主力大模型还是走低成本小模型，需要根据业务场景、用户等级、复杂程度动态判断。更进一步，请求内容本身属于什么意图（翻译、写代码、客服问答），也能触发不同的路由策略。这是传统网关完全没概念的能力。

流式响应的网关侧治理。大模型响应基本全是 SSE 流式输出，传统网关注重的是请求转发和响应缓存，对流的处理非常弱。AI 网关需要支持流式转发、流式限流、流式内容的实时过滤和修饰，还要处理客户端断连时如何通知上游终止生成——这个能力直接关系到你的账单。

Token 维度的计量与限流。传统限流看 QPS，AI 网关必须增加 Token 维度。一次请求可能消耗几百 Token，也可能消耗几万 Token。如果只按 QPS 限流，一次恶意或异常的巨额 Token 请求就能打爆你的模型预算。

模型故障转移与降级。传统网关的熔断降级是针对服务实例的，AI 网关的降级是针对“模型供应商”的。OpenAI 挂了要自动切到 Anthropic 或者切到自建模型，这种切换还要考虑不同模型的能力差异，不是简单的 LB 摘除节点那么粗暴。

1.2 为什么不该把这些问题抛给业务代码

有一个很经典的误区：觉得“我自己写个 SDK 封装一下就行了，不用上网关”。如果你只有一两个服务在调模型，这个方案确实可行，但服务一多就失控了。

业务代码直接集成模型 SDK，意味着每个服务都要维护自己的 API Key、都要自己写重试和故障切换逻辑、都要自己统计 Token 用量。结果是：公司层面没有一个统一的模型调用视图，成本核算全靠 Excel 人肉统计；某个模型服务出故障时，各服务各自为战，有的切了备用模型，有的还在疯狂重试打满供应商限流配额；新接入一个模型时，所有服务都要改代码发版。

网关层解决的就是这个集中化问题。模型 API Key 只在网关存一份，策略在网关统一配置，调用数据在网关统一采集。业务团队只需要面向网关暴露出来的“公司内部统一模型接口”开发，完全不需要关心背后到底接了几家供应商。这就是 AI 网关最本质的价值。

2. 三强对决：Higress、Kong、Envoy/Istio 的 AI 原生能力拆解

这三个方案的差异，本质上是路线之争。Higress 是“为 AI 而生，开箱即用”，Kong 是“传统强者逐步补课”，Envoy/Istio 是“基础设施派，啥都给你但啥都要自己装”。

2.1 Higress：AI 原生网关的激进派

Higress 是阿里开源的一款基于 Envoy 构建的云原生网关，它的设计理念从一开始就没打算只做传统流量管理。从 1.x 版本开始，Higress 就内置了大量 AI 场景插件，到了 2.0 版本更是直接把 AI 网关作为核心定位。

AI Proxy 插件是它的杀手锏。这个插件实现了最核心的协议归一能力：网关对外暴露一个统一的 OpenAI 兼容接口，对内你声明好各家供应商的接入信息，请求进来后由插件自动转换成对应供应商的协议格式再转发。

# Higress AI Proxy 配置示例（简化） providers: - name: qwen type: openai baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1 apiKey: ${env.QWEN_API_KEY} models: - qwen-max - qwen-plus - name: deepseek type: openai baseUrl: https://api.deepseek.com/v1 apiKey: ${env.DEEPSEEK_API_KEY} models: - deepseek-chat - name: llama-local type: openai baseUrl: http://llama-server.default.svc.cluster.local:8080/v1 models: - llama3.1-70b # 路由规则：默认走 qwen，失败自动切换到 deepseek，再到本地 llama routes: - name: primary-fallback fallbackModels: - qwen - deepseek - llama-local

这段配置解决的事情，放在传统网关里你至少得自己写一个几百行的自定义插件才能做到。而 Higress 里这只是一个配置项。

Semantic Router 实现了真正的“语义路由”。这个能力非常强——它不是看 URL 或 Header 做路由，而是分析请求里的 Prompt 内容，根据语义判断该走哪个模型。比如电商场景里，简单商品问答走便宜的小模型，复杂售后纠纷走最强的主力模型。这种路由粒度在传统网关里是完全不可想象的。

原生 MCP 支持是它面向 AI Agent 时代的前瞻布局。MCP（Model Context Protocol）是现在 AI 应用与外部工具交互的热门协议。Higress 在网关层直接支持 MCP 的聚合与转发，可以把多个 MCP Server 统一收敛到一个网关入口，Agent 应用只需要对接网关这个“超级 MCP Server”。这个能力现在很多网关都还在规划中，Higress 已经落地了。

Wasm 插件机制保证了扩展性。Higress 基于 Envoy 的 Wasm（WebAssembly）插件体系做了二次封装，自带插件市场，可以像安装应用一样给网关装插件，不需要重新编译、不需要重启网关进程。这对运维来说是巨大的便利——改插件逻辑就是热更新，业务不中断。

配套的 AI 可观测性。Higress 的指标里直接内置了 Token 消耗、模型响应延迟、各供应商成功率等维度，配合 Grafana 面板可以直观看到每个模型的成本和使用情况。这个能力传统网关要么没有，要么你得自己从日志里二次加工。

2.2 Kong：传统网关强者的 AI 补课

Kong 在企业级 API 管理领域的地位不用多说了，它的核心优势在于成熟稳定、插件生态丰富、管理面功能完善。Kong 的 AI 路线是典型的“渐进式增强”：底层转发能力不变，通过插件补齐 AI 场景需求。

Kong AI Gateway 插件家族。Kong 在 3.x 版本中推出了官方 AI Gateway 功能集，核心插件包括：

• AI Proxy / AI Proxy Advanced：负责协议转换和模型路由，支持 OpenAI、Cohere、Azure 等多个供应商格式。AI Proxy Advanced 额外支持多模型负载均衡和 Fallback。
• AI Semantic Prompt Guard：做 Prompt 注入攻击的检测防御。这个插件用 AI 模型本身来判断输入中是否含有注入攻击的语义，对安全要求高的场景非常有用。
• AI Request Transformer：在转发前对请求体做语义级转换，比传统的 Request Transformer 插件更智能。
• AI Response Transformer：在流式响应上做内容修饰和格式转换。

光看功能列表，Kong 的 AI 能力覆盖得其实挺全。但注意一个关键区别：Higress 的 AI Proxy 是核心内置能力，Kong 的 AI 功能是插件生态的一部分。这意味着你要自己装配、自己验证插件之间的兼容性，而且某些高级 AI 功能只有在企业版中才提供。

Kong Manager 的主动健康检查配置。我最近帮人排查过一个 Kong 场景的问题，正好涉及健康检查配置。在 AI 网关场景里，健康检查非常重要——模型供应商的可用状态直接决定路由要不要切换。

Kong 的节点主动健康检查配置一般在 Upstream 的healthchecks.active部分：

# 通过 Kong Admin API 配置 health check 的典型方式（Kong Manager 里对应 UI 操作） curl -X PATCH http://localhost:8001/upstreams/ai-models \ -H 'Content-Type: application/json' \ -d '{ "healthchecks": { "active": { "type": "http", "http_path": "/health", "healthy": { "interval": 10, "http_statuses": [200, 301, 302], "successes": 2 }, "unhealthy": { "interval": 10, "http_statuses": [429, 500, 503, 504], "http_failures": 3, "timeouts": 2 } }, "passive": { "healthy": { "http_statuses": [200, 301, 302], "successes": 3 }, "unhealthy": { "http_statuses": [429, 500, 503, 504], "http_failures": 3, "timeouts": 2 } } } }'

这里有几个参数值得特别注意。Interval 不建议设太低，模型供应商的健康检查端点可能并不愿意承受高频探测，10 秒是一个合理起点；状态码 429 必须纳入不健康判定，因为 429 表示限流，说明该供应商已经过载，继续往里打流量只会让情况更糟；Successes 和 Failures 的阈值要结合供应商实际的稳定性设置，设得太低会导致抖动频繁切换，设得太高又起不到保护作用。我通常建议 Successes=2、Failures=3 起步，运营一段时间后再根据实际表现微调。

DB-less 模式的优劣。Kong 支持传统数据库模式和 DB-less 模式。DB-less 模式下配置以声明式 YAML 管理，适合 GitOps 流程，但代价是 Kong Manager 的 UI 操作会受限，配置修改后需要推送新的声明式配置文件。在 AI 场景下我建议用 DB-less 模式，因为 AI 网关的配置变更频繁，版本化管理和回滚很重要。

2.3 Envoy/Istio：基础设施派的自主路线

Envoy 是数据面的事实标准，Istio 是服务网格的主流实现，这套组合的定位从来不是“开箱即用的 AI 网关”，而是“你可以用它搭出任何你想要的东西”。这种自由度的代价是——你得自己动手。

Envoy 作为 AI 网关的能力底子。Envoy 本身具备非常完善的 HTTP 处理能力：七层路由、负载均衡、熔断、重试、超时、限流、外部鉴权（ext_authz）、Wasm 扩展。这些是所有 AI 网关功能的地基。比如模型供应商的负载均衡和故障转移，用 Envoy 的 Cluster 定义和 Weighted Cluster 就能实现；超时控制和重试策略，用 Route 的 Timeout 和 Retry Policy 就能搞定。

# Envoy 配置片段：模型供应商 Cluster 定义与超时重试策略 clusters: - name: openai_cluster connect_timeout: 2s type: STRICT_DNS lb_policy: LEAST_REQUEST load_assignment: cluster_name: openai_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: api.openai.com port_value: 443 health_checks: - timeout: 2s interval: 10s unhealthy_threshold: 3 healthy_threshold: 2 http_health_check: path: /v1/models

但距离“AI 网关”还差一整层。协议转换（把 OpenAI 格式转成 Anthropic 格式）、Token 计量、语义路由、Prompt 安全管理——这些 Envoy 原生都不提供。你面临两个选择：要么用 Wasm 写插件实现，要么在外面套一层业务服务做协议适配。

Wasm 插件方案的好处是性能好、和 Envoy 进程内联，但开发调试成本很高，而且 Envoy 的 Wasm SDK 和 Higress 封装的插件 API 相比，简直是在用汇编语言和高级语言写同一个功能。外部适配服务方案更容易实现，但多一跳网络开销，还多了一个需要维护的高可用组件。

Istio 的价值主要在流量管理和安全。Istio 提供的是控制面和边车注入能力，VirtualService、DestinationRule、PeerAuthentication 这些抽象对微服务间的通信治理非常有用。在 AI 网关场景下，我更倾向于把 Istio 用在服务网格内部——比如控制业务服务到 AI 网关之间的流量——而不是用它来直接做 AI 网关本身。

什么人适合选 Envoy/Istio 路线？我见过一个平台团队，他们在 Envoy 上自研了一套内部 AI 网关，做了模型接入编排、令牌桶、按部门计量费用等功能，共投入了三个后端开发将近两个季度。团队规模在 10 人以上、有足够的基础设施研发资源、对控制力要求极高——符合这些条件的可以考虑这条路，否则建议谨慎。

3. 选型决策：三个实战场景对应的推荐方案

光看功能列表做不了决策，得回到你自己的场景里来。我用三个典型场景拆解一下不同方案的实际表现，你可以对号入座。

3.1 场景一：中小团队快速接入多家模型，要开箱即用

假设你是一个几十人的产品团队，后端十来个服务，现在要接 OpenAI、通义千问和本地部署的一个开源模型。你有三个诉求：统一网关入口方便前端调用、故障时自动切换供应商、成本中心能看到每个业务的 Token 消耗。

这个场景我直接推荐 Higress。理由很直接：你花在实现核心链路的时间几乎为零。部署一个 Higress，配置 AI Proxy 插件声明好三家供应商，再挂一个 Token 限流插件，核心需求就全部满足了。语义路由和 MCP 这些功能你现在用不上，但等业务涉足 Agent 场景时，这些能力直接就有，不需要二次搬迁网关。

一个小建议：部署形态推荐采用 Higress 的 Helm Chart 安装到 K8s 集群里，和业务服务走 Ingress 同链路。如果是非 K8s 环境，Docker Compose 方式部署也能跑起来，但少掉的服务发现和动态配置能力会限制后续演化空间。

3.2 场景二：传统企业需要成熟管理面，已有 Kong 体系

假设你所在的企业已经用 Kong 管了多年 API，管理流程、审计合规体系都围绕 Kong 建立起来了，现在要引入 AI 能力。此时推倒重来换网关几乎不可能，最高效的路径是在现有 Kong 体系内打 AI 补丁。

你需要装好 AI Proxy Advanced 插件（企业版）或者 AI Proxy 插件（开源版），在 Upstreams 里定义好模型供应商目标，配好主动健康检查，再给 AI 路由挂上适合的限流策略。如果你们之前是 DB-less 模式，叠加声明式管理加上 GitOps 流程就能做到 AI 配置的版本化审计。

这个路线的痛点是 AI 能力的深度有限。语义路由、MCP 聚合这些前沿能力在 Kong 里要么没有要么很初级。如果未来业务对 AI Agent 场景爆发式增长，可能还是要评估专门的 AI 网关旁挂方案。

3.3 场景三：大厂平台团队要完全自控

假设你有独立的平台基础设施团队，运维着大规模 K8s 集群，内部有严格的安全合规要求。AI 模型接入必须走内部的统一协议，不允许把各家供应商的 SDK 直接暴露给业务线。

这种场景下 Envoy/Istio 路线释放的自由度是 Higress 和 Kong 都给不了的。你可以定义自己的“公司内部模型协议”，用 Envoy 的 L4/L7 能力做底层转发；用 Wasm 插件实现协议转换、计量和路由；用 Istio 做网格内的安全通信和灰度发布；自己上 Prometheus+Grafana 监控模型调用指标。

但这要求你清楚认识到这是一条重投入路线。你要组建一个虚拟团队专门维护这套网关，持续跟进 Envoy 上游版本更新，自己解决生产环境里遇到的各类边缘问题。我认识的团队走这条路的，没有一个小体量的。

3.4 一张表看透三个方案的本质差异

4. 深度实操：Higress 和 Kong 的 AI 网关落地方案

选型之后真正难的是落地。这一节我把两个主流方案（Higress 和 Kong）从部署到配置的完整步骤写清楚，附带我实测过的最佳参数实践。

4.1 Higress 快速部署并配置第一组模型路由

部署。Higress 官方提供 Helm Chart，如果你的集群里有 Istio，注意 Higress 有两种运行模式：作为 Istio 数据面的代替品直接运行，或者以独立网关形态运行在网格外侧。我建议 AI 网关场景先用独立网关模式，避免和服务网格的控制面产生耦合。

# 添加 Helm 仓库并安装 Higress（简化版） helm repo add higress.io https://higress.io/helm-charts helm install higress higress.io/higress \ --namespace higress-system \ --create-namespace \ --set global.local=true \ --set global.disableAlpnH2=true

安装完成后，通过kubectl get svc -n higress-system查看网关对外暴露的负载均衡地址。

配置企业模型供应商。通过 Higress 的 Console 或用 Kubernetes CRD 定义 AiProxy 资源。我习惯用 CRD 方式，因为可以纳入 Git 管理。

配置好之后，你的业务调用入口就统一变成了 Higress 暴露出来的 OpenAI 兼容端点：https://your-gateway.com/v1/chat/completions。业务代码里只需要配一个固定的base_url和网关下发的api_key，至于这个请求实际打到哪家模型供应商，完全由网关侧路由策略决定。这种解耦带来的收益，你只有真正接了三家以上模型之后才能感受到。

配置 Fallback 链路。当主力模型供应商出现故障时，Higress 会根据你在fallbackModels里声明的前后顺序自动切换。关键在于：切换粒度可以是模型级别，也可以是供应商级别。

我可以做到“qwen-max 挂了自动切 qwen-plus，qwen-plus 也挂了再切 deepseek-chat”，这种多级降级策略比传统网关简单粗暴的实例摘除要精细得多，因为不同模型的能力边界和成本差异是真能影响业务结果的。

4.2 Higress 语义路由配置实战

语义路由是 Higress 的差异化功能，值得单独实操一遍。它的本质是接入了某个 Embedding 模型（可以复用你的供应商，也可以单独指定），对请求里的 Prompt 做向量化，和预设的意图模板做相似度比对，再根据匹配结果绑定不同的路由策略。

假设你要做一个客服机器人场景：

• 简单问题（如查物流、改地址）→ 走便宜快速的小模型
• 复杂问题（如纠纷仲裁、退款判定）→ 走最强的主力模型

配置语义路由规则前，你必须先用一批真实的历史问题样本去测试你的 Embedding 模型对意图区分的准确率。这个环节被很多人跳过，但在实际运行中它就是路由准不准的命根子。我在实测中发现，Embedding 模型的选择差异对路由准确率的影响，远比阈值参数调整要大。同一个意图区分任务，换个 Embedding 模型准确率可能从 70% 提到 90%。

语义路由规则下发后，Higress 会在请求处理链路中做一次向量比对，这个延迟通常在 5-15ms 左右，对 LLM 动辄几秒的响应时间来说可以忽略不计。

4.3 Kong 部署 AI 插件并配置主动健康检查

安装 AI 插件。Kong 3.6+ 版本的 AI 插件可以用 Kong Manager UI 操作，也可以用deck命令行管理。假设你用声明式配置方式，给服务llm-service挂上 AI Proxy 插件的配置大致如下：

_format_version: "3.0" services: - name: llm-service url: http://localhost:8000 routes: - name: llm-route paths: - /v1/chat/completions plugins: - name: ai-proxy config: route_type: llm/v1/chat auth: header_name: Authorization header_value: env OPENAI_API_KEY model: provider: openai name: gpt-4o targets: - route_type: llm/v1/chat auth: header_name: Authorization header_value: env ANTHROPIC_API_KEY model: provider: anthropic name: claude-3-5-sonnet

这段配置的语义是：对外暴露一个/v1/chat/completions端点，主目标指向 OpenAI 的gpt-4o，备用目标指向 Anthropic 的claude-3-5-sonnet。当主目标触发健康检查熔断时，Kong 自动把流量切到备用目标。

配置主动健康检查的完整参数。上一节我给了 API 方式，这里把参数建议写清楚：

注意：健康检查只是发现故障的一只眼睛，要完整实现“故障自动切换到备用模型”，还需要把 AI Proxy Advanced 插件和 Upstream 的健康检查打通。没有健康检查的 Fallback 配置是残缺的，流量切过去之后不会自动切回来，除非目标恢复后手动干预或被动健康检查重新标记目标为健康。

4.4 流式响应场景下的超时与重试参数调优

大模型请求的流式响应特性，使网关的超时和重试参数必须专门调优，绝不能沿用传统 API 网关默认值。

超时参数。大模型请求最长响应时间很难预估，简单问答 2 秒能回，长文档摘要可能要 60 秒以上。传统网关常用的 5 秒/10 秒超时直接会让长任务全部中断。我在 Higress 上一般把超时设为 120 秒起步，Kong 上对应设置 Upstreamread_timeout=120000，Envoy 上对应 Route 级timeout: 120s。

但有一点很关键：超时不能无限放宽，这会掩盖上游模型服务的真实问题。我的做法是：区分场景设置不同超时——简短对话类走 30 秒，长文生成类走 120 秒，文件处理类走 300 秒。关键在于你的业务侧必须能容忍“生成过程中客户端连接断开”这个状态。

重试策略。LLM 请求和普通 HTTP 请求最大的不同是：重试可能重复计费。你发了一次请求，模型已经生成了内容，但因为网络中断没收到响应，如果网关盲目重试，等于同一份内容你付了两次钱。

因此 AI 网关场景的重试必须严格遵守两个原则：只在连接建立前失败时重试（上游还没开始生成内容）；绝不在响应流中断时盲目重试。Higress 和 Kong 的 AI 插件实际上都对重试做了保守处理，但你手动配 Envoy 的 Retry Policy 时，一定不要照抄普通微服务的贪婪重试配置。

我实测一个很实用的策略：重试次数设 1 次就够，重试超时加倍。比如首次超时 60 秒，重试超时给 120 秒。这样既给了上游一次喘息机会，又不会因为多次重试导致费用失控。

5. 常见问题与排查技巧实录

这个部分是踩坑总结。AI 网关的故障模式比传统网关丰富得多，很多问题在传统场景里根本不存在。

5.1 模型供应商返回格式不兼容导致网关报错

现象：同一套配置，接 OpenAI 完全正常，换一个国产模型供应商之后频繁 502 或者解析错误，但供应商那边查日志说请求成功返回了。

原因：各家供应商对 OpenAI 兼容协议的支持程度参差不齐。有的字段名不一致（比如finish_reason可能标注为stop_reason），有的流式格式不完全符合 SSE 规范（缺少data:前缀或[DONE]标记处理差异）。

排查路径：第一步，在网关配置里临时关掉流式响应改为非流式，看是否还报错，如果能定位到是流式解析的问题；第二步，用测试工具直接请求供应商原始 API 对比响应体差异；第三步，看网关日志里透传的原始响应内容，确认哪个字段解析失败。

解决：从协议适配角度，Higress 对主流国产模型做了兼容处理，这类问题少一些。自建方案遇到只能自己写适配层——这也是我反复强调协议归一能力重要性的原因。

5.2 健康检查配置正常但 Fallback 就是不生效

现象：Kong 的 Upstream 健康检查配置检查没问题，目标供应商也已经标记为不健康，但 AI Proxy 插件的流量还是打到故障目标上，Fallback 目标没收到任何流量。

原因：这是典型的“健康检查状态”和“路由策略”没有联动。Kong 的健康检查作用于 Upstream 的 Target 选择，但 AI Proxy 插件的模型选择逻辑走的是另外一套配置体系。AI Proxy Advanced 和企业版的 AI 路由能力才会根据健康状态自动切换模型目标。开源版 AI Proxy 插件只做静态单目标转发，完全没有 Fallback 能力。

解决：用 AI Proxy Advanced 插件，并在配置里声明多个 target 时，Kong 会自动根据健康检查状态选择可用目标。或者自己写一套外部巡检脚本，定期检查模型供应商状态，再动态调整 Upstream 中 Target 的权重。

5.3 流式响应下网关内存飙升

现象：开启流式转发后，网关节点内存增长明显，高峰期甚至触发 OOM。

原因：传统网关把整个响应体缓冲到内存里再回给客户端，流式场景下如果网关层没有做真正的流式透传，而是先把整个 SSE 流攒齐再转发，当一次生成几千 Token 时内存消耗就非常夸张。

解决：确认网关的流式转发是边收边发模式。Higress 的流式处理是原生支持的，不需要额外配置。Kong 的ai-proxy插件在处理 SSE 时也是边解析边转发，但要检查是否有插件在中间做了缓存。另外，给网关 Pod 设置合理的内存限额（建议 512Mi 起步）并开启水平扩缩容，防止突发流量把节点打垮。

5.4 限流策略误伤正常用户

现象：按 Token 限流后，业务方反馈有些正常用户被频繁限流，后台一查，这些人单个请求消耗的 Token 确实很少。

原因：这是典型的“只按单请求 Token 限流”导致的可绕过大单请求问题。一个用户可以在 1 秒内发起 100 个小请求，每个请求都低于单请求限制，但总量已经远超预算。传统按 QPS 限流的思路漏掉了 Token 维度，而只按单请求 Token 限流又漏掉了频率维度。

解决：必须采用双层限流：网关层同时限制 QPS 和 TPM（每分钟 Token 数）。Higress 的 Token 限流插件支持分钟级维度，Kong 可以用限流插件做 QPS 限流，再叠加一层自定义 Token 统计。我的经验是 TPM 限制应该按用户等级区分（免费用户和 VIP 用户分别设限），不同模型特别是不同价格档位的模型分开统计。

6. 最后说点个人体会

做 AI 网关选型这一年多，我最大的体会是：别被“AI 原生”这个词绑架。团队没有自研能力却选了 Envoy/Istio，最后大概率会陷入自建网关的泥潭；团队有明确 AI Agent 规划却选了传统网关补丁路线，后面很可能要二次迁移。选型本质上是把自己的团队实力、业务阶段、长期规划放在一起做匹配。

给准备动手的人三个建议：

第一，先用一天时间做概念验证（POC）再定方案。找几个真实业务请求，分别在 Higress 和 Kong 上跑一遍，重点测三个指标：接入速度、故障切换体验、以及是否满足你现有监控体系的接入要求。纸上对比一百遍不如真跑一天。

第二，从最简单的模型接入起步，逐步增加复杂性。先只接一家供应商跑通全链路，再增加第二家配 Fallback，最后再上语义路由和 MCP。一次搞太多 AI 特性，出了问题你都分不清是配置错误还是方案本就不行。

第三，一定把成本和用量可视化做起来。不管选了哪个方案，上线第一天就要有 Token 消耗、请求量、延迟的分维度看板。模型费用失控的案例我见得太多了，没有数据支撑，你根本拿不出优化方案。

网关本质上是一个“流量治理的集中点”，AI 时代的网关只是把治理的维度从“服务”扩展到了“模型”，底层逻辑没有变。先把模型接入的稳定性、成本和安全管好，再往前看语义路由和 Agent 场景，这个顺序不会错。