AIBrix 把推理 Pod 编成一支舰队

Liguang Xie（左）与 Jiaxin Shan 在 KubeCon + CloudNativeCon China 2025 介绍 AIBrix。这张真实的会议照片贴合该项目，因为其战略价值来自把字节跳动的运营经验带入国际开源基础设施社区。[6]

快速推理引擎可以提升单个模型服务器的效率。至于请求该发给哪个副本、缓存中的提示词是否存在于别处、何时启动另一个副本、该由哪种加速器执行，以及多节点部署失败后如何恢复，单靠引擎无法决定。这些属于舰队层面的问题。

在 AIBrix 身上，值得纳入 AI-China 观察的信号就在这道分界线上。字节跳动于 2024 年初启动该项目，在内部工作负载中投入使用，并于 2025 年 2 月通过 vLLM 项目将其开源，定位为一套运行在 Kubernetes 上的服务栈，覆盖路由、自动扩缩容、模型管理、分布式推理和故障处理。[1] 到 2026 年 6 月，AIBrix v0.7.0 已经扩展了这套约定：vLLM、SGLang 与 TensorRT-LLM 可以接入同一套控制界面，重建后的批处理平面、共享 KV-cache 通路和多副本网关，则让项目越过了“在 Kubernetes 上运行 vLLM”这一层定位。[2]

这项变化所输出的是基础设施，“中国拥有更快模型”这类主张已经退居次位。字节跳动在运营中承受的压力，正被整理成推理引擎上方的开放层，进入全球 Kubernetes 与 vLLM 的共同开发，再被装入中国的商业云。供应链所指向的对象也从 GPU 和模型权重扩展到一层软件：它让持续变化的 GPU 与模型权重组合起来，呈现为一项统一服务。

引擎与服务之间的缺口

vLLM 的核心职责是执行 token，包括内存高效的注意力计算、批处理、模型并行和 API 服务器。AIBrix 从单个引擎进程停止的位置接手。它的控制平面登记适配器与模型元数据，伸缩工作负载，并管理多节点部署；数据平面分派请求、观测负载与缓存状态，再把模型服务器接入共享存储和网络资源。[1][3]

这项分工很重要，因为 LLM 流量带有很强的状态属性。两个在通用 HTTP 负载均衡器看来完全相同的请求，成本会相差很大：一个请求可以复用很长的缓存前缀，另一个需要昂贵的 prefill，第三个则指向仅由一个副本加载的 LoRA 适配器。轮询路由因而会把任务发往无法利用现有状态的位置。与此同时，即使 GPU 内存、排队中的 token 数或首 token 延迟持续恶化，CPU 利用率仍会给出失真的扩缩容信号。

AIBrix 的 2025 年技术论文描述了一种感知 LLM 状态的网关，可依据请求数、吞吐量、延迟、KV-cache 使用情况或前缀缓存是否可用来选择路由。项目还在引擎 Pod 旁放置轻量级运行时，让控制平面跨引擎统一处理模型加载、指标采集和生命周期操作。[3] 各种具体算法都位于这套设计之内；更重要的选择，是让分派任务的那一层看见 token 负载、缓存位置、适配器所在副本和加速器容量。

v0.7 将哪些能力纳入可组合体系

阅读 2026 年 6 月的版本更新时，可以看到四项原先彼此分离的运营问题被纳入同一套舰队约定。

第一，引擎选择进入了元数据。模型可以标注为使用 vLLM、SGLang 或 TensorRT-LLM，网关再把各引擎的指标映射到路由决策中。三种引擎依然存在差异：AIBrix 表示，vLLM 和 SGLang 仍是经过最多生产检验的两条通路，项目也尚未公布 TensorRT-LLM 的正面对比。这里的变化在于，更换引擎时，北向部署与流量管理层可以继续保留。[2]

第二，部署开始以模型为中心。带版本的模板可以固定引擎、模型来源、加速器类型与数量、并行方式、量化方案、副本数量范围和适配器配置。重建后的批处理服务保留了熟悉的 OpenAI 兼容作业界面，同时增加一个可选的 AIBrix 配置块，用于选择这类模板。由此产生的交接关系很清楚：应用代码提交熟悉的请求，平台则准确记录模型应当以何种方式、在何处运行。[2]

第三，KV cache 成为共享的数据平面状态。prefill/decode 解耦通常需要把缓存从 prefill worker 送到 decode worker，随后请求之间的缓存卸载与复用，往往又走另一条通路。AIBrix v0.7 把两者都引入可插拔缓存层，以 DRAM 作为其中一层，下面再接入可替换的后端存储。架构上的收益是需要配置的独立缓存系统更少；运营上的代价随之转移到网络特性、连接器成熟度、淘汰策略和缓存一致性，这些都成为生产环境中的主要依赖。[2]

第四，网关本身也学会以舰队方式运行。为了可用性而复制路由器会带来一项矛盾：每个路由器只看见部分流量，判断活跃请求和缓存前缀时所依据的视图并不完整。AIBrix 通过由 Redis 保存的状态同步，让多个网关副本共享这些视图。v0.7 路由器也可以混合多项策略，例如分别为请求数和吞吐量设定权重，让不同工作负载按组合规则运行。[2]

这些变化合在一起，也解释了标题中的“舰队”。舰队的内涵超过多个 Pod，它还要求多个 Pod 共享身份、状态、策略与恢复方式。

基准数据的适用范围很窄

项目给出的性能证据有参考价值，适用范围则止于特定实验，无法覆盖整个 v0.7 技术栈。AIBrix 论文中的分布式缓存实验采用 Bird-SQL 工作负载和四块 NVIDIA A10 GPU。与启用前缀缓存的 vLLM 相比，报告中的配置将峰值吞吐量提高约 50%，平均首 token 延迟和 P99 首 token 延迟分别降低约 60% 和 70%。这些数字对应特定的工作负载、硬件、软件版本和缓存配置，尚不足以证明每一种模型、上下文分布、网络或连接器都能得到相同增益。[3]

论文对适用范围的交代相当充分。部分路由和异构服务实验覆盖的非理想工作负载仍不足以支持广泛外推，GPU 优化器也依赖离线分析。[3] 当前版本又增加了几项限制：Console 刚刚推出，Batch API 刚完成重建，云 GPU 执行与 Resource Manager 仍处于预览阶段。评估时需要把核心网关、自动扩缩容和 KV-cache 工作，与外围的自助服务外壳分开判断。[2]

因此，AIBrix 适合作为评估对象，距离通用默认选项仍有一段距离。对于只运行少量稳定副本的团队，新增的复杂度会超过容量收益；拥有大量适配器、不均匀的提示词前缀、多种引擎、突发批处理任务或异构加速器的舰队，则有充分理由测试它。仓库 star 数和一键演示只能作为表层信号；决定性指标落在缓存命中率、明确延迟目标下的有效吞吐量、冷启动表现、路由失衡、恢复时间，以及维持系统清晰可读所需的运维工时。

一个项目，两条供应链方向

AIBrix 正在向上游移动。2025 年 4 月，Google 介绍了与字节跳动、Red Hat 共同参与 Kubernetes Gateway API Inference Extension 的工作，其中包括感知 LLM 状态的路由和通用性能测量。AIBrix 创始人 Jiaxin Shan 将这项协作描述为提取共享基础设施层，让 AIBrix 与更广泛的服务体系都能从中受益。[5] 此后在 KubeCon China 的演讲中，项目被置于 vLLM 社区内部；字节跳动工程师也把讨论放进 Kubernetes、Envoy、分布式缓存与开放研究的共同语汇里。[6]

它也在向下游移动。火山引擎的中文 VKE 文档如今把 AIBrix 列为 AI 原生 ServingKit 中可部署的组件，产品范围包括自适应扩缩容、缓存感知路由、资源调度和异构算力管理。[4] 这条双向流动已有具体证据：字节跳动可以把内部基础设施发布到国际开源项目，再在国内云产品中使用并维护这个开放层。

这条通路在战略上比一句兼容性口号更耐久。模型家族会起落，加速器采购组合也会变化。当引擎、适配器、缓存和设备不断轮换时，控制平面仍能保留应用约定，从而吸收其中一部分波动。切换成本依然存在，只是转移到模板、指标映射、连接器和运营策略中，工程师至少可以检查这些环节。

怎样的证据能证明舰队已经成立

接下来的证据需要展示 AIBrix 如何承受差异。独立运营团队应能在论文的四块 A10 配置之外复现路由与缓存结果，公布网关和 worker 丢失时的故障表现，并在同一套工作负载约定下比较 vLLM、SGLang 和 TensorRT-LLM。预览功能需要升级保证与清晰的回滚通路。项目征集采用者、讨论成立正式发布团队，因而与增加一种路由策略同样重要：舰队软件需要一套寿命超过发起公司的治理安排。[2]

这些证据若能补齐，AIBrix 将代表一种低调却影响深远的中国 AI 输出。届时，字节跳动交付的意义会超出一段可运行模型的代码，它还将参与定义开放推理如何成为可运营的舰队，并把这层能力置于中国云、全球开源引擎与 Kubernetes 基础设施共同使用的位置。

cronfeed.work