最近在帮团队重新搭 AI 应用的接入层前后试了 Kong、APISIX、以及几个专门做 LLM Gateway 的商业产品折腾一个多月最后还是把 Higress 这个“中登”请了回来。中登这个词放在技术圈多少带着点自嘲不年轻了不像新框架那样满身噱头但胜在稳、能扛事、该会的东西一样不缺踩过的坑比年轻时候走过的路都多。Higress 在我眼里就是这么一个角色——外表看着像传统网关骨子里却是奔着 AI 时代去的。它不是那种把 AI 挂在嘴边、实际只是包了一层 Prompt 的玩具项目。Higress 本身就是云原生网关早期在阿里内部承接了双十一大促的海量流量沉淀了极强的稳定性和扩展能力后来转向开源并加入 CNCF把 Envoy、Istio 的能力打磨到生产可用。而到了现在这个阶段它又前瞻性地补齐了大模型流量的治理能力多模型路由、token 计量、AI 插件、流式响应处理、一站式的可观测性。说它是当下做 AI Gateway 时很值得优先考虑的一个选项真不是抬举。这篇文章我想聊点实在的Higress 在 AI 时代到底解决了哪些传统网关解决不了的问题核心能力怎么用实际操作中会踩到哪些坑以及在什么团队规模下适合把它放进自己的技术栈。尽量少讲空泛的概念多讲能直接落地的经验。1. AI 流量为什么让传统网关开始“力不从心”1.1 从请求维度到会话维度的质变过去我们做 API 网关核心处理对象是“请求”进来一个 HTTP request做鉴权、限流、路由然后转发给下游拿到响应返回给客户端。整个过程是短连接、同步的、上下文无关的。哪怕有 Gateway 插件去改 Header、做灰度逻辑都相对单纯因为每次请求都是独立的。但接入大模型之后整个流量模型变了。应用要跟 LLM 服务做流式对话一次会话里可能包含多轮上下文同一段业务逻辑会同时请求多个模型做对比请求不再只是“发出去就能拿到结果”而是变成了一条长时间存在的流。响应内容是分片到达的失败可能发生在中途Token 消耗要按每次请求分别统计。这直接带来一个问题传统网关的限流、熔断、监控都是面向“请求数 QPS”设计的。但现在 AI 接口的成本、负载、风险不再只取决于请求次数更多取决于 Token 数、对话轮数以及模型处理时长。我曾经在一个项目里用 Nginx 做代理发现限流完全失效——因为用户一次会话中会产生极高频的子请求而我们的配额是按“月 Token 总量”卖的Nginx 根本不知道一个响应里有多少 Token。这不是换一台网关、写几个 Lua 脚本就能解决的问题而是整个网关的领域模型都需要升级。1.2 AI 网关不只是“转发”Higress 团队在早期设计 AI 能力时显然认识到了这件事。他们不是简单给网关加一个“启用大模型”按钮而是把 AI 流量所需的通用逻辑做成了网关原生能力多家模型服务商的统一接入与协议转换基于路由规则的模型灰度、按业务场景选择模型Token 级别的计量、限流、配额管理针对流式响应SSE的过滤、缓存、内容审核一种插件机制让你可以在请求前、响应后、甚至每个流式 chunk 到达时执行自定义逻辑。这种从“短请求”到“长连接 流 Token”的建模方式是传统网关很难模仿的。因为背后的数据面是 Envoy而 Higress 则把 Envoy 的高性能网络模型和 CRD 控制面能力结合到了一起这让它可以越过诸多自研网关难以逾越的“高并发 可扩展”门槛。我在一个实际项目里用 Higress 同时代理了 OpenAI、通义千问和本地部署的Qwen模型并且通过同一个对外域名暴露给业务方。业务方只知道自己在调用一个标准接口根本不用关心背后是哪个模型供应商。每次调用的 model 参数只用在内部路由中这也是现在很多团队做“模型中台”的第一步。2. Higress 的 AI 能力矩阵比“中转代理”多走好几步2.1 多模型路由让每个业务挑适合自己的模型传统的服务路由是根据 URL 或 Header 做分发比如/api/v1/pay转发到支付服务/api/v1/user转发到用户服务。Higress 当然支持这套基本能力但在 AI 场景下它的路由维度更灵活。你可以这样配置外部请求统一打到https://gateway.example.com/v1/chat/completionsHigress 根据请求体中的 model 字段作为路由条件例如model: qwen-plus- 转发到阿里云 DashScopemodel: gpt-4o- 转发到 OpenAImodel: internal-embedding- 转发到内网自建的 embedding 服务这让你的后端服务不再需要写出一堆 if-else 去判断调用哪家 API所有决策都收敛到网关层。好处非常明显模型供应商变动时业务代码不受影响想给某个高价值客户单独分配 GPT-4o而内部测试流量走便宜模型只需要调整一条路由规则。更精细的玩法是做模型灰度。比如你在测试一个新的微调模型先让它承接 5% 的线上请求。这种场景如果用代码实现需要改服务配置并发布。但在 Higress 里可以直接利用插件或基于权重路由将指定比例的流量切到新模型上。我有个朋友所在的团队就是这样用半个月时间灰度了一个垂域微调模型彻底替代了他们原先调用的通用大模型成本下降了 70%整个过程没有一次发版。2.2 统一接口协议把“兼容层”外置AI 模型服务商五花八门OpenAI 是 OpenAI 的格式Anthropic 是 Anthropic 的格式国内各家也有自己的风格。如果业务方直接集成多家SDK 和数据结构会非常混乱如果自己写一层适配又成了纯体力活而且测试成本不低。Higress 在数据面内置了协议转换能力。它对上游可以对接多种格式对下游则可以暴露统一的 OpenAI 兼容风格接口。这意味着你的业务团队只要写一套 OpenAI SDK 调用逻辑就能访问各种底层模型未来新增一家供应商时只需要在网关中配置一个 upstream将请求体里关于该模型的具体差异在网关侧消化掉。实测下来这种外置协议转换对业务侵入极低。我们遇到过一个场景某第三方模型返回的字段名和 OpenAI 规范不一致比如output_text而非choices[0].message.content。原先所有业务代码都得适配这个特例后来我们把协议转换逻辑放进 Higress 的 AI 插件里业务侧看到的还是标准 OpenAI 响应底层却已经悄悄映射过了。稳定运行一个季度没出过问题。2.3 Token 计量与配额控制很多团队上 AI 网关第一诉求其实是“成本管控”。随着业务方使用大模型的场景越来越多谁在调用什么模型、消耗了多少 Token、花了多少钱如果只有一个大而全的账单根本没法做内部结算。Higress 提供 token 级别的计量也就是请求结束或者流结束时能精确从模型响应中解析出 prompt_tokens、completion_tokens、total_tokens并标记到某条调用记录里。配合它的 Prometheus 指标你可以看到每个业务线 / 每个 API Key 的 Token 消耗趋势不同模型的平均响应时长与 Token 吞吐单次会话的 Token 分布、异常请求如超长输出、中途中断的占比。限流也不再只看 QPS而是可以按 Token 维度来限制。比如某个免费套餐用户每天最多消耗 100K Token一旦超过网关直接返回 429。这点是我们迁移到 Higress 的最大动力。2.4 流式响应执行插件AI 网关的特殊舞台很多网关能处理普通 HTTP 响应但遇到 SSEServer-Sent Events流式响应就“傻眼”了因为流式响应的 Body 是一块块到达的传统 Lua / Java 插件很难在数据流上进行逐段处理。Higress 基于 Envoy 则可以实现对流式响应的逐 chunk 过滤。这个能力意味着你可以做很多传统网关做不到的事在流式返回过程中逐段对内容做敏感信息过滤针对流式响应做增量缓存把第一块 Token 快速返回后后续内容在网关节流刷新把 token 消耗信息从流尾动态解析并写入访问日志实现 AI 内容审核一旦发现异常话术直接在网关层夹断连接。我常用它做一个很实用的功能对不同等级客户返回不同的首字延迟策略。免费用户的流式响应可以加一点延迟缓冲保证付费用户享受更流畅的资源调度。这虽然有些“区别对待”但确实是商业产品逃不开的诉求。用 Higress 实现这类逻辑不需要改上游插件一处配置就搞定。3. 实操记录从零部署到把第一个模型请求跑通3.1 环境准备与安装Higress 的安装方式有很多种Kubernetes 环境建议用 Helm测试环境也可以直接用 Docker 一键起。这里我以 Docker Compose 快速体验为例因为不是所有团队都一开始就有 K8s 集群。我用的是官方镜像docker run -p 8000:8000 -p 8443:8443 --name higress -d higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/higress:latest # 等待容器启动后访问本地控制台 open http://localhost:8000如果你是 K8s 环境则通过 Helmhelm repo add higress.io https://higress.io/helm-charts helm upgrade --install higress higress.io/higress -n higress-system --create-namespace安装本身并不复杂麻烦的是后续理解和配置 Higress 的几个核心 CRD 概念。刚上手的人容易把 Higress 当成传统单体网关去配一上来就找nginx.conf或者路由配置文件但其实它的思路更像 Istio Ingress Controller一切配置都以 Kubernetes CRD 的方式存在最终由 Higress Controller 转化为 Envoy 的配置。如果你不熟悉 Envoy并不妨碍使用 Higress因为大部分工作只需要操作三种资源Ingress/Http2Ingress对外暴露的 API 入口规则Gateway监听端口和 TLS 配置McpBridge注册到 Higress 的后端服务来源可以是 Kubernetes Service、Consul、Nacos 甚至静态 IP。初次上手最容易漏掉的是在Ingress中设置精确的路由目标服务。Higress 默认会监听 Ingress只要你的服务在集群里便能自动解析到目标 Endpoint。3.2 配置 OpenAI / DashScope 模型路由假设你有一个业务域名ai.example.com我们需要做到客户端统一请求/v1/chat/completions请求 body 中 model 为qwen-plus时转发到阿里云 DashScopemodel 为gpt-4o时转发到 OpenAI。先创建一个后端服务定义指向外部的模型供应商apiVersion: networking.higress.io/v1 kind: McpBridge metadata: name: llm-providers namespace: higress-system spec: registries: - type: dns name: dashscope domain: dashscope.aliyuncs.com port: 443 - type: dns name: openai domain: api.openai.com port: 443这里注册了两个 DNS 类型的 upstream。接下来是 Ingress 路由apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ai-gateway namespace: higress-system annotations: higress.io/upstream-vhost: dashscope.aliyuncs.com spec: ingressClassName: higress rules: - host: ai.example.com http: paths: - path: /v1/chat/completions pathType: Prefix backend: service: name: dashscope port: number: 443这只基础转发但还没有处理模型选择。要让网关真正理解 model 字段并自动路由可以用 Higress 提供的 AI Proxy 插件中文叫 AI 代理。它支持 OpenAI、Azure OpenAI、DashScope、Anthropic、百度千帆等多个 provider。以 DashScope 为例在 Higress 控制台添加插件并填写如下配置aiProxy: enable: true provider: type: dashscope apiTokens: - sk-xxxxxx routeRules: - match: model: qwen-plus targetProvider: type: dashscope fallbackProvider: type: dashscope这样所有命中这个 Ingress 的调用都会走 AI Proxy 插件插件会解析请求体中的 model 字段找到对应路由。如果没有匹配到就走 fallback provider。OpenAI 的配置类似只需要把 provider 类型改成openai并填入你的 API Key。更关键的是Higress 还允许你在targetProvider中重写模型名。比如你在请求里写的是gpt-4o-mini实际上想映射到公司的内网中转服务也可以在配置里通过modelMapping映射掉这个我们后面会讲。3.3 一个最简单的请求验证完成配置后在任意一台能访问该网关的机器上执行curl http://ai.example.com/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-plus, messages: [{ role: user, content: 你好请用一句话介绍你自己 }] }如果能收到正常的 completion 响应说明基本链路通了。注意首次请求可能会因为上游 DNS 解析、TLS 握手而稍慢但正常情况 1~2 秒内应该返回。很多人在这一步卡住问题往往不是 Higress 本身而是上游服务的 Host 头未正确传递。阿里云 DashScope 的 OpenAPI 对 Host 校验很严格如果你使用自定义域名访问网关并且没有在 Higress 中把到上游的Host头设置为dashscope.aliyuncs.comDashScope 会返回 403。所以上面 Ingress 的higress.io/upstream-vhost注解必须配置。3.4 HTTPS 与密钥管理生产环境基本都会要求 HTTPS。Higress 默认支持通过 Kubernetes Secret 挂载 TLS 证书再通过 Gateway 或 Ingress 注解关联。具体操作kubectl create secret tls higress-tls --certtls.crt --keytls.key -n higress-system # 或在 Ingress 中指定 kubectl annotate ingress ai-gateway higress.io/tls-secrethigress-tls其实 Higress 还提供基于CertificateCRD 的证书自动管理如果你使用 Let‘s Encrypt它甚至能自动申请续期。我这边因为企业域名证书是内部 CA 签发只能手动挂载 Secret但也够用了。至少不用像以前 Nginx 时代那样每次改配置都去 reload 进程。4. 把 Higress 跑进生产前这些“反直觉”的坑一定要知道4.1 插件执行顺序与请求 Body 的读取时机Higress 的插件体系继承了 Envoy 的 Filter 机制。每个插件在处理链上会有顺序要求有些插件需要读完整请求体有些则是边读边转发。最常见的坑是你在自定义插件里想读请求的 JSON body例如 model 字段原本该由内置 AI Proxy 解析但 Higress 的 HTTP 请求 Body 默认是流式透传的如果不先配置“允许读取 Body”你在这个后续插件中看到的就是空内容。传统网关不会这么讲究因为传统网关大部分逻辑只看 URL 和 Header而 AI 网关则非常依赖 body 内的字段。解决办法是在自定义插件或 AI 插件之前通过配置让 Higress 先缓存并解析 body。内置的 AI Proxy 插件已经处理了这个问题但如果你写的是自定义 Wasm 插件就要注意在插件描述里声明httpRequest.body的读取权限否则你费劲写半天也拿不到model。我踩过一个印象很深的坑我给团队写了一个“分账”插件想按请求中的 orgId 字段计量到各自部门结果插件上线后所有的 orgId 都取不到一度以为是自己代码 Bug。最后查了 Higress 源码发现默认阶段Phase中还没有读取 body 的插件数据会直接透传。调整了插件执行阶段到Access之后并显式开启read_body权限才恢复正常。这些细节文档里不会用大篇幅提醒你但它直接影响功能是否可用。4.2 “AI Proxy” 与普通流量的共存策略Higress 的 AI Proxy 是一个“大招”但如果你让所有流量都不分青红皂白地走 AI 插件就会出现一个性能坑AI Proxy 为了解析 token 和做流式处理会对匹配的请求进行更多处理哪怕你只是在请求一个普通 REST API也会被强制进入 AI 相关逻辑。最佳实践是将 AI 流量和普通流量分布在不同的 Ingress 或不同的路径下。比如https://api.example.com/llm/*- 走 AI Proxy 插件https://api.example.com/v1/product/*- 走普通路由与标准调用链。这样你一不会在普通接口上浪费性能和日志存储二能避免普通 POST 请求被 AI Proxy 误解析。尤其是那些内容为纯文本、JSON 体很大的接口不走 AI 插件可以把不必要的延迟和开销都省下来。4.3 流式响应下的超时与重试我们知道大模型响应耗时普遍较长尤其流式返回时连接可能持续几十秒甚至更久。Higress 的默认超时直接继承 Envoy 的全局超时未必适合 AI 场景。调用者往往在“接收首字节”后还有一个很长的“流式读取”过程。如果你只设置了全局读超时 30 秒那一次稍微慢点的长对话就会被网关切掉。针对这种场景需要在对应 Ingress 或插件配置中单独设置更长的超时通常我会给 LLM 接口配置连接超时10s上游响应头超时30s空闲超时300s或更长取决于模型最慢响应间隔如果使用的是 Kubernetes Ingress 注解可以这样设置higress.io/upstream-connect-timeout: 10 higress.io/upstream-send-timeout: 300 higress.io/upstream-read-timeout: 300但这里还有个坑流式响应期间前面说过需要确保网关不会因为“一段时间没有数据”而断开连接这个超时不能设置得太紧。我们遇过腾讯云上的一个模型因为思考过程较长两个 data chunk 之间间隔超过 60 秒结果连接被网关“静默断开”业务方还以为是模型吞了响应。后来查了网关日志才发现是 idle timeout 过短。也不建议无脑把超时设成无限大因为一旦上游服务挂起不返回连接会被白白占用。我的经验是设置一个足够大的“最大允许模型思考时间”比如 300s并在业务侧通过前端轮询等方式兜底超过预期时间直接抛错而不是让用户傻等。4.4 灰度 / 金丝雀发布中的 Header 透传Higress 支持基于 Header 的灰度发布比如higress.io/canary-version: true higress.io/canary-weight: 10很灵活但如果你对接的是多家 AI 服务商要注意上游会在响应中返回不同内容与 Header。为了让业务侧能区分调用的是哪个模型供应商你需要在转发前把模型信息加入 Header而某些模型服务商严格控制了 CORS 头导致浏览器无法读取响应头这种情况下你可以配置 Higress 的响应头改写插件将X-Model-Name这类 Header 透传出来。我记得有一次对接一个国企项目内网会统一替换所有外网 Header导致我们从上游拿到的x-request-id全部丢失排查链路问题时花了整整两天才定位到是内网防火墙的问题。很难完全靠网关解决但一般建议在 Higress 的访问日志里同时记录自定义 Header通过它可以快速确认真实来源。4.5 密钥管理不要交给明文配置很多人在演示阶段直接把 API Key 写进 Higress 插件配置apiTokens: - sk-xxxxxxxx这在测试环境没问题但生产环境一定要避免。Higress 支持通过 Kubernetes Secret 注入配置或者引用环境变量这样即使配置泄漏也不会导致密钥泄露。我推荐在部署时用外部 Secret 管理工具比如 Vault 或云厂商的 KMS通过同步机制生成一个 Higress 可以读取的 Secret。一个很现实的场景是当你同时管理几十个模型供应商每个 provider 的 key 分散在多人手里时如果没有统一管理迟早会有人把 Key 提交到 Git。Higress 对 Secret 的引用可以做权限隔离只有会读配置的人才能拿到明文团队层面至少多一道防线。5. 与其它网关选型对比Kong、APISIX、自研中间层5.1 一次横向评测的感受在最终选择 Higress 之前我把市面主流的几条路线都过了一遍。不是每个项目都必须上 Higress但了解差异能帮大家少走弯路。方案优势短板Nginx / OpenResty稳定、轻量、部署普遍需要自己写大量 LuaAI 场景的流式处理和 Token 计量无现成能力Kong插件生态成熟、社区大脱离 K8s 的控制面能力偏强部署模式较传统AI 插件起步晚APISIX国内社区活跃、扩展能力强AI 相关能力需要组合多插件没有像 AI Proxy 这样开箱即用体系Higress与 Istio / Envoy 一脉相承、云原生友好、内置丰富 AI 能力学习曲线稍陡概念多如果团队对 Envoy 体系不熟需要适应期纯自研 AI Gateway控制力最强、完全贴合业务需要长期投入模型迭代越快越容易成为瓶颈这块表格能直观看出定位。如果你是想快速在现有微服务上补一个 AI 网关Higress 是最容易找到参考资料的之一因为它在设计上就把“AI 流量治理”当作一等公民而如果你只是给一个很简单的单体应用加一层代理那随便一个 Nginx 都能搞定没必要为复杂功能付出学习成本。在我实际测试中三种网关均能完成“多模型转发”这件事。但 Higress 有一个巨大优势它把 Envoy 的资源模型沉淀成了 Kubernetes CRD这意味着你不需要另起一个管理面或者数据库配置、版本、回滚都可以围绕 GitOps 进行。APISIX 虽然也支持声明式配置但大量逻辑仍然依赖 Admin API 和 etcd规模大了以后配置管理和审计不见得有 K8s 原生 CRD 舒服。5.2 适合什么团队上 Higress首先团队最好已经或准备使用 Kubernetes。Higress 在 K8s 环境下发挥的威力最大它可以通过自动注入 sidecar 或作为 Ingress Controller 工作。如果你还是一个传统的 VM 部署模式虽然也能用 Docker 部署但控制面和数据面分离的优势就无法最大化反而增加了运维复杂度。其次业务方对 AI 模型有“多供应商”诉求。比如同时采购了多家模型以做容灾和成本对比或者会频繁替换供应商。只要出现这种“模型分发”需求AI 网关的收益就会很明显。反之如果你只是固定调用通义千问或 OpenAI 一个接口则完全可以用最薄的代理。最后团队需要有能力维护云原生基础设施。Higress 有一个活跃的社区官方中文文档也齐全但它毕竟不是一款双击安装的软件。你需要理解 Pod、Service、Ingress、CRD甚至稍微了解一点 Envoy 的 Filter 原理。如果内部缺乏这类人才直接把三台机器部署上 Higress遇到问题可能会无从下手。5.3 我的选型建议如果你现在还是零基础我建议你至少先在测试环境跑通一遍 Higress。它和写一个自定义网关的区别在于你会慢慢发现AI 网关真正的难点不是“怎么转发”而是“怎么在转发的同时理解、跟踪、计量 AI 语义”。Higress 让你不必从零发明这些东西你只需要在它提供的底座上填自己的业务规则。如果你的团队已经在用 K8s Istio 微服务体系那 Higress 更像是顺手拿来就能用的能力增强。它的控制面和 Istio 天然兼容可以在已有的 Gateway 资源上扩展 AI 路由。事实上我们落地 Higress 只花了两周其中第一周是学习和配置第二周就接入了三条业务线。6. 对 Higress 未来演进的一些个人观察6.1 从“接入网关”到“MaaS 控制面”我觉得 Higress 未来一定会继续强化“模型即服务”的控制面能力。现在的 AI 网关更多的还是在处理路由、鉴权、计量这类通用问题但 AI 应用本身也在进化Agent 应用需要调用工具复杂任务要编排多个模型数据可能既要在私有化部署的模型上推理又要定期同步到云端。这些场景下网关如果不能理解应用层的工具调用和 Agent 会话就会成为瓶颈。好的一面是 Higress 与 Istio 的体系提供了清晰的扩展点它能在现有服务网格能力之上持续沉淀上层 AI 模型治理逻辑。比如我最近观察到社区里已经有人在尝试把 MCPModel Context Protocol接入 Higress使得网关能直接管理 AI Agent 的外部工具调用链路。虽然还没有完全成熟但这个方向很吸引我。6.2 AI 可观测性将是团队 AI 落地中最需要的入口过去我们讲可观测性主要关注延迟、错误率、流量和饱和度四项指标。但 AI 网关还需要回答一组新问题这次调用的 prompt 质量如何模型回复是被截断了还是因为触发了安全机制被过滤了上下文的整体长度离模型窗口极限有多远Higress 的访问日志里已经能记录模型名、token 使用数以最高维度的信息但还不够细。我期待未来它能将 trace、span 和 token 成本自动关联而不是像现在这样让开发者在业务日志和网关日志之间“手工 join”。如果你现在准备在团队内部构建 AI 可观测平台建议先考虑数据的规范化最好能通过标准 OpenTelemetry 语义输出模型调用的 Span而不是只在网关日志打几个字段。7. 写在最后绕着“中登”走了一圈还是它靠谱我经历过各种花里胡哨的网关方案也曾被某些新项目的“AI 原生”概念吸引但最终留在生产环境里长期稳定运行的总是像 Higress 这样有深厚技术底座、同时在持续进化的项目。它可能不是每次发布会最亮眼的那个年轻框架但一旦承载大流量、面临真实业务故障时你会感激它的稳重与内敛。有几个小建议送给准备上 AI 网关的朋友不要把网关当作可以一步到位的大一统平台先接一条业务线验证运维节奏再逐步扩大。务必把模型密钥纳入密钥管理系统避免凭经验让密钥以明文形式散落各处。日志与可观测性要在第一周就纳入建设不要等出问题再补看板。善用 Higress 社区的官方微信群和 issue很多配置细节直接搜 issue 比看文档更高效。到现在Higress 在我这边已经连续运行小半年支撑了每天数百万次的大模型调用没出过一次因网关本身导致的严重故障。它的确像那个靠谱的“中登”——不喧哗不博眼球但在你需要的时候永远稳稳地顶在那里。如果你们团队也在搭 AI 网关我会建议你把 Higress 放到评估清单里花一个周末跑通一个 Demo你大概率会和我一样把它留在生产环境的名单上。