Intel PyTorch 团队详解基于 Xeon 6 CPU 与 SGLang 低成本部署 DeepSeek R1

DeepSeek R1 的出色表现标志着大型语言模型（LLM）中巨型混合专家（MoE）模型的崛起。然而，其庞大的模型规模和独特的架构给部署带来了新的挑战。巨大的内存需求通常需要 8 块甚至 16 块高端 AI 加速器才能部署。

Intel PyTorch 团队在过去几个月中为 SGLang 贡献了 CPU 后端，我们提出了一种仅使用第六代英特尔® 至强® 可扩展处理器的纯 CPU 高性能解决方案，成本仅为很小一部分。在这篇博客中，我们解释了在单节点上使用至强® 6 CPU 高效部署 DeepSeek 的技术细节。

亮点

• SGLang 现已在英特尔® 至强® CPU 上支持原生 CPU 后端，并利用英特尔® 高级矩阵扩展（AMX）。
• 支持 BF16、INT8 和 FP8，适用于稠密 FFN 和稀疏 FFN（MoE）。
• 与 llama.cpp 相比，TTFT 实现 6-14 倍加速，TPOT 实现 2-4 倍加速。
• 通过高度优化的 MoE 内核，实现 85% 的内存带宽效率。
• 通过张量并行（TP）实现多 NUMA 并行。

CPU 优化策略

在这篇博客中，我们将解释内核级优化的技术细节，包括任务划分策略、内存访问效率以及有效利用英特尔® AMX 实现高度优化的 GEMM 实现。 本节聚焦于 4 个性能热点：Extend Attention 和 Decode Attention，它们是 SGLang 中 RadixAttention 的后端；MoE，它贡献了 DeepSeek R1 中的大部分权重；以及 FP8 GEMM，我们在没有原生 FP8 支持的现有 x86 平台上采用了模拟方法。

Extend Attention

我们基于 RadixAttention 的接口实现了一个使用英特尔® AMX 的原生 C++ 后端，它包含两个主要组件：a) Extend Attention，处理多头注意力（MHA）的预填充阶段；b) Decode Attention，用于解码阶段。以 GPU 内核为参考，我们将 flash attention 算法映射到 CPU 内建函数，如下图所示 Fig-1：

为了消除冗余计算，SGLang 将查询序列分为两部分：

• prefix – 历史序列，其中注意力为矩形；
• extend – 新添加的提示，其中注意力为下三角。

CPU 内核精确映射到 Flash Attention V2 算法，我们仔细选择 Query 序列和 KV 序列的块大小，以确保注意力 Si 和动量 mi、S* 的中间值适合 L1/L2 缓存。GEMM 部分由 AMX 计算，Block Pointwise OPs 由 AVX512 计算。由于 AMX 在 FP32 中进行累加（例如 A: BF16；B: BF16；C: FP32），我们将数据类型转换与动量更新融合，保持 Si 为 FP32（第一个 GEMM 的结果），S∆ 为 BF16（第二个 GEMM 的输入），在实现高计算效率的同时将舍入误差降至最低。

Decode Attention

与预填充相比，解码在并行化方面面临更大压力，因为查询序列长度缩减为一。具体而言，在多头注意力中，我们可以在[Batches, Heads, qBlocks]的维度上并行化内核，而对于单请求解码，这将简化为[1, Heads, 1]，导致并行度不足。我们实现了Flash Decoding算法，将KV序列分块为多个拆分以增加并行度，如图-2所示。该实现分两个阶段完成：首先计算每个KV拆分的注意力；然后将所有拆分的中间结果归约为最终输出。

多头潜在注意力（MLA）优化

MLA是DeepSeek系列模型的核心特性之一。除了Flash Decoding之外，我们在MLA CPU实现上提供了几项关键优化。我们参考了FlashMLA，它利用了键和值共享同一张量存储这一事实，并将内存加载与计算流水线化。

• 一次加载，两次打包：AMX要求瓦片数据采用VNNI格式，此外键和值需要以不同方式打包，因为第一个GEMM是NT而第二个GEMM是NN。我们实现了完全向量化的打包逻辑，如图-3所示，KV缓存通过2个带预取的LUT获取；每加载32个通道（BLOCK_N等于32），同时打包到两个线程本地中间缓冲区中，一个用于以[E/2, BLOCK_N, 2]格式存储的键，另一个用于以[BLOCK_N/2, Ev, 2]格式存储的值。
• 头折叠：MLA在解码阶段采用权重吸收，这将键和值的头数都减少为1。因此，我们可以将头维度折叠进GEMM以提高计算强度，如下所示。并且我们在分块头维度时平衡了并行度：对于DeepSeek R1中头维度为22的情况，我们对单请求使用BLOCK_SIZE 6，并随着请求增多逐渐增加到22。

总体而言，MLA上的内核级优化相比原始实现提供了约1.9倍的性能加速。值得注意的是，我们还将KV缓冲区设置与解码内核融合，这带来了12%的提升，因为它消除了torch中的若干低效之处：用于索引的隐式数据类型转换、为切片张量创建TensorImpl，以及使用TensorIterator进行映射复制等。

MoE

使用torch的朴素MoE实现会依次循环遍历专家，并在线性投影之前为每个专家收集（掩码）激活。为了提高效率，一种常见策略是对激活的索引进行排序并将它们分块。我们遵循了SGLang上现有GPU内核的实现，如图-4所示，在topk_ids上运行argsort，并根据专家ID将激活的索引保留在sorted_ids中。

我们为CPU内核做了几项额外优化：

• SiLU融合：为了融合up_proj和SiLU，我们实现了以A×[B1, B2]=[C1, C2]模式运行的GEMM内核。利用左半部分的B1和右半部分的B2，我们可以将SiLU(C1 ) * C2融合在一起，消除对up_proj输出的额外加载/存储。
• 动态量化融合：在我们为 MoE 设计的 INT8 动态量化内核中，我们将从 BF16 到 UINT8 的量化与激活值的获取融合在一起。我们实现了 AVX512 和 AMX 两种内核，并根据输入配置在两者之间进行选择。与同时支持 U8S8 和 S8S8 的 AMX 不同，AVX512-VNNI 仅支持 U8S8（A 为 UINT8，B 为 INT8），我们不得不做出妥协，将权重对齐到 U8S8 模式，这意味着需要一个补偿因子 -128×B 来将 S8S8 转换为 U8S8：A × B=(A + 128) × B - 128 × B。

结合这些优化，我们在 INT8 MoE 上实现了 85% 的内存带宽效率，即在多路复用秩双列直插内存模块（MRDIMM）上实现了 1.45TB/s 的有效内存带宽。

FP8 推理

DeepSeek R1 采用 FP8 混合训练，这对 CPU 设备来说是一个巨大的挑战，原因很明显：现有的 x86 设备不原生支持 FP8。然而，提供 FP8 支持至关重要，因为它代表了原始的用户体验。我们针对 FP8 MoE 和 GEMM 做了几项优化：

• 仅权重量化 FP8：我们对 FP8 MoE/GEMM 采用了仅权重量化的模式，即将 FP8 转换为 BF16（与激活值相同），然后进行计算。
• 高效向量化转换：从 FP8 到 BF16 的数据类型转换是 CPU 上的主要性能瓶颈，我们尝试了两种方法：a) 从 2^8 表中收集 BF16 数据的查找表；b) 内建函数向量化转换。值得注意的是，两种方法的速度同样慢，需要 60 到 70 个周期才能完成，对于任何性能关键场景都是不可接受的。我们对方法 b) 做了权衡，跳过了 NaN 检查和 DENORM 处理，这将转换时间减少了一半。
• 感知 WOQ 的缓存分块：为了将数据类型转换开销降至最低，我们在 GEMM 期间从缓存分块中的 WOQ 进行权重解包。具体来说，对于分配给每个线程的每个权重块，我们以之字形模式访问权重块，并将解包后的 BF16 块缓存在 L2 中，确保每个块缓慢的数据类型转换只发生一次。 我们在 GSM8K 和 MMLU 上进行了验证，我们模拟的 FP8 实现与 GPU 结果相比给出了相同的准确率。并且通过上述这些优化技巧，FP8 实现达到了 INT8 实现约 80% 到 90% 的性能。

多 NUMA 并行

非统一内存访问（NUMA）是一种用于多处理的计算机内存设计，常见于服务器 CPU 上，其中内存访问时间取决于内存位置相对于处理器的位置。在 NUMA 下，处理器访问自己的本地内存比访问远程内存（另一个处理器的本地内存或处理器之间共享的内存）更快。为了将远程内存访问降至最低水平，我们将多 GPU 的张量并行（TP）映射到 CPU 服务器上的多 NUMA。

我们还基于共享内存方法实现了通信原语，例如 all reduce、all gather，跳过了使用带有繁琐调用栈的 torch.distributed。总体而言，通信开销仅占端到端时间的 3%。

评估

我们的测试平台是一台最先进的双路 Intel® Xeon® 6980P CPU 服务器，每个插槽 128 核。我们采用另一个流行的 LLM 工具 llama.cpp 作为性能基线，与 SGLang CPU 后端进行对比。我们评估了 4 个模型，范围从 3B 到 671B：DeepSeek-R1-671B、Qwen3-235B、DeepSeek-R1-Distilled-70B 和 Llama3.2-3B。

基准测试说明：

• 插槽设置：我们对 Llama3.2-3B 使用单插槽，对其他三个模型使用双插槽，因为在双插槽上运行 3B 小型 LLM 会导致性能下降。
• Sub-NUMA Clustering (SNC) 设置：SGLang 数据在 SNC 开启时采集，llama.cpp 数据在 SNC 关闭时采集，因为 llama.cpp 在 SNC 开启时无法保证本地 NUMA 访问。
• 多实例：由于 llama.cpp 未实现我们上面提到的 Multi Numa Parallelism，在双插槽上运行 1 个实例甚至比在单插槽上更慢。为公平起见，我们在双插槽上为 llama.cpp 使用 2 个实例，每个插槽 1 个，并采集 TTFT 和 TPOT 指标。
• 基线数据类型：我们将 INT8 与 GGUF Q8 格式进行比较。由于 llama.cpp 没有针对 FP8 优化，我们也将 FP8 与 GGUF Q8 进行比较。

表 1：SGLang 与 llama.cpp 的性能评估

(Request=1, INPUT/OUTPUT=1024/1024)

详细分解

• TTFT 实现了 6-14x 的性能加速。MoE 模型的提升更大，因为在 llama.cpp 中专家是顺序计算的，而我们通过重新对齐专家索引在专家之间并行计算。
• TPOT 实现了 2-4x 的性能加速。由于解码阶段往往受内存带宽限制，TPOT 的加速比远小于 TTFT。
• 总体而言，我们模拟的 FP8 实现已经在硬件能力范围内达到了最佳效率。

局限性与未来工作

虽然我们目前在 SGLang CPU 后端上的工作展示了显著的吞吐量提升，但仍存在若干局限性和未来增强的领域：

• 图模式启用：当并发请求数量较低时，Python 开销占据了相当大的一部分时间，我们正在尝试通过图模式配合 torch.compile 来消除 Python 开销。初步结果表明 TPOT 额外提升了 10%，该工作仍在进行中。
• 数据并行 MLA：当前的 Multi Numa Parallelism 遵循 Tensor Parallel 模式，这会导致不同 rank 中对 KV cache 的重复访问，GPU 上已经存在一种利用 DP Attention 的更高效解决方案。
• GPU/CPU 混合执行：KTransformers 创新性地使用混合执行模式进行大型 MoE 模型推理，其中 MoE 层在 CPU 上运行，Attention 层在 GPU 上运行。我们正在 SGLang 上试验类似的方法，并进一步将来自异构硬件的计算阶段流水线化。

总结

在这篇博客中，我们解释了基于 SGLang 实现仅 CPU 部署高性能的技术细节。这项工作已完全开源并合入 SGLang 主分支。我们将继续为 CPU 后端以及其他英特尔® 平台带来更多性能优化。

致谢

在 SGLang 中启用和优化英特尔® 至强® 是一个重要的里程碑，为业界提供了 LLM 推理的新替代方案，这离不开社区的深度协作与贡献。

我们衷心感谢：

• SGLang 核心团队与社区贡献者：Yineng Zhang、Jiexin Liang、Mick、Thien —— 感谢他们分享宝贵的想法、细致地审阅 PR、对 RFC 提供富有洞见的反馈，以及扎实的代码贡献。
• KTransformers 团队：Mingxing Zhang —— 感谢他分享关于 GPU/CPU 混合执行的见解与创新想法。

此外，作为英特尔 PyTorch 团队，我们迎难而上，为这项任务贡献力量：Mingfei Ma、Chunyuan Wu、Yanbing Jiang、Guobing Chen、Beilei Zheng、Jianan Gu、Zaili Wang、Hengyu Meng、Weiwen Xia、E Cao、Mingxu Zhang、Diwei Sun。

附录

相关 RFC 与 PR

#2807, #5150, #6216, #6339, #6404, #6405, #6408, #6419, #6452, #6456, #6458, #6493, #6549, #6614, #6641, #6657, #6769, #6770, #6771, #6833, #7390, #7462, #7486, #7647, #7818, #7838, #7885.

安装带 CPU 后端的 SGLang

# Clone the SGLang repository
git clone https://github.com/sgl-project/sglang.git
cd sglang/docker
 
# Build the docker image
docker build -t sglang-cpu:main -f Dockerfile.xeon .
 
# Initiate a docker container
docker run \
    -it \
    --privileged \
    --ipc=host \
    --network=host \
    -v /dev/shm:/dev/shm \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 30000:30000 \
    -e "HF_TOKEN=<secret>" \
    sglang-cpu:main /bin/bash

使用 CPU 后端运行 SGLang

# Launch_server cmd:
# DeepSeek-R1-671B INT8:
SGLANG_CPU_OMP_THREADS_BIND='0-42|43-85|86-127|128-170|171-213|214-255' python3 -m sglang.launch_server --model meituan/DeepSeek-R1-Channel-INT8 --trust-remote-code --device cpu --disable-overlap-schedule --quantization w8a8_int8 --disable-radix-cache --tp 6 --mem-fraction-static 0.8 --max-total-tokens 63356
# DeepSeek-R1-671B FP8:
SGLANG_CPU_OMP_THREADS_BIND='0-42|43-85|86-127|128-170|171-213|214-255' python3 -m sglang.launch_server --model deepseek-ai/DeepSeek-R1 --trust-remote-code --device cpu --disable-overlap-schedule --disable-radix-cache --tp 6 --mem-fraction-static 0.8 --max-total-tokens 63356
# Qwen3-235B-A22B-INT8:
SGLANG_CPU_OMP_THREADS_BIND='0-42|43-85|86-127|128-170|171-213|214-255' python3 -m sglang.launch_server --model Qwen3-235B-A22B-INT8 --trust-remote-code --device cpu --disable-overlap-schedule --quantization w8a8_int8 --disable-radix-cache --tp 6 --mem-fraction-static 0.8 --max-total-tokens 63356
# Qwen3-235B-A22B-FP8:
SGLANG_CPU_OMP_THREADS_BIND='0-42|43-85|86-127|128-170|171-213|214-255' python3 -m sglang.launch_server --model Qwen/Qwen3-235B-A22B-FP8 --trust-remote-code --device cpu --disable-overlap-schedule --disable-radix-cache --tp 6 --mem-fraction-static 0.8 --max-total-tokens 63356
# RedHatAI--DeepSeek-R1-Distill-Llama-70B-quantized.w8a8:
SGLANG_CPU_OMP_THREADS_BIND='0-42|43-85|86-127|128-170|171-213|214-255' python3 -m sglang.launch_server --model RedHatAI/DeepSeek-R1-Distill-Llama-70B-quantized.w8a8 --trust-remote-code --device cpu --disable-overlap-schedule --quantization w8a8_int8 --disable-radix-cache --tp 6 --mem-fraction-static 0.8 --max-total-tokens 63356
# meta-llama--Llama-3.2-3B-Instruct:
SGLANG_CPU_OMP_THREADS_BIND='0-42|43-85|86-127' python3 -m sglang.launch_server --model meta-llama/Llama-3.2-3B-Instruct --trust-remote-code --device cpu --disable-overlap-schedule --disable-radix-cache --tp 3 --mem-fraction-static 0.8 --max-total-tokens 63356
# Serving cmd:
python3 -m sglang.bench_serving --dataset-path ShareGPT_V3_unfiltered_cleaned_split.json --dataset-name random --random-input 1024 --random-output 1024 --num-prompts 1 --request-rate inf --random-range-ratio 1.0 --max-concurrency 1 --host 127.0.0.1 --port 3000

[注意]：当前的 CPU 原生后端仅支持具备英特尔® AMX 支持的 CPU，其他 x86 平台预计性能较慢。

产品与性能信息

在 Intel(R) Xeon(R) 6980P 上测量，HT 开启，Turbo 开启，NUMA 6，集成加速器可用 [已使用]：DLB [8]、DSA [8]、IAA[8]、QAT[on CPU, 8]，总内存 1536GB（24x64GB DDR5 12800 MT/s [8800 MT/s]），BIOS BHSDCRB1.IPC.3544.D02.2410010029，微码 0x11000314，CentOS Stream 9，由英特尔于 2025 年 7 月 7 日测试。

声明与免责声明

性能因使用情况、配置和其他因素而异。请在性能指数网站了解更多信息。性能结果基于所示日期在特定配置下的测试，可能无法反映所有公开可用的更新。有关配置详情，请参见备份。没有任何产品或组件能够绝对安全。您的成本和结果可能有所不同。英特尔技术可能需要启用硬件、软件或服务激活。 Intel Corporation。Intel、Intel 标识及其他 Intel 标志是 Intel Corporation 或其子公司的商标。其他名称和品牌可能被主张为他人的财产。