Higress AI网关实战：统一模型路由、Token配额与流式返回的中间层-代码聚汇网

Higress AI网关实战：统一模型路由、Token配额与流式返回的中间层

Scifi-gamer·2026-09-06·阅读 21 GEO检测（免费）

AI网关Higress模型路由

|难度：普通|阅读约 24 分钟

这两年大家聊 AI 落地，听到最多的瓶颈是模型效果、算力成本，但我个人体感最深的，反而是从模型到业务之间的“接入层”。项目一变大，OpenAI、通义、Claude、本地微调模型排在一起，调用路径乱得没法看，流式返回、token 计量、多租户配额全得自己造轮子。Higress 这个网关项目刚好在最合适的时间补上了这块空白——它把入口网关、微服务转发和 AI 特有的模型路由、token 配额、流式适配做进同一套控制面，业务侧只需要按 OpenAI 风格把请求丢进去就行了。标题里的“中登”可以理解成“中间层”的诨名，它确实站在链路最中间，把 AI 时代新增的复杂度都揽到了自己背后。

1. 为什么 AI 时代需要一层专职的中间网关

1.1 AI 调用和普通 HTTP 请求本质上是两回事

很多团队一开始把大模型调用当成普通 HTTP API 接入，结果都要返工。普通接口的请求通常几百毫秒内结束，返回 JSON 就直接完事；大模型调用动辄几十秒，整个链路走下来像一条长连接，而且是流式返回，逐字往客户端吐。

这里有几个关键差异。

长耗时连接：GPT 这类模型生成一篇长文可能耗时 20-40 秒，网关如果按普通读超时配置，连接早就被掐断了。
流式协议：SSE（Server-Sent Events）是 AI 应用最常见的交互方式，网关需要理解流，不能整个缓冲完再转发，否则用户感知到的“打字机效果”全没了。
计量维度变了：传统接口按 QPS 限流，AI 服务按 token 计费，不同模型单价还不一样。
生态碎片化：OpenAI、Azure OpenAI、Anthropic、通义、Moonshot、Ollama、vLLM 各家 API 格式都有差异，协议适配特别繁琐。

这些差异决定了，AI 调用不能继续裸奔在普通网关后面，它需要一层理解模型语义的转发组件——这也是 Higress 今年开始重点发力 AI 网关能力的原因。

1.2 Higress 是拿 Envoy 当底座，再往上做 AI 适配

Higress 的底层是 Envoy 数据面，这一点很关键。Envoy 在高并发、连接管理、可观测性上是经过大规模生产验证的，Higress 不用自己重造网络引擎，而是把控制面做成 Kubernetes 原生 CRD，一套声明式配置就能管理入口流量。

之前很多人用 Higress 主要是当 Ingress 或微服务网关用，支持 K8s Ingress、Gateway API，也能对接 Nacos 这类注册中心。它真正的杀手锏是 WASM 插件扩展，插件可以用 Go、Rust、C++ 等语言编写，编译成 WASM 后热加载到数据面，不用重启网关就完成逻辑替换。

在 AI 能力上，Higress 通过 LLMProvider、AiConsumer、AiRoute 三类 CRD 把模型路由、多 Provider 适配、token 配额变成了声明式资源。这跟我以前用 Nginx 或 APISIX 完全是两种体验：传统的做法是“网关本身不懂 AI，靠 Lua/自定义插件硬凑”，Higress 是“从资源模型层面就按 AI 场景设计好了”。

1.3 中登要解决的核心问题清单

我在实际项目中梳理过，AI 网关至少要处理这些事：

路由转发：不同模型、不同版本、不同渠道的请求区分
协议转换：统一收敛成 OpenAI 兼容格式，业务侧只对接一套 SDK
租户隔离：不同 API Key、不同项目、不同会员等级分别限流
token 计量：预扣、实际消耗、超额拒绝
弹性兜底：模型超时自动重试、provider 故障切换
安全防控：避免业务服务直接持有多个厂商密钥

这张清单列出来之后，结论就非常明显了——这些事放在业务代码里做，必然失控；放在普通网关里做，能力又不够。Higress 恰好卡在中间，成了那个“中登”。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 拆解 Higress 的 AI 原生能力

2.1 多模型路由与 Provider 故障转移

早期我为了同时兼容 DeepSeek 和通义，在业务代码里写了一个路由类，根据用户配置的 modelName 走不同的 SDK，看起来不复杂，但加一个模型就要改代码重新发版。Higress 的做法是把它变成配置。

大致的思路是：把每个模型渠道定义成一个 LLMProvider，可以指定 providerType、apiKey、domain、模型名称等。然后在路由里指定要转发到哪个 provider，或者按请求里的 model 参数动态选择。

我常用的一种玩法是灰度切换：比如新版本模型先在 5% 流量上试用，用 Higress 的权重路由能力按比例分配请求。还有一种更实用的场景——本地 vLLM 服务挂掉时自动切换到云上模型，这种兜底策略在现网非常有价值。传统网关做这种策略需要写一堆 if-else，Higress 的 AI 路由直接识别 model 参数，原生就能操作。

2.2 顺手兼容一半的协议适配

用 Higress 之前，我最大的痛点是各家模型厂商的 API 长得都不太一样。OpenAI 的接口格式是事实标准，但 Azure OpenAI 的路径前缀、鉴权 header 和它不同，Anthropic 用的是 x-api-key 和 anthropic-version header，通义早期也是 OpenAI 兼容但细节有出入。业务侧如果直接对接每个厂商，SDK 版本、鉴权逻辑、错误处理全都要维护。

Higress 的做法是把这些都封装在 Provider 层。比如定义 Azure OpenAI 渠道时，它会帮你处理好路径重写、密钥转换、版本 header 注入，业务侧看到的依然是一个标准的 OpenAI 风格接口。用它的时间越长，我越觉得这种“协议归一”是刚需，尤其在团队里负责 AI 中间层的同学减少了不少无谓的调试工作。

2.3 Token 配额和用户维度限流

AI 场景的限流不要按 QPS 来，这是我在项目里最强烈的感受。两个用户调同一个模型，一个查询 20 字节的数据库，另一个做长文生成，消耗的 token 可能差了 100 倍。Higress 的 AiConsumer 资源支持按 API Key 维度做 token 配额，比如每个 key 每月 100 万 token，或者每分钟请求次数限制。当用户超限之后，网关直接拒绝并返回一个标准错误，业务侧不用自己记账。

这在多租户场景里特别方便。我们有个 SaaS 产品分免费版和付费版，免费版每个用户每天最多 2 万 token，付费版 20 万。以前做这套配额要靠一个 Redis 计数器自己实现，老担心数据不一致。迁移到 Higress 之后，配置几个 AiConsumer 对象就解决了，网关本身就是唯一的执行点。

2.4 密钥收敛与安全管控

我把模型厂商的 API Key 全部收拢到 Higress 的 Provider 配置里，不再下发到业务容器。业务服务端只需要持有 Higress 颁发的 key，即便业务容器被攻破，攻击者拿到的也只是网关层 key，可以随时吊销，不会直接泄露厂商主 key。这个设计在当前安全要求严格的环境里非常实用，另外密钥轮换的时候只需要改网关配置，完全不用重新部署业务服务。

3. 一次实际落地方案的全程记录

3.1 安装 Higress 控制面与数据面

我用 K8s 做载体，Helm 安装非常简单。先把仓库加进来，然后一条命令装好控制面：

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

安装完成后，higress-system 命名空间里会多出网关 Pod，以及一套 CRD。这里建议装完先确认一下 CRD 是否就绪，再继续后续配置：

bash复制kubectl -n higress-system get pods
kubectl get crd | grep higress.io

有一点要注意，如果是在阿里云 ACK 之外的自建集群里用，需要提前给 LoadBalancer 准备好公网 IP 或 SLB 资源，网关要对外提供服务才能被外部业务访问。

3.2 定义你的第一个模型 Provider

下面拿 OpenAI 和本地 vLLM 两个渠道举例。先定义 LLMProvider 资源，示意如下：

yaml复制apiVersion: extensions.higress.io/v1alpha1
kind: LLMProvider
metadata:
  name: provider-openai
  namespace: higress-system
spec:
  providerType: openai
  domain: "api.openai.com"
  port: 443
  protocol: openai
  apiKeys:
    - "sk-xxxxxxxx"
  defaultModel: "gpt-4o"

本地 vLLM 的例子略有不同，它不需要外部域名，直接指向集群内 Service 即可：

yaml复制apiVersion: extensions.higress.io/v1alpha1
kind: LLMProvider
metadata:
  name: provider-local-vllm
  namespace: higress-system
spec:
  providerType: openai
  serviceName: vllm-service
  servicePort: 8000
  protocol: openai
  defaultModel: "Qwen2.5-72B"

定义好 Provider 之后，Higress 会自动把这些上游能力暴露在网关的统一入口里，业务侧不用关心渠道信息。

3.3 配置消费者和路由规则

接着定义 AiConsumer，指定哪个 API Key 属于哪个调用方，以及它的配额：

yaml复制apiVersion: extensions.higress.io/v1alpha1
kind: AiConsumer
metadata:
  name: consumer-free
  namespace: higress-system
spec:
  apiKeys:
    - "higress-free-key-001"
  quota:
    token: 100000
  rateLimit:
    rpm: 20

再定义 AiRoute，把请求路径和一个 Provider 关联起来，同时指定可用的消费者范围：

yaml复制apiVersion: extensions.higress.io/v1alpha1
kind: AiRoute
metadata:
  name: route-chat-openai
  namespace: higress-system
spec:
  consumerRefs:
    - consumer-free
  providerRef:
    name: provider-openai
  path: /v1/chat/completions

这样一来，业务侧只需要向网关地址发一个 OpenAI 风格的请求，带 higress-free-key-001 作为鉴权，网关就会解析 model 字段，把请求转发给 OpenAI，并统计本次调用消耗的 token，计入配额。

3.4 验证流式返回

现网验证时，我最常用的是 curl 的 -N 参数，它能关闭 curl 的缓冲，直接看到 SSE 流：

bash复制curl -N https://<gateway-address>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer higress-free-key-001" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "讲个冷笑话"}],
    "stream": true
  }'

如果流式是通的，终端的输出会一段一段地蹦出来，每段是一个 data: 开头的数据块，最后有一个 [DONE] 标记。我在这步踩过一个坑，一开始配的网关证书域名和实际请求域名不一致，导致 curl 包异常，排查了好久才发现是 host header 问题。后来我们干脆统一用网关服务自动注入的 host，不让业务侧覆盖。

4. 踩过的坑和排查技巧实录

4.1 连接池耗尽，服务雪崩

有次现网升级模型版本时，我突然接到告警，部分请求延迟飙升。当时查 K8s 里业务 Pod 的状态，一切正常，CPU 也没打满，后来才发现问题出在网关到模型服务的连接池上。

很多 AI 模型服务对单个 IP 的连接数有限制，如果网关侧复用连接不及时，高并发下很容易把上游的连接数打满，请求全部排队。Higress 里这块配置在网关的 Cluster 级别的连接池参数里，需要给大模型专用 Provider 调大连接上限。

我的经验是先把 http1_max_concurrency 调大，同时确认上游服务是否支持连接复用，另外重试策略上要控制住并发爆炸。简单说，不要对模型 provider 做“无脑重试”，否则一次上游抖动会导致全链路请求翻倍压过去。

4.2 SSE 流式场景的超时配置

SSE 场景的核心特征是“连接一直在，但数据是一点一点来的”。如果网关还在用普通的 15s 读超时，生成长文时服务端中间停顿超过 15 秒，连接就会被打断，体现为用户那边生成到一半突然卡住。

我后来把长文本场景的读超时调大到 300 秒，并在网关层关闭了对这个路由的空闲连接回收。这里有一个建议：不同场景要拆开配置，实时代理类的短请求继续用快超时，摘要生成、长文续写这类慢场景走长超时通道，不能一刀切用同一套参数。

4.3 请求体过大被网关拦截

有个客户做多文档问答，会把几万字文档塞进 system prompt 一起提交，结果请求被网关以 413 Request Entity Too Large 拒掉了。这是典型的默认 large client header 限制导致的，Higress 继承了 Envoy 默认对 header 大小的限制，但大模型场景一个请求里可能塞了大量上下文，1MB 都不一定够。

调整方式是给对应路由配置更大的请求体限制，同时把 Envoy 侧的 max_request_bytes 调大。这里提醒一下，不能光改网关，后端模型服务的吞吐迟早也会瓶颈，建议这种大上下文交互走离线任务或摘要管道，别硬塞在线链路。

4.4 多网关对比：准确找到定位

市面上不是只有 Higress 能做网关，我也用过 Nginx Ingress、APISIX、Kong，这里给一个 AI 场景下的主观对比。

维度	Higress	APISIX	Kong	Nginx Ingress
AI 原生资源模型	有 LLMProvider、AiConsumer、AiRoute	需要自研插件	插件生态但无内置 AI 语义	没有
流式请求支持	原生适配 SSE	有一定能力但配置繁琐	可支持需要更多调参	需要自己处理缓冲
控制面扩展语言	WASM，支持 Go/Rust/C++	Lua，部分版本支持 Plugin Runner	Lua，部分支持 Go/Java 插件	无扩展机制
多模型路由	声明式配置，按 model 字段智能路由	需要写 Lua 逻辑	需要自定义插件	不可用
token 配额计量	内置	需要额外开发	需要额外开发	不可用

如果你的团队已经重度使用 OpenResty 或 Lua，APISIX 可能更顺手；但如果目标是长期做 AI 中间层，不想每个功能都从插件造起，Higress 的原生 CRD 优势很突出。

4.5 排查工具链

我平时排查 Higress 问题时，最喜欢用的组合是：

看网关 Pod 日志中的访问日志，确认请求走到哪一步
用 curl -v 追踪真实的证书、Header、响应码
在 Higress 控制台看指标面板，重点看 upstream_rq_time 和 upstream_cx_overflow
临时关掉限流和配额配置，判断是不是配额判断逻辑挡住了请求

这几个手段能覆盖 80% 的线上问题。尤其要养成先看 upstream 指标的习惯，它能快速区分是网关本身的问题还是上游模型服务的问题，不会让你在错误的方向上浪费太多时间。

5. 中登的边界与选型建议

Higress 这种“中间层”不是万能药，它有明确的适用边界。

如果你只是接三四个模型，日调用量很小，临时脚本或者一个薄封装就能搞定，直接上网关反而是增加复杂度。但当你的团队同时开发多款 AI 应用，或者一个应用里面用了多个模型服务，又或者你正在做一个面向外部客户的 AI 平台时，Higress 的价值就会凸显出来。

我判断是否该引入 Higress，只看三个条件：

是否存在多个上游模型渠道，需要统一接入和切换
是否有多租户配额、计费、安全管控需求
是否已经将 K8s 作为基础设施，希望用声明式方式管理一切

只要命中两条，Hightess 大概率是比自研更合适的选择。

最后分享一个我在项目里的做法：即使规模还不大，我也会把大模型调用统一收敛到网关层，再定义一个暴露给业务的轻量接口。这样做的好处是，后续加模型、换厂商、调配额，操作全都发生在接入层，业务代码几乎零改动。时间久了你会发现，一开始多花的部署和配置成本，早就被省下的返工时间抵消了。这套“中登”的心法，值得大家试试。