本文整理自 11 月 1 日 vLLM Meetup • 北京站上蚂蚁集团的分享《AIGW——大规模推理服务智能枢纽》。
本文主要讨论三个问题：
网关的负载均衡是发展了几十年的成熟技术，在 AI 时代，网关推理的负载均衡面临什么样的挑战？我们应该具备什么解决思路？
AIGW 架构优势和在蚂蚁落地的性能表现
面临 AI 推理的快速演进，网关演进的未来规划
引言：从传统负载均衡到 AI 推理请求调度
在进入 AI 时代之前，网关负载均衡作为一项基础技术，已经发展了几十年，算法和系统设计都相当成熟。然而，当这一实践置入 AI 推理服务中，问题发生了根本性的变化。蚂蚁集团在大规模推理服务中构建了推理网关（AIGW，AI Gateway），专注于推理请求的智能调度，以降低时延、提升集群吞吐。
本文将从三个部分展开：首先是 AI 场景下负载均衡面临的挑战及解决思路，其次是我们在蚂蚁的架构、落地实践和性能表现，最后是我们正在探索的演进方向。一路看下来，你会发现，AI 推理的请求调度逻辑与传统通算的差异远超想象。
AI 推理场景中的负载均衡挑战
业界对 AI 网关有不同的解读，比如推理的 API 流量治理、认证鉴权等。在本次分享的场景下，AIGW 做的核心事情是智能推理请求调度，网关工作在推理引擎上面一层。
在传统的通用计算场景中，负载均衡算法往往建立在一个近乎理所当然的假设之上——请求的计算量与数量之间存在线性关系。基于这一假设，简单的策略（如 Round Robin）便能在大部分情况下工作良好。
推理场景下面临的最大挑战是推理引擎的负载与请求数量不再呈线性相关，不同请求计算负载波动大，难以预计，有的请求在几十毫秒内结束，有的则需要数十秒。并且，推理引擎的并发能力较弱，稍有调度失误就可能造成请求排队等待，让用户的等待时间成倍攀升。 推理中常见的 KV Cache 优化需遵循 Prefix 语义，而不是传统缓存的简单哈希匹配。
Round Robin 处理线上流量时两个指标对比
如上图，我们用线上流量使用 Round Robin 回放来观察十个引擎的两个指标 Running Request 和 TokenNum，可以看到不同引擎的请求分布很不均衡，Token 占用也大幅波动，很容易造成负载不均衡，拉低集群整体吞吐。
解决思路：从计算特征到调度策略
那么应该使用什么样的策略？首先我们大致了解下大模型推理的计算特征。
LLaMA2-70B 模型在不同序列长度或批处理大小下的 Prefill 与 Decode 阶段归一化的吞吐量及延迟
引用自 Mooncake 论文（https://arxiv.org/abs/2407.00079）
推理任务的计算过程可以分为两个阶段：Prefill 阶段一次性对输入数据进行前向计算，计算量大，对 GPU 资源消耗显著，耗时往往随着输入 Token 长度持续增长；Decode 阶段每次只生成一个 Token，单次计算开销相对较小，可通过组 batch，批处理的方式提升吞吐率。然而，Batch Size 增大不仅会增加吞吐，也会导致同一 batch 内的每个 Token 输出延迟上升。
在 8K 和 32K 上下文长度下每个 Decoding Token 的理论计算量与内存访问量
引用自 StepFun 论文（https://arxiv.org/html/2507.19427v1）
再拆解 Decode 阶段，也可以发现其中的 Attention 和 FFN 这两个模块的计算特征也有很大不同，Attention 模块计算和访存量都与上下文长度正相关，FFN 模块则与上下文长度无关，而是计算量与 Batch Size 正相关。
引擎侧通过 Scheduler 在 token 粒度组 Batch，进行批处理计算，最大化的压榨硬件的性能，而 AIGW 网关层在请求级调度，通过两者的协同优化，达成最佳的集群性能。
实现方案：AIGW 架构与高可用设计
在蚂蚁集团内部，AIGW 作为数据中心级的推理网关，承担数据中心内所有模型的统一接入。路由过程先根据模型 ID 确定推理服务集群，再根据该集群内各引擎的负载选择合适的引擎节点。
网关技术架构
这个网关架构的设计有四个亮点：
灵活且强大的 Envoy Golang 扩展：底层 Proxy 能力基于标准 Envoy 和 Istio 构建，使用 Golang 来实现复杂调度的能力。
基于 Metadata Center 组件实现准实时的负载指标收集。
适用于大规模场景的多因子综合权重负载均衡策略。
水平可扩展的高可用架构设计。
接下来依次详解每一个亮点设计。
亮点一：基于 Envoy Go 扩展
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/golang_filter
Envoy Golang 扩展是我们为 Envoy 贡献的强大扩展机制。AIGW 代码由标准的 Golang 语言实现，再编译为 so 文件，动态加载到 Envoy 进程，使得我们只需要维护一个组件、并且本地同进程内函数调用方式也更高效。
而 AIBrix、llm-d 的 Inference Scheduler 等扩展方式，Envoy 通过 gRPC 与外部扩展进程交互，不仅引入了额外的维护成本，也多一次 gRPC 调用的网络时延。
亮点二：准实时的负载指标收集
指标收集机制架构
负载指标收集机制也基于 Envoy Golang 机制，通过在 Envoy 数据面上针对请求不同阶段的 Hook，再与 Metadata-center 组件协作进行计数，相对自闭环的方式完成准实时的负载指标收集。
可以实现每引擎级别统计如下指标：
处于 Prefill 阶段的请求数
处于 Prefill 阶段的 Prompt 长度
总请求量
总的 Token 使用量（WIP）
相比于定期从引擎 Metrics 接口获取负载指标（或者引擎定期上报），这个方案核心优势是指标的时效性很高。因为定期拉取的方案，存在固定的周期性轮询时间，而且没办法做到非常小。这会导致在大规模场景下，由于 QPS 比较高，导致算法基于过期数据作出错误选择，多个请求容易集中到同一个节点，造成引擎排队，延迟随之增加。
全局近似 cache-aware 架构
同样的方式，我们借助 Metadata Center 组件构建了全局近似的 Radix Tree，用于 KVCache 亲和性调度。
请求中的 prompt 文本，按照 512 字节长度来切chunk，每个chunk 计算一个哈希值，每个请求得到一个哈希值数组，所有请求都汇总到 Metadata-center，就构建一颗前缀树。并且也做了近似的 GC 淘汰机制，从而得到了跟所有引擎侧近似的全局近似前缀树。
在请求路由调度决策时，通过查询 Metadata Center 可以得到这个请求，在不同引擎上将有的不同 KVCache 命中率，以此实现 KVCache 亲和性调度。
亮点三：多因子综合权重负载均衡策略
调度核心是这三个因子的综合权重算法，缓存命中率越高、请求数量越低、Prefill 负载越轻的节点得分越高，根据得分排序选取 Top K，再从其中挑选一个节点。其中每个因子都可以配置不同的权重，可能模型/业务场景不同，需要微调定制不同的权重策略。
整体策略的导向是，KVCache 亲和性优先，Prefill 优先，因为会优先选没有 prefill 排队的引擎，以及也兼顾了请求数量的均衡性。
亮点四：高可用方案
数据面设计为无状态，以支持水平扩展；Metadata Center 组件通过副本之间广播数据，实现多活部署。
同时，数据面通过哈希将同一组模型集群映射到同一个 Metadata Center 节点，降低 Metadata Center 同步时延影响。由于对负载指标的一致性没有严格的强依赖，这种设计大幅降低了维护难度和容错成本，单节点升级或故障时也能快速切换。
线上生产系统优化效果
这套方案已经在蚂蚁内部的项目全量上线。上线后取得了明显的优化效果，上图是部分模型的优化对比数据。我们可以看到，KVCache 命中率有明显的、将近一倍的提升，平均 TTFT 降低 50%，长尾 TTFT 时延更是有数量级的降低。
未来演进方向
整个推理服务架构也在持续演进过程中，我们也有一些后续的演进规划，分享出来与大家进行讨论。
精确 Cache-aware 调度
未来的第一个目标是让缓存感知从近似走向精准。原近似 cache-aware 的方案，因为缺少 token 的精确感知，以及近似的淘汰策略，会引入一定的 KVCache 命中率误差，我们在线上简单统计过，准确度只有 80%，也就是有 20% 误差从而导致决策误差。
上图是我们在演进的一个方案，由引擎暴露一个新接口来生成 KVCache key，网关通过调用这个接口获取到 KVCache key，再从 Mooncake store 的 master 节点查询不同节点的 KVCache 命中率。
对比于独立的 KVCache Indexer 组件，这套方案通过复用 Mooncake Store Master，减少 KVCache Location 信息的传输，也可以减少一个独立组件的维护。
不过，因为多了一个 KVCache key 的生成调用，其中包括了比较耗时的 Tokenizer 过程，会引入额外的时延，对于一些 KVCache 命中率不高的场景，存在一定的局限性。
分离式架构演进
在 PD 分离式架构上，Prefill 节点和 Decode 节点的调度策略可以简化。Prefill 节点只需关注缓存命中率与 Prompt 长度，而 Decode 节点仅考虑并发度和 Token 用量，这种拆分使调度更有针对性。但在超节点这类大 DP 场景下，多个 DP 之间计算的同步等待会带来木桶效应，负载最重的 DP 很大程度决定了整体延迟，又会增加调度策略的复杂性。我们计划采集统计各 DP 的 Token 使用量，并在节点内指定最优的 DP Rank 执行任务，以全局视角来实现 DP 负载均衡。
SLO-aware 调度
另一个重要方向是基于时延预测的 SLO-aware 调度。当前的打分算法虽然能选择看似最优的节点，却无法直接与时延需求挂钩。如果我们有能力预测指定推理节点响应某一请求的时延，就可以更直接地为不同 SLO 需求的用户分配资源。
通过我们的一些分析，发现时延是具备可预测的规律。例如，Prefill 阶段的耗时与 Token 长度关系近似二次函数，Decode 阶段的耗时与 Batch Size 呈阶梯上升趋势，与 Token 长度呈线性关系。
有了预测的时延之后，路由决策就可以基于时延而不仅是得分，让高优先级用户获得低延迟资源，而将次优资源留给对延迟相对不敏感的低优用户，从而提高整体资源利用率。
开源 & 社区协作 Co-Design
AIGW 由蚂蚁集团联合 Mooncake 社区、头部云厂商等共同开源，通过社区协作 Co-Design，共同推进推理架构的持续演进，支撑大规模集群提供高效、稳定的推理服务。欢迎感兴趣的一起来参与协作共建。
项目地址：
https://github.com/aigw-project/aigw
欢迎大家微信扫描进群交流
如遇群满/过期无法扫描加入，
欢迎加小助手微信：doujiang24
结语：在时延与性能之间找到平衡
AI 推理网关的负载均衡策略与传统计算的思路存在本质差异。它需要做的不再是按请求量均匀分配，更是理解推理计算的细节，在请求级别做智能调度。从最初的问题暴露、到对推理计算特性的深入分析，再到架构设计、实时指标采集及缓存亲和性优化，AIGW 使我们的推理服务性能和用户体验都得到了显著提升。
AIGW 的实践证明，即时的指标采集、缓存感知以及多因子综合评分，能够在满足用户 SLO 的前提下最大化集群资源潜力。未来的演进将集中于精确 KVCache-aware、架构分离优化和基于时延预测的调度，让 AIGW 成为 AI 推理的高效入口。
在推理场景下，负载均衡的真正目标不是让节点负载均匀，而是让用户的感知延迟可控且达标。我们希望通过开源与社区一起，把这一系列实践转化为更普适的解决方案，让更多推理服务跑得更快、更稳、更智能。
作者介绍：朱德江，蚂蚁集团技术专家，Mooncake 核心成员，Envoy Golang Maintainer
点击【阅读原文】，访问 AIGW