分核

使用背景

以A2服务器配置的NPU卡为例，一个卡中包含ai cube core计算单元24个，ai vector core计算单元48个，算子执行时，会根据shape来计算所需要的核数，一般情况下会用满24个cube core或者48个vector core；算子使用的核数越多，算子每个核需要执行的计算量就会越少，导致算子的耗时降低。

针对CTR推理场景，有多实例并发的因素，对于算子的性能分析，不能单看算子的耗时，还需要看算子占用的资源总量，即核数。假设某个cube算子耗时100us，占24个cube core，那么在100us的时间内，NPU单卡只能执行这一个算子。同时，假设在相同算子，限核到12个cube core后，耗时150us，则相当于在150us内实际执行了2个该算子，平均执行时间只有75us，相较于原始场景更优。

这里，限核带来的收益主要有如下几点：

1. 对于us级别小算子，大部分时间在算子启动头开销上，占用的核越多，头开销就会越大。
2. 因为CTR场景，大部分算子shape都不大，在切核后，单核内mini tiling的次数可能不会太多，这些mini tiling可能在尾块造成算力浪费。
3. NPU核间访问相同地址会有访存冲突，造成访存速率大幅度下降。索引类算子，如Gather，如果数据分布较为集中，核越多，核间的冲突会越严重。

   同时，需要注意，核数也不能限制得太低，一般来说，vec/cube 的限制都分别在6-12核中（因为CV实际上是模型上的不同资源，所以不用保证硬件引入的1:2比例）。

使用约束

在单流场景下，分核后的推理耗时对比不分核的推理耗时，通常都会有劣化；在时延敏感场景需要根据时延要求把控好时延劣化范围。

具体案例

• TensorFlow demo：修改方法可参考《TF Adapter 接口（1.x）》的“session配置参数说明”章节配置aicore_num参数。
• PyTorch demo：该特性暂不支持。