1. 华为昇腾服务器 DeepSeek V3/R1 推理部署最佳实践 樊玉伟，郑灵超，李勇锋，区晓峰，李 君，Ken Zhang，韩 伟，李 亿 杜霄鹏，王鹏程，刘 杰，董谷音，梁 王鹏宇，赵 毅，王 翔，林 泓，柳伊扬，廖崎臣，高雪健 栋，练韵文，林清扬，陈 吕俊龙，兰龙文，张维熹，丁益斌，高 宇，陶 壮，张 衎，庞西豹 弓，谢冬辉 范港华，范峻逸，胡琤球，李 宝，郑乐文，陈付恺，申智好，金 颖 华为技术有限公司 2025 年 5 月 19 日 摘要 本报告旨在探讨华为昇腾服务器上部署 DeepSeek V3/R1 推理的最佳实践。为满足不同 推理场景的需求，本文提供两种不同的部署形态。第一种是基于华为 CloudMatrix 384 超 节点的大规模 EP 部署策略：为充分发挥 CloudMatrix 384 的独特组网优势，使用其中的 144 张卡作为一个 Decode 实例，以实现较低时延下的高并发，当前已达到了 50ms 时延约 束下每卡输出 1920 Tokens/s。第二种是基于 Atlas 800I A2 服务器的小规模 EP 部署策略： 使用 4 节点 A2 服务器作为一个 Decode 实例，以实现较优吞吐下的灵活部署，当前达到了 100ms 时延约束下每卡输出 723∼808 Tokens/s。 我们采用基于 vLLM 的部署框架，并面向昇腾服务器进行修改以适配 EP/DP/TP 混合 并行策略，同时满足灵活调度和极致性能的需求。模型层面，采用 A8W8(INT8) 的动态量 化方式，并使用 Multi-Token Prediction 技术进行加速。针对昇腾芯片和昇腾服务器组网特 征，从数学上重新审视模型的推理过程，选用了合适的并行方式和计算逻辑，同时还充分利 用了昇腾硬件支持多种多流并发的能力以最大化实现通信/计算/数据搬运的相互掩盖，实 现模型层面的性能极致。算子层面，提出了多种结合数学等价变换、融合算子、缓存复用和 流水掩盖等技术的计算和通信算子的优化方案，使 MLA、MoE 和通信算子达到预期的算 力利用率、访存带宽和通信带宽。 本报告将详细介绍上述两套部署方案，并列出关键的特性和优化技术，更详细的技术细 节之后会陆续公开。 1

2. 目录 1 引言3 2 昇腾服务器和组网5 2.1昇腾芯片. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 2.2Atlas 800I A2 服务器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 2.3CloudMatrix 384 超节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 3 DeepSeek V3/R1 模型部署方案 6 3.1模型与框架配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 3.2Atlas 800I A2 部署方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 3.3CloudMatrix 384 超节点部署方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 框架侧性能优化 14 4.1API Server 扩展技术 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2MoE 模型负载均衡 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 模型侧性能优化 15 5.1模型侧通信优化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2模型侧并发方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3推理投机框架 FusionSpec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6 昇腾算子性能优化 19 6.1MLA 算子优化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2MoE 通信算子优化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7 性能分析 21 7.1Altas 800I A2 性能分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2CloudMatrix 384 超节点性能分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8 下一步工作 25 2

3. 1 引言 DeepSeek V3/R1 作为业界领先的开源大语言模型，已在自然语言处理、代码生成、知识推 理等多个领域展现出卓越的应用价值。DeepSeek 团队于 3 月份推出了迭代版本 DeepSeek V3-0324 [4]， 加 强 其 代 码 和 数 学 能 力， 并 于 4 月 份 发 布 具 备 更 强 数 学 定 理 证 明 能 力 的 DeepSeek-Prover-V2-671B [11]。这两款新的模型与原始 DeepSeek V3 架构完全兼容，仅需进 行参数差异化配置的权重调整，便可实现既有模型部署方案的无缝迁移。这一设计不仅降低了 技术迭代的边际成本，更有效扩大了 DeepSeek V3 系列模型的使用范围。 本报告分享当前在昇腾服务器上高性能 DeepSeek V3/R1 部署方案的最佳实践，包括具体 的部署方案和关键优化特性的简单介绍。关键优化特性的详细报告将于近期陆续发布。 昇腾服务器有多种配置和型号，我们针对近期发布的 CloudMatrix 384 超节点和 Atlas 800I A2 推理服务器两种典型机型进行部署。 为了解耦 Prefill 阶段的首 token 时延约束和 Decode 阶段的解码时延约束，同时希望针 对不同场景选择最优的部署策略和计算流程，我们采用 PD 分离部署的方式。在框架侧，以 vLLM 为基础，针对 DP、EP 和 TP 并行策略做了相应适配，在 KVCache 传输方面采用了灵 衢直联的技术来降低开销，在请求下发、调度策略和框架前后处理等方面做了性能优化，以实 现整个系统的最优性能。模型方面，采用 A8W8(INT8) 的动态量化策略。针对昇腾芯片和昇 腾服务器组网特征，从数学上重新审视模型的推理过程，并综合考虑了数据搬运量、数据通信 量、计算量和内存占用量，选用了合适的并行方式和计算逻辑，有效降低了模型推理过程中的 通信和计算耗时；我们还充分利用了昇腾硬件的多流并发能力，实现通信-计算并发、通信-通 信并发和通信-权重预取并发等多种加速技术，从而做到通信/计算/数据搬运的相互掩盖，实 现模型层面的极致性能。算子方面，我们针对 DeepSeek 模型的特点，提出了多种结合数学等 价变换、融合算子、缓存复用、流水掩盖等技术的极致优化的计算算子和通信算子，特别是在 MLA、MLA 前序计算、Dispatch/Combine 通算融合算子和指令级底层通信调度方面做了深入 的优化，以最大化利用昇腾的算力、访存带宽和通信带宽。 详细的部署方面，由于两种机型定位和配置不同，所以具体部署方案也不尽相同。 3

4. 针对 CloudMatrix 384 超节点，其特殊的组网方式使其具有很高的通信带宽。按照 DeepSeek 的论文 [16] 所述，Decode 部分是严重的通信瓶颈，在 Micro-batch 技术的加持下，几乎可以做 到通信掩盖其他所有计算类操作。而 CloudMatrix 384 的独特组网使得通信耗时大幅降低，可 以有效释放昇腾芯片的算力，具体见第 7.2 节。因此，针对超节点我们采用大规模 EP 并行的 方式来部署：Prefill 使用 16 卡，Decode 使用 144 卡。其中 Decode 部分使用 128 卡通过大规 模 EP 的方式部署路由专家，16 卡通过 DP 的方式部署共享专家，MLA 部分使用 DP 的方式 进行部署。按照类似于 [16] 的分析，超节点可以获得非常高的理论吞吐。实际场景下，由于各 种因素的影响，包括 Decode 时延的约束使得各部分耗时未能达到理想的线性度，带宽抢占带 来一部分性能劣化，框架的耗时和调度开销带来了额外的时延增加，MLA 部分的序列负载均 衡和 MoE 部分的专家负载均衡带来进一步的性能恶化；最后多种因素综合在一起，使得当前 吞吐如 [19] 所述，实现在保证 50ms 时延下单卡 Decode 吞吐达到 1920 Tokens/s。 针对 Atlas 800I A2 服务器，由于每个节点包含 8 张昇腾芯片，我们需要采用多节点互联 的方式来进行部署。综合考虑模型吞吐和部署灵活性，我们选定使用 2 节点 16 卡作为一个 Prefill 实例，4 节点 32 卡作为一个 Decode 实例。为了部署时尽可能的灵活，这里选用的卡 数较少，这使得整个系统采用较小规模的 EP 并行策略：每张卡上部署 8(Decode)/16(Prefill) 个路由专家和 1 个共享专家。在 Decode 阶段，MLA 部分采用 DP 并行策略，通信方式采用 AllGather/ReduceScatter 方案。这种部署方式可以在卡数较少情况下依然达到相当可观的吞 吐。值得一提的是，真实负载下 AllGather/ReduceScatter 比 Dispatch/Combine 的通信方案具 有更好的性能表现。综合上述优化方案，我们实现了在 100ms 时延下单卡吞吐达到 723∼808 Tokens/s。 本文结构安排如下：在第 2 节简单介绍昇腾服务器相关的硬件信息，在第 3 节详细介绍两种 不同机型下的部署方案，在第4, 5, 6节分别介绍框架层、模型层和算子层的优化技术，在第 7 节 给出两种部署下的性能分析结果，最后列举一些当前部署方案后续要增加的特性和优化方案。 4

5. 2 昇腾服务器和组网 2.1 昇腾芯片 昇腾 NPU 芯片是华为推出的一系列高性能 AI 处理器，专为大规模 AI 训练、高性能 AI 推理 等任务设计。该系列芯片采用达芬奇架构 [18]，具备强大的计算能力和高效的能效表现，能够 满足深度学习模型训练与推理、自然语言处理等多种应用场景的需求。该系列芯片分为多种型 号，不同型号的性能不同，不同服务器会根据定位选用不同型号的芯片。 2.2 Atlas 800I A2 服务器 昇腾 Atlas 800I A2 推理服务器（下文简称为 A2 服务器或 A2）一个节点包含 8 张 NPU 芯片， 形成多机组网架构 (图 1)，具有以下特点： • 节 点 内 拓 扑：A2 单 节 点 内 8 卡 NPU 通 过 Fullmesh 形 成 全 互 联 结 构， 通 信 总 带 宽 392GB/s。 • 节点间拓扑：A2 节点间通过网络交换机进行互联，形成 Stars 结构，通信总带宽 50GB/s。 图 1: Atlas 800I A2 服务器节点内和节点间组网。左图：A2 节点内全互联；右图：多节点间通 过交换机实现互联。 节点间通信时，由于不同卡上的数据汇聚到同一个网络通信接口上，共享总带宽。所以如果 模型需要部署在多个节点上时，需关注节点间通信量和通信次数，减少节点间带宽对性能带来 的影响。 5

6. 2.3 CloudMatrix 384 超节点 CloudMatrix 384 超节点（下文简称为 CM384）是基于灵衢高速互联总线，满足 AI 时代海量 算力需求的大规模超节点集群 (图 2)。CM384 通过多卡紧耦合互联，统一内存编址，统一标 识，统一通信等技术，实现算力、互联带宽、内存带宽的全面领先。因此，在 CM384 上进行 网络部署时，子节点间带宽不再成为通信瓶颈，可考虑利用全部 AI 处理器的算力分布式部署， 如全域的专家并行，以充分利用超节点高算力高带宽的特性。 图 2: CloudMatrix 384 超节点内卡间和多子节点间高速互联。 3 DeepSeek V3/R1 模型部署方案 本节重点介绍 DeepSeek V3/R1 在昇腾服务器上的具体部署方案和调度策略。考虑到 Atlas 800I A2 和 CloudMatrix 384 超节点的部署方案比较相似，我们将在第 3.2 节中详细介绍 Atlas 800I A2 上的部署方案，在第 3.3 节中介绍 CloudMatrix 384 超节点上的部署方案相比 Atlas 800I A2 的差异。 3.1 模型与框架配置 3.1.1 模型量化策略 为适配昇腾芯片保证推理性能，这里采用 SmoothQuant 技术 [15] 对模型进行 A8W8 动态量化 (权重激活均采用 INT8 量化数据类型)，计算过程的中间变量采用 BF16。当前 KVCache 采用 了 BF16 的数据类型进行存储和计算，后续该量化策略会记为 A8W8C16，即激活 INT8、权重 INT8 和 KVCache BF16。 6

7. 3.1.2 Prefill 和 Decode 分离部署 大模型推理过程主要分 Prefill 和 Decode 两个阶段。Prefill 阶段通常是计算瓶颈，而 Decode 阶段通常是带宽瓶颈和通信瓶颈，这导致两者的最佳部署策略往往不同。此外，由于权重吸收 的技术，MLA 模块在 Prefill 和 Decode 阶段的计算逻辑是不同的，部署在同一实例上会导致 额外的权重占用。 另一方面，由于实际服务时对首 Token 时延 (TTFT) 和 Decode 时延 (TPOT) 的要求，如 果在同一套硬件上部署 Prefill 和 Decode，导致该系统要同时满足 TTFT 和 TPOT 两个指标， 这会导致整体吞吐难以达到最优。 综合上述原因，如果采用 Prefill 和 Decode 分离部署的方式，可以更好的获得两阶段的极 致性能，并更好的满足实际需求。所以本报告中我们总是基于 Prefill 和 Decode 分离的方式进 行部署（后续称为 PD 分离） 。 3.1.3 服务框架配置 vLLM [8] 是当前较为流行的开源大模型推理框架，我们以此为基础来对大模型进行部署。为适 配 PD 分离，并获得极致的性能，我们在框架侧做了相应的适配： 图 3: 基于 PD 分离部署的 vLLM 框架调度示意图。 7

8. • Prefill 调度分桶：基于 vLLM 框架，结合请求长度与 KV 亲和性调度策略，根据任务特 性动态优化资源分配，显著提升了在高并发场景下的推理性能； • 灵衢互联与分层传输：在 KVCache 传输上，我们采用了灵衢互联与分层传输的形式，来 降低 KVCache 传输时延。 为了支撑大规模 EP、小规模 EP、DP 和 TP 等并行策略，我们对框架做了相应的修改和 适配。同时为了支持超高并发（10K 以上） ，需要较为极致的性能优化，这部分在第 4 节框架优 化部分会详细介绍。 3.2 Atlas 800I A2 部署方案 在 Atlas 800I A2 的部署上，综合考虑模型吞吐和部署灵活性，我们在 Decode 阶段仅使用 32 卡进行部署，Prefill 阶段仅使用 16 卡部署。如果 Decode 要达到高吞吐，或 Prefill 要支持长序 列，则意味着高内存占用，这导致内存可能会成为关键瓶颈，所以具体的部署策略上要特别注 意内存的占用。 图 4: DeepSeek V3/R1 主体网络架构。 PrefillDecode MLATP16DP32 Dense FFNDP16DP4 + TP8 路由专家EP16EP32 共享专家DP16DP4 + TP8 EmbeddingTP16DP4 + TP8 LM HeadTP16DP4 + TP8 表 1: Altas 800I A2 的 PD 分离部署。 DeepSeek V3/R1 模型共有 61 层（图 4）和额外的一层 MTP 层，每层包括 MLA 模块和 Dense FFN/MoE 模块。整体部署策略如表 1所示。总体来说，MoE 部分均采用 EP 部署策略， 其中共享专家部分采用 DP4+TP8 并行，MLA 部分在 Prefill 和 Decode 部分因其核心逻辑的 差异导致采用不同的部署策略。此外，稠密层 FFN、Embeding 和 LM Head 部分均为了节省 内存采用 DP4+TP8 的部署策略。下面详细介绍各模块的部署方案。 8

9. 3.2.1 多头潜在注意力（MLA） DeepSeek V3/R1 使用了独特的 MLA 进行 KVCache 压缩。不同于传统的 MHA [14]，MLA 的多个头共用压缩后的 KVCache。在 Decode 阶段，对 MLA 用 TP 无法节省内存, 反而会导 致 KVCache 的大量重复搬运；而在 Prefill 阶段，矩阵乘计算取代数据搬运成为主要性能瓶颈， DP 与 TP 的计算量相同，但 TP 可以获得一定的内存收益。 内存分析 单张卡上 MLA 部分的内存占用可以描述为： Memory = W KVCache + + Memory激活 , TP DP 其中 W 是模型 MLA 部分的权重大小。在 Decode 阶段, KVCache 会占据大量内存 (卡均 72 并发，序列长度为 4K 时，KVCache 内存占用接近 20 GB)。由于 MLA 的多头共享 KVCache 机制，传统的 TP （head 轴切分）部署并不能降低单卡 KVCache 占用，因此全 DP 部署是最 节省内存的并行部署方式。而在 Prefill 阶段，并发数较小，序列长度较大，权重（约 11.6 GB) 和激活内存（总 token 数为 16384 场景下，约 1 GB）占据了大部分内存，更适合采用 TP 的 方式进行部署。因此，我们对 Prefill 和 Decode 采取不同的部署策略。 Prefill 我们采用 Attention 前序计算 DP16，Attention TP16, Attention 后序计算 DP8 + TP2 的混合部署策略，流程图示见图 5b。具体而言： • 在 Q、K、V 降维阶段采用 DP16 部署，这部分模型权重数量较少，使用 DP 不会占用过 多内存，且降维后的 Q、K、V 可以最大程度降低切换到 TP 所引入的通信开销; • 在 Q、K、V 升维以及 Attention 计算阶段采用 TP16 部署，显著降低算子激活内存; • Output 投影矩阵采用 DP8 + TP2, 能显著降低 TP 转换为 DP 的通信量, 具体技术见 第 5.1 节。 Decode 此时 MLA 的性能瓶颈主要在权重和 KVCache 搬运，其中 KVCache 搬运为主要耗 时。因此，我们采用业界主流的 DP32 与权重吸收 [5] 的部署方式，避免 KVCache 重复搬运， 降低 Attention 算子的耗时。 9

10. (a) Prefill 稠密层 (b) Prefill MLA 图 5: 左：Prefill 稠密层使用 DP Dense FFN 提升 Prefill 性能，避免引入额外通信。右：Prefill 的 MLA 部分使用 DP-TP16-TP2 的方式部署。其中，我们选择在 Q、K、V 降维之后进行 DP-TP 转换，最大程度降低通信量。Attention 采用 TP16，最后对 Output 投影矩阵计算 (图中的 O Proj) 使用 DP8+TP2。注：简洁起见，图中忽略了 RoPE 和 RMSNorm 部分的计算。 3.2.2 Dense FFN Prefill 此时性能瓶颈是矩阵乘的计算量。注意到无论使用 DP 或者 TP，计算量都保持不变, 但是使用 TP 会引入额外的通信，且全 TP 在长序列场景下的矩阵乘法的维度对计算硬件不亲 和，影响矩阵乘计算性能。因此，我们对 Dense FFN 采用全 DP 的部署方式。Prefill 阶段稠密 层的计算流程见图 5a。 Decode 此时性能瓶颈是权重搬运。综合考虑 FFN 性能和通信耗时，以及权重所需内存（总 共约 1.1 GB)，我们采取 DP4 + TP8 的部署策略。Decode 阶段稠密层的计算流程见图 6。 3.2.3 混合专家（MoE） 路由专家 DeepSeek V3/R1 庞大的专家数量对内存提出了巨大挑战。每个专家在总共 58 层共 占权重约 2.5 GB，而每张 Atlas 800I A2 昇腾卡的内存大小是 64 GB。因此，我们在 Prefill 和 Decode 阶段都采用了业界主流的 EP 并行部署策略，即将 256 个路由专家平均地部署到所有 昇腾卡上。对于 Prefill 节点而言，每张卡上需要部署 16 个路由专家；Decode 节点上每张卡部 10

11. 图 6: Decode 阶段稠密层采取 DP32 MLA + 节点内 TP8 Dense FFN 的部署方式。MLA 使用 DP32 可以避免 KVCache 的 重复搬运，且有效降低了单卡的内存压力。Dense FFN 采用了节点内 TP8，避免过高的通信代价，同时能够部分降低单卡载入的 权重（约 1 GB）。注：简洁起见，图中已忽略各处的 RMSNorm 计算。 署 8 个路由专家。这种部署方式很大程度上减轻了单卡的内存压力和计算量，但同时也引入了 别的挑战如 MoE 前后的通信开销（见第 5.2 节）和专家负载不均衡（见第 4.2 节）。 共享专家 通常场景下，我们选择对共享专家应用全 DP 的并行策略。在长序列的场景下，内 存成为提升吞吐的瓶颈之一，我们可以选择对共享专家应用节点内 TP8 的并行策略，这能节省 约 2.1GB 内存。两种场景下，共享专家的计算都与路由专家的通信操作并发掩盖。 总体流程 Decode 节点 MoE 层的具体计算流程请见图 7 。由于 Prefill 的流程与 Decode 高度 相似（共享专家部署略有不同） ，这里不另展示 Prefill 的流程图。 3.2.4 Embedding 和 LM Head DeepSeek V3/R1 模型一开始的 Embedding 和模型最后的 Language Model (LM) Head 都涉及 对一个巨大的形状为 (129280, 7168) 的 BF16 数据格式的字典映射/矩阵乘，权重大小均为 1.7 GB，共约 3.5 GB。在 Prefill 节点上，我们采取 TP16 的部署方式；而在 Decode 节点上，我 们采取类似 Dense FFN 的 DP4+TP8 的部署方式。这部分减少内存占用约 3 GB，但需要引入 额外的节点内通信操作。 11

12. 图 7: Decode 节点稀疏层的计算流程。MLA 部分和稠密层一样采取 DP32 的方式，降低 KVCache 搬运量。MoE 部分使用 EP32 的部署策略。首先对 MLA 的输出使用 AllGather 通信，所有路由专家计算完毕后，使用 ReduceScatter 分发结果给下一 层。 3.3 CloudMatrix 384 超节点部署方案 本节介绍我们在 CM384 上设计的部署策略。 Prefill CM384 在 Prefill 阶段的部署方案与 Atlas 800I A2 基本相同，主要差异是，在 CM384 上 MoE 模块的通信方式为 All2All。CM384 的子节点间通过交换设备形成无收敛高速互联 （第 2.3 节） ，因此在 CM384 上采用 All2All 方案，比 AllGather+ReduceScatter 的方案（图 6） 性能更优。 Decode 由于 DeepSeek V3/R1 模型的路由专家数量多，在 Decode 阶段，MoE 模块的主要 性能瓶颈为权重搬运。EP 的规模越大，意味着每个子节点需要搬运的专家权重越少，但代价 是通信时延的增加。在 CM384 上，子节点间的互联带宽相比 Atlas 800I A2 大大提高，这使得 大规模的 EP 部署成为可能。 在 Decode 阶段，我们用 18 个 CM384 子节点（共 144 卡）进行部署。具体部署方案与 Atlas 800I A2 的对比如下： 1. MLA 模块的部署方案与 Atlas 800I A2 基本相同，采用 DP。但在 Output 投影矩阵部分， 12

13. CM384 Decode 稠密层 子节点 1~18 NPU 1 & 2 NPU 3 & 4 Batch 1 DP MLA Batch 2Batch 3 DP MLADP MLA TP2 O-proj Batch 1 NPU 5 & 6 Batch 4Batch 5 DP MLADP MLA TP2 O-proj Batch 2 Batch 3 NPU 7 & 8 Batch 6Batch 7 DP MLADP MLA TP2 O-proj Batch 4 Batch 5 Batch 8 DP MLA TP2 O-proj Batch 6 Batch 7 Batch 8 AllGatherAllGatherAllGatherAllGather TP2 Dense FFNTP2 Dense FFNTP2 Dense FFNTP2 Dense FFN ReduceScatterReduceScatterReduceScatterReduceScatter Batch 1 Batch 2 Batch 3 Batch 4 Batch 5 Batch 6 Batch 7 Batch 8 图 8: CM384 Decode 阶段稠密层部署方式为全 DP MLA 和 TP2 Dense FFN。在 CM384 Decode 子节点上，稠密层的 MLA 整体上采取全 DP 的部署方式，最后的 Output 投影矩阵采用 TP2（图中的 O-proj）。不同于 Atlas 800I A2 上的 TP8，基于 CM384 的组网特点（第 2.3 节） ，我们在 FFN 层采取了 TP2 的部署方式。 CM384 Decode 稀疏层 子节点 1 Batch 1 DP MLA … … TP2 O-proj Batch 1 … 子节点 2 Batch 8 Batch 9 DP MLADP MLA TP2 O-projTP2 O-proj Batch 8Batch 9 … … … …… 子节点 3 Batch16 Batch17 DP MLADP MLA TP2 O-projTP2 O-proj Batch16Batch17 … … … DP MLA 子节点 18 Batch137 Batch24 …… DP MLA TP2 O-projTP2 O-proj Batch24Batch137 … … Batch144 DP MLA TP2 O-proj … Batch144 Dispatch All2All DP 共享专家 … DP 共享专家 DP 共享专家 … DP 共享专家 路由专家 1-2 … 路由专家 15-16 …… 路由专家 241-242 … 路由专家 255-256 Combine All2All Batch 1 … Batch 8 Batch 9 … Batch16 Batch17 … Batch24 Batch137 … Batch144 图 9: CM384 Decode 阶段稀疏层部署方式为 DP MLA 和 EP144 MoE。在 CM384 Decode 子节点上，稀疏层的 MLA 整体上 采取 DP 的部署方式，最后的 Output 投影矩阵采用 TP2（图中的 O-proj） 。MoE 采取 EP144 的部署方式，共享专家也被当做 路由专家处理 [6]。在 18 个 CM384 子节点中，2 个子节点以 DP 的方式部署共享专家；其余 16 个子节点用于部署路由专家，每 张卡部署两个专家。 由于通信性能更高，CM384 采用了 TP2。 2. Atlas 800I A2 上节点内是 Fullmesh 组网，TP2/TP4 无法充分利用带宽，但 CM384 上 子节点内是通过交换设备互联，不存在这一问题。因此，不同于 Atlas 800I A2 的 TP8， 13

14. CM384 上稠密层 FFN 的并行策略采取 TP2（见图 8）。 3. 与 Prefill 相同，CM384 上 MoE 模块采用了 All2All 的通信方式（见图 9），并且将共享 专家看做一个必选的路由专家 [6]，部署到单独的 NPU 上。由于每个 Token 会选择 8 个 路由专家和 1 个共享专家，因此单独部署时，共享专家的数量应为路由专家的 8 分之 1。 在 18 个 CM384 子节点的 144 张 NPU 中，128 张用于部署路由专家，其余 16 张卡用于 部署共享专家（EP144）。 4. 对于 Embedding 模块，由于 CM384 上采用了 EP144，内存压力小，没有使用 TP；而在 LM Head 部分，由于 TP 切分可以减小每张卡上的权重搬运，带来性能收益，我们最终 采用了 TP8 。 4 框架侧性能优化 为了实现 DeepSeek V3/R1 的高吞吐，需要框架支持 10K 甚至更高的并发度。为此我们需要对 框架进行增强，通过性能优化和多 Server 并发等来降低框架侧耗时。我们在 vLLM 的以下关 键环节进行了深度优化： 1. 请求下发：支持下发水平扩展，结合负载均衡机制，降低转发时延。 2. 调度策略：采用请求长度感知与 KVCache 亲和等高级调度策略，实现负载均衡与资源高 效利用。 3. 系统建链：简化系统通讯链路，在保证稳定性的前提下去除所有非必要链路。 4. 前后处理：多核全并行、全异步的高效前后处理，降低 NPU 闲置率，确保推理结果快速 返回，降低端到端延迟。 4.1 API Server 扩展技术 当前单节点 API Server 部署存在故障风险。在昇腾服务器高性能架构下，高并发请求易使单点 API Server 成为性能瓶颈，导致响应延迟增加，NPU 算力资源浪费。因此我们做了如下优化： 14

15. • API Server 水平扩容策略：通过 Global Proxy 组件插件化实现 KVCache 亲和、负载均 衡及序列长度调度优化，提升请求处理能力和系统吞吐量（QPS），降低用户请求延迟。 • 组网方案优化：从 API Server 与 DP 全连接简化为 1:1 组网，减少通讯开销，增强系统 鲁棒性。整体方案显著提升 TTFT 提高推理服务可用性与效率，充分发挥昇腾算力，为 高并发场景下的大模型推理服务提供可靠支持。 • 全并行、全异步前后处理，并结合 Multi-Step 技术进一步降低 Decode 前后处理耗时； Prefill 部分支持动态进程前后处理降低 TTFT。 4.2 MoE 模型负载均衡 针对混合专家（MoE）模型推理中的“冷热专家”问题，我们提出高效负载均衡策略，解决负 载不均、推理延迟高及吞吐量低等痛点。通过专家重排、分层冗余部署和近实时调度，显著提 升推理性能，具体包括： • 动态负载均衡：基于激活数据与计算均衡，动态调整专家部署，缩小通信域，优化后结果 静态负载均衡的收敛性与负载均匀性。 • 热专家冗余部署：为高频专家分配冗余实例，结合实时资源预测，降低通讯开销，从而提 升吞吐量。 • 实时调度：动态调整专家分配，实现快速收敛、适应输入变化的同时，保持低延迟。 • 动态监控：独立流监控激活数据，不干扰推理，确保高鲁棒性。 5 模型侧性能优化 5.1 模型侧通信优化 大模型多卡部署时，卡间并行方式包括数据并行（DP） 、张量并行（TP） 、专家并行（EP）等。 不同的卡间并行方式对多卡间通信方式和通信算子有着不同的需求，从而影响模型部署时的通 信时延。 15

16. MoE 层整体通信策略 针对 Altas 800I A2 的组网架构，我们采用 AllGather 和 ReduceScatter 来进行 MoE 层前后的数据通信，而非经典的 EP 部署下的 All2All。这是因为节点间通信带宽 相较节点内的较低。当单卡的并发数为 BS 时，若采用 AllGather 通信，单卡需要进行节点间 通信的数据量为 BS × 3× hidden_size。作为对比，若采用 All2All 方案，单卡平均需要进行节 点间通信的数据量为 BS × 6× hidden_size。同时 All2All 方案的通信数据量会受到专家负载 不均的影响，不如 AllGather/ReduceScatter 方案稳定。结合细粒度分级流水算法 (第 6.2 节)， AllGather/ReduceScatter 方案可以做到节点间通信耗时几乎被节点内通信耗时掩盖。另一 方面，采用 AllGather 的分发模式，AllGather 通信可以和 Gating 函数的计算解耦，实现计 算通信并发，详见第 5.2 节。综上所述，在 Altas 800I A2 的 32 卡部署方案中，我们采用了 AllGather/ReduceScatter 来进行 MoE 层前后的数据通信。 FlashComm 主流张量并行（TP） [12] 中使用 AllReduce 进行通信的方案存在通信次数 多、通信数据量大等问题，且 AllReduce 之后的残差连接和归一化计算存在计算冗余，没 有充分利用多卡并行能力。为此，我们提出 FlashComm 网络通信方案：在 Prefill 阶段针对 DeepSeek V3/R1 网络 MLA 层前后的 AllReduce 通信，基于相同的集合通信逻辑将张量并行 中的 AllReduce 通信算子进行替换，并对通信算子在网络中的位置进行编排，实现了低比特和 低维度数据通信，从而有效降低了通信数据量和通信时延，并消除了网络中存在的冗余计算。 FlashComm 技术应用于 DeepSeek V3/R1 模型 Prefill 阶段，降低 25% 的通信量，提升 10% 的推理性能。 层内并行转换技术 在 FlashComm 的基础上，为进一步优化通信算子的时延，我们提出层内 并行转换的优化技术：针对 Prefill 阶段网络 MLA 层的节点内通信，我们重新设计了 MLA 层 内的多卡并行策略，实现张量并行（TP）与数据并行（DP） [9] 的灵活转换，消除了节点内卡 间求和的需求，且充分利用网络中低维度数据和量化特性实现节点内通信量的大幅降低，从而 显著优化了通信时延。层内并行转换技术应用于 DeepSeek V3/R1 模型 Prefill 阶段，降低 71% 的节点内通信量，提升 10% 以上的推理性能。 16

17. 5.2 模型侧并发方案 昇腾芯片支持多种计算资源如张量计算单元、向量计算单元，以及通信资源的并发使用，这为 尽可能发挥昇腾硬件的算力和带宽提供了支持。我们针对 DeepSeek V3/R1 模型的架构进行了 细致的流水编排，从而尽可能利用硬件资源，实现极致的性能。具体来讲，包含如下几项技术： 通信通信并发 昇腾芯片提供了通信和通信并发的机制。当通信带宽利用率比较低的时候， 可以把两个通信算子并发起来以掩盖通信算子的启动开销，同时提高通信带宽的利用率。在 DeepSeek V3/R1 模型中，我们将 Norm 算子和量化算子移到 AllGather 通信前，从而降低通 信的数据量，进而提高通信的效率。由于量化算子的前移，需分别通信量化后的激活值和量化 Scale，进而增大了通信算子启动开销。由于量化 Scale 的数据量较小，对带宽的占用较低，因 此我们采用通信通信并发的机制，将通信激活值和通信量化 Scale 并发起来，在不增加激活值 通信开销的前提下，掩盖掉量化 Scale 的通信开销。 计算通信并发 昇腾芯片也提供了计算和通信的并发机制。MoE 层的计算过程需要使用 AllGather 汇聚各张卡上 token 的特征，以进行激活专家的筛选和计算。但 Gating 函数无须依 赖 AllGather 汇聚的结果。因此，对 Gating 函数使用先计算后通信的方法，对共享专家使用 DP 部署，从而保证 Gating 函数的计算和通信、共享专家的计算，以及特征汇聚的 AllGather 通信之间解耦。我们利用昇腾的多流机制，将这三部分进行并发处理，从而最大化推理模型 的性能。结合通信通信并发技术可以实现极致的流水编排（参见图 10）。此技术在 DeepSeek V3/R1 模型在大并发下可以实现 Decode 性能提升 15%。 通信和权重预取的并发 昇腾芯片提供了缓存机制，算子在进行计算时，会优先从缓存中寻 找数据，如果命中，则直接从缓存中读取数据，否则从 HBM 中读取数据，而缓存的带宽是 HBM 带宽的数倍。由于通信算子进行过程中 HBM 带宽占用率较低，我们在通信算子的进行 过程中可以将后续算子需要的权重提前预取到缓存中，从而降低后续算子计算过程中的权重搬 运开销。同时昇腾芯片支持限定预取带宽，因此在通信过程中预取对通信性能影响很小。对于 DeepSeek V3/R1 模型，我们在 MoE 模块末尾的 ReduceScatter 预取下一层 MLA 模块中的权 17

18. 重和 KVCache，提升了 MLA 约 10% 的性能。 图 10: Decode MoE 层计算通信并发和通信通信并发。利用昇腾多流机制，使能 Gating 函数计 算和通信，激活值的 AllGather 通信，共享专家计算进行通信计算并发。量化后激活值和 Scale 的通信，路由专家门控系数和 Index 的通信进行通信和通信并发 5.3 推理投机框架 FusionSpec 在大模型推理优化领域，投机推理是一种极具潜力的技术路径：其通过引入轻量模型或外部知 识数据，为大模型生成推理草稿，从而在解码阶段一次推理多个 token ，提升了计算密度。以 DeepSeek V3/R1 模型 [6] 为例，其创新性地引入 MTP（Multi-Token Prediction）投机层，实 现了投机推理技术的落地。 投机推理在模型解码阶段的高计算密度天然匹配昇腾高算力带宽比的特点。为了充分发挥 这一优势，在低时延大并发场景下实现高吞吐，我们提出了投机推理框架 FusionSpec，包括投 机流程及投机算子性能的优化技术，持续提升 MTP 在昇腾上的推理性能，使得 MTP 部分框 架耗时降为 1ms 左右： • 流程拼接：在推理流程上，将投机模型置于主体模型之后，直接使用主体模型的输出，并 复用主体模型的控制参数，大幅减少了框架耗时，适配 PD 分离的部署场景。 18

19. • 轻量步间准备：在投机场景中针对框架与算子优化，实现了轻量步间准备，适配多核并行 全异步框架，降低端到端时延。 6 昇腾算子性能优化 6.1 MLA 算子优化 Attention 算子 MLA 相较于传统的 Attention（如 MHA, GQA 类在 Decode 阶段显著带宽 瓶颈的算子） ，由于其中间变量膨胀且计算量显著增加，为算子优化带来了新的挑战。针对昇腾 处理器的架构特性，我们借鉴了 Flash-Attention 的思想 [2, 3]，对 MLA 场景的 Attention 算 子 [5, 6] 进行了计算过程的优化，以及硬件亲和的性能优化。主要包括以下几点： • 提出 AMLA（Ascend MLA）算法，通过浮点二进制编码解析及存内计算能力实现乘性计 算的加性等价转换，从而实现直接在内存上更新输出矩阵 O 的步骤，无须进入向量计算 单元，大幅降低中间变量的重复搬运。 • 根据 [2, 3] 的思想，对 L1 缓存进行了细致规划，尽可能地减少数据重复搬入搬出的过程。 • 在工程实现方面，通过优化计算流程提高 L2 缓存命中率及数据复用率，并且利用 K-buffer 流水排布等策略，实现张量计算和向量计算互相掩盖；使能昇腾硬件亲和的数据 排布，提高了算子整体性能。 上述优化方案提升 Attention 算子性能接近 1 倍，非 MTP 场景算力利用率达到 55%，使用一 个 MTP 模块场景算力利用率达到 60%。 MLA 前序算子 针对复杂的 MLA 前序算子，我们分别在 Prefill 阶段和 Decode 阶段采取了 不同的优化策略： • 在 Prefill 阶段，我们通过双流并发等技术实现了流水掩盖，同时增加了 Attention 算子 对多种输入输出模式的支持以消除纯访存类冗余算子。 • 在 Decode 阶段，我们采用权重吸收，同时将前序算子深度融合为 MLAProlog 算子，并 且针对昇腾硬件架构进行了全方位的深度优化。具体优化措施包括：采用权重预取减少流 19

20. 水线空泡；基于最小化搬运以及最大化带宽的 Tiling 策略；通过计算解耦减少依赖；利用 局部计算融合消除全核同步开销等。基于上述优化方案，MLAProlog 算子性能提升 30% 以上。 6.2 MoE 通信算子优化 Dispatch/Combine 通算融合算子 在 EP 部署模式中，MoE 中的专家分布在通信域的各个 卡上，每个 token 需要分发到对应的卡上进行计算。原始的方案使用 InitialRouting 根据专家 排序对所有 token 进行重排，再利用两次通信算子（All2All 以及 All2Allv）完成 token 分发。 该方案在通信域比较大的场景下，存在通信次数多，卡间同步开销大等问题，导致端到端时延 增加。针对此问题，我们提出 MoEDistributeDispatch 和 MoEDistributeCombine 两个通算融 合算子：将计算和通信拆解为 token 粒度，通过流水排布实现两者的并行执行；利用内存语义 的通信技术直接向不同卡上的内存传输数据，从而减少了本地拷贝和等待数据的开销；通过本 地内存筛选和拷贝的机制，减少了数据传输次数和卡间同步开销。 SMTurbo-CPP 针对 MoE 层大通信域场景下，小数据量传输效率低的问题，我们提出 SMTurbo-Concurrent Push and Pull （SMTurbo-CPP）技术：在内存语义级别对通信算子 All2All(v) 进行优化，充分利用硬件并发能力，使用读写混合、聚合流水、批量检测等技术，提 升了线程的访存效率与吞吐，显著降低 Dispatch 和 Combine 场景通信算子的时延。实测可降 低 Dispatch/Combine 算子 8%-20% 的推理时延。 细粒度分级流水算法 Atlas 800I A2 服务器通信协议支持细粒度的分级流水算法，可大幅提升 AllGather、ReduceScatter、All2All 等集合通信算子的执行效率 [17]。该算法利用 A2 组网的 特性，实现了节点内/节点间通信的并发执行以提高带宽利用率。采用细粒度分级流水算法后的 AllGather 和 ReduceScatter, 在 4 节点时，可以达到节点间通信耗时被节点内通信耗时几乎完 全掩盖。在 Decode 4 节点部署 / Prefill 2 节点部署场景中，其性能相较 All2Allv 具有更大优 势。 20

21. 图 11: 细粒度分级流水算法 [17]，每次 Server 间传输过来的数据，在下一个步骤将此数据用于 Server 内传输，同时获得下一份 Server 间的数据，以此类推。 7 性能分析 7.1Altas 800I A2 性能分析 7.1.1Decode 性能 A2 Decode 的测试方式为： • 序列长度为 2K 输入 + 2K 输出 / 1K 输入 + 2K 输出。 • 在使能 MTP 进行推理加速的情况下，由于不同测试数据集和业务场景的 MTP 接受率不 同，性能测试结果会有比较大的偏差。因此在计算时延和吞吐的时候默认按照 70% 接受 率来折算。 • TPOT（Decode 平均每 token 时延）不超过 100ms。 对于序列长度是 2K 输入 + 2K 输出的情形，每卡平均并发数为 72，此时端到端耗时为 99.6ms， 卡均吞吐为 723 Tokens/s。具体数据详见表 2。图 12中详细拆解了每个模块的耗时，可以看出： • 由于 MLA 的 Attention 算子，尤其在使能 MTP 时，计算密度远高于 GQA 和 MHA，与 MQA 相当，此时 MLA 的计算不再是完全带宽瓶颈。我们通过第 6.1 节中的优化方案， 当前的算子实现可以达到 55% 的算力利用率。 21

22. 不同接受率吞吐 (Tokens/s) 输入长度 输出长度 单卡并发数 70%80%90% 2K2K72723765808 1K2K80784830876 表 2: Altas 800I A2 的 Decode 性能：在不同 MTP 接受率和不同序列下的单卡吞吐。 图 12: Atlas 800I A2 的 Decode 在序列长度 2K+2K，卡均 72 并发的各模块耗时拆解。 • 卡均 72 并发，且使用一个 MTP 模块时，MoE 中的全连接层中，每个专家激活的 token 数是 72 × 2 × 8 × 32/256 = 144，对于昇腾硬件而言，这还是一个相对带宽瓶颈的场景， 算力利用率不高。未来使用更大规模的 EP 部署方案，可以进一步提高单卡并发数，提高 MoE 模块的算力利用率。 • 由于采用了 AllGather 和 ReduceScatter 来作为通信方式，而非 All2All 方案，所以通信 数据量不随着真实的专家负载变化，负载不均仅通过 MoE 路由专家计算不均来影响性 能，对整体性能的影响相对较小。 • 根据 DeepSeek 披露的数据 [16]，MTP 接受率可达 80%∼90%。如果按照 90% 的 MTP 接受率来估算，2K 输入 + 2K 输出的 Decode 单卡吞吐可达 808 Tokens/s。 22

23. 7.1.2 Prefill 性能 A2 Prefill 的测试方式为：单 batch 输入序列长度为 2K / 1K，通过拼 batch 的方式拼成一共 16K 序列。对于序列长度是 2K，共 8 batch 拼成一共 16K 序列的场景，端到端耗时为 631ms， 卡均吞吐为 1622 Tokens/s。具体的数据见表 3，具体的拆解数据见图 13。分析如下： 输入长度总并发数单卡吞吐 2K81622 1K161650 图 13: 序列长度 8 × 2K, Prefill 阶段 表 3: Altas 800I A2 的 Prefill 性能。 各组件的耗时占比。 • Prefill 阶段除了 MoE 层前后的 AllGather 和 ReduceScatter 之外，由于我们 MLA 部分 采用了 TP16 的部署策略，所以这里也存在 AllGather 和 ReduceScatter 通信过程。 • 由于在 Output 投影矩阵部分采用了第 5.1 节中提到的层内并行转换技术，我们在 Prefill 阶段也存在 All2All 通信过程。 • 虽然采用了 AllGather 和 ReduceScatter 通信方式，在负载不均时 MoE 部分的通信数据 量是不受 MoE 负载不均影响的。不过负载不均会导致不同卡的 MoE 部分计算时间不同， 不同卡间等待的过程在当前的统计方式里会表现在通信的耗时上。 • 当前为了部署的灵活性，同时考虑到实际场景 Prefill 难以拼到足够的并发数，我们采 用了 16 卡部署，MLA 选择 TP16，所有卡的序列长度之和为 16K 的一种方案。如果 采用 DP MLA 的部署方式，则可以减少 MLA 前后的通信，同时如果采用更大的并发 数，可以进一步提高 MoE 部分的算力利用率。同时根据 [13]，大并发的 Prefill 阶段采用 Micro-batch (Two-batch Overlap) 技术可以得到相当大的吞吐收益，甚至可以完全掩盖 通信。据此计算，Altas 800I A2 在 Prefill 阶段可达到卡均 3095 Tokens/s 的吞吐。 23

24. 7.2 CloudMatrix 384 超节点性能分析 DeepSeek 团队基于 H800 的算力、带宽和网络互联带宽，给出了 DeepSeek V3/R1 模型的理论 分析 [16]。由于 H800 高单卡算力带宽，而低网络带宽的特性，作者使用 Micro-batch 技术，提 出利用 Dispatch/Combine 掩盖其余所有计算的方案，并给出了理论的耗时估计。 昇腾 CloudMatrix 384 超节点由于其独特的网络互联使得其通信方面具有显著优势，这 使得在 CM384 上我们不再是通信瓶颈。基于此，可以设计不同的 Micro-batch 掩盖策略：使 用 MLA 中 Attention 计算掩盖其他部分，包括其他计算部分。根据当前 MLA 的实现（当前 MTP 的 MLA 算子接近 60% 的算力利用率），并考虑到使用 MLA 计算掩盖其余部分会带来 35% 左右的性能劣化，以 3K 序列长度为例，估算单层 MTP 的 MLA 的耗时大约为 BS × 3072 × (576 + 512) × 128 × 2 × 2 = 6.2BS us. 707.8 × 1012 × 0.6 × 0.65 这里 BS 表示单卡的并发数，从而按照 70% 的 MTP 接受率来算的话，整个网络的耗时接近 6.2BS us/Layer × 62.5Layer = 0.228BS ms. 1.7 如果不限制 Decode 时延，理论吞吐可以达到 BS Tokens = 4386Tokens/s. 0.228BS ms 在实际部署的时候，由于多种因素的影响，实际可达吞吐会大幅打折。一个关键原因是 Decode 时延的约束限制了实际使用的并发数，使得各部分耗时未能达到理想的线性度，导致可达吞吐 的大幅下降。另一方面，带宽抢占带来的恶化不可忽略，实际上上述评估中需要使用 MLA 来 掩盖 MoE 等其他计算部分，这里会发生严重的 HBM 带宽抢占导致整体带宽利用率下降。框 架的耗时和调度开销也会带来额外的时延增加，从而进一步降低吞吐。在实际部署时，MLA 部 分的序列负载均衡和 MoE 部分的专家负载会分别使得 MLA 和 MoE 部分耗时增加，导致进一 步的性能恶化。这些因素结合在一起，使得当前吞吐明显低于理论值。 2025 年 4 月，硅基流动联合华为云基于 CloudMatrix 384 超节点昇腾云服务，采用与本报 告完全相同的大规模专家并行方案正式上线 DeepSeek-R1。该服务在保证单用户 20 TPS （等 效 50ms 时延约束）水平前提下，单卡 Decode 吞吐突破 1920 Tokens/s。[19] 24

25. 图 14: 2025 年 4 月，硅基流动联合华为云基于 CloudMatrix 384 超节点上线 DeepSeek-R1，单 卡 Decode 吞吐突破 1920 Tokens/s. 8 下一步工作 当前已经完成了在昇腾服务器上部署 DeepSeek-V3/R1 模型的方案，后续还有一些工作需要完 善，以进一步提升性能和支撑更多场景： • 低时延场景的极致优化：本报告中的部署方案主要瞄准高吞吐场景，暂未针对低时延场 景进行极致优化。基于当前的部署方案，CloudMatrix 384 超节点在卡均 8 并发下时延 为 15ms，Atlas 800I A2 服务器上的方案在卡均 4 并发下时延为 30ms。实际上当前的整 体部署方案、算子优化和模型并行优化策略均未针对低时延下做优化，也并未使能多层 MTP，还有很大的优化空间。 • Micro-batch 优化方案：在 DeepSeek 公布的 DeepEP 方案 [1, 13] 中，提出通过将数据 拆分为两个 Micro-batch 的思路，实现了通信和计算的相互掩盖。该技术可以预见地会有 较大的性能收益，尤其在高并发的 Decode 和 Prefill 场景。当前在 CloudMatrix 384 超 节点的部署上已经采用了该技术，但在 Altas 800I A2 上还未有效使用。接下来我们会基 于 Altas 800I A2 进行适配以及更极致地优化。 • 低比特量化方案：当前模型采用的是 A8W8C16 的量化模式。对于 MLA 而言，其计算 密度远大于经典的 GQA 方案，所以传统的 KVCache 量化 [7, 10] 只能保证较大的内存 收益，能带来的性能收益有限。因此我们也在探索一些将 Q/K/V 全部量化的计算方案， 如果可以给出满足精度要求的量化方案，会给 Attention 计算带来可观的加速效果。另 25

26. 外，针对低时延场景，Decode 部分是强访存带宽瓶颈，如果对 MoE 部分使用 A8W4 或 A4W4 的量化方案，可有效降低访存带宽需求量，从而大幅提升性能。因此我们需要探索 针对 MoE 部分 INT4 的量化技术。 • MLA 层算子量化支持：在长序列下 KVCache 量化可以大幅减少推理过程中的内存占用， 我们将同步进行 Attention 及 MLAProlog 算子针对仅 KVCache 的 INT8 量化和 Q/K/V 全 INT8 量化场景的适配，通过深度的算子重构与极致流水优化保证性能。 • Altas 800I A2 的更大 EP 部署方案：对于 Altas 800I A2，当前采用的是 32 卡的部署 策略，每张卡的路由专家个数是 8 个，这带来了不小的 FFN 层的开销。单卡 72 并发， 使用一个 MTP 模块时，MoE 的每个专家激活 token 个数是 144 个。而对于昇腾硬件来 言，其算力带宽比较高，因此行数为 144 的 GEMM 还不足以实现较高的算力利用率。我 们可以进一步地采用更大 EP 的部署策略，例如 64 卡或 128 卡部署。可以预见更大 EP 的部署方案可以进一步地提高 MoE 部分的算力利用率，提高单卡吞吐。 • 序列负载均衡优化方案：实际部署的 Decode 阶段，每个请求由于其输入序列长度不同和 Decode 开始时间不同，使得整个实例中不同请求的序列长度相差很大，进而导致不同卡 上 MLA 耗时相差很大，这时 MLA 阶段会出现严重序列负载不均的问题。针对该问题， 可以按照不同的请求的处理时间对请求序列进行处理优先级划分，从而减少整体的等待 时间。具体来说，可以通过某种简单的预测手段快速预测请求输出长度。在获得输出长度 之后结合输入长度来做卡间负载均衡调度，最小化不同卡间的序列负载不均。 References [1] DeepSeek AI. DeepEP, 2025. URL https://github.com/deepseek-ai/DeepEP. [2] Tri Dao. FlashAttention-2: Faster attention with better parallelism and work partitioning. International Conference on Learning Representations, 2024. [3] Tri Dao, Dan Fu, Stefano Ermon, Atri Rudra, and Christopher Ré. FlashAttention: Fast 26

27. and memory-efficient exact attention with IO-awareness. Advances in neural information processing systems, 35:16344–16359, 2022. [4] DeepSeek. DeepSeek-V3-0324, 2025. URL https://huggingface.co/deepseek-ai/ DeepSeek-V3-0324. [5] DeepSeek-AI, Aixin Liu, Bei Feng, and Bin Wang et al. DeepSeek-V2: A strong, econom- ical, and efficient mixture-of-experts language model, 2024. URL https://arxiv.org/ abs/2405.04434. [6] DeepSeek-AI, Aixin Liu, Bei Feng, and Bing Xue et al. DeepSeek-V3 technical report, 2025. URL https://arxiv.org/abs/2412.19437. [7] Coleman Hooper and et al. Kim. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization. In A. Globerson, L. Mackey, D. Belgrave, A. Fan, U. Paquet, J. Tomczak, and C. Zhang, editors, Advances in Neural Information Processing Systems, volume 37, pages 1270–1303. Curran Associates, Inc., 2024. [8] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient Memory Management for Large Language Model Serving with PagedAttention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023. [9] Shen Li, Yanli Zhao, Rohan Varma, Omkar Salpekar, Pieter Noordhuis, Teng Li, Adam Paszke, Jeff Smith, Brian Vaughan, Pritam Damania, and Soumith Chintala. Pytorch distributed: Experiences on accelerating data parallel training. arXiv:2006.15704, 2020. [10] Zirui Liu, Jiayi Yuan, Hongye Jin, Shaochen Zhong, Zhaozhuo Xu, Vladimir Braver- man, Beidi Chen, and Xia Hu. KIVI: A tuning-free asymmetric 2bit quantization for KV cache. In Ruslan Salakhutdinov, Zico Kolter, Katherine Heller, Adrian Weller, Nuria Oliver, Jonathan Scarlett, and Felix Berkenkamp, editors, Proceedings of the 41st Interna- 27

28. tional Conference on Machine Learning, volume 235 of Proceedings of Machine Learning Research, pages 32332–32344. PMLR, 21–27 Jul 2024. URL https://proceedings.mlr. press/v235/liu24bz.html. [11] ZZ Ren, Zhihong Shao, Junxiao Song, Huajian Xin, Haocheng Wang, Wanjia Zhao, Liyue Zhang, Zhe Fu, Qihao Zhu, Dejian Yang, et al. DeepSeek-Prover-V2: Advancing for- mal mathematical reasoning via reinforcement learning for subgoal decomposition. arXiv preprint arXiv:2504.21801, 2025. [12] Mohammad Shoeybi, Mostofa Patwary, Raul Puri, Patrick LeGresley, Jared Casper, and Bryan Catanzaro. Megatron-LM: Training multi-billion parameter language models using model parallelism. arXiv:1909.08053, 2019. [13] The SGLang Team. Deploying DeepSeek with PD Disaggregation and Large- Scale Expert Parallelism on 96 H100 GPUs, 2025. URL https://lmsys.org/blog/ 2025-05-05-large-scale-ep/. [14] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. Attention is all you need. Advances in neural information processing systems, 30, 2017. [15] Guangxuan Xiao, Ji Lin, Mickael Seznec, Hao Wu, Julien Demouth, and Song Han. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. In Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato, and Jonathan Scarlett, editors, Proceedings of the 40th International Conference on Machine Learning, volume 202 of Proceedings of Machine Learning Research, pages 38087– 38099. PMLR, 23–29 Jul 2023. URL https://proceedings.mlr.press/v202/xiao23c. html. [16] Chenggang Zhao, Chengqi Deng, Chong Ruan, Damai Dai, Huazuo Gao, Jiashi Li, Liyue 28

29. Zhang, Panpan Huang, Shangyan Zhou, Shirong Ma, Wenfeng Liang, Ying He, Yuqing Wang, Yuxuan Liu, and Y. X. Wei. Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI Architectures, 2025. URL https://arxiv.org/abs/2505. 09343. [17] 昇 腾 CANN. 昇 腾 CANN 集 合 通 信 技 术 解 读 —— 细 粒 度 分 级 流 水 算 法, 2025. URL https://www.hiascend.com/developer/techArticles/20250427-1. [18] 梁晓峣. 昇腾 AI 处理器架构与编程. 清华大学出版社, 2019. ISBN 9787302534525. [19] 硅基流动. 比肩 H100! 硅基流动上线基于昇腾云 CloudMatrix 超节点的 DeepSeek-R1, 2025. URL https://mp.weixin.qq.com/s/hTTNafDoy2dcnUtWb2sKcA. 29