案例分享2

开箱：在未开启优化的场景（只沿用算子模式的配置，gatherV2高性能，Cube开启HF32），模型单次modelExecute需要51ms，离目标性能差距在10倍。

1. 因为串行执行，算子的耗时是稳定的，profiling上可以直接基于op_name去重后分析单次推理的性能。

   

2. 这里通过按task_duration倒排，可以看到每次推理执行时间在44ms左右，同时因为大量dynamic算子，引入了7ms左右的task_wait时间（等待host调度）。

   分析这里的Gather算子shape和周遭结构，首先dynamic的Gather算子，使用的是逻辑核，无法通过GE的限核功能限制，在这里不满足需要兼顾高压下性能的前提，同时，步骤1图中Gather算子的index数量只有至多20000，理论上分析不需要ms级别（实际因为数据重复度较高，有较大的核间冲突）。

   从结构上分析，这部分Gather来源于如下结构中第一个Gather。

   

   这段子结构因为引入Where算子，后续算子的shape都不固定，所以引入动态子图，同时由于Where是3类算子（输出shape不固定），会导致动态图执行到Where算子后，将shape信息返回host，才能执行后续算子的shape推导。导致整网出现大量的task_wait时间。

   从执行逻辑上分析，这段子结构在原始Gather逻辑上扩展了一个遇到<0的索引则返回全0向量的功能。同时，基于重复数据做分析，这里的输入实际上带着很长的一段padding的0，实现一个自定义的Gather算子，同时对部分table在UB内全载之后能解决这段动态子图/Gather动态限核不生效/Gather性能问题。

profiling分析-->step2：

通过自定义算子解决上述问题后，重新采集profiling进行分析。当前串行执行时间已经降低到9ms左右，同时default_gather的性能对比原始场景性能有了极大提升。

然后这里没有被DefaultGather替代的算子，不在那个动态结构中，但是对于序列长度仅为4000的Gather算子，从理论分析也不需要180us+的时间（这里的问题实际上是因为GatherV2高性能模式在全载场景实现导致的）。从算子设计上，对于shape为400,50的table shape，直接全载之后，性能会有较大提升。

这里通过自定义Gather算子覆盖该场景（同步算子优化需求）。

profiling分析-->step3：

通过CustomGather实现全载逻辑后替换剩余Gather算子后，模型串行时间来到了6.1ms左右。在这个场景下，就可以针对模型的优化点去全量扫一遍。

继续分析瓶颈点，top的TopK和Equal，TopK算子因为底层不支持SIMT，所以通过vec上一套较为复杂的算法实现，导致时延很长，从算子上无优化空间。但是基于用户实际业务，这里的TopK的输入，也有包含padding的0，所以设计上如果给TopK算子传入有效长度，能大幅降低TopK算子的平均执行时间（对TP99影响不大，但会影响最大QPS）。这个优化点依赖用户上层框架改动传入实际长度，所以在这个示例中暂未实现。

针对Equal算子，1,4000;400,1的shape执行在230us+，理论上距离vector算子的算力相差很远。这里实际是因为Int64的实现造成的，通过测试，同shape的Int32 Equal算子只需要30us不到，Int64相较于Int32，是线上肯定不可能需要近一个数量级以上的时间。这里针对这种双广播场景，单独设计了一个Equal的Int64实现，可以将Equal算子时延降到75us上下。

同时，我们发现这里还有Unique，Where等AICPU算子，

算子需要依赖上层拆图（当前场景拆图逻辑受用户控制，在示例中未处理）。而Where算子，来源于以下这个结构，可以通过自定义PASS消除Where引入的动态结构。

同时针对这种batchMatmul，将运算逻辑替换为2,400, 300 * 2, 300, 16后，性能也能有提升。

最终模型在通过自定义Equal、消除Where，替换BMM后，串行时延到了4.6ms，基本满足性能需求。