案例分享1

背景描述

该客户的数据是从大盘分配固定百分比的流量，到某一个集群中，这个集群中有若干数量的NPU卡来处理这些请求，性能调优以降低这个集群中的卡的数量，且同时保证处理请求的时延不超标为目标。

分析过程

本地测试数据 ---> step1：

1. batching策略是在客户的服务端框架做的，可以通过参数，修改其攒batch时间，和档位；
2. 最大档位意思是从1到该最大档位中间每个bs都配置成档位；
3. 流数则表示一张NPU卡上的实例数，即最大可以几个推理任务同时并行跑；
4. 分核第一个数字是cube数量，第二个数字是vector数量；
5. 最后三列性能均是通过1000/平均时间*流数算出来的QPS值。

   

   通过上面数据表格，可以看到最大档位为16bs，流数为3时，QPS最高。需要注意的是，这个数据本身是本地均匀压力测试，bs分布不代表线上真实情况，所以跟线上实际表现，不一定完全一致，只能作为定向的分析手段。

线上bs分布 ---> step2：

从线上环境抓取的bs数据如下，可以看到大多数bs都很小，90%都是bs 20以下的，86%是bs 16以下。

那么这里结合上面的本地测试性能，我们就可以选择最大档位为16，流数为3。

线上bs性能调优 ---> step3：

实际数据，在流量高峰的时候，NPU的时延劣化严重，即时延随流量增大而增大，所以怀疑到利用率上面去。

通过本地测试数据（12/24分核的场景），对比当单个batch size为20的请求过来时，NPU卡上的处理情况如下所示：

• 如配置最大bs为20，则这个请求可以一次性跑完，耗时9.19ms，硬件资源只需要占用12/24的核数。
• 如配置最大bs为16，则这个请求会被拆分为两个bs 10，两个bs 10并行跑完，耗时7.01ms，时间比直接跑bs 20要少，但是占用的硬件资源是24/48的核数，比直接跑bs 20多一倍，这样就会导致NPU利用率过高。

通过修改最大bs配置，线上实际的平均时延无明显变化，但是NPU利用率平均下降5%，流量高峰时延劣化情况明显改善。