字节跳动推出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 如何协同工作并优化利用率。

• 单服务跨区域：多数据中心和跨区域部署使得同步管理模型与推理任务变得更加复杂，同时也对容灾和可用性提出了更高的要求。

传统的微服务框架（如 KNative）或服务网格（如 Istio）在鉴权、流量控制、版本升级等通用功能上已经相当成熟，不过对于大模型服务来说，仍显得过于庞大，且缺乏针对性的优化。此外，市场上大多数项目往往将推理引擎视作一个“黑箱”，无法深入协同优化。

设计理念

为了应对这些挑战，AIBrix 的核心理念是通过“引擎层”和“系统层”的紧密合作，构建一个轻量化、云原生的解决方案。具体来说，我们将一些通用的引擎功能转移到系统层进行管理，并对模型推理常用功能进行封装，向外提供统一的引擎接口。这种模式可以在大规模场景下同时兼顾性能、成本和易用性，帮助企业级大模型的部署实现更高的弹性和可控性。

系统架构

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

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

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

AIBrix v0.1.0：

无服务器与高密度部署

无服务器与弹性伸缩

AIBrix v0.1.0 的主要思路是结合大模型在生产环境中面临的核心问题，和无服务器领域的几项关键技术（冷启动、快速伸缩和高密度部署）相结合。我们并不想让大模型完全“无服务器化”，因为这在现实中难以实现理想效果，也不是企业级生产环境的最佳选择；更切实的做法是借鉴并改进无服务器技术，对大模型的部署环节进行针对性的优化。

线上观察：自动伸缩与指标的挑战

在实际应用中，自动伸缩的最大挑战是：流量高峰与推理实例利用率之间往往存在显著的时间滞后（通常在 2～5 分钟），这在高并发场景下很容易导致短时间的过载，从而延长长尾延迟。而传统的 GPU 性能指标（例如 DCGM 提供的 DCGM_FI_DEV_GPU_UTIL 或 DCGM_FI_PROF_SM_ACTIVE）严重依赖于引擎自身实现，难以反映 GPU 的空间利用率，导致扩缩容的决策往往不够精确。

多种伸缩方案的探索

优化扩缩容与冷启动的全新探索

为了更好地判断扩缩容时机，我们尝试将 KV_CACHE 的使用情况和待处理请求的输入输出数据结合起来。你可能会觉得，这样听起来不错，但实际上，保障 SLO（服务级别目标）往往比单纯追求 GPU 的利用率更为重要。因此，传统依赖资源利用率的自动扩缩容策略效果并不理想。为了应对这个问题，我们开始研究一种基于 Profiling 的扩缩容方案，旨在通过分析历史和实时流量分布，动态决定扩缩容的时机，从而减少系统过载和降低延迟。

现在，AIBrix 在这个方向上还在不断进行迭代和改进，我们正在探索一些更具前瞻性的 LLM 特定指标以及主动式弹性策略，力求让系统在处理突发流量时更加从容不迫。

在我们的架构设计中，v0.1.0 版本引入了 Gateway API 插件（Envoy）和 Runtime 这两个关键组件，以适应大模型通常需要的两种路由方式：应用层路由和代理层路由。在大模型社区，像 vLLM 这样的项目正在不断丰富自己的 API（包括 token、转录、评分等），而保持与引擎原生接口的一致性可不是件简单的事。为了解决这个问题，我们采用了高性能的标准化 envoy gateway 结合扩展服务器，来实现既高效又可定制的流量管理：

• 在必要的地方对请求头和主体进行修改，尽量避免重复实现类似 OpenAI 的 API；

• 同时支持对请求进行缓存感知调度，比如采用 kv cache 最少使用、最少提示和前缀缓存感知等策略，以进一步缩短长尾 TTFT（首次 token 响应时间）等性能指标。

冷启动与模型加载优化

在冷启动方面，我们特别关注不同机型在网络带宽、本地盘 I/O 和 RDMA 等性能上的差异。虽然云原生社区已经有像 Fluid 这样的项目在“1 -> N”场景中能加速缓存，但在“0 -> 1”阶段，磁盘 I/O 有时并不总是比网络加载快，反而通过远程流式加载将权重直接加载到 GPU 内存中会更有效率。

因此，在 v0.1.0 中，AIBrix 实现了一种 GPU 流式加载方案，支持在 Tensor 层面上灵活控制下载速度和顺序，为开发者提供多种组合策略。需要注意的是，如果机型配备了本地 NVMe 磁盘，可能在本地加载时表现更佳；而在分布式文件系统的场景下，单机自我读取也能缓解对共享文件系统的压力。AIBrix 将这些功能进一步封装，开发者可以根据自己的机型和带宽情况，选择最优的加载方式。

高密度模型部署

对于精调模型（像 LoRA），实现高密度部署是提升其竞争力的关键。我们在 vLLM 项目中做了很多调整，支持 LoRA 的动态部署和度量，包括血缘关系追踪、LoRA 指标单独计量等功能，方便与 AIBrix 控制面深度集成。但在这个过程中，仍然面临一些待解决的挑战，我们正在逐步完善，并计划在后续版本中增加更多功能：

• 单容器混合部署：目前基本模型和精调模型通常被打包在同一个容器中，这虽然能减少节点数量，但也打破了容器的隔离性和不可变性原则，某些情况下可能会因为过载而导致部署失败。

• Adaptive LoRA 批处理、动态合并等高级功能正在研发中，旨在进一步提升同一 GPU 上运行多个模型或微调版本的效率。

• 定制化内存分配器：在固定的 GPU 资源中快速切换不同基础模型，利用引擎的 CUDA 虚拟内存管理能力，使多模型部署更具鲁棒性和灵活性。

AIBrix v0.2.0：

分布式与解耦系统

分布式编排与多机推理

AIBrix v0.2.0 的工作重点是构建分布式与解耦系统，特别是在多机推理的编排方面。经过对 DeepSeek-R1 671B 模型和16卡满配场景的验证，我们已经实现了一套较为稳定的分布式推理方案。具体来说，AIBrix 采用 Ray 来进行分布式推理任务的编排，其原因包括：

• vLLM 自带分布式运行时：默认支持 Ray 和多进程，这为分布式推理奠定了良好的基础。

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

• 云原生多角色编排：在一个 CRD 中灵活编排不同容器或角色（如 TP/PP 等）并不容易，而多机调度策略也可能因具体业务场景而变化。通过“混合编排”理念，让 Ray 负责应用内部的角色管理，而 Kubernetes 则专注于升级、扩缩容等普遍任务，这样分工明确更具灵活性。

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

KV缓存管理与异构计算优化

说到 KV Cache 组件，它在很多场景下都显得不可或缺，比如在 Prefix/Session Cache、P&D 分离、跨机请求迁移等方面。如果我们把它仅仅放在推理引擎内部，那跨机共享 KV Cache 的操作就会变得相当复杂。

AIBrix 采用了分布式 KV 缓存，成功应对了这些挑战。它不仅实现了跨引擎的 KV 复用，还在网络和内存效率上进行了优化。我们的方案使用了一种抗扫描的淘汰策略，有选择地保留了热点 KV 张量，这样能最大限度减少不必要的数据传输。此外，通过异步更新元数据，我们降低了系统的开销，并在缓存和引擎的协同部署中，利用共享内存加快了数据传输的速度。

在实际的部署过程中，我们发现了一些有趣的现象：

• 内存层次优化：在 prefix cache 的场景下，如果低端的 GPU 型号模型已经占用了大部分 HBM 显存，那么留给 KV Cache 的空间就很有限。这个时候，可以利用空闲的 CPU DRAM 作为“二级”缓存，达到扩容的效果。虽然从绝对性能来看，这样的方案会带来 CPU DRAM 和 GPU HBM 之间数据交换的额外开销，但在容量与性能之间找到平衡对于某些业务来说仍然非常重要。

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

关于异构计算和成本优化

在异构资源环境下，并不是每个用户都能在同一个集群中获得相同的 GPU 规格，往往需要混合不同型号的 GPU 来满足业务需求。但是，异构 GPU 的性能差异也会影响控制面的调度和数据面的路由。

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

故障诊断与模拟工具

AI 加速器的故障诊断与模拟工具是 AIBrix 的一部分，基于火山引擎容器服务（VKE）的经验开发。它专门应对 GPU 故障和性能下降，这在大规模 AI 部署中是一个重大挑战。静默错误、过热、内存泄漏和间歇性故障都可能导致模型的性能下降、延迟增加，甚至系统崩溃。而在异构 AI 加速器环境下，不同型号的 GPU 在不同工作负载下的表现也不尽相同，这使得故障诊断和自动运维的难度加大。

• 故障检测：现在，我们的系统可以自动识别不同品牌的显卡故障，帮助用户在问题影响正常运行之前及时发现性能隐患。

• 故障模拟：这个工具能够模拟显卡性能下降或硬件故障，给开发者一个测试的平台，助力他们构建更具容错能力的 AI 系统。一旦出现问题，系统可以快速恢复，减少对整体服务的干扰。

• 硬件支持：目前已经支持了像 NVIDIA GPU 这样的主流 AI 芯片，未来还会不断兼容更多种类的加速器。

AIBrix 在 VKE 上

火山引擎的容器服务已经实现了 AIBrix 的模块化接入。在一系列生成式 AI 场景的基准测试中，我们看到弹性伸缩性能和 token 吞吐量都有超过 10% 的提升，LoRA 应用的成本最高降低了 4.7 倍，模型加载速度提升了超过 50%。具体收益如下：

在这些核心功能中，弹性伸缩就像是连接云应用和云服务的桥梁。接下来，我们将重点讨论 LLM 的弹性伸缩，深入了解它在生成式 AI 场景中的作用，以及与 VKE 的结合为我们带来了哪些价值。

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的未来与创新

在这篇文章的最后，我们想分享一下AIBrix的愿景。我们的目标是把大模型推理的“系统侧”能力和“引擎侧”创新融合在一起，致力于提供从资源调度、网络流量控制到分布式推理的完整解决方案。通过与vLLM开源社区的紧密合作，我们希望在云原生环境中不断优化大模型的部署架构，帮助企业更灵活、轻松地构建面向生产的LLM推理服务。

在AIBrix的开发旅程中，我们的许多创新灵感都源自学术界的研究，比如Preble、Melange、QLM和MoonCake等项目。在此，我们衷心感谢那些背后默默付出的研究人员。此外，我们也非常感激vLLM社区的支持，使得AIBrix能够成为vLLM的控制面，这让我们在构建可扩展和高效AI基础设施的路上更有动力。

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

推荐阅读

分布式系统编程真的停滞了吗？

Curl之父：我是如何在18万行C代码中安然入睡的？

DeepSeek刚刚宣布利润率高达545%！做AI基础设施的你该警惕了吗？

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