作者：昇腾实战派
系列文章：DeepSeek知识地图

背景概述

在大语言模型推理服务部署过程中，性能稳定性是保障用户体验的关键指标。本文档记录了一次在专家并行（EP）推理场景下，Decode阶段时延出现无规律波动的排查与优化过程。通过系统化的性能监控、Profiling数据采集与分析，最终定位根因并实施有效解决方案，为类似场景的性能调优提供参考。

一、问题现象

基于Atlas 800I A3服务器启动DeepSeek大EP推理服务后，推理过程中的Decode阶段出现时延无规律波动，波动幅度显著（详见左下MindIE Metrics监控界面）。

二、业务部署情况

1、软硬件部署配置

• DeepSeek大EP部署配置：2* 2P + 1* 4D，PD分离部署
• P节点：CP=2，TP=16，EP=32
• D节点：TP=1，DP=64，EP=64

2、负载情况

• 输入/输出序列长度：平均输入/输出长度50K/100；同时也包含部分短输入序列，序列长度差异显著，呈现长短混合特点。
• 并发规模：使用4台Atlas 800I A3服务器作为Decode节点，在TPOT波动显著时，系统并发数较低（<DP数）。

三、DeepSeek DP/EP并行原理简化示意

DeepSeek模型中每一层的前向计算主要包含Attention、Dispatch、MoE、Combine四个步骤。一次完整Decode过程共执行61次前向推理（对应模型61层）。其并行架构如下：

其中：

1. Attention部分：采用数据并行（DP）或“DP+张量并行（TP）”策略，不同的DP域负责处理不同请求的Attention计算。在目标场景中，Decode节点的DP设置为64，因此请求被分发至64个设备并行处理。
2. MoE部分：采用专家并行（EP）策略，将不同专家分布在不同设备上，以处理不同的Token。在目标场景中，Decode节点的EP同样设置为64。
3. 分发（Dispatch）：将来自各DP域的Token，动态分发至对应专家所在的设备进行处理。
4. 合并（Combine）：收集所有专家对Token的处理结果，并按原始顺序进行重组。

四、分析过程

1、推理性能波动规律分析

阶段	关键动作&现象	怀疑点	进一步分析方向
1	获取Decode节点单机Profiling数据： 发现16个Device上所有的MoeDistributeDispatch算子耗时均较长， 但是未识别到某个具体Device上算子执行耗时过长	1、通信存在问题，存在通信闪断等问题 2、DP负载不均，导致不同卡处理速度存在较大差异 3、Device节点Profiling数据不全，未识别到耗时异常的卡	【1】收集NPU、交换机等硬件层面日志进行排查分析 【2】获取各个DP域推理的序列长度 【3】采集Decode节点全量的Profiling数据，分析是否存在异常卡
2	构造“不定长随机数据集1（输入混合8K、20K、40K）”进行压测，未复现波动问题	性能波动随机出现，还是怀疑通信存在问题	【4】进一步基于真实数据进行压测，分析TPOT波动规律
3	推理压测，TPOT波动整体不算剧烈，偶现尖刺	暂无	【5】等待问题复现

通过前期观察，并没有发现明确的事件，会触发、恢复TPOT波动问题，分析一度陷入停滞。在排除底层硬件、通信等问题后，还是计划在性能波动问题复现后，重点将精力放到推理过程指标的分析：如DP域负载情况分析、Decode节点全量Profiling数据分析。

2、推理服务Profiling数据采集&分析

（1）数据采集与解析

采集方法：使用MindStudio服务化调优工具，在4台Decode节点同时采集Profiling数据（使用方法见“参考资料”）；采集完后进行数据解析

采集时刻：观察监控界面，当TPOT@AVG上升时，在4台机器同时触发Profiling数据的采集；采集时间设置为3-5s（避免时间过长，采集数据量过大；预估3-5s可以捕捉出现问题的时刻）

（2）Timeline对比分析

1、将4台Decode节点解析后的Profiling数据同时导入MindStudio Insight：

2、对比分析不同Device的Timeline，如下图所示：

通过分析可以发现：

• Device 0上MLAKernel计算耗时过长，导致其他Device（也即其他DP域）出现了不同程度的等待。
• 对于Device 1，可以发现其与Device 0在同一Layer下的KERNEL_AIVEC算子耗时较长；KERNEL_AIVEC为all_reduce算子，该算子耗时过长是因为Attention算子之后的O_Proj，在Device 0、1上设置了o_proj_local_tp=2进行TP并行，因此计算耗时更短的Device 1需要等待Device 0

• 对于其他Device，可以发现耗时较长的算子均为MoeDistributeDispatch；如前面DS并行原理所述，该算子主要负责将各DP域的Token，动态分发至对应专家所在的设备进行处理（也即MoE部分），由于Device 0处理速度慢，因此其他Device/DP域均需要进行等待。

（3）MLAKernel性能溯源

• 通过分析，Device 0上单个MLAKernel耗时相比Device 1上增加了很多。
• 根因分析：MLAKernel针对长序列使用了优化特性FlashDecoding：
  当序列长度差异大（一长一短，短序列<2K）时，可能导致FlashDecoding优化未触发，从而长序列处理耗时显著增加。

注：当前MindIE使用了ATB MLA算子，算子各输入的含义如下图所示（参考技术文档）：

五、解决方案及验证

1、解决方案

由于推理业务平均输入长度较长，并且TPOT有要求，因此Decode节点整体并发度不高。可以将Decode节点设置DP=64，并且限制DP域bs=1，强制开启FlashDecoding优化特性，避免出现MLAKernel耗时过长的问题。

实施方案：设置Decode节点maxBatchSize=1，限制DP域bs。

其他方案：1、MLAKernel优化；2、调度策略优化，序列长度感知的调度。

2、随机数据集验证

构造混合输入长度数据集（20K（40%）+400（60%）），拉起推理服务后进行压测。观测TPOT变化规律，同时采集Profiling，观察DP域bs是否成功限制为1。

3、真实数据集验证

接入真正的推理请求后，性能监控数据如下图所示。可以看到，相比修改前TPOT更加稳定；并且由于Decode节点并发数依然较低（20左右，<DP），因此理论上可以支撑更大的并发。

六、参考资料

1. MindIE性能监控工具：
   • MindIE服务化部署实现监控功能
   • 监控可视化
2. MindIE在线Profiling操作说明