深度解读昇腾CANN小shape算子计算优化技术，进一步减少调度开销
GE（Graph Engine）将模型的调度分为Host调度与下沉调度两种模式。经过上期的介绍我们知道，在模型为静态shape时，由于其输入tensor shape固定不变，在编译时就能确定所有算子的输入输出shape，并能提前完成模型级内存编排、tiling计算等Host调度工作，因此采用模型下沉调度方式可以将整个模型下沉到Device侧执行，从而提升模型调度性能。
与之对应的，在模型为动态shape的情况下，由于输入tensor shape不确定，需要在上一个算子完成shape推导后，才能确定下一个算子的输入shape等信息，因此无法将整个模型下沉执行，只能采用Host调度模式。
1 Host调度简介及优化背景
所谓Host调度，是指模型的调度主体位于Host CPU，由CPU完成逐算子调度。一个算子的调度任务为kernel执行准备必要参数，通常包含shape推导、tiling、内存分配、launch等。
Host调度模式下，GE将模型中算子的执行单元划分为Host CPU执行与Device（昇腾AI处理器）执行两大类。对于卷积、MatMul等对算力要求高的算子，会被划分到Device执行；而由于shape信息在Host CPU维护，Shape、Reshape等算子更适合被划分到Host CPU执行；除此之外，还有一些算子，在shape较小时，计算量也很小，调度开销往往大于算子的实际计算开销，就需要考虑如何尽可能减少调度开销带来的性能影响。
图1 网络拓扑片段
图1是一段网络拓扑片段示例，按照一般的调度机制，Gather、Concat算子会下沉到Device侧计算，Shape、Unsqueeze、Reshape算子在Host侧计算。其执行时序如图2所示，模型E2E执行耗时除了包含算子计算的时间外，还包含Host与Device之间的数据拷贝、算子下沉调度、Stream同步等开销，整体执行E2E耗时在毫秒级别。
图2 优化前执行时序
而对于小shape（如shape size小于8）的Gather、Concat，算子本身在Host侧CPU的计算开销上仅微秒级别，与Device侧计算的性能相差无几。此时下发带来的额外开销就显得比较明显。针对上述这种shape较小且输入Tensor内存在Host的场景，GE识别将这部分算子保留在Host侧执行，可有效减少调度开销带来的性能影响。
2 小shape算子计算优化实现
在图编译流程执行到引擎选择之后，GE选择在Host侧执行的算子并将其作为锚点，然后向后递归查找计算数据个数小于8的算子，并将这些算子的执行引擎修改为Host CPU。针对图1所示的网络片段，假设shape算子的输出的shape size小于8，则Gather、Concat算子的执行引擎都会被刷新成Host CPU。优化后执行时序如图3所示，此时模型执行只有算子计算带来的开销，经测试约为10微秒（3ms –> 10us），显著的提高了E2E执行性能。
图3 优化前后执行前后时序对比
3 优化效果
以LLaMA2大语言推理模型为例，符合上述执行引擎刷新的算子有Pack、Gather、Concat等约650+个，刷新前模型E2E耗时约1.062S，刷新后执行时间优化到了1.009S，吞吐提升5%。
4 更多介绍
GE小shape算子计算优化技术的相关介绍就到这里，欢迎大家关注后续技术分享。如需获取更多学习资源请登录昇腾社区。
往期推荐：
- 点赞
- 收藏
- 关注作者
评论（0）