前 言随着 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.0Serverless 与高密度部署Serverless 与弹性伸缩AIBrix v0.1.0 的主要思路是将大模型在生产环境中面临的核心难题与 Serverless 领域的几项关键技术冷启动、快速伸缩与高密度部署相结合。我们并不追求让大模型像 FaaS 一样彻底“无服务器化”因为这在现实中尚难达到理想效果也并非企业级生产环境的最佳形态更可行的路线是借鉴并改进 Serverless 的相关思路对大模型的部署环节进行有针对性的优化。线上观察Autoscaling 与指标挑战在实际应用中Autoscaling 最大的难点是流量波峰和推理实例利用率之间通常存在显著的时间滞后常见在 25 分钟导致高并发场景下容易出现短时过载从而拉升长尾延迟。此外传统的 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 等策略以进一步缩短长尾 TTFTTime 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 等并非易事而多机调度策略也可能因具体业务场景例如 PD、Splitwise 论文提出的 Router/CLS、Mixed Pool 或 vLLM xPyD 等而改变。通过“混合编排Hybrid Orchestration”理念让Ray负责应用内部的角色管理Kubernetes 则专注于升级、伸缩等通用工作双方分工明确且更具灵活性。在实际实现中我们将一个多容器推理实例视作一个 Ray 应用用 RayCluster 来进行描述再由 RayClusterFleet 负责升级与扩缩容等通用任务。除此之外我们还在 vLLM 中加入了额外的弹性功能允许集群节点在资源不足时先行等待触发 Pod 调度与自动扩缩容后再承接推理负载这一改进在生产环境中显著提升了容错与鲁棒性。KV Cache 组件管理在 Prefix/Session Cache、PD 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 中随机抽取并以指定的并发数将这些请求分发给该服务。对于 HPAAIBrix 会创建一个 Kubernetes 原生的 HPA 实例以扩展指标的方式进行伸缩。对于 KPAAIBrix 实现了其完整的流程包括指标收集、对目标部署状态的定期监控以及伸缩操作。实验数据如下所示。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 基础设施的使命感。