年初这波AI应用落地的浪潮里很多团队一边追着换模型一边被接入层的问题反复折磨。模型今天试A家、明天测B家业务方动不动就提“两个模型同时跑对比一下效果”后端同学改接口改到崩溃。大家天天聊的是模型能力、Prompt工程和RAG可真正把线上服务稳定扛下来的往往是那层不怎么被提起的API网关。Higress就是在这个节骨眼上被我重新认识的它给我的感觉特别像团队里那个平时不怎么说话、但一上线就全靠他兜底的老工程师也就是大家常说的“中登”。够稳、够全、能扛流量而且把AI网关能力直接内置了省掉了自己拼轮子的功夫。这篇文章我会从为什么AI应用需要专门网关讲起再把Higress的部署、模型接入、多模型路由、限流、观测这些环节逐个过一遍。所有配置我都按实际能跑的方式给出来并标注清楚哪些地方是我踩过坑之后调整过的。如果你正在做AI应用的后端接入或者准备把私有化大模型统一暴露给内部业务方这篇应该能帮你少走不少弯路。1. 为什么AI应用先崩的总是接入层而不是模型本身1.1 纵使模型再聪明也要走HTTP这条路我见过太多团队启动AI功能时把精力全放在“模型选型”和“效果调优”上直到要接线上业务了才发现卡住的根本不是模型效果而是接入层的一堆烂摊子。大模型再聪明对外暴露的也就是一个HTTP服务你的业务要调用它绕不开域名、路径、鉴权、负载均衡、超时控制、流量治理这些基本功。换个角度看AI应用本质上是一个依赖外部大模型API的后端服务。它跟普通后端服务最大的区别在于模型服务通常不是你自己的团队在维护模型供应商提供的接口形态也五花八门。你可能会同时用一家云厂商的托管模型、自己内网部署的开源模型、甚至国外厂商的API这些服务各有各的鉴权方式、各有的路径规范、各有的响应格式。如果让业务代码直接裸调这些上游一旦上游发生切换你就要改业务代码、改配置、重新发版。网关在这种场景下的价值就是把“业务和模型之间的耦合”切断。业务侧只需要面对网关暴露出来的统一接口到底背后接的是哪个模型、怎么鉴权、怎么路由全部由网关层处理。Higress在这里做的事情本质上就是一个标准的API网关但它在AI场景上做得更彻底把很多原本需要自己写代码的活变成了一个插件配置。1.2 传统网关在AI场景下的三个盲区如果你已经有一个Nginx Ingress或者Spring Cloud Gateway能不能直接拿来代理大模型当然能通但仅限“能通”。真正跑起来之后传统网关至少有三个地方会明显不合适。第一个是多模型路由。传统网关的转发规则基本围绕域名、路径、Header来设计做静态匹配很顺手。但AI场景下同一个接口可能要根据不同的调用方、不同的业务线、甚至不同的请求参数转发到不同的模型服务。比如A业务要走便宜的小模型B业务要用效果更好但更贵的大模型C业务要做模型对比需要同时请求两个模型。这些需求在传统网关上要实现就得写一堆自定义插件或者正则匹配规则维护成本很高。第二个是流式响应。大模型接口普遍用SSEServer-Sent Events做流式输出也就是连接建立后服务端会持续往同一个连接里推数据块直到生成完毕。传统网关在代理普通HTTP请求时往往会做响应缓冲这会导致模型已经生成了一部分内容客户端却迟迟收不到体感就是“一个字一个字往外蹦但特别卡”。更麻烦的是如果客户端中途断开连接网关能否及时取消上游请求直接决定你会不会为那些生成了一半的Token继续付费。第三个是Token计量与成本控制。传统网关统计的是QPS、带宽、响应时间这些指标在AI场景里完全不够用。因为模型API是按Token计价的一个5000字的长回复和一句“好的”价格差了上百倍。你没法从请求字节数里准确推断出Token消耗量更没办法在网关层做到“每个调用方每月只能用多少Token”这种精细管控。Higress这类AI网关把Token维度的统计和限流直接内置了这一块下面我会展开讲。2. Higress是什么一支能打的老牌“中登”团队2.1 云原生网关的基本盘Higress是阿里开源的一个云原生网关项目底层基于Envoy和Istio构建同时兼容Kubernetes Ingress和Gateway API规范。中文社区里有时候会拿它跟Nginx Ingress Controller、Spring Cloud Gateway、APISIX这些项目对比但Higress的定位更偏向于“统一入口”既能当K8s集群的流量入口也能当微服务网关还能承担API Gateway的职责一个组件替换掉原来三层网关的拼凑组合。我用下来比较明显的感觉是Higress的控制面配置非常Kubernetes原生你不需要额外部署一堆管理组件通过CRDCustom Resource Definition就能声明各种路由规则和插件配置。这种模式对已经在用K8s的团队极其友好因为GitOps那套流程可以无缝套上去所有配置都走YAML可审查、可回滚。再加上它的核心数据面是Envoy性能和稳定性在云原生领域已经经过大量验证不需要担心“新项目不靠谱”的问题。2.2 AI Gateway这条第二增长曲线如果说前面这些还是“常规网关基本功”那Higress真正让我眼前一亮的是它对AI场景的系统性支持。从大概1.4版本开始Higress就明确把AI Gateway作为一个核心方向来做了内置了一批和AI服务治理强相关的插件包括AI Proxy、AI Proxy多模型、AI统计、AI限流、AI缓存、Prompt模版等。用大白话说Higress已经不再是“一个能转发AI请求的普通网关”而是一个为AI服务而生的网关。它理解OpenAI协议理解流式响应理解Token计量甚至能帮你做模型间的故障转移和成本控制。这些能力并不是靠外部插件拼凑出来的而是作为Higress的一等公民设计和实现的。2.3 为什么是“插件化”而不是再造一个专用网关我第一次看到Higress的AI能力时下意识有个疑问为什么不在K8s里再单独部署一个“AI网关”非要耦合在通用网关上后来又想了想这个设计其实是经过认真权衡的。如果单独部署一个AI网关意味着你线上会有两套流量入口两套证书管理两套可观测系统运维复杂度直接翻倍。而Higress选择把AI能力做成插件跑在同一个数据面上用一个域名和一套入口把普通API请求和AI请求统一接管。这样业务方接入时只有一个网关地址你可以在同一个地方配置普通接口的路由规则和大模型的AI策略前面提到的多模型路由、限流、观测也都能在同一个控制台上闭环。插件化设计还有个隐藏优势热更新。Higress的插件基于WasmWebAssembly拓展支持在网关运行过程中动态加载和卸载不需要重启数据面。我原来改Nginx配置都要小心翼翼走变更流程在Higress里改插件配置基本就是提交一个CRD网关会自动reconcile压力小很多。3. 把私有大模型接进Higress一份可直接落地的配置3.1 安装Higress选择适合自己的部署方式Higress的安装方式有Helm、K8s YAML、以及阿里云上的托管产品几种。如果你的K8s集群已经比较成熟我建议直接用Helm安装后续升级和回滚都方便。下面这份是Helm安装Higress的常用命令helm repo add higress.io https://higress.io/helm-charts helm upgrade --install higress -n higress-system --create-namespace higress.io/higress装完之后等higress-system命名空间下的网关Pod处于Running状态。注意一个细节默认安装下Higress的网关服务类型是LoadBalancer如果是自建机房或者本地测试环境没有LB也可以改成NodePort或者直接端口转发做验证。初次部署完我习惯先执行一下kubectl get svc -n higress-system看看外部地址是否正常分配。3.2 准备一个OpenAI兼容的上游服务Higress的AI Proxy插件默认对OpenAI协议支持最完整所以在内网部署私有化模型时我强烈建议你在模型服务外层套一个OpenAI兼容接口。比如用vLLM起一个Qwen2.5模型启动参数里带上OpenAI兼容的服务模式这样模型服务暴露出来的就是标准的/v1/chat/completions接口可以直接被Higress代理。假设我的模型服务部署在K8s里Service名是qwen-vllm端口是8000那整个上游地址就是http://qwen-vllm.default.svc.cluster.local:8000/v1。这一步准备好的话后续一切都会非常顺滑。3.3 通过AI Proxy插件做统一接入接下来要做的就是给Higress配置一个AI Proxy插件让它把对外的一个URL和这个私有化模型服务关联起来。Higress的插件配置都是CRD下面是我实际在用的一份配置apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: ai-proxy-qwen namespace: higress-system spec: defaultConfig: provider: type: openai apiTokens: - sk-local-not-used model: qwen2.5-7b-instruct endpoint: http://qwen-vllm.default.svc.cluster.local:8000/v1 matchRules: - ingress: - ai-gateway这里简单解释几个关键字段provider.type指定上游协议类型这里用openai表示上游是OpenAI兼容协议。apiTokens即使私有化模型不需要真实鉴权建议也随便填一个占位符避免Higress做配置校验时报错。model默认使用的模型名也可以通过在请求中传model字段覆盖。endpoint上游模型服务的Base URL注意要包含到/v1这一级。matchRules.ingress表示这个插件生效在哪个Ingress上。然后创建一个Ingress把对外访问路径指向网关并挂上这个插件apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ai-gateway namespace: default spec: ingressClassName: higress rules: - host: ai.internal.example.com http: paths: - path: /v1/chat/completions pathType: Exact backend: service: name: higress-gateway port: number: 80到这一步Higress已经把ai.internal.example.com/v1/chat/completions这个对外路径和私有化Qwen模型打通了。3.4 验证访问地址确认代理生效常有朋友问我Higress代理私有大模型服务后对外访问地址到底是什么。答案其实很直白就是你给Higress网关配置的域名加路径。比如上面这个例子业务方只要把环境变量里的Base URL改成http://ai.internal.example.com/v1API Key随便填一个非空字符串模型名填qwen2.5-7b-instruct就能像调用OpenAI一样调用内网私有模型了。本地验证时可以直接用curl模拟一个对话请求curl http://网关外部IP/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-local-not-used \ -d { model: qwen2.5-7b-instruct, messages: [{role: user, content: 你好介绍一下你自己}], stream: false }返回正常的话说明Higress已经成功代理了私有化模型服务。我第一次跑通这个流程时印象很深整个过程从安装到发起对话前后不到半小时比预想中顺畅很多。4. 生产环境一定会用到的三个能力多模型路由、限流、流式处理4.1 按调用方路由到不同模型接入通只是第一步生产环境里第一个高频需求就是“不同调用方走不同模型”。比如同一个对话接口免费用户用7B小模型付费用户用70B大模型运营后台做评测用最新版本模型。如果每个调用方都要单独部署一套服务成本和管理复杂度都不可接受。Higress的多模型路由插件可以做到在同一个对外接入地址下根据请求Header、请求体参数等条件把请求路由到不同Provider。我这边一个简化的配置思路是apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: ai-proxy-multi namespace: higress-system spec: defaultConfig: fallbackProvider: type: openai apiTokens: - sk-default model: qwen2.5-7b-instruct endpoint: http://qwen-vllm.default.svc.cluster.local:8000/v1 providers: - name: qwen-7b type: openai apiTokens: - sk-local-not-used model: qwen2.5-7b-instruct endpoint: http://qwen-vllm.default.svc.cluster.local:8000/v1 - name: qwen-72b type: openai apiTokens: - sk-local-not-used model: qwen2.5-72b-instruct endpoint: http://qwen-72b-vllm.default.svc.cluster.local:8000/v1 rules: - match: - headers: - x-tier: premium route: provider: qwen-72b这个配置的逻辑很清晰默认请求全部走7B小模型当请求头里带x-tier: premium时自动切换到72B大模型。业务方接入时代码可以完全不用感知模型差异网关帮你把路由逻辑收敛了。4.2 按Token维度做限流而不是只限QPSAI网关另一个特别实用的功能是Token级限流。我之前用普通网关做限流时只能限制每秒请求数效果很粗糙。因为有的请求只问“今天天气怎么样”有的请求让模型写一篇长文两者消耗的资源和成本可能相差几十倍。单纯限QPS要么把不重要的小请求误伤了要么让大请求把资源全占了。Higress的AI限流插件支持两种维度一个是在网关层按Token消耗速率做限流一个是按用户或者AppId维度做配额管理。比如我可以给某个内部业务方配置“每分钟最多消耗10万Token”超过之后直接拒绝或者排队。这样成本控制才能真正落到每一个调用方头上而不是月底拿着账单两眼一抹黑。4.3 流式响应的转发与中断取消流式响应是AI网关和普通网关差距最大的地方。Higress在转发SSE流时会自动处理连接缓冲、心跳保活这些底层逻辑。我在测试时特意观察过首字延迟Higress转发流式请求时基本不会额外引入明显延迟模型输出一个Token网关就同步推给客户端一个事件体感和直连上游差异很小。更关键的是客户端中断取消。每次模型开始流式生成Token就在哗哗增长。如果客户端中途点了“停止生成”或者直接断了网网关要能立刻向上游发送取消请求否则上游模型会傻傻地把整段内容生成完毕这部分Token费用就白白浪费了。Higress在这块的处理让我比较放心它会在客户端断开时主动取消上游流实测下来模型侧的任务会被快速终止不再继续计费。5. AI网关的观测体系从QPS到Token都算清楚5.1 传统指标和AI指标同时看网关接入AI流量之后可观测性不能再只盯着QPS、错误率、P99延迟这几个传统指标。你需要关注模型名分布、Token消耗总量、单请求Token数、首Token延迟、流式持续时间这些新维度。Higress提供了一个AI统计插件可以把这些指标直接暴露成Prometheus格式配合Grafana能很快画出一张AI调用全景图。我这边实际观察下来下面几个指标在生产环境中最有用Token消耗总数用来做成本核算和环境对比。按模型名维度的请求量分布用来判断模型切换是否生效。首Token延迟用来评估模型服务的真实响应速度。Error率按上游Provider分组用来快速定位是哪家模型服务出了问题。5.2 日志链路里还原一次AI请求除了指标日志和链路追踪同样重要。Higress会在访问日志里加入AI场景的扩展字段比如模型名、Token用量、Provider名称等。这意味着你用现有的日志采集链路就能把一次AI请求的完整信息记录下来。我排查问题时的习惯是先通过Trace ID找到网关日志再根据里面的Token用量和模型名信息判断问题出在业务参数、网络链路还是上游模型本身。这里有个很实用的建议一定要把模型名和Provider信息加入日志检索维度。有一次我们线上某个模型突然大量超时排查时发现是业务方代码里写死了另一个模型名根本没走预期的新模型路由。如果只看QPS和错误率很难在第一时间联想到模型路由配置的问题。6. 我在实际部署Higress时踩过的坑和调优细节6.1 上游服务不是OpenAI协议怎么办虽然现在绝大多数模型服务都已经兼容OpenAI协议但总有例外。比如某些自研模型服务、或者老的网关封装对外暴露的是自定义协议。这种情况我会分两步处理第一步看Higress有没有对应的原生Provider类型第二步如果没有就先用Higress的请求转换插件把外部请求转换成上游能识别的格式再把上游响应转换回来。虽然多一层配置但至少不用推翻整个网关方案。6.2 超时和长连接配置要反复压测流式接口的耗时可能长达几十秒甚至几分钟这跟普通HTTP接口几十毫秒的耗时完全不是一个量级。如果你直接用默认超时配置很可能出现“模型还在生成网关已经断开连接”的故障。Higress的超时配置支持到分钟级建议根据你实际业务的流式生成时长把读写超时都调到合理范围。另外上游模型服务通常需要保持长连接注意检查网关和上游Pod之间的keep-alive配置避免频繁重建连接导致额外的延迟开销。6.3 模型切换一定要走灰度发布就算Higress配置支持热更新我也强烈建议在模型路由调整时走灰度发布流程。方法是利用Higress的Canary发布能力先让5%的请求走新模型验证效果和稳定性之后再逐步放量。我之前有一次图省事直接全量切换到一个新部署的模型服务结果这个模型服务的Batch推理参数没调好响应极慢线上反馈迅速涌进来。如果当时先灰度5%这个问题完全可以在影响范围很小的时候被发现。6.4 资源占用别小看Wasm插件Higress的插件基于Wasm运行好处是隔离性强、热更新方便但也意味着会有额外的内存开销。如果业务规模较大网关Pod的内存和CPU资源配置要适当上调。我遇到过在压测时网关Pod频繁OOM的情况排查后发现主要是Wasm插件内存占用和并发量一起涨上去了。调整资源上限并做横向扩容后问题就解决了。生产环境建议提前做一轮压测摸清每个插件在不同QPS下的资源占用曲线给未来的容量规划留好余量。最后再分享一个小技巧。AI网关上线后我建议把Higress的变更配置也纳入CI/CD流程所有路由规则、AI插件的变更都走代码评审和自动化发布。这样当你需要紧急回滚模型路由或者调整限流策略时一条流水线就能搞定不用手动去点控制台。我踩过的那些坑绝大多数都跟“变更没有留痕”“配置没有评审”有关系。Higress既然给了这么强的配置化能力就一定要用工程化的方式去约束它这样才能在AI时代真正当一个省心的“中登”而不是每天救火的消防员。