本文分享自华为云社区《深度解读昇腾cann模型下沉技术，提升模型调度性能》，作者：昇腾cann。

ai模型的运行通常情况下需要cpu和npu（昇腾ai处理器）等ai专用处理器协同工作，cpu所在位置称为主机端（host），而npu所在位置称为设备端（device）。对于采用host调度的ai模型来说，host下发task的时序和device执行task的时序是异步的，如果device执行task的速度比host下发task的速度快，则device会处于空闲状态。比如，大模型场景的增量推理或训练的finetune阶段，都是计算量较小的场景，此时很容易出现单个算子的host下发时间比device上的算子执行时间还长，从而导致device间歇处于空闲状态。这种现象通常称为host bound，这种模型也称为host bound模型。

如何减少host bound模型的device空闲时间，从而优化模型执行性能显得尤其重要，ge（graph engine）图引擎通过图模式的host调度和模型下沉调度的方式，可提升模型调度性能，缩短模型e2e执行时间。

1 模型host调度

host cpu将模型中的算子依次下发到device执行（如下图中的标号①所示），每一个算子在执行流上以1个或多个task的形式存在，昇腾ai处理器依次拉取执行流上的task执行（如下图中的标号②所示），我们称这个过程为host调度。host调度需要host和device频繁交互，在实际的训练或推理场景中，模型会运行多次，每次运行都会触发host把模型上的所有算子遍历下发一遍。

图1 host调度：

1.1 device bound与host bound

如果device上task执行速度比host下发慢，则device上task调度开销和算子执行时间成为瓶颈，这种模型通常称为device bound模型，如图2所示。device bound的模型，task的下发开销会被已下发task的执行时间掩盖起来。

图2 host调度场景device bound执行时序分析：

如果device上task执行速度比host下发快，则host调度开销成为瓶颈，这种模型通常被称为host bound模型，如图3所示。host bound的模型，task的下发开销不能完全被已下发task的执行时间掩盖，device执行时序上存在间歇的空闲状态。

图3 host调度场景host bound执行时序分析：

1.2 单算子模式host调度与图模式host调度

在前面几期介绍中，我们知道当前业界主流的深度学习框架提供了eager执行（eager execution，即时执行）模式与图执行模式。eager模式也叫单算子模式，它是一种host调度模式，由host cpu逐个下发算子，一个算子的下发流程包含python处理、python到c++数据结构转换、tiling计算，申请算子的workspace内存和输出内存，launch等host操作。为了加速单算子host调度，在pytorch中，昇腾适配层采用了生产者—消费者双线程模式加速，生产者线程主要负责launch之前的处理动作，消费者线程主要负责launch算子。

相比于单算子模式，图模式的host调度可以避免总是返回python调用栈，避免冗余流程与数据结构转换，并且可以直接使用图编译阶段完成的infer shape与tiling计算结果。因此，图模式host单线程调度与单算子模式host双线程调度相比，调度性能持平或略优。

2 模型下沉调度

图模式调度可以降低host侧的调度耗时，并一定程度减少模型执行e2e耗时，但如何降低device上执行时序的空闲时间仍是需要考虑的问题。对于静态shape模型，昇腾支持下沉调度，可大幅优化host调度性能。

所谓静态shape模型，是指模型每次执行的输入tensor shape是固定不变的，模型中的所有算子，给定输入shape后，都可以确定自己的输出shape，那么该模型为静态shape模型。

静态shape模型在编译时即可确定所有算子的输入输出shape，结合昇腾内存复用算法，可完成模型级内存编排；静态shape模型在编译时还可提前完成所有算子的tiling计算等host侧计算。综上，静态shape模型可以在编译时完成所有执行时的host调度工作，这是静态shape模型下沉调度的理论基础。

2.1 下沉调度原理

模型下沉调度分为两个阶段，模型加载和模型执行。

图4 模型下沉示意图：

模型加载

模型加载的具体动作和host调度类似，即遍历图中的所有算子并将其整体下发至device流上，区别在于下发到流上不立即执行。模型加载是一次性的动作，在首次模型执行时完成模型加载，如图4中的过程①所示。

模型执行

模型加载完成之后，可以像下发单算子task一样，向执行流下发一个模型执行task，昇腾ai处理器调度到该task时（如图4 “执行流”中的e），执行模型中所有task（如图4中的过程③）。如果需要多次运行模型，仅需多次下发模型执行task，如图4中的过程②所示。

host bound调度和模型下沉调度的时序比较如图5所示，可以看出模型下沉执行的开始有一个模型下发的头开销，模型下沉执行e2e会有一个相对于host调度的收益，模型的下沉头开销越小，收益将越大。

图5 模型下沉调度host/device时序分析：

每次模型下发时，支持更新模型的feature map内存地址和输入输出内存地址，如果模型的feature map内存和模型输入输出内存发生了更新，则在模型下沉头开销（即上图中的m_l_t，后文有介绍）中会完成模型内算子相关地址的刷新。

2.2 下沉效果

模型下沉执行存在如下优势：

减少cpu的负载

对于模型下沉执行的方式，执行时不需要host和device频繁交互，调度的开销仅包含模型下沉的头开销和task从流上调度到加速器上的开销。总的来说，模型下沉执行的方式，host cpu的负载降低了，在一定程度上整机、集群的功耗也会降低。

减少rank之间的通信抖动

对于host调度执行方式，集群场景下由于不同卡上的host下发时序不一定完全同步，卡间集合通信可能存在一定程度上的抖动。而下沉执行方式则不存在该问题，因为task已提前排布到device上。

提升e2e的收益

由于task已提前下沉到了device，对于host bound的模型，e2e会有性能提升。以host bound的llama-7b模型的推理场景为例，图6是host调度的profiling性能数据，图7是模型下沉执行的profiling性能数据。通过profiling结果可以看出该模型是一个host bound模型，采用host调度方式，device上计算时间和空隙的时间比例接近1:1，采用模型下沉执行方式，device空隙大幅减少，并且端到端有18ms的收益，吞吐量整体提升37%。

图6 llama-7b decoding host调度profiling：