StreamSparkAI

详细摘要 摘要

生成：2025-06-17 09:46

摘要详情

音频文件
2025-06-15 | 字节开源 AIBrix 基于vLLM的高性价比LLM推理加速方案
摘要类型
详细摘要
LLM 提供商
openai
LLM 模型
gemini-2.5-pro-preview-06-05
温度
0.3
已创建
2025-06-17 09:46:04

摘要内容

概览/核心摘要 (Executive Summary)

字节跳动基础架构团队负责人谢立广于2025年6月15日介绍了其开源项目AIBrix——一个基于vLLM的高性价比LLM推理加速方案。该项目旨在解决大规模自托管大语言模型（LLM）推理服务在生产环境中面临的成本和时延两大核心挑战，提供从部署、管理到自动伸缩的云原生、端到端解决方案。

AIBrix的核心技术创新包括：
1. 成本优化：通过异构资源下的自动扩缩容（利用专用指标如TTFT、TPOT，并根据GPU性价比调度请求）、高密度LoRA（Low-Rank Adaptation）管理（动态适配器加载、智能调度、专用路由控制平面，可降低高达4.7倍成本）以及缓存感知路由（平衡KV Cache命中率与负载）。
2. 性能优化：通过KV Cache异步卸载（将部分KV Cache张量卸载至分布式存储如Infinistore，通过RDMA访问，显著提升首Token时间TTFT达80%）和Prefill-Decode（PD）分离（将计算密集的Prefill与IO密集的Decode阶段分配给不同节点处理，引入“Role Group”概念简化管理，P95 TTFT可降低80%）。

AIBrix自2025年2月开源以来，已获得社区广泛关注（超3600星标），并与谷歌、红帽、AWS等展开合作，推动AI推理在Kubernetes生态的优化。项目强调社区驱动和开放性，计划持续迭代，集成更多字节内部研究成果与实战经验。即将发布的0.4版本将聚焦PD分离、KV Cache异步卸载、智能路由及多租户支持。

引言与项目背景

Speaker 1 (谢立广，字节跳动基础架构团队，AIBrix项目发起人与负责人) 介绍了字节跳动最新的开源项目AIBrix，旨在分享项目开源的初衷、对大语言模型推理的思考以及生产实践中的技术细节。

  • LLM技术趋势：
    • 自2024年1月以来，以DeepSeek为代表的开源模型与OpenAI、谷歌等闭源模型之间的性能差距急剧缩小，整体AI模型性能快速趋近。
    • 高性能模型的成长推动推理成本急剧下降。
    • AI在开发者和企业中的应用正在加速：
      • 过去16个月，GitHub上AI开发者代码仓库数量增长175%。
      • 谷歌披露其产品与API每月处理的Token总数从2024年5月的10万亿个飙升至2025年5月的480万亿个，一年增长近50倍。
  • 企业面临的核心问题：如何构建大规模、自托管的大语言模型推理服务，以实现数据安全可控、显著降低推理成本并提高推理性能。
  • 大规模LLM部署挑战：
    • 单点小模型部署（几十B，单机）相对简单。
    • 跨机部署大型模型（如DeepSeek Coder One 671B满血版）复杂度增加。
    • 在大型GPU集群上部署大量模型时，传统分布式系统问题（自动伸缩、路由至特定模型/LoRA适配器、容错、SLO保障、成本效率）变得更加棘手。

AIBrix：架构与核心特性

AIBrix是字节跳动针对上述挑战开发的、基于vLLM的云原生LLM服务栈，专为Kubernetes（K8s）设计，提供一整套生产部署、管理到自动伸缩的解决方案。

  • 核心目标：简化部署流程、降低成本、提供端到端极致性能、易用性、可拓展性。
  • 概念架构（五层）：
    1. 统一入口层：兼容OpenAPI的标准化、可拓展入口，处理所有LLM推理请求。
    2. API网关层：基于Envoy Gateway拓展，优化实例路由，支持可拓展的自定义路由策略。
    3. 模型服务层：支持高密度LoRA管理，动态注册LoRA并在vLLM中追踪来源，简化管理，降低维护成本。
    4. 编排调度层：支持多种生产场景下的LoRA自动扩缩容策略。
    5. 分布式解耦KV Cache层：引入分布式KV Cache，支持高容量、跨引擎的KV Cache复用，优化网络与内存效率。
    6. 辅助工具：统一Runtime、GPU流式加载器、混合编排模型、诊断故障模拟工具、基准测试工具。
  • 实际部署架构：比概念图复杂得多，由众多云原生组件构成，具备真正的生产可用性（详情见GitHub）。
  • 开源状态与社区影响 (自2025年2月21日发布)：
    • 通过vLLM官方渠道宣布开源。
    • 发布首周登顶GitHub热门项目排行榜。
    • 累计超过 3600个star，收获 50多个社区开源贡献者。
    • 目标：建成社区驱动的项目。
    • 合作：
      • 与Kubernetes社区、谷歌、红帽合作，推动AI推理负载在K8s生态的部署优化。
      • 与AWS团队合作，将AIBrix部署到AWS EKS（全球最大规模K8s托管服务）。
      • 在KubeCon EU（荷兰）上，AIBrix与AWS联合展示了在EKS上部署DeepSeek Coder One满血版模型，并运行在AWS Graviton和Inferentia芯片上。Speaker 1强调：“And this is a big deal, 就因为这个证明了air bi是可以在mv的这个G P U上跑的”（应指非NVIDIA GPU）。
    • 业界认可：获得谷歌Distinguished Engineer Clayton Coleman和Anyscale联合创始人Robert Nishihara等的高度评价。Clayton Coleman评价：“ByteDance has been a phenomenal partners in helping Google driving standardization of LLM serving in K8s.”
  • 版本迭代：
    • 0.1 (2024年10月)：构建LLM服务的云原生基础，包括GPU流式加载器（降低冷启动时延）、自动伸缩、高密度部署LoRA适配器（降低推理成本）。
    • 0.2 (2025年2月)：新增分布式KV Cache支持，适配DeepSeek Coder One的跨节点编排与异构硬件服务能力，向分布式解耦架构迈进。
    • 0.3 (2025年5月)：推出业界领先（SOTA）的KV Cache异步卸载方案（显著提升首Token响应时间TTFT，降低80%），引入Prefix-Cache感知与公平性调度策略等高级路由能力，提供完整Benchmark工具。
    • 0.4 (预计2025年6月发布)：聚焦Prefill-Decode (PD) 分离。

成本优化策略

AIBrix从自动扩缩容、LoRA管理和路由管理三方面着力优化推理成本。

异构资源下的自动扩缩容 (Auto-scaling on Heterogeneous Resources)

  • 传统K8s自动伸缩机制的挑战：
    • 扩缩容指标选择：QPS不适用于LLM推理（QPS平稳时，时延可能剧烈波动）。常用GPU指标（如SM Activity）也并非百分百可靠。原因是不同长度的LLM请求资源消耗差异大且不可预测。
    • GPU异构性：生产环境中常有多种GPU类型（如A100, L20），需兼顾利用率和SLO。
    • 突发流量应对：LLM推理对计算资源要求高，弹性伸缩能力至关重要。
  • AIBrix的解决方案：
    • 专用扩缩容指标：提出如TTFT（首Token时延）、TPOT (Tokens Per Output Token) 等更精细化指标，准确判断业务与资源压力。
    • 异构GPU调度：基于观察“便宜的GPU其实是比较适合去处理小的request小的请求的，而且高端的GPU是可以处理更合适去处理大一点的，比较heavy的请求的”。例如，在小请求场景下，A100（相对低端）对比H100在token per dollar指标上性价比可提升40%。AIBrix利用此观察设计异构GPU自动扩缩容方案。
    • 扩缩容决策算法：
      • Reactive-based：根据当前请求模式变化决策。
      • Prediction-based (Proactive)：预测未来请求模式提前调整（计划引入）。
    • 整合方案：将模型整合到在线自动扩缩容解决方案中，有效监控请求负载，并将请求路由到合适类型的GPU。

高密度LoRA管理与路由 (High-Density LoRA Management and Routing)

  • LoRA技术背景：一种高效微调预训练模型的技术，仅调优少量参数（LoRA adapter），其存储和内存开销约为预训练模型的1%。允许将大量LoRA adapter部署在同一Pod中，实现高密度部署，降低成本。
  • 字节跳动生产实践：支持大量LoRA adapter，流量模型差异巨大（少数关键高流量，多数低流量实验性模型）。认为提高部署密度是应对微调模型数量激增的关键技术。
  • LoRA在K8s上的挑战：
    • LoRA adapter必须与基础模型一起加载，打破K8s传统“一个模型/服务对应一个Pod”的干净一对一映射假设。
    • K8s默认服务机制无法发现哪个LoRA adapter负载最低，导致同一Pod内多adapter竞争资源。
    • 路由棘手：难以将请求路由到特定低负载adapter。
  • AIBrix的解决方案 (与vLLM社区联合贡献)：
    1. 动态模型适配器管理 (Dynamic Model Adapter Management)：允许平台根据需求动态加载和卸载LoRA适配器，而非容器启动时固定加载。
    2. 先进调度算法 (Advanced Scheduling Algorithms)：根据当前负载、GPU可用性、适配器亲和性，智能地将LoRA部署到合适的Pod，减少干扰，最大化推理性能。
    3. 基于KubeRay的LoRA专用路由控制平面：将每个adapter作为独立路由目标暴露，实现流量精确路由到最合适的Pod和adapter。
  • 成本与性能收益：
    • 稀疏流量场景下，资源成本可降低高达 4.7倍。
    • 高负载情况下，依然能保持约 1.5倍 的资源节省（对比传统vLLM及高性能LoRA内核）。
    • 通过高密度部署和合理调节batch大小，成本可下降约 8% 至 2.1倍 (具体数值依赖负载模式)。

缓存感知路由 (Cache-Aware Routing / Prefix Routing)

  • 核心思想：为命中KV Cache，请求需路由到持有相关KV Cache的实例（Pod）。路由器需知道哪个Pod拥有哪些前缀（prefix）。
  • 路由决策复杂性：需权衡延迟（KV Cache命中率）与负载。例如，请求“I like apple very much”，若Node1有“I like apple”的缓存（50%命中）但负载50%，Node2无缓存但负载30%，决策需综合考量。
  • AIBrix的实现：
    • 前缀可感知路由算法 (Prefix-aware routing principles)：动态决定在Cache环境下请求应发往哪个Pod，以平衡负载与时延。
    • 架构：请求 → Envoy Gateway (配置其external service) → AIBrix Router (执行定制规则，计算目标Pod IP) → 目标Pod。AIBrix Router作为Envoy的外部服务存在，完全解耦，允许用户自定义生产环境的路由规则。

性能优化策略 (Latency)

AIBrix主要通过KV Cache卸载和PD分离来优化性能（降低延迟）。

KV Cache卸载与管理 (KV Cache Offloading and Management)

  • KV Cache的重要性与挑战：
    • 可复用性：LLM（基于Transformer）推理会遗留中间计算结果（KV Cache），后续有相同前缀的请求可复用以加速计算（“以存代算”），常见于聊天机器人、多轮对话、AI Agent（如System Prompt复用）。
    • 显存消耗巨大：随模型规模和上下文窗口增大而急剧增加。例如，一个70B模型支持10万上下文，KV Cache可占几百GB显存，超出GPU显存上限会导致频繁清除和重算，浪费算力。
    • KV Cache迁移：引擎故障时，如何具备容错能力地迁移KV Cache。
    • 硬件平台限制：低端GPU实例可能无NVLink或RDMA，多GPU共享VPC网卡易成瓶颈，导致网络堵塞和服务时延飙升。
  • AIBrix的解决方案：
    • 选择性KV Cache缓存卸载：只卸载部分选定的KV张量，减少不必要数据传输，最大化利用网络带宽。
    • 可拓展的KV Cache卸载框架：
      • 可插拔淘汰策略 (Eviction Policy)：支持从LRU到基于Attention分数的感知淘汰等多种策略，实现高效选择性卸载。
      • 可插拔序列化引擎：研究KV感知压缩、量化算法对性能的影响。
    • 分布式KV Cache集群编排：
      • 每个vLLM Pod内部集成AIBrix KV Cache Connector模块。
      • 通过一致性哈希访问一组分布式KV Cache Server（底层由字节跳动另一开源项目 Infinistore 提供）。
      • 缓存卸载通过 RDMA 直接进行。
      • 轻量化控制面：使用Redis存储元数据和slot映射数据，客户端可直接查询后端节点信息，实现高效可拓展访问。

Prefill-Decode (PD)分离 (Prefill-Decode (PD) Separation)

  • 传统架构问题：Prefill（计算密集型，处理prompt）和Decode（内存/IO密集型，生成token）两个阶段在同一GPU上运行，会产生资源干扰。尤其大prompt会拖慢轻量Decode请求，Prefill占用大量计算资源延迟其他请求的Decode。
  • PD分离原理：将Prefill和Decode阶段分别交由不同的工作节点处理，并针对各自负载进行优化。确保Decode阶段的时延在高并发和重Prefill情况下保持稳定。
  • AIBrix的实践与效果 (将在0.4版本发布)：
    • 测试表明，启动PD分离后，首Token时延（TTFT）的P95可降低高达80%。
    • 尤其在DeepSeek Coder One这类大模型中，当推理（reasoning）能力开启且输出较长时，Decode易成瓶颈，优化效果显著。
  • PD分离的两种架构方式实现于AIBrix：
    1. 集中式KV Cache存储架构 (Centralized KV Cache Architecture)：Prefill完成后，KV数据写入共享KV存储服务；Decode Worker从中心存储服务拉取数据。类似Moonshot AI的“mooncake”方案，具良好横向拓展能力，适应多节点大规模部署。
    2. 点对点P2P架构 (Peer-to-Peer Architecture)：Decode Worker直接从原始Prefill节点拉取KV Cache，省去中间跳转，时延较好，但节点耦合性强，拓展性相对受限。
  • AIBrix的抽象：“角色组” (Role Group)：
    • 随着PD分离成为行业常态，推理服务单元演变成由多组件（Decode, Prefill, 可选本地调度器等）组成的小型分布式系统。
    • AIBrix引入“Role Group”新抽象概念，将Prefill、Decode及本地调度器作为一个逻辑整体进行统一调度和生命周期管理，有效简化实例内部复杂度。

未来规划与展望

  • AIBrix 0.4版本 (预计本月，即2025年6月发布) 核心内容：
    • 编排增强：支持跨角色组的滚动升级（确保服务高可用），引入网络亲和性（Network Affinity）和Gang Scheduling（保证协作组件间性能协同与低延迟）。
    • PD解耦架构。
    • 基于vLLM Connector的 KV Cache异步卸载机制。
    • KV Cache智能路由机制。
    • 对 多租户场景的支持（源自Intel提出的一个scenario）。
  • 技术开放性：作为开源项目和控制面平台，AIBrix保持高度开放性，计划与Mooncake、S-LoRA (Sarathi-Serve，前身为DyableX) 等推理项目实现无缝集成，灵活适配用户技术栈。
  • 持续开源：陆续推出字节内部多个技术方向的研究成果和实战经验。

结论

Speaker 1 最后感谢听众，并展示了AIBrix项目的GitHub Repo和社区微信交流群二维码。他表示，团队将听取社区反馈，不断迭代改进AIBrix项目，并呼吁大家关注和支持。一个关于如何一键部署AIBrix以实现DeepSeek Coder One部署和PD分离的Demo因时间关系被略过。

返回音频媒体