开头：一个被反复追问的问题
上一篇聊完 AI 网关是什么，后台收到最多的一个问题就是："这不就是个 API 网关吗？我们公司早就上了 Nginx / Kong 这类网关，加个插件不就行了？"
这个直觉不奇怪。因为从"表面能力清单"上看，两者确实高度重叠------都要做鉴权、路由、限流、负载均衡、日志。如果只看这张清单，你会觉得 AI 网关不过是传统网关换了个名字。
但我想说，这两者处理的是两种完全不同的对象 。上一篇文章我只给了一张对比表格，这一篇我不用表格，就挑一个具体场景------限流------从头讲到尾。讲透这一个场景，你就能理解为什么 AI 网关不是一个"加了插件的传统网关"，以及这个差异背后，藏着一次架构上的本质转变。
一、先承认：表面看，它们确实"长得很像"
我不回避这个问题。AI 网关和传统 API 网关在"无状态 HTTP 转发"这件事上，确实是重叠的。
无论是传统网关还是 AI 网关，都要回答这几个问题：这个请求是谁发的？能不能放行？要不要限流？转发给哪个上游？请求日志记在哪？
也正是因为这套"通用能力"如此相似，很多人会得出一个结论：AI 网关 = 传统网关 + 几个 AI 插件。
这个结论错在哪？错在它只看到了"输入输出都是 HTTP 请求"，却忽略了两者真正"处理的对象"完全不同。
二、本质区别：一个处理"信封"，一个处理"信的内容"
我用一个比喻把这件事说清楚。
传统 API 网关，像一个邮局分拣中心。 它看的是信封------收件地址、发件人、邮编、重量。它不需要打开信封看里面写了什么，也看不懂。它做的所有决策（路由到哪、是否限流、是否放行）都基于信封上的信息，也就是 HTTP 请求的元数据：URL、Method、Header、来源 IP、请求频率。
AI 网关，必须"拆开信封读信的内容"。 因为它要治理的东西------模型成本、提示词质量、内容合规、token 用量------全部藏在**请求体（body）**里。它必须读懂请求体里的 messages 写了什么、调的是哪个模型、大概消耗多少 token，然后才能做出限流、路由、计费、护栏这些决策。
这就是最根本的差异：
传统网关处理的是"请求的元数据"；AI 网关处理的是"请求的语义内容"。
这句话不是我发明的漂亮口号，而是我踩了坑之后总结出来的。下面我用"限流"这个场景，把这句话拆开给你看。
三、用一个场景讲透：限流的演变
场景设定
假设你们公司有 100 个员工，共用一个模型 API。财务说："模型调用要控制成本，给我加个限流。"
这个需求很常见，对吧？但"限流"这两个字，在传统网关和 AI 网关手里，做出来的东西完全不是一回事。
传统网关怎么做限流
传统网关的限流，本质是按"请求次数"算的。它的典型配置长这样（示意）：
yaml
# 传统网关：按请求数限流
limit_req:
zone: api_limit
rate: 100 req/s # 每秒最多 100 个请求
key: client_ip # 按来源 IP 计数这套逻辑很成熟，也很高效。但它有两个致命的盲区，一旦用到 AI 流量上就原形毕露。
盲区一：一个"请求"的价值可以差几万倍。
"帮我翻译这句话"------可能就 3 个 token。"读这份 50 页的 PDF，帮我总结要点"------可能 10 万个 token。在传统网关眼里，它们都是"1 个请求"，占用的是同等的限流额度。
于是你会看到一种荒诞的现象：那个烧钱烧得最凶的大请求，反而是"合规"的；那个只做一句话翻译的小请求，反而可能被限流拦住。 按请求数限流，对 AI 流量来说，等于没限。
盲区二：QPS 限流管得住"频率"，管不住"成本"。
模型的成本是按 token 算的，不是按请求算的。同一个模型、同样的请求数，token 用量可以差出几个数量级。你按 QPS 限流限得再准，月底账单照样爆表，因为**"频率"和"花钱"之间没有稳定的换算关系**。
AI 网关怎么做限流
AI 网关的限流，本质是按"token 数"算的，而且通常还要叠加"团队预算"这个维度。它的配置长这样（示意）：
yaml
# AI 网关：按 token + 团队预算限流
rate_limit:
unit: token # 单位从"请求"变成了"token"
prompt_tokens_per_min: 50000 # 每分钟 prompt token 上限
completion_tokens_per_min: 20000 # 每分钟输出 token 上限
team_budget: # 按团队做预算
- team: 推荐系统
monthly_token_quota: 10000000 # 每月 1000 万 token
overage: reject # 超了直接拒绝
model_prices: # 按模型单价折算成本
- model: 主力对话模型
price_per_1k_prompt: 0.02
price_per_1k_completion: 0.06看出区别了吗？计量的单位从"请求"变成了"token"，限流的维度从"频率"扩展到了"预算"。
为什么必须这么做？因为模型成本的三个基本事实决定了传统网关那套"按请求限流"天生不适用：
- 成本按 token 算，不同模型单价差几十倍；
- 请求的价值极度不均匀，一个请求可能是 3 token 也可能是 10 万 token；
- 成本的归口是团队和业务，而不是 IP 和请求。
所以 AI 网关的限流，不是"把 QPS 限流参数调一调"，而是换了一套计量体系和治理维度。
四、底层原理：为什么"必须读 body"这件事，改变了整个架构
到这里，你可能已经隐约感觉到了：AI 网关限流要按 token 算，就意味着它必须知道每个请求消耗了多少 token 。而这个需求，逼着网关去做一件传统网关根本不需要做的事------读请求体、解析协议、估算 token。
这一步，才是 AI 网关和传统网关在架构上真正分道扬镳的地方。
传统网关为什么几乎不用读 body
传统网关的限流、路由、鉴权，靠的都是 Nginx 的 access 阶段里的几个内存变量------URL、Header、IP、计数器。它不需要把 body 缓冲到内存里、不需要 JSON 解析、不需要知道里面写了什么 。所以它可以跑得飞快，这也是 Nginx 这类网关高性能的根本原因之一：全程不碰 body，转发就行。
AI 网关为什么必须读 body
AI 网关要做 token 级限流和计费，就必须回答两个问题：
- 请求进来时，prompt 大概是多少 token？ ------ 需要读请求体里的 messages，把它解析出来，再估算 token 数。
- 响应返回时，completion 实际是多少 token？ ------ 需要读响应体，统计实际消耗。
这就意味着，AI 网关在请求处理链路上，必须插入"缓冲 body → 协议识别 → 语义解析 → token 估算"这一整段传统网关没有的逻辑。
而更麻烦的是，这一步还牵扯出另一个问题：模型协议不止一种。
OpenAI、Anthropic、Bedrock 各有各的请求格式和流式返回格式。你要"读懂"请求体，就得先识别出这个请求走的是哪家协议，再用对应的解析逻辑去拆。传统网关面对的是"统一的 HTTP 协议"，AI 网关面对的是"HTTP 外壳下好几种互相不兼容的语义协议"。
这个差异带来两个直接后果
后果一：性能代价。 缓冲 body、解析 JSON、估算 token，这些都是有开销的。传统网关可以做到"零拷贝转发"，AI 网关做不到。这也是为什么 AI 网关普遍要基于能跑脚本逻辑的网关内核来改造，而不是纯 Nginx------纯 Nginx 的模块机制，很难在"转发路径"里优雅地插入"读懂 body 再决策"这种逻辑。
后果二：能力边界被重新定义。 传统网关的能力边界止步于"请求元数据"，AI 网关的能力边界延伸到了"请求语义"。这不是简单的加法，而是处理对象变了------一旦网关能读懂请求内容，路由、限流、缓存、安全这些老能力，全部都要围绕"语义"重新设计一遍（比如限流变成 token 级、缓存变成语义缓存、路由变成按模型/成本/质量）。
所以，回到开头那个"加个插件不就行了"的问题，答案就很清楚了：
给传统网关加个插件，只能让它在"信封"层面多做点事；但 AI 治理需要的是"拆信读内容"，这要求从处理模型到能力边界做一次重构，不是一个插件能补上的。
五、实践落地：同一需求，两套配置的差异
为了让你有个直观感受，我把"限流"这个需求，用两个"如果我是工程师会怎么配"的视角，并排摆出来。
需求：控制一个"翻译服务"的模型调用成本
传统网关视角（基于请求元数据）：
我关心的是------谁在调、调得多不多。于是我会配：按 IP 限流、按 URL 限流、按 QPS 限流。配完之后，我能回答"这个接口每秒被调了多少次"，但我回答不了"这个接口每分钟花了多少钱"，也回答不了"哪个部门烧得最狠"。
AI 网关视角（基于语义内容）：
我关心的是------每个请求消耗多少 token、按什么单价、归到哪个团队。于是我会配：按 token 限流、按团队设预算上限、按模型单价折算成本。配完之后，我能回答"这个月模型总共花了多少、哪个团队超了预算、哪个模型最贵"，甚至在超预算时自动拦截，而不是月底才追悔。
核心差异一句话： 传统网关的配置，回答的是"流量长什么样"；AI 网关的配置，回答的是"这流量值多少钱、该不该放行"。
六、踩坑与边界：别把这两个概念用错
这部分是我自己交过学费的，分享给你。
坑一：token 估算不准，限流会误杀或漏杀
AI 网关的 prompt token 是估算 出来的（响应 token 才是实际统计的）。估算就有误差。我们踩过的坑是：估低了，大请求漏过限流，成本没控住；估高了，正常请求被误杀，用户报"莫名其妙被限流"。限流阈值一定要留缓冲，别卡得太死。
坑二：上了 AI 网关，却把它当传统网关用
这是最常见的浪费。很多团队上完 AI 网关，结果还是只配了 QPS 限流、IP 白名单这套"信封层"的东西，token 预算、团队归集、成本核算这些"语义层"的能力全没用起来。等于花了 AI 网关的钱，只用了传统网关的功能。 token 级治理，才是它的核心增量价值。
边界一：AI 网关是"能力叠加"，不是"替代"
要特别说清楚：AI 网关不替代 传统网关。传统网关那套鉴权、路由、负载均衡、连接管理，AI 网关里照样要有。准确的关系是：AI 网关 = 传统网关的地基 + 语义治理的增量层。 你不能因为上了 AI 网关，就把原有的接入治理能力扔了。
边界二：不是所有场景都需要"读 body"的能力
如果你的场景是单模型、低并发、对成本不敏感，那传统网关那套"信封层"能力其实就够了，硬上 AI 网关反而是过度设计。"读 body"带来的性能代价和复杂度，只有在"多模型、多团队、成本敏感"的场景下才划算。
结语
写到这里，我想用一句话收束这一整篇：
传统网关和 AI 网关的差别，不在能力清单的长短，而在它们处理的对象------一个看信封，一个读信的内容。
这个差异看似抽象，但它决定了限流、路由、缓存、安全这些能力在 AI 时代全部要"重做一遍"，也决定了 AI 网关不能靠"加插件"拼凑出来。
下一篇，我会用一个 AI 请求的完整生命周期，带你走一遍"接入 → 协议识别 → 加工 → 限流 → 转发 → 观测"的全过程，看看这个"读信的内容"到底是怎么一步步发生的。
（本文基于个人团队在多模型接入过程中的实践与踩坑记录，不构成任何产品推荐。文中配置均为示意，未附任何外部链接。）