开头一个被反复追问的问题上一篇聊完 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 网关手里做出来的东西完全不是一回事。传统网关怎么做限流传统网关的限流本质是按请求次数算的。它的典型配置长这样示意# 传统网关按请求数限流 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 数算的而且通常还要叠加团队预算这个维度。它的配置长这样示意# 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 网关为什么必须读 bodyAI 网关要做 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 请求的完整生命周期带你走一遍接入 → 协议识别 → 加工 → 限流 → 转发 → 观测的全过程看看这个读信的内容到底是怎么一步步发生的。