Scifi-gamer这两年大家聊 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 故障切换
- 安全防控：避免业务服务直