第100篇 AI全栈 · AI 时代，网关更能打了？

原创

陈看山
陈看山

安全诸子

2026年10月13日 07:45
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

如果你正在维护一个以 LLM 应用为核心的业务，大概率已经遇到了这样的场景：用户正在与对话式 AI 交互，突然因为网关配置变更导致 WebSocket 连接断开，对话上下文全部丢失；或者你发现某个免费用户在短时间内消耗了巨额的 Token 成本，而对方仅仅是用脚本模拟了低频率的请求，却发送了超长文本触发多次推理。

这些问题的共性在于，传统的流量管控手段在 AI 场景下开始失效。过去十年，以 Nginx 为代表的网关体系解决了 Web 2.0 时代的并发连接和反向代理问题，但面对 LLM 应用的长连接、高延时、大带宽特征，这套体系显得力不从心。这并非某个厂商的营销话术，而是基础设施层正在发生的真实代际更替——网关的职能正在从“转发流量”扩展到“管理 AI 工程化成本与安全”。

为什么说这不是一次简单的功能升级

判断一项技术变化是否具有趋势性，要看它是否改变了资源消耗模型和攻击成本模型。传统 Web 应用中，服务端处理请求的资源消耗通常是可控的，客户端发起攻击需要付出与服务器对等的成本。但在 LLM 场景下，这个等式被打破了。

客户端发送一个长文本提示词，或者要求模型进行多轮推理，服务端需要调用的算力和内存可能是客户端的数百倍。这意味着攻击者可以用极低的成本消耗你极高的资源。传统的 QPS 限流在这种情况下形同虚设——攻击者不需要高频率请求，只需要让每个请求都足够“重”。

另一个关键变化是长连接的普及。SSE、WebSocket、gRPC 流式协议成为 AI 应用的默认选择，这使得网关配置变更不再是无感操作。传统网关如 Nginx 在配置 Reload 时会断开所有连接，这在 Web 2.0 时代尚可接受，但在 AI 对话场景中，一次 Reload 就意味着正在进行的对话全部中断，用户体验是断崖式的。

这些变化指向同一个结论：AI 时代的网关必须重新设计，核心不是性能提升，而是架构假设的改变。

趋势信号一：配置热更新成为硬性要求而非可选项

过去，网关配置变更导致连接闪断被认为是可接受的运维成本。但在 AI 场景下，长连接比例极高，任何形式的 Reload 都会直接伤害业务。

以 Higress、Envoy 为代表的新一代网关，通过 LDS、CDS、RDS、SDS 的配置分离机制解决了这个问题。Listener 配置变更不会影响 Upstream 连接，Cluster 配置变更不会影响 Downstream 连接，路由和证书变更更是可以独立热更新。这套设计彻底摆脱了“修改配置必须重启 Worker”的宿命。

这里的关键洞察是：Envoy 并没有发明全新的网络模型，而是对配置域做了更合理的抽象。它将连接管理与路由决策解耦，使得不同层级的变更可以独立生效。对于 AI 业务而言，这意味着你可以随时调整后端插件、修改模型路由策略，而不会中断正在进行的用户会话。

如果继续使用传统网关，每次模型供应商切换或插件更新都可能引发大规模断连，这在生产环境中是不可接受的。

趋势信号二：限流维度从 QPS 转向 Token 吞吐与成本核算

传统限流关注的是请求速率，但 LLM 应用的成本引擎是 Token 消耗。一个请求可能消耗 100 Token，也可能消耗 10000 Token，两者的资源开销差异是两个数量级。

因此我们看到，Higress 等 AI 网关开始支持 TPM/TPH/TPD（每分钟/每小时/每日 Token 数）限流，并且支持 IP、Cookie、Header、Bearer Token 等多维度统计。这不仅仅是计量单位的改变，而是成本控制理念的升级——你需要限制的不是用户的调用次数，而是用户消耗的推理资源总量。

这对于防止资损至关重要。许多 AGI 企业提供免费 Web 应用吸引用户，但黑灰产会爬取调用逻辑，封装成收费 API 转售。传统的 IP 限流可以通过代理池绕过，但 Token 级别的配额管理可以精确识别异常消耗模式。例如，某个 IP 每天消耗的 Token 量超过正常交互的 10 倍以上，即使请求频率不高，也应该触发告警或限流。

这里有一个容易忽略的细节：Token 限流必须与流式处理配合。如果网关需要缓存完整请求/响应体才能计数，那么大带宽场景下内存会迅速耗尽。真正的流式 Token 计数是在数据块经过时实时累加，这对网关的内存管理提出了更高要求。

趋势信号三：内容安全从可选配置变成平台责任

传统网关的内容审核主要集中在 URL 过滤和基础 WAF 规则。但 LLM 应用生成的内容是基于推理的，无法通过简单的关键词黑名单来管控。

如果大模型被诱导生成有害内容、泄露隐私信息或产生违规表述，平台方需要承担法律责任。这意味着网关必须在推理结果返回给用户之前进行实时内容安全检测。目前可行的方案是网关对接第三方内容安全服务，对 LLM 的响应进行流式审核，一旦发现违规内容立即截断或替换。

这个环节的挑战在于：内容审核会增加响应延迟，而 AI 应用本身已经存在高延时问题。因此审核逻辑必须足够轻量，且与流式响应机制深度集成，不能将整个响应缓存后再审核。这又是一个需要在架构层面解决而非通过插件堆叠解决的问题。

主要参与方的策略差异与风险对比

哪些判断可能过于乐观或过于悲观

乐观的一面是，AI 网关的技术路线已经趋于清晰——Envoy 内核加上 Wasm 插件扩展成为事实标准。这意味着你不需要从零开始构建，可以站在开源社区的肩膀上。

但需要警惕过度乐观的预期。目前 AI 网关的功能差异更多体现在工程实现层面，而非算法突破。热更新和流式处理是 Envoy 十年前就具备的能力，Higress 等项目的贡献在于将 Kubernetes、Istio 生态与 AI 场景做了适配。如果你期待 AI 网关能解决模型幻觉或推理质量的问题，那是用错了工具。

悲观的一面是，传统网关厂商可能不会轻易退出历史舞台。Kong、APISIX 等基于 OpenResty 的网关拥有大量存量部署，很多企业的运维团队对 Nginx 体系的熟悉程度远高于 Envoy。迁移到新架构意味着重新培训团队、重构监控体系、适配内部发布流程，这些隐性成本可能让不少企业选择“再等等”。

但等待的代价同样高昂——AI 业务的竞争对手不会等你。如果你的竞品已经在使用 Token 级限流和流式内容审核，而你还在用 QPS 限流和全量缓存，那么每一次恶意攻击和每一次大流量对话都会变成你的成本黑洞。

接下来值得你关注和动手的三个方向

第一，评估现有网关的长连接保持能力。做一个简单的压测：在网关配置变更时，观察现有 WebSocket 和 SSE 连接是否存活。如果答案是会断开，那么你已经有了替换网关的充分理由。这个测试不需要复杂的工具，用 WebSocket 客户端保持连接，然后在服务端执行一次配置 Reload 即可验证。

第二，梳理你的成本模型。如果你运营 LLM 应用，需要知道每个用户的平均 Token 消耗、异常消耗的阈值、以及免费策略被滥用的可能性。基于这些数据去调研网关是否支持 Token 维度限流。如果当前网关不支持，这应该成为选型新网关的关键标准，而不是加分项。

第三，验证流式处理能力。检查网关是否对请求和响应体进行真正的流式转发，还是需要缓存完整 Body。你可以通过发送大文件请求并观察网关内存变化来判断。如果内存随 Body 大小线性增长，说明网关没有流式处理能力，这在 AI 大带宽场景下会很快耗尽资源。

基于当前可见的信息，Higress 是目前少数明确提出 AI 网关定位并落地大规模生产环境的开源项目，但技术选型不应只依赖单一来源。建议你同时关注 Envoy 上游社区的进展，以及 AWS、Google Cloud 在托管网关服务中如何集成 AI 能力，这能帮助你判断哪些是通用趋势，哪些是特定厂商的差异化策略。

AI 时代的网络基础设施正在经历从“连接复用”到“会话保持与成本治理”的范式转移。网关不再只是流量的守门员，更是 AI 业务成本和安全的第一道防线。理解这个角色的转变，比纠结于具体工具选型更重要——因为工具会迭代，但架构假设的改变是不可逆的。