xLLM：京东开源的大模型推理引擎，瞄准国产AI加速卡

背景：电商巨头的AI推理之战

2025年双十一，京东每秒处理超过50万次商品推荐查询，每一次背后都有大语言模型的推理支撑。当全球目光聚焦在 NVIDIA H100 的算力神话时，很少有人注意到中国电商巨头京东已经悄然打磨出一套自研推理引擎，并在2025年10月发表技术报告、2026年7月正式将项目捐赠给开放原子开源基金会——它就是 xLLM。

这个项目并非从零起步的学术玩具，而是诞生于京东零售核心业务的生产级系统，支撑着AI客服、商品推荐、供应链优化等日均数十亿次调用的业务场景。选择开源，是因为京东希望推动国产AI芯片生态——项目名称中的"x"代表多样化（multi-accelerator support），目标是在华为昇腾NPU、寒武纪MLU、摩尔线程S5000、海光DCU等多种国产芯片上实现对标甚至超越国际主流框架的推理性能。

核心功能：三层架构拆解

xLLM 采用业界领先的解耦式服务-引擎双层架构，这是它区别于 vLLM、TGI 等单层推理框架的核心差异。

xLLM-Service（服务层） 负责请求调度与可用性保障。其中的核心组件包括：

• 智能调度器：动态优先级队列，支持在线/离线任务混合调度，根据请求的时延敏感度自动分配计算资源。这解决了一个实际痛点——推荐系统的离线批量任务与在线实时查询抢资源时，传统固定优先级方案往往顾此失彼，xLLM 的弹性调度让两者共存于同一集群而互不干扰。
• PD/EPD 解耦策略：Prefill-Decode 分离（PD Disaggregation）将模型推理的预填充阶段（计算密集）与解码阶段（内存密集）分配到不同硬件资源；进一步提出 Encode-Prefill-Decode（EPD）解耦，为多模态输入（图像+文本）设计的更细粒度分离方案，避免视频/图像编码与文字生成之间的资源争抢。
• 全局 KV Cache 管理：集成 Mooncake 的分布式 KV Cache 能力，支持多级缓存与智能预取，在多卡推理场景下避免重复计算同一上下文的 Key-Value。

xLLM-Engine（引擎层） 专注于计算效率最大化：

• 多级执行流水线：从模型图层的算子融合、kernel 层的计算与内存访问重叠，到张量层面的异步并行，将 GPU 利用率压榨到接近硬件极限。
• 自适应图模式：静态图适合已知的标准模型结构，动态图适合变长输入与条件分支，xLLM 根据模型特征自动选择最优执行模式。
• 投机解码（Speculative Decoding）：小模型预测大模型下一步输出，提前批量验证，在保持输出质量的同时将解码速度提升2-3倍。
• 动态 EPLB（Expert-Level Load Balancer）：针对 MoE（混合专家）架构中各专家负载不均的问题，动态调整计算图，使稀疏激活的专家得到均衡利用。

技术特性一览

xLLM 支持的模型范围极广，按场景可分为四大类：

• LLM：Qwen（Qwen2.5/Qwen3）、GLM（GLM-4/GLM-5）、DeepSeek（V3/V4）、MiniMax-M3 等主流开源模型，提供 day-0 支持（即模型发布当天即完成适配）。
• VLM（视觉语言模型）：GLM-4.6V、VLM-R1 等图像+文本多模态推理。
• DiT（扩散Transformer）：图像/视频生成背后的骨干网络推理加速。
• REC（推荐模型）：京东核心业务场景，LLM 化推荐推理。

在硬件加速方面，项目针对国产芯片做了深度优化：华为昇腾 NPU（A2/A3）、寒武纪 MLU、摩尔线程 MUSA S5000、海光 DCU（BW1000）、沐曦 MACA（MXC500）、芯动 ILU（BI150）——几乎覆盖了国内主要的 AI 芯片玩家。这意味着部署者可以在昇腾服务器上跑 Qwen，也可以在摩尔线程上跑 DeepSeek，而无需修改上层代码。

依赖技术栈上，xLLM 大量借鉴了开源社区的成熟组件：底层 Runtime 执行参考了 ScaleLLM，全局 KV Cache 基于 Mooncake 构建，HTTP 服务层使用 Apache brpc（百度开源的高性能 RPC 框架），分词器使用 MLC-AI 的 tokenizers-cpp，模型权重加载则依赖 Hugging Face 的 safetensors C binding。

快速上手

xLLM 提供了完整的 Docker 镜像，支持 CUDA 12.8 环境下的快速验证。由于是 CMake 构建系统，需要从源码编译，依赖包括 CUDA、cuDNN、PyTorch 等，开发者在 Docker 环境中可以避免繁杂的本地环境配置。

核心推理服务通过 Python API 调用，支持流式输出（Streaming）与批量推理两种模式。服务端基于 C++ 实现，通过 pybind 与 Python 层桥接，兼顾开发效率与运行性能。

示例代码展示了纯 Python 调用接口的简洁性：加载模型、构造输入、调用推理——三步完成一次完整推理，对习惯了 PyTorch 风格的开发者非常友好。

现有限制与挑战

xLLM 的定位是高性能生产级推理引擎，因此上手门槛较高：

• 无 Web UI：完全面向开发者与运维人员，需要通过 Python 脚本或 API 调用来操作。
• 编译依赖复杂：CMake + CUDA + cuDNN + PyTorch + 国产 NPU SDK 的组合，在非 Docker 环境下配置难度极大。
• 文档尚在完善中：核心文档为英文，但中文社区活跃度较高（微信公众号），GitHub 文档站点（docs.xllm-ai.com）仍在快速迭代。
• 硬件依赖性强：项目以国产芯片优化为核心卖点，在纯 NVIDIA 环境下的性能优势可能不明显。

行业意义

xLLM 的出现填补了国产 AI 推理框架的一个关键空白——不是做另一个 vLLM，而是针对多硬件共存的国产算力生态设计的推理基础设施。随着开放原子开源基金会的托管，项目获得了更大的社区治理可信度，未来有望成为国产芯片厂商对接上层模型的统一推理底座。

从增长数据看，项目在 GitHub 上保持稳定活跃，核心开发来自京东零售技术团队，持续跟随主流开源模型做 day-0 支持，这对于企业级用户来说是重要的稳定性保障。

图1：xLLM 项目 Logo（来源：GitHub 仓库）

图2：xLLM 服务-引擎双层架构图（来源：GitHub 仓库）

图3：xLLM 开源贡献者图谱（来源：contrib.rocks）