企业官网建设流程全解析

AI 网关从零到上手（一）大模型应用还在"裸奔"？

兄弟们，今天开一个新坑。

这两年大家的应用，已经从"要不要接大模型"卷到了"接了几个大模型"：聊天客服、RAG 知识库、AI 编程助手、Agent 数字员工……恨不得每个功能后面都站着一个模型。

我在《Token 工厂》那篇聊过供给端：国家数据局的数字，2024 年初全国大模型日均 Token 调用量 1000 亿，2026 年 3 月已经突破 140 万亿——两年涨了一千多倍。

但应用端呢？接模型的姿势，大部分团队还停留在最原始的状态：点对点直连，中间什么都不隔。

我打算写一个系列文章，说说AI网关，希望咱们一起交流学习。今天是第一篇，先把病根讲透。

一、先看三个"裸奔"现场

现场 1：API Key 在裸奔

前端同学为了赶进度，直接在页面里调模型 API。打开浏览器 Network 面板一看——你的 API Key 明晃晃躺在请求头里，谁都能抄走。薅你羊毛的人，可能已经在排队了（哈哈，这个有点夸张了，开发的同学这个问题应该不会犯吧）。

后端也好不到哪去：10 个人各注册各的 Key，各自硬编码在各自的服务里。有人离职，全员换 Key、改代码、发版（这个在初创公司之间还真遇到过，就是为了蹭免费的额度就经常换不同的人注册账号）。

问题出在哪？钥匙和锁绑死了——发出去的 Key，管不住也收不回。

现场 2：模型挂了，应用陪葬

你精心做的客服机器人，接的是 DeepSeek。某天晚高峰，DeepSeek 官方 API 抽风：限流、超时、偶尔返回空结果——你的机器人跟着瘫了一整晚。

你是凌晨三点挂的，早上九点老板刷到用户吐槽，你才知道出事了。

想切到备用模型？可以：改代码、改配置、测试、发版，半小时后见。这半小时里用户看到只能是你们的降级页面。

问题出在哪？应用和某一个模型锁死了，中间没有"切换"这一层。

现场 3：Token 账单是笔糊涂账

月底，财务甩过来一张账单：这个月模型 API 花了 5万。

哪个团队花的？——不知道，Key 是各自注册的。
哪个模型烧的？——不知道，账单散在各家厂商的后台。
哪个功能薅的？——不知道，调用埋在每个应用的代码里。

你只能对着总账单发呆，连"下个月砍谁预算"都无从下手。

问题出在哪？调用发生在每个应用的代码里，没有一个统一记账的地方。

三个现场，一个病根：

你的应用和大模型之间，是点对点直连——没闸门、没账本、没保安。

这就是 AI 网关要解决的问题。

二、AI 网关是什么？先说人话

一句话：AI 网关是大模型流量的"总闸门 + 收费站 + 保安"。

• 总闸门：所有进出模型的流量走同一个口。谁过、过多少、什么时候停，闸门说了算
• 收费站：每个请求用了多少 Token、该记到谁头上，过路就记账
• 保安：进来的审一遍（prompt 有没有攻击、带没带敏感信息），出去的也审一遍（回答合不合规）

放进架构里，变化是这样的。先看裸奔模式——每个应用揣着各自的 Key，各自直连：

套上网关之后——所有流量走同一个口，应用只拿网关发的钥匙：

注意：应用手里拿的是网关发的"消费者钥匙"，不是模型的真 Key。真 Key 收在网关里，谁也偷不走；谁超预算、谁离职，网关上点一下就停——这就是"闸门"的含义。

用一张表对比，体感更直接：

三、我有个 Nginx，不行吗？

看到这，做过微服务的同学会问：网关我熟啊，Nginx、Kong、Spring Cloud Gateway 都用过，加个代理不就行了？

不行。AI 流量和传统 API 流量，底层逻辑变了四件事：

1. 计费和限流的单位变了：从"次"到"Token"

传统网关限流按 QPS——每秒多少个请求。但大模型是按 Token 计费的：同样一个请求，问"你好"消耗 4 个 Token，塞一份 50 页 PDF 让模型总结，几万 Token 起步。

请求次数一样，消耗差一万倍。只按 QPS 限流，一个超长请求就能把你的预算打穿——限了个寂寞。

2. 响应是"流"出来的，不是"攒"出来的

大模型的回答是一个字一个字往外蹦的（SSE 流式响应），用户要看着字往外长才有"AI 在思考"的体验。

传统网关的习惯是把响应攒齐了再转发。到 AI 这儿，攒齐了再发？用户体验直接回到拨号上网时代。

3. 请求体是"内容"，不是"参数"

传统 API 的请求体是结构化参数，校验个格式就够了。大模型的请求体是一坨自然语言——里面可能藏着 prompt 注入攻击，可能带着用户的身份证号；模型生成的回答，也可能违规。

这就不是"格式校验"了，是内容安检——得在网关里过一遍内容安全，这活儿传统网关听都没听过。

4. 上游是会"抽风"的

传统网关后面接的是自家服务，稳定性自己说了算。AI 网关后面接的是一堆厂商的模型 API——限流、超时、空结果、发新版本抽风，家常便饭。

所以模型 Fallback（A 挂了自动切 B）、多供应商负载均衡，是 AI 网关的标配能力。传统网关：没这个概念。

四件事总结成一张表：

四、这个系列的主角：Higress

AI 网关这个赛道，玩家不少：Kong AI Gateway、APISIX、LiteLLM、one-api……各自什么斤两，系列后面会专门横评。这个系列我选Higress当主角，三个理由：

1. 出身硬。阿里开源，CNCF 沙箱项目，在内部生产环境里泡了多年。携程旅游在选型时公开讲过一句很实在的话：“Higress 在阿里内部有着长时间的实践和技术沉淀，稳定性良好。”

2. 底子好。内核是 Istio + Envoy——云原生领域被验证了无数遍的数据面组合，性能和稳定性不用赌。插件用 Wasm 写，Go、Rust、JS 都行，热更新不断流。携程看中的也是这条：“支持使用多种语言编写 Wasm 插件，具有极强的扩展性。”

3. 社区活。一般两到三周就发一个新版本，AI 相关的新能力（MCP、内容安全、智能路由）都是最近几个月密集上的。这意味着教程里的截图可能很快过时——也意味着功能追新很快，写系列的时候我会尽量标注版本。

还有一个关键差别：Higress 不是"老网关加了个 AI 插件"，而是AI 原生的设计——控制台里"AI 服务提供者"“AI 路由”"Token 监控面板"是开箱即用。

顺带说一句背书：官网的案例墙上，携程、快手、大疆、唯品会、BOSS 直聘、蚂蚁……都是真实在生产里跑的。

五、一个 Higress，管三类 AI 流量

最后把格局拉开一点。AI 应用的流量，其实不止"调模型"一类：

① 模型 API 流量（LLM 网关）：你的应用 ↔ 模型厂商。统一协议、Token 限流、模型 Fallback、语义缓存、内容安全——本系列前半程的主战场。

② 工具调用流量（MCP 网关）：你的 Agent ↔ 外部工具。数据库、内部 API、三方服务，全部用 MCP 协议统一接入，认证、限流、审计一个口子管。Agent 时代的刚需，系列第三篇章细讲。

③ 推理集群流量（推理网关）：流量 ↔ 你自建的 GPU 推理服务。同一个请求，路由到队列最短的 Pod、显存最够的机器——这块对接的是 Kubernetes 的 Gateway API Inference Extension 标准，Higress 是首批符合实现的网关之一。自己起 GPU 集群跑模型的团队才需要，先混个脸熟。

一句话总结：

调用模型的、调用工具的、跑推理的——一个网关全接管。

六、这个系列，我打算这么讲

分为四段，从"是什么"到"怎么用"再到"大厂怎么玩"：

每篇独立成文，串起来是一条完整成长线，就不一下子全搞到一个文章里面了，短视频时代让大家的注意力都太浮躁了，文章太长了，估计大家都没有耐心的读一下去了。

下篇预告：《5 分钟，Docker 起一个自己的 AI 网关》——保姆级，把环境搭起来。后面 所有的文章，全在这套环境上玩。

觉得有用的话，点个"关注"，转发给还在裸奔的兄弟。