截至 2026-05-28 UTC，理解 xLLM 的有效路径，是把它放在中国模型竞赛与硬件约束交汇的运行时层。若只把它看成又一个带有本地标识、试图复刻 vLLM 的推理框架，就会错过更尖锐的 AI-China 信号。京东在这一层开源了一个具有生产形态的运行时。xLLM 自己的 README 将其描述为一个面向 Chinese AI accelerators 优化的高效 LLM 推理框架，具备服务-引擎解耦架构、动态 PD 分离、混合多模态与高可用机制、图融合、投机推理、动态负载均衡和全局 KV cache 管理。[1]
这套措辞之所以重要，是因为加速器问题经常被压缩成一个过于简单的提问：中国有没有足够多的芯片，这些芯片与 NVIDIA 相比处在什么位置。对开发者而言，下一层问题更加具体。严肃的模型工作负载能否在国产硬件上运行，并同时获得稳定延迟、可用的内存行为、模型兼容性与生产故障处理能力。xLLM 释放出的信号是，答案同样取决于服务软件，而芯片供给只是其中一部分。[1][2]
图片语境：封面使用 Wikimedia Commons 上真实的数据中心服务器机柜照片，未使用生成式插图或示意图。本文讨论的是 AI 部署的机房层：请求调度、加速器适配、内存迁移与服务可靠性。[6]
运行时是芯片政策进入工程现场的位置
xLLM 的公开材料不断指向模型卡片之下的层面。项目称它支持在中国 AI 加速器上部署 DeepSeek、Qwen 等主流大模型，并称其已经部署在京东真实零售业务中，包括智能客服、风险控制、供应链优化和广告推荐。[1] 这些是一方说法，应当作为产品证据处理，尚未构成中立的采用证明。即便如此，它们仍然清楚界定了目标运行环境：面向密集企业流量的生产系统，研究演示不在这个中心位置。
重要的设计选择，是服务与引擎之间的分离。在服务层，xLLM 强调面向在线与离线请求的弹性调度、动态 prefill/decode 分离以及高可用机制。在引擎层，它列出多流并行计算、图融合优化、投机推理、负载均衡和全局 KV cache 管理。[1][2] 这道分层就是主线。国产加速器栈需要同时处理流量的外部形态与执行的内部形态。任一侧出现脆弱环节，模型层面的标题都会在生产接触中失去支撑。
这也解释了为什么 xLLM 作为场域信号比作为基准测试对象更值得观察。基准测试可以说明某个模型在某组提示下以某种速度提供服务。运行时则要回答更棘手的问题：上下文长度变化时会怎样，MoE experts 失衡时会怎样，prefill 与 decode 拥有不同瓶颈时会怎样，VLM 请求把图像处理与文本生成混在一起时会怎样，KV cache 需要在节点之间迁移时会怎样，一个服务同时承载实时需求与批处理需求时会怎样。[1][2][4]
硬件表就是信息本身
supported-models 页面把国产硬件策略写得很明确。xLLM 列出了跨 NPU、MLU 与 ILU 通道的支持情况，模型覆盖包括 DeepSeek-V3/R1/V3.1、DeepSeek-V3.2、Qwen2/2.5/QwQ、Qwen3、Qwen3 MoE、Kimi-k2、Llama2/3、GLM4.5、GLM4.6、GLM-4.7 和 GLM-5，并呈现为不同硬件组合。[3] 对视觉语言模型，它列出 MiniCPM-V、MiMo-VL、Qwen2.5-VL、Qwen3-VL、Qwen3-VL-MoE、GLM-4.6V 和 VLM-R1，同样采用硬件列的组织方式。[3]
这里要读的，是兼容性矩阵本身已经成为战略性物件；各模型在各设备上的覆盖差异，说明部署问题已经进入运营层。中国企业若试图降低对单一硬件供应商的依赖，部署问题就会变成跨加速器家族的路由问题。有些工作负载落在 Ascend-class NPUs 上，有些落在 MLU 设备上，有些落在 ILU 设备上，还有一些继续落在 CUDA 上。一个把这件事呈现为模型-硬件支持表的运行时，所做的工作已经超出功能罗列。它正在把可移植性转化为运营计划。[3]
v0.9.0 发布说明强化了这种读法。该版本在 NPU 上新增了对 GLM-5、GLM4.7-Flash、Qwen3-next、OneRec、Qwen3.5 和 Qwen3.5-MoE 的模型支持；在 CUDA 上新增 LongCat 图像模型；在 MLU 上新增 DeepSeek-V3.2 和 GLM-5 变体；在 ILU 上新增 Qwen3 模型。它还列出 CANN 8.5 与 PyTorch 2.7.1 适配、NPU 上 VLM LLM 组件的图模式、面向 NPU DeepSeek-V3.2 与 GLM-5 的上下文并行、可扩展多模型服务、remote-to-local KV cache transfer、Anthropic Messages API 支持，以及统一请求统计日志。[4]
这组发布内容说明工作真正落在何处。难点已经超出“支持 Qwen”或“支持 DeepSeek”。持续变化的模型家族、加速器后端、图模式、量化行为、缓存策略、API 与服务计量矩阵，决定了一次部署能否支撑数月运营；数分钟演示无法覆盖这些变量。[4]
xLLM 正加入更宽的 Ascend-serving 层，而不是取代它
阅读 xLLM 时需要把它放在更宽的语境中。vLLM-Ascend 项目作为面向 Ascend NPUs 的专用 vLLM 插件存在，其代码库围绕将 vLLM serving stack 适配到 Ascend 硬件展开自我定位。[5] 这个背景很重要，因为它显示出一个类别正在成形：中国推理栈已经从模型权重加厂商 SDK 的组合，扩展为开放运行时、插件、缓存管理器、图执行器、模型适配器与部署镜像组成的层，将模型需求翻译为加速器工作。[1][4][5]
xLLM 的差异化信号，在于它明确带有公司与工作负载的形状。京东对这个项目的呈现不止是社区运行时。README 把它与零售场景、推荐、风险控制、客服和供应链工作连接起来。[1] 这种垂直压力很重要。零售商的服务栈需要的能力超出 chat completions。它需要峰值下的吞吐、在线与离线混合通道、推荐路径、故障隔离，以及能够向平台团队解释的可观测性。
风险同样清楚。公开的支持矩阵和发布说明，尚未构成广泛第三方生产采用的证明。它们告诉我们项目试图让什么成为现实。清晰的反证路径是，若 xLLM 长期停留为京东内部部署工件，外部 operator 牵引有限，模型适配缓慢，或硬件专用路径碎片化速度超过框架统一速度，那么这一信号就会减弱。
就当前材料看，场域信号已经足够明确。xLLM 显示，AI-China 的基础设施竞赛正在移向运行时边界。下一阶段可持续优势，将来自让许多模型在许多国产设备上运行，并具备合理调度、缓存行为、图执行、API 兼容性与服务可靠性；单纯发布强模型或获得稀缺加速器，都不足以覆盖这个层面的工作。[1][3][4][5]
来源
- JD Open Source，
jd-opensource/xllmGitHub repository README（项目概览、服务-引擎解耦架构、国产加速器定位、京东部署说法、硬件表与核心功能列表）。 - Liu et al.，“xLLM Technical Report,” arXiv:2510.14686（官方 xLLM 代码库链接的技术报告，覆盖设计蓝图与实现细节）。
- xLLM documentation，“Model Support List”（LLM、VLM、rerank、DiT 与推荐模型在 NPU、MLU、ILU 硬件通道上的支持情况）。
- JD Open Source，xLLM release
v0.9.0（2026-04-14；模型支持新增、CANN/PyTorch 适配、图模式、上下文并行、KV cache transfer、API 支持与运行时修复）。 - vLLM Project，
vllm-ascendGitHub repository（面向更宽中国加速器推理生态的 Ascend NPU serving plugin 语境）。 - Wikimedia Commons，“File:Datacenter Server Racks (22370909788).jpg”，作者 Robert from Scotts Valley, California（本文图像所用真实服务器机柜照片的来源页面）。