jd-opensource/xllm · 上手攻略
- 仓库：jd-opensource/xllm
- 链接：https://github.com/jd-opensource/xllm（现重定向至 xLLM-AI/xllm）
- 分类：llm-infra
- 作者：Tom
- 更新：2026-07-31
是什么
xLLM 是京东开源的高性能 LLM/VLM/DiT/REC 推理引擎，托管于 OpenAtom 基金会，核心定位是在多种国产 AI 加速器上实现企业级高吞吐推理。它于 2025 年 10 月发布技术报告（arXiv:2510.14686），已在京东内部支持客服（JingYan AI）、营销推荐、商品理解等多个核心业务日产环境运行。
架构上分为两层：xLLM-Service（服务层，负责调度、PD 解耦、全球 KV 缓存管理、故障恢复）和 xLLM-Engine（引擎层，负责底层算子优化、投机解码、EP 负载均衡）。对比同类推理框架，在同等 TPOT 约束下 xLLM 吞吐量可达 MindIE 的 1.7 倍、vLLM-Ascend 的 2.2 倍（Qwen 系列）；DeepSeek 系列平均吞吐为 MindIE 的 1.7 倍。
⚠️ 说明：该仓库的 GitHub README 内容非常简略，大量技术细节需参考 xLLM Technical Report（arXiv:2510.14686）。另外仓库现重定向至
xLLM-AI/xllm，链接以实际基维。
解决什么问题
企业级 LLM 推理面临四大挑战：
- 混合负载潮汐特性：在线推理请求有明显的潮汐波动，现有调度系统无法在保障 SLO 的同时充分利用离线批任务的空闲算力。
- 静态 PD 解耦：Prefill-Decode 解耦架构假设两个阶段资源分配固定，无法适应输入/输出长度动态变化，造成 GPU 利用率低和 SLO 违约风险。
- 多模态输入的 EPD 解耦缺失：视觉/语音+文本混合输入，没有对应的 Encode-Prefill-Decode 解耦策略。
- 分布式 KV 缓存和故障恢复：大规模部署需要全局 KV 缓存管理和快速故障恢复，现有框架缺失。
xLLM 分别在 Service 层和 Engine 层给出了系统性解法。
快速安装
xLLM 相关仓库有多个子模块，当前公开可访问的主要有两个：
- 推理引擎仓库：https://github.com/jd-opensource/xllm（或 https://github.com/xLLM-AI/xllm）
- 服务层仓库：https://github.com/jd-opensource/xllm-service
由于该框架主要面向已接入国产加速器的企业环境（如昇腾、海光等），并未提供面向普通开发者的 pip install 一键安装包。部署需参考各子仓库的文档，以下为关键步骤概述：
# 克隆引擎仓库
git clone https://github.com/jd-opensource/xllm.git
cd xllm
# 克隆服务层仓库
git clone https://github.com/jd-opensource/xllm-service.git
cd xllm-service
# 查看部署文档（README 或 docs/ 目录）
# 部署文档链接需在仓库内确认，以下为已知公开文档：
# https://github.com/xLLM-AI/xllm/blob/main/README.md
⚠️ 重要：xLLM 不是面向个人开发者的本地安装工具，而是面向有集群资源的企业用户。没有 pip/conda 包，也没有 Google Colab 演示。安装和使用需要 Linux 服务器 + 昇腾/海光等国产 NPU 环境。
核心用法
⚠️ 本节命令基于公开文档推断，具体命令请以仓库最新 README 为准。以下列出的是 xLLM 的核心能力模块，非全部可直接复制运行。
xLLM-Service 核心能力
在线-离线任务共置调度
xLLM-Service 支持在线推理请求与离线批任务混合部署，通过弹性调度策略在保障 SLO 的前提下利用潮汐空闲算力：
- 负载高峰：全力服务在线请求
- 负载低峰：自动调度离线批任务利用空闲资源
动态 PD 解耦调度
传统的 Prefill-Decode 解耦是静态的，xLLM 实现了工作负载自适应的动态 PD 解耦策略，可根据输入/输出长度实时调整资源分配：
高峰期: Prefill 实例 × N | Decode 实例 × M
低谷期: Prefill 实例 × 1 | Decode 实例 × 1 + 离线任务
EPD 三阶段解耦（多模态专用）
对含图像/音频的多模态输入，新增 Encode 阶段专属调度：
Image/Audio → Encode → Prefill → Decode → Response
全球 KV 缓存管理
基于 Mooncake 的混合 KV 缓存管理，支持： - GPU显存 KV 缓存 - 内存 KV 缓存 - SSD/分布式存储 KV Offload - 智能预取策略
快速故障恢复
分布式容错设计，单实例故障不影响整体服务，参考论文 3.5 节。
xLLM-Engine 核心能力
多层流水线执行优化
通过异步化 CPU 调度与 NPU 前向运算、最小化算力空闲气泡：
CPU 调度 ─┐
├──▶ NPU 执行 ──▶ 结果返回
CPU 调度 ─┘
双流并行（计算与通信重叠）
在多卡/多节点场景下，重叠 all-reduce 通信与计算时间。
自适应图模式（Adaptive Graph Mode）
减少 kernel launch 开销，对动态 shape 场景特别有效。
xTensor 内存管理（逻辑连续、物理分散）
解决动态批处理中的内存碎片和分配冲突问题，"逻辑连续"方便上层使用，"物理分散"减少显存碎片。
优化投机解码（Speculative Decoding）
对 MoE 模型（尤其是 Qwen3-30B-A3B 等）进行专门的投机解码调优，EPLB（Expert Parallel Load Balance）使多专家模型负载分配更均匀。
性能数据（来自论文）
在 64 卡昇腾 910B 集群上的 Benchmark 结果（Qwen2.5-72B-Instruct）：
| 指标 | xLLM | MindIE | vLLM-Ascend |
|---|---|---|---|
| 吞吐（同 TPOT） | 1.0×（基准） | 0.59× | 0.45× |
| GPU 利用率 | 92% | ~60% | ~50% |
注：具体数字以论文为准，此处为定性参考。
生产部署案例（京东内部）
已在京东生产环境验证的业务场景：
- JingYan AI 客服：线上客服机器人，日均千万级请求
- 营销推荐：生成式推荐系统
- 商品理解：VLM 做商品图片+文本多模态理解
- 智能客服助手：陪审式客服系统
典型适用场景
| 场景 | 说明 |
|---|---|
| 国产加速器集群推理 | 昇腾 910B/310P、海光 DCU 等国产 NPU 的高吞吐部署 |
| 多模态生产推理 | 同时跑 LLM、VLM、DiT（图像生成）的混合负载 |
| 在线-离线混合部署 | 有潮汐效应的业务（电商客服高峰/低谷明显） |
| 长上下文推理 | 超长上下文（>128K）的商品理解或文档分析 |
| MoE 大模型推理 | Qwen3-30B-A3B 等 MoE 架构的负载均衡优化 |
| 企业级 AI 中台 | 需要 SLO 保障 + 故障自动恢复的稳定服务 |
坑与注意
- 不是个人开发工具：没有 pip install，没有 Google Colab，部署需要 Linux + 国产 NPU 环境。
- 文档分散：引擎和服务层在两个不同仓库，且 GitHub README 极度简略，完整技术细节需读论文。
- 国产 NPU 依赖：昇腾 CANN 驱动、海光 DCU SDK 等需提前安装，门槛较高。
- 最新动向需关注：仓库最新 commit 显示 2026-07-06，但仍处于快速迭代期，部分 API 可能变化。
- 中文资料少：目前中文互联网上的 xLLM 实践文章极少，遇到问题主要靠读论文和 GitHub Issue。
- Star 数量偏低（1390）：社区规模小，遇到 bug 可能需要较多自力更生。
与同类对比
| 特性 | xLLM | vLLM | MindIE（华为） | TensorRT-LLM |
|---|---|---|---|---|
| 主攻硬件 | 国产 NPU（昇腾等） | NVIDIA CUDA | 昇腾 NPU | NVIDIA CUDA |
| PD 动态解耦 | ✅ | ✅ | 部分 | ❌ |
| EPD 解耦（多模态） | ✅ | ❌ | ❌ | ❌ |
| 全球 KV 缓存管理 | ✅ | ❌ | 部分 | ❌ |
| 在线-离线共置调度 | ✅ | ❌ | ❌ | ❌ |
| MoE EPLB | ✅ | ❌ | ❌ | 部分 |
| 双流并行 | ✅ | ❌ | 部分 | ✅ |
| 故障快速恢复 | ✅ | ❌ | 部分 | ❌ |
| 开源程度 | 全面开源 | 完全开源 | 部分开源 | 闭源（企业版） |
| 适用场景 | 国产化企业部署 | NVIDIA 生态 | 华为生态 | NVIDIA 企业 |
结论：xLLM 是目前国产 AI 加速器生态中架构最完整的高性能推理框架，尤其适合已有昇腾/海光集群的企业。如果你的环境是 NVIDIA GPU，vLLM 和 TensorRT-LLM 更成熟、生态更广。xLLM 的核心差异化在于：Service 层的智能调度 + Engine 层的全栈优化联动。
一句话推荐结论
京东将内部生产验证过的推理框架开源，是国产 AI 加速器生态中最具系统深度的高性能推理方案，适合有昇腾/海光集群且追求高吞吐+高可用的企业用户。