Each language version is independently generated for its own context, not a direct translation.
这篇技术报告介绍了一个名为 xLLM 的“超级大脑管家”。它的任务是让大型人工智能模型（LLM，比如能写诗、聊天的 AI）在京东这样的超大规模企业环境中，跑得更快、更稳、更省钱。
为了让你更容易理解，我们可以把运行 AI 模型想象成经营一家繁忙的“智能餐厅”。
1. 核心痛点：以前的餐厅为什么忙不过来？
在 xLLM 出现之前，主流的 AI 推理框架（比如 vLLM 或 MindIE）就像一家管理僵化的传统餐厅，面临四个大麻烦：
- 潮汐效应难应对：餐厅在饭点（在线用户提问）人满为患，但在深夜（离线数据分析）却空无一人。以前的系统要么饭点排队太长，要么深夜机器闲置浪费。
- 工序死板：以前做一道菜（AI 生成回答）必须严格按顺序：先备菜（Prefill，处理输入），再炒菜（Decode，生成输出）。如果备菜的人忙不过来，炒菜的人就得干等着；反之亦然。
- 多任务处理笨拙：现在的 AI 不仅能看文字，还能看图、听声音（多模态）。以前的系统处理图文混合任务时，像是一个厨师既要切菜又要画画，手忙脚乱，效率极低。
- 故障恢复慢：如果某个厨师（服务器节点）突然晕倒，以前的系统得把整道菜重新做一遍（重新加载模型），导致所有客人都要等很久。
2. xLLM 的解决方案：双核驱动的“智能餐厅”
xLLM 把整个系统拆成了两个核心部门：前台调度部 (xLLM-Service) 和 后厨引擎部 (xLLM-Engine)。
A. 前台调度部 (xLLM-Service)：聪明的“大堂经理”
这位经理拥有“读心术”和“变形金刚”般的能力：
在线/离线混坐策略：
- 比喻：就像餐厅在饭点时，优先服务点急菜的客人（在线聊天）；但在客人少的间隙，立刻安排空闲的厨师去处理“预制菜”（离线数据分析）。一旦饭点高峰来临，立刻把预制菜的任务暂停，让厨师全力服务急客。
- 效果：既保证了急客不用等，又让机器在空闲时没闲着，资源利用率拉满。
动态工序分离 (PD/EPD 解耦)：
- 比喻：以前是“一人包办”（备菜和炒菜都在一个灶台）。xLLM 把“备菜”和“炒菜”分给不同的专业团队。
- 动态调整：如果今天“备菜”的人手不够（输入很长），经理就立刻把几个“炒菜”的厨师调过来帮忙备菜；反之亦然。
- 多模态特化：对于图文混合任务，它引入了“绘图师”（编码模块），让绘图、备菜、炒菜三个环节可以并行或灵活组合，互不干扰。
全球库存管理 (KV Cache)：
- 比喻：AI 聊天需要记住之前的对话（KV Cache）。以前每个厨师只能记自己手里的笔记，记多了就记不住。xLLM 建立了一个云端共享笔记库。如果 A 厨师记满了，可以把笔记瞬间传给 B 厨师，或者存在高速硬盘里，确保大家都能随时调取上下文，不会“失忆”。
极速故障恢复：
- 比喻：如果某个厨师晕倒了，系统不会重新培训他，而是立刻把他的手头工作（笔记）无缝移交给旁边的厨师，就像接力赛一样，客人甚至感觉不到换人了。
B. 后厨引擎部 (xLLM-Engine)：硬核的“超级灶台”
这是真正干活的部门，它通过软硬结合，让硬件跑得飞快：
3. 实际效果：京东的“实战”表现
xLLM 已经在京东的“京言”AI 客服、营销推荐等核心业务中上线了。
- 速度提升：在同样的硬件条件下，xLLM 的吞吐量（上菜速度）比现有的主流方案（MindIE）快了 1.7 倍，比另一个方案（vLLM-Ascend）快了 2.2 倍。
- 更稳：无论流量怎么波动，都能保证用户（在线请求）不卡顿，同时还能利用空闲时间处理更多后台任务。
- 更省：因为效率高，企业可以用更少的机器跑更多的业务，节省了大量成本。
总结
xLLM 就像给 AI 模型装上了一套“智能交通系统”和“超级引擎”。
它不再让 AI 像一辆笨重的卡车在拥堵的公路上走走停停，而是把它变成了一列高铁：
- 调度灵活：根据客流自动调整车厢（动态资源分配）。
- 并行高效：乘客上下车和列车行驶同时进行（流水线重叠）。
- 故障自愈：哪怕一节车厢坏了，也能瞬间切换，列车不停。
这套系统不仅让京东的 AI 服务更流畅，也开源给了全世界，希望能让所有的 AI 应用都跑得更快、更聪明。
Each language version is independently generated for its own context, not a direct translation.
1. 研究背景与核心问题 (Problem)
当前主流的大模型推理框架（如 vLLM, SGLang, TensorRT-LLM 等）在面向企业级大规模部署时，面临以下四大核心挑战：
- 混合与动态工作负载的调度难题：
- 在线服务（如聊天机器人）具有潮汐效应，对延迟（SLO）要求严格；离线任务（如数据分析）对延迟不敏感。现有调度系统难以在保障在线 SLO 的同时，充分利用闲置资源处理离线任务。
- 现有的 Prefill-Decode (PD) 解耦架构通常采用静态资源分配，无法适应实际业务中输入/输出长度动态变化的情况，导致 AI 加速器利用率低或 SLO 违规风险增加。
- 多模态推理支持不足：
- 缺乏针对多模态请求（图像、语音、文本）的高效策略，特别是 Encode（编码）、Prefill（预填充）和 Decode（解码）三个阶段的并行处理与细粒度资源分配。
- 高可用性与容错机制缺失：
- 随着集群规模扩大，节点或实例故障频发。现有机制多基于训练场景的 Checkpoint 恢复，推理场景下恢复慢，难以满足低延迟要求，容易导致服务中断。
- 硬件利用率与系统效率瓶颈：
- 计算气泡：CPU 调度与 AI 加速器执行之间存在串行依赖，导致加速器空闲。
- 通信开销：MoE 架构中的 All-to-All 通信和专家并行（EP）负载不均衡限制了系统扩展性。
- 显存管理：长上下文（Long Context）导致 KV Cache 显存需求指数级增长，传统显存管理策略难以平衡连续性与动态分配需求。
2. 方法论与系统架构 (Methodology)
xLLM 采用创新的 服务 - 引擎解耦架构 (Service-Engine Decoupled Architecture)，分为 xLLM-Service（服务层）和 xLLM-Engine（引擎层）两个核心部分。
2.1 xLLM-Service (智能服务层)
负责集群管理、实例调度和请求分发，核心设计包括：
- 在线/离线混合部署与统一弹性调度：
- 提出抢占式调度策略，在线请求优先，离线任务利用空闲资源运行。
- 设计无状态实例池，支持 Prefill 和 Decode 实例角色的动态切换（基于负载和 SLO 预测），实现零等待时间的实例重分配。
- 动态 PD 解耦策略 (Dynamic PD Disaggregation)：
- 摒弃静态 PD 比例，根据实时 TTFT (首字延迟) 和 TPOT (每字延迟) 指标，动态调整 Prefill 和 Decode 实例的比例，甚至支持实例角色的快速反转。
- 混合 EPD 解耦策略 (Hybrid EPD Disaggregation)：
- 针对多模态请求，提出 Encode-Prefill-Decode (EPD) 三阶段解耦。
- 通过 EPD Profiler 自动搜索最优策略（如 EP-D, ED-P, 或 E-P-D），实现视觉编码与语言生成的双流并行，最大化吞吐量。
- 全局 KV Cache 管理：
- 采用分层存储架构（HBM-DRAM-SSD），结合 Mooncake Store 技术，实现跨实例的 KV Cache 路由、复用和迁移，提升缓存命中率。
- 快速故障恢复架构：
- 针对推理场景优化，支持故障实例的快速检测、KV Cache 迁移或重计算决策，以及实例的快速恢复，确保高可用性。
2.2 xLLM-Engine (高性能推理引擎)
负责底层计算优化，通过软硬协同设计最大化硬件效率：
- 多层流水线执行引擎 (Multi-layer Pipeline Execution)：
- 框架层：异步 CPU 调度与加速器执行重叠，消除计算气泡。
- 模型图层：采用双流微批并行 (Dual-stream Micro-batch Parallelism)，将计算流（Attention/MLA）与通信流（MoE Dispatch/Combine）重叠，隐藏通信延迟。
- 算子层：针对 AI 加速器的矩阵（Cube）和向量（Vector）单元进行细粒度重叠，最大化硬件利用率。
- 自适应图模式 (Adaptive Graph Mode)：
- 解决动态输入（变长序列/Batch）与图编译的矛盾。提出部分图模式 (Partial Graph) 和维度参数化，将动态模块（如 Attention）与静态模块分离，结合多图缓存，在保持灵活性的同时大幅降低 Kernel 启动开销。
- xTensor 显存管理：
- 提出 “逻辑连续、物理离散” 的 KV Cache 存储结构。
- 通过虚拟地址映射和按需物理页分配，既满足了算子对连续显存的计算效率需求，又实现了类似 PagedAttention 的高显存利用率，解决了显存碎片化问题。
- 算法级优化：
- 优化推测解码：结合 MLA 架构优化，减少数据搬运，利用异步 CPU 处理。
- 动态负载平衡：针对 MoE 的专家并行 (EPLB) 和数据并行 (DP) 提出分层负载均衡策略，包括基于 KV Cache 感知的请求调度、跨 DP 组负载迁移和算子级细粒度切分。
- 生成式推荐优化：
- 针对京东核心业务，优化 Beam Search 过程，通过 Host-Device 操作重叠和剪枝策略，显著提升推荐场景下的推理效率。
3. 主要贡献 (Key Contributions)
- 架构创新：首创服务 - 引擎解耦架构，实现了从集群调度到底层算子的全栈优化。
- 调度策略突破：
- 实现了在线/离线任务的混合部署与智能抢占。
- 提出了适应动态工作负载的 PD 解耦和针对多模态的 EPD 解耦策略。
- 系统效率提升：
- 通过多层流水线、双流并行和自适应图模式，显著消除了计算气泡和通信延迟。
- 设计了 xTensor 显存管理方案，解决了显存连续性与动态分配的矛盾。
- 算法与业务融合：
- 集成了优化的推测解码、动态负载均衡算法。
- 针对生成式推荐等特定场景进行了深度定制优化。
- 开源与落地：框架已在京东内部大规模生产环境部署（覆盖电商、客服、营销等场景），并开源至 GitHub。
4. 实验结果 (Results)
在 Ascend 910B/910C 加速卡上，xLLM 与 MindIE 和 vLLM-Ascend 进行了广泛对比：
- 吞吐量提升：
- 在 Qwen 系列模型上，xLLM 的吞吐量最高达到 MindIE 的 1.7 倍，vLLM-Ascend 的 2.2 倍。
- 在 DeepSeek 系列模型上，xLLM 平均吞吐量达到 MindIE 的 1.7 倍。
- 在 DeepSeek-R1 的 PD 解耦场景下，吞吐量提升了 34%。
- 业务场景表现：
- 京东“京言”AI 助手：在 Qwen3-8B 模型下，4 卡部署时吞吐量约为 vLLM-Ascend 的 1.6 倍。
- 生成式推荐：在高并发（Beam Width=128）场景下，端到端延迟降低了约 23%。
- 客服与商家助手：在大规模集群下，xLLM 保持了近线性的扩展效率，而竞品出现明显的扩展瓶颈。
- 消融实验：
- 验证了动态 PD 策略、混合 EPD 策略、多层流水线、自适应图模式等模块均对性能有显著正向贡献。例如，自适应图模式使 Qwen3-1.7B 吞吐量提升 27.4%。
5. 意义与展望 (Significance)
- 企业级落地标杆：xLLM 证明了在复杂的混合工作负载和严格 SLO 约束下，通过软硬协同设计可以大幅提升大模型推理的效率和成本效益，为大规模企业级 AI 应用提供了成熟解决方案。
- 国产化硬件生态：深度适配华为 Ascend 系列芯片，展示了国产 AI 硬件在高性能推理领域的潜力，推动了软硬件生态的协同发展。
- 开源贡献：通过开源 xLLM 框架，降低了企业构建高性能推理系统的门槛，促进了社区在调度策略、显存管理和多模态推理等领域的创新。
- 未来方向：计划进一步向"AI 原生操作系统”演进，支持更多样化的硬件生态、更广泛的模型类型（如文生图/视频），并提供更完善的 AI 应用开发工具链。
总结：xLLM 不仅仅是一个推理加速工具，而是一个面向企业级大规模服务的完整推理系统。它通过解耦架构、智能调度和底层算子优化，有效解决了当前大模型落地中的性能、成本和稳定性痛点，具有极高的工程价值和学术参考意义。