智算服务器SGM7-40,适配主流LLM,单卡可运行70B的大语言模型
SOM1684,搭载算能BM1684,支持16路高清视频分析
Core-1684-JD4,搭载算能BM1684,支持16路高清视频分析
SBC-6841,搭载算能BM1684,支持16路高清视频分析
iCore-1684XQ,搭载算能BM1684X,支持32路高清视频分析
Core-1684XJD4,搭载算能BM1684X,支持32路高清视频分析
Shaolin PI SLKY01,搭载算能BM1684,支持16路高清视频分析
QY-AIM16T-M,搭载算能BM1684,支持16路高清视频分析
QY-AIM16T-M-G,搭载算能BM1684,支持16路高清视频分析
QY-AIM16T-W,搭载算能BM1684,支持16路高清视频分析
AIV02T,PCIE板卡,1684*2,半高半长
IVP03X,搭载算能BM1684X,支持32路高清视频分析
IVP03A,微服务器 被动散热,12GB内存
Coeus-3550T,搭载算能BM1684,支持16路高清视频分析
EC-1684JD4,搭载算能BM1684,支持16路高清视频分析
CSA1-N8S1684,算力集群服务器,BM1684*8,1U
DZFT-ZDFX,ARM+DSP智能封条分析,搭载算能BM1684X
ZNFX-32,搭载算能BM1684,支持16路高清视频分析
ZNFX-8,ARM+DSP架构,隔爆兼本安分析装置符合煤安要求,搭载BM1684X
EC-A1684JD4,微服务器主动散热,16GB内存,32GB eMMC
EC-A1684JD4 FD,搭载算能BM1684,支持16路高清视频分析,16GB内存,32GB eMMC
EC-A1684XJD4 FD,搭载算能BM1684X,支持32路高清视频分析
ECE-S01,搭载算能BM1684,支持16路高清视频分析
IOEHM-AIRC01,微服务器,主动散热,搭载算能BM1684,支持16路高清视频分析
IOEHM-VCAE01,搭载算能BM1684,支持16路高清视频分析
CSA1-N8S1684X,算力集群服务器,BM1684X*8,1U
QY-S1U-16,1U版本BM1684盒子
QY-S1U-192,算力集群服务器,BM1684*12,1U
QY-S1X-384,算力集群服务器,BM1684X*12,1U
视频实时压缩转码上云和监测异常事件,增强道路运行安全事件的发现和处置能力
为交通拥堵、行车安全、车辆违法和道路污染治理问题赋能
以国产化算力支撑海量视频的结构化解析,服务警务应用实战
以数据为中心打造“智能、协同、高效、创新”的步态识别大数据分析系统
为用户快速构建融合人、车、通行等多维数据的业务能力
对生产全过程、全方位实时感知与精细化监管,推进应急监测智能化,赋能风险识别预警
为粮仓、棉仓等大型仓储园区的办公、质检、磅房、库区等区域提供了违规行为和异常事件的安全监控方案
全量场景感知预警,赋能烟草生产作业过程数智化
为白酒生产企业细化风险监测因素,建立智能感知与预警感知体系,提高企业安全生产管理水平
以云边协同的新型算力基础设施赋能各类数字城市场景,为数字经济发展提供源动力
以自动化训练推理一体化平台为基础,助力算力/算法整合应用快速、高效工程化落地
typedef struct {
int N, C, H, W;
unsigned long long output_addr;
unsigned long long input_addr;
} __attribute__((packed)) param_t;
这里默认对c维度进行softmax。
测试用例参数:
param_t params[] = {
{.N = 1, .C = 370, .H = 13, .W = 13 }, // 0
{.N = 1, .C = 1000, .H = 1, .W = 1 }, // 1
{.N = 4, .C = 2, .H = 157, .W = 283}, // 2
{.N = 79, .C = 4090, .H = 1, .W = 1 }, // 3
{.N = 6132, .C = 21, .H = 1, .W = 1 }, // 4
};
一般做法
算丰算子库中没有提供softmax算子,因此需要使用基础算子完成softmax操作。
softmax的表达式为:
可以看到需要使用的有exp算子,div算子,以及一个跨channel求和的操作。
算丰的算子库也没有提供跨channel求和的操作。这里提供两个思路,一个是使用权重为1.0的1X1卷积,需要多开辟一些空间存放卷积核参数,另一个是由于在计算c维度的softmax的时候,HW的大小并不会有影响,因此,可以将C维度移动到H维度,原本的H,W维度移动到W维度,[N,C,H,W]->[N,1,C,H*W],这样可以通过在新的H维度计算avgpool再乘以元素个数来达到求和的目的。
local_addr_t input_addr, output_addr, sum_addr;
S2L(input_addr, param->addr);
cal_exp(input_addr); // input = exp(input)
cal_sum(sum_addr, input_addr); // sum = input.sum()
div(output_addr, input_addr, sum_addr); // output = input / sum
L2S(param->output_addr, output_addr);
这里的按N切分就比较简单,例如用例4,只需要切分到合适的N就可以完成计算:
local_addr_t input_addr, output_addr, sum_addr;
for(int i=0;i<blocks;i++)
{
S2L(input_addr, param->addr + input_skip_bytes);
cal_exp(input_addr); // input = exp(input)
cal_sum(sum_addr, input_addr); // sum = input.sum()
div(output_addr, input_addr, sum_addr); // output = input / sum
L2S(param->output_addr + output_skip_bytes, output_addr);
}
在softmax中,在使用avgpool计算求和时,由于将C维度移动到了H维度,因此原本的C维度就为1。
但是我们知道,比赛使用的有64个NPU,当C为1时,仅仅会使用第一个NPU进行计算。因此,可以通过将N合理分配到N以及C两个维度,使得既能通过N的切分存放数据,也能够最大利用NPU的算力。
在计算用例2时,由于H和W都为1,因此可以将C维度的4090分摊到H和W维度,将池化由[4090,1]改为[409,10],这样能够加快NPU的计算。
另外,例如用例3,无论怎么调整,C维度的占用都比较少,这时可以调整数据搬入时的stride,使得C维和H维转置,[4,2,157,283]−>[4,157,2,283],这样即可以避免NPU使用不足的问题,也可以避免local memory不够用的问题。