字节跳动开源 AIBrix：填补云原生大模型推理“系统层”空白

AIBrix 项目目前已经开源，本文为 AIBrix 技术解析。

详见：

🔗 vLLM 博客：https://blog.vllm.ai/2025/02/21/aibrix-release.html

🔗 代码仓库：https://github.com/vllm-project/aibrix

🔗 技术详解博客：https://aibrix.github.io/posts/2025-02-20-vllm-control-plane/

前言

随着 LLaMA、DeepSeek、Qwen 等开源大模型的快速崛起，企业在模型部署的灵活性、成本与自主可控性方面迎来了新的机遇。然而，仅靠对模型本身的优化尚不足以将这些模型部署成高效且可扩展的生产级 API。大模型推理往往引入诸多独特的系统挑战，如 GPU 弹性伸缩指标的非线性问题、长尾模型和精调模型流量过低的问题、多机推理时的角色编排以及 GPU 卡型的异构管理等，都对易用性和成本控制提出了更高要求。因此，我们需要从推理引擎到底层基础设施进行全栈系统设计，才能真正让大模型在生产环境中长期稳定且高效地运行。

AIBrix 作为首个基于 Kubernetes 的企业级推理系统项目，正好填补了业界在“系统层”上的空白。它通过优化资源调度、自适应扩缩容、缓存感知路由以及异构计算管理等多项能力，为企业级大模型的大规模部署提供高效、低成本、可扩展的解决方案。AIBrix 与 vLLM 等推理引擎深度协同，持续优化推理效率，并融合多项前沿研究成果，推动大模型推理走向更加高效、可落地的生产化阶段。

AIBrix 的项目背景与设计理念

在规划 AIBrix 项目的过程中，我们始终站在基础架构的角度，思考如何在大规模场景下为推理引擎提供更好支持。结合字节跳动内部的业务实践，我们发现，大模型往往会带来一系列与传统微服务截然不同的系统挑战，包括：

• 模型权重的下载 / 加载：如何快速分发和加载体积庞大的模型文件，降低冷启动延迟。

• GPU 弹性伸缩指标的非线性：大模型对 GPU 的利用率并非线性关系，传统的指标收集与弹性策略常常滞后或不精准。

• 长尾模型或精调模型流量低：针对这些流量低但又需要及时响应的模型，如何做到有效的资源利用和成本控制。

• 多机推理的角色编排：在分布式推理场景下，如何更高效地在多个节点之间分配和调度任务。

• GPU 卡型异构：不同型号、不同性能的 GPU 共同部署时，如何协同工作并优化利用率。

• 单服务跨 Region：多数据中心与跨区域部署的需求增大了同步管理模型与推理任务的难度，同时对容灾与可用性提出了更高要求。

传统微服务框架（如 KNative）或服务网格（如 Istio）在鉴权、流量管控、版本升级等通用能力上已经相当成熟，但对于大模型服务而言仍然显得过于臃肿，且缺少针对性的优化。此外，市面上大多数项目往往将推理引擎视作一个“黑盒”，无法进行深度协同优化。

设计理念

为应对上述挑战，AIBrix 的核心理念在于通过“引擎层”与“系统层”的紧密协同，搭建一个轻量化、云原生的方案。具体而言，我们将部分通用的引擎功能卸载到系统层面进行管理，并对模型推理常用能力进行封装，向外提供统一的引擎接口层。这种模式能够在大规模场景下同时兼顾性能、成本和易用性，帮助企业级大模型部署实现更高的弹性和可控性。

系统架构

AIBrix 包含控制平面组件与数据平面组件，并完全基于 Kubernetes 进行开发，采用完整的云原生设计来确保系统的可扩展性、可靠性以及资源效率。AIBrix 充分利用了 Kubernetes 的现有功能，包括自定义资源 (CRD)、控制器机制以及动态服务发现等，为大规模 LLM 推理服务提供了稳健的基础设施。

控制平面组件主要负责管理模型元数据注册、自动扩缩容、模型适配器注册，并执行各种策略。数据平面组件则提供可配置的请求派发、调度与推理服务能力，实现灵活且高性能的模型推理执行。下图为 AIBrix 的系统架构：

AIBrix 项目已发布了 v0.1.0 和 v0.2.0 两个版本。在 v0.1.0 阶段，我们主要针对 Serverless 场景进行了一系列优化，着重解决冷启动、弹性伸缩和高密度部署的问题；而在 v0.2.0 阶段，我们则聚焦于分布式与解耦化，通过多机推理、KV-Cache 管理以及异构计算管理等特性，让大模型的规模化部署更加高效可控。

AIBrix v0.1.0：Serverless 与高密度部署

Serverless 与弹性伸缩

AIBrix v0.1.0 的主要思路是将大模型在生产环境中面临的核心难题，与 Serverless 领域的几项关键技术（冷启动、快速伸缩与高密度部署）相结合。我们并不追求让大模型像 FaaS 一样彻底“无服务器化”，因为这在现实中尚难达到理想效果，也并非企业级生产环境的最佳形态；更可行的路线是借鉴并改进 Serverless 的相关思路，对大模型的部署环节进行有针对性的优化。

线上观察：Autoscaling 与指标挑战

在实际应用中，Autoscaling 最大的难点是：流量波峰和推理实例利用率之间通常存在显著的时间滞后（常见在 2～5 分钟），导致高并发场景下容易出现短时过载，从而拉升长尾延迟。此外，传统的 GPU 性能指标（如 DCGM 暴露的 DCGM_FI_DEV_GPU_UTIL 或 DCGM_FI_PROF_SM_ACTIVE）严重依赖引擎自身实现，也很难体现 GPU 空间利用率，导致扩缩容决策往往不够精确。

多种伸缩方案探索

为此，我们尝试过将引擎 KV_CACHE 利用率 与队列中待处理请求的输入 / 输出指标结合起来，做出更精细的扩缩容判断。然而在实际业务中，保障 SLO（而非 GPU 利用率）通常是更高优先级的目标，这使得传统基于资源利用率的 Autoscaling 策略效果有限。为了应对这一挑战，我们又探索了 基于 Profiling 并以 SLO 驱动的扩缩容方案，通过对历史与实时流量分布进行分析，动态确定扩缩容时机，减少过载并降低尾部延迟。

目前，AIBrix 在此方向上仍在持续迭代研究，包括尝试更具前瞻性的 LLM 专用指标，以及 Proactive 主动式弹性策略，让系统在应对突发流量时更加游刃有余。

在架构设计中，v0.1.0 主要引入了 Gateway API Plugin (Envoy) + Runtime 这两个组件，以适配大模型通常面对的两类路由方式：应用层路由（app router） 和 代理层路由（proxy router）。在大模型社区，如 vLLM 正不断丰富自身 API（含 token、transcription、score 等），保持与引擎原生接口一致是一项不小的挑战。为此，我们采用了高性能标准化的 envoy gateway 配合 extension server 来实现定制化，来进行高性能且可定制化的流量管理：

• 只在必要处做 request head/body 的修改，尽量避免重复实现类似 OpenAI 的 API；

• 同时支持对请求进行缓存感知的调度，包括 kv cache least used、least of prompt、prefix-cache aware 等策略，以进一步缩短长尾 TTFT（Time to First Token） 等性能指标。

冷启动与模型加载优化

在冷启动问题上，我们重点考察了不同机型在 网络带宽、本地盘 I/O、RDMA 等方面的性能差异。虽然云原生社区已有如 Fluid 等项目可在 “1 -> N” 场景下发挥缓存加速作用，但在 “0 -> 1” 阶段，磁盘 I/O 并不总能比网络更快，有时通过 远程流式加载 直接将权重加载进 GPU memory 反而效率更高。

为此，AIBrix 在 v0.1.0 中实现了 GPU 流式加载 方案，支持在 Tensor 层面更细粒度地控制下载速度和顺序，为开发者提供灵活的组合策略。需要注意的是，若机型配有本地 NVMe 磁盘，则本地加载可能仍优于远程；而在分布式文件系统场景下，单机自我读取也能减轻对共享文件系统的集中访问压力。AIBrix 将这些能力进一步封装，开发者可基于自有机型和带宽状况，自行选择最佳加载方式。

高密度模型部署

对于精调模型（如 LoRA），实现高密度部署是释放其竞争力的关键。我们在 vLLM 项目中做了大量改动来支持 LoRA 的动态部署与度量，血缘关系追踪、LoRA metrics 单独计量等关键特征，方便与 AIBrix 控制面深度集成。但这其中依然存在若干未解决的挑战，我们正在逐步完善并计划在后续版本中支持更多功能：

• 单容器混合部署：目前基本模型（Base Model）和精调模型（LoRA）常被打包在同一容器，虽然能减少部署节点，但也打破了容器隔离以及不可变性的原则，某些场景会因过载触发部署失败。

• Adaptive LoRA batch、dynamic merge 等高级功能还在持续研发当中，旨在进一步提高同一 GPU 上运行多个模型或微调版本的效率。

• 定制化内存分配器（memory allocator）：在固定 GPU 资源中快速换入换出不同基础模型，利用引擎原生的 CUDA 虚拟内存（visual memory）管理能力，使多模型部署具备更好的鲁棒性与伸缩性。

AIBrix v0.2.0：分布式与解耦系统

分布式编排和多机推理

AIBrix v0.2.0 的工作重心是分布式与解耦（Distributed and Disaggregated）系统，分布式部分主要涉及到多机推理的编排。我们在对 DeepSeek-R1 671B 模型、16 卡满配场景下进行验证后，已经实现了较为稳定的分布式推理方案。具体来说，AIBrix 采用 Ray 来编排分布式推理任务，原因包括：

• vLLM 自带分布式 runtime：默认支持 Ray 与多进程，为分布式推理奠定良好基础。

• KubeRay 场景经验积累：AIBrix 项目的核心成员曾主导 KubeRay 的开源工作，对如何在 Kubernetes 与 Ray 之间实现高效整合有着丰富的实践。目前，KubeRay 是行业通用的 Ray on Kubernetes 编排方案，被广泛应用于包括字节跳动在内的多家企业生产环境。

• 云原生的多角色编排：在一个 CRD 中灵活编排不同容器或角色（如 TP/PP 等）并非易事，而多机调度策略也可能因具体业务场景（例如 P&D、Splitwise 论文提出的 Router/CLS、Mixed Pool 或 vLLM xPyD 等）而改变。通过“混合编排（Hybrid Orchestration）”理念，让 Ray 负责应用内部的角色管理，Kubernetes 则专注于升级、伸缩等通用工作，双方分工明确且更具灵活性。

在实际实现中，我们将一个多容器推理实例视作一个 Ray 应用，用 RayCluster 来进行描述，再由   RayClusterFleet 负责升级与扩缩容等通用任务。除此之外，我们还在 vLLM 中加入了额外的弹性功能，允许集群节点在资源不足时先行等待，触发 Pod 调度与自动扩缩容后，再承接推理负载；这一改进在生产环境中显著提升了容错与鲁棒性。

KV Cache 组件管理

在 Prefix/Session Cache、P&D Disaggregation、跨机请求迁移等场景中，KV Cache 组件扮演至关重要的角色。如果仅放在推理引擎内部，诸如跨机分享 KV Cache 等操作就会非常复杂。

AIBrix 通过分布式 KV 缓存来应对这些挑战，不仅实现了跨引擎的 KV 复用，同时也在网络与内存效率方面进行了优化。我们的方案采用了一种可防扫描（scan-resistant）的淘汰策略，有选择地保留热点 KV 张量（hot KV tensors），从而最大程度地减少不必要的数据传输；此外，通过异步方式维护元数据更新进而降低系统开销，并在缓存与引擎的协同部署（colocation）中利用共享内存进行更快速的数据传输。

在实际部署场景中，我们发现：

• 内存层次优化：在 prefix cache 等场景中，  如果低端 GPU 型号模型加载已经占用大部分 HBM 显存，留给 KV Cache 的空间十分有限；此时可借助空闲的 CPU DRAM 做“二级”缓存，能实现一定程度上的容量扩展。需要注意的是，从绝对性能角度，这种方案不可避免地会带来从 CPU DRAM 到 GPU HBM 间数据交换的额外开销，但在容量与性能间取得平衡对于某些业务仍然十分必要。

• 灵活的替换策略：AIBrix 正在基于 vLLM v1 的架构调整，向上游社区贡献更多 KV Cache 淘汰策略的实现，敬请期待后续更新。

异构计算与成本优化

在异构资源环境中，并非所有用户都能在同一集群内获取一致的 GPU 规格，常常需要混合不同型号的 GPU 来支持同一业务。而异构卡的性能差异也会影响控制面的调度与数据面的路由。

AIBrix 针对这种需求，通过 Profiling + ILP （整数线性规划） 的组合，找到了成本最优的机型分配和部署方案。对于异构路由策略层面的能力，目前相关功能和特性也正在开发中。

故障诊断与模拟工具

AI Accelerator 故障诊断与模拟工具是 AIBrix 的系统组件，基于火山引擎容器服务 (VKE) 的经验开发，针对的是 GPU 故障和性能下降在大规模 AI 部署中构成重大挑战 – 静默错误、过热、内存泄漏和间歇性等故障可导致模型性能下降、延迟增加，甚至系统崩溃；而在异构 AI accelerator 环境中，不同 GPU 型号在不同工作负载下表现不一致，故障诊断和自动化运维更加棘手。

• 故障检测：目前针对不同厂商的卡型能够完成自动化故障检测， 帮助用户在影响负载之前识别性能问题。

• 故障模拟：该工具可以模拟 GPU 的性能下降或硬件故障，方便开发者测试和构建高容错能力的 AI 系统。一旦故障发生，系统能平滑恢复，降低对整体服务的影响。

• 硬件支持：目前已支持 NVIDIA GPU 等主流 AI 芯片，后续也将持续扩展兼容更多类型的加速器。

AIBrix On VKE

火山引擎容器服务已实现了 AIBrix 的组件化接入，在一系列 GenAI 场景下的基准测试中，弹性伸缩性能与 token 吞吐量提升超 10%，LoRA 应用成本最高降低 4.7 倍，模型加载提速可超 50%。收益详情如下：

在上述核心特性中，弹性伸缩是连接云上应用与云服务的桥梁。接下来，我们将着重聚焦 LLM 弹性伸缩，深入探究其在 GenAI 场景中发挥的作用以及与 VKE 结合所带来的价值。

Autocsaling On VKE

资源准备与镜像预置

VKE 通过节点池统一管理实例资源，使用节点池创建 8 台 A10 单卡实例，作为实验环境。

节点池支持包年包月、按量付费、弹性预约、Spot 等多种实例交付方式，满足不同场景下的成本与可用性需求

容器镜像方面，通过预加载的方式在实例上提前拉取 deepseek-coder-7b 模型镜像，加快 Pod 拉起速度。

端到端可观测性

VKE 集成了对网络请求流入流出、各类资源状态与利用率、Kubernetes 资源对象以及应用自身运行指标的端到端观测，并且支持应用的自定义指标透出，借助这些能力，可以全面观测 LLM 应用的运行状态。对于弹性伸缩场景，观测指标一方面用于工作负载伸缩，一方面用于观察 AIBrix 的弹性伸缩效果。

实验与结论

AIBrix 集成了多种 Pod 伸缩方法，在本例中，使用 Kubernetes 原生的水平 Pod 自动扩缩器（HPA）与 AIBrix 实现的 Kubernetes Pod 自动扩缩器（KPA，可参考 KPA）进行对比。

LLM 应用负载，使用 vllm 运行 deepseek-coder-7b，弹性伸缩指标使用 vllm:gpu_cache_usage_perc，访问请求从 ShareGPT 中随机抽取，并以指定的并发数将这些请求分发给该服务。对于 HPA，AIBrix 会创建一个 Kubernetes 原生的 HPA 实例，以扩展指标的方式进行伸缩。对于 KPA，AIBrix 实现了其完整的流程，包括指标收集、对目标部署状态的定期监控以及伸缩操作。

实验数据如下所示。AIBrix 支持直接从 Pod 中拉取关键指标，因此伸缩响应速度获得显著提升，大模型应用首次伸缩响应耗时 12 秒, 相比 HPA 的 67 秒耗时加速 82%。AIBrix 的完整扩容周期为 120 秒，而 HPA 为 320 秒，加速 62.5%，并且震动频次降低 33%。

写在最后

AIBrix 的目标是将大模型推理的“系统侧”能力与“引擎侧”创新完美结合，提供从资源调度、网络流量控制到分布式推理的端到端解决方案。通过与 vLLM 开源社区的深度协作，我们希望不断迭代并完善在云原生环境下的大模型部署架构，让企业能够更加轻量、弹性地构建面向生产的 LLM 推理服务。

在 AIBrix 开发过程中，我们的很多创新想法都受到了学术研究的启发，比如 Preble、Melange、QLM 和 MoonCake 等，在这里我们真诚地感谢这些成果背后的研究人员。我们也非常感谢 vLLM 社区的支持，使 AIBrix 成为了 vLLM 的控制面，进一步增强了我们构建可扩展和高效 AI 基础设施的使命感。

AIBrix 由字节跳动开源，现在正在开源社区的支持下成为一个完全开源的项目——目前项目已经吸引了来自密歇根大学、伊利诺伊大学厄巴纳 - 香槟分校、华盛顿大学、Google、DaoCloud 等学术界和工业界的开源伙伴。未来，我们也希望 AIBrix 能通过开放、协作的方法塑造 AI-Infra 的未来，持续将顶尖学术研究和行业内的生产级实践结合起来。也欢迎更多开发者和企业加入我们，为开放、可扩展的 AI 基础设施的未来做出贡献：https://github.com/vllm-project/aibrix

今日好文推荐

分布式系统编程已停滞？！

Curl 之父：我是如何枕着18万行C代码还能安稳入睡的

刚刚，DeepSeek 突然公布成本利润率高达545%！做 AI Infra 的该慌了？！

“前端已死”是危言耸听吗？