- [x] 解决当前运行时的错误。 - [x] 解决推理精度问题[LLAMA系FP16精度问题已解决]。 - [x] 使用内存池管理临时使用的dev或者host内存(buddy system)。还需要考虑及时释放已经使用完的内存(stream 同步时释放, dst重用时释放,需要优化成更优雅的方式),避免OOM。目前支持单卡,如果内存存在问题,考虑是否先同步运行。 - [ ] 自定义算子,使用模板减少重复代码。 - [x] 接口中的alloc padding,tensor alloc等函数,重新审视下是否符合NPU的使用场景。 - [ ] 组合算子替换成融合算子,提高效率,提需求,包括要支持bs的mm算子。 - [x] 对所有的代码完善文档,所有的函数完善注释。 - [x] ollama适配,0代码0配置使用npu后端的ollama服务。 - [x] 考虑q5_x量化的可行性。 - [x] 模型运行过程中的精度对比,建议保留对比工具函数。 - [ ] 添加tensor自定义内存布局的测试用例。 - [x] cont,dup,cpy算子统一。 - [x] ascendc_rope_init_cache函数使用多核。 - [x] kernel函数中param拷贝耗时长,需优化(加载模型时统一拷贝需考虑ne,nb在transpose/permute过程中改变的问题) - [ ] 清理代码中的TODO。 - [x] rope_init_cache函数param拷贝input_ne踩内存问题定位,后续使用tiling进行参数传递 - [x] llama_kv_cache_update_internal()中进行k-shfit时存在问题,模型输出错误 - [ ] 算子异步发射 - [x] 文档 - [x] 多卡切图不正确,执行会卡住
Activity
hipudding commentedon Jun 11, 2024
llama.cpp 算子性能对比
[toc]
环境信息
构建命令
算子性能对比
GGML_OP_ADD 😄
GGML_OP_ACC 😄
GGML_OP_MUL 😄
GGML_OP_DIV 😄
GGML_UNARY_OP_GELU 😄
GGML_UNARY_OP_SILU 😄
GGML_UNARY_OP_GELU_QUICK 😄
实际上调用的是GELU算子,未实GELU_QUICK。
GGML_UNARY_OP_TANH 😄
GGML_UNARY_OP_RELU 😄
GGML_UNARY_OP_HARDSIGMOID 😄
GGML_UNARY_OP_HARDSWISH 😄
GGML_OP_NORM 😄
GGML_OP_GROUP_NORM 😄
GGML_OP_UPSCALE ❓ (算子执行出错)
GGML_OP_PAD 😄
GGML_OP_LEAKY_RELU 😄
GGML_OP_SCALE 😄
GGML_OP_CLAMP 😄
GGML_OP_ARGSORT 😄
GGML_OP_CONCAT 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_REPEAT 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_ARANGE 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_TIMESTEP_EMBEDDING 🌚 (需实现融合算子)
执行慢的原因:调用了多个算子组合,需要融合算子
GGML_OP_RMS_NORM 🌚(需修改算子接口)
执行慢的原因:gamma是必传参数,需要构造全1矩阵,rstd输出是必传参数,需要申请设备上内存。
GGML_OP_SQR 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_CONT 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_DIAG_MASK_INF 🌚 (需实现融合算子)
执行慢的原因:调用了多个算子组合,需要融合算子
GGML_OP_IM2COL 🌚 (需实现融合算子)
执行慢的原因:调用了多个算子组合,需要融合算子
GGML_OP_POOL_2D 🌚 (需实现融合算子)
执行慢的原因:max pool 调用了多个算子组合,需要融合算子,算子本身也慢
GGML_OP_SUM_ROWS 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_DUP 🌚
执行慢的原因:算子本身执行慢。
GGML_OP_SOFTMAX (需实现融合算子)
GGML_OP_ROPE (需实现融合算子)
GGML_OP_ALIBI 🌚 (需实现融合算子)
执行慢的原因:max pool 调用了多个算子组合,需要融合算子
hipudding commentedon Jun 11, 2024
量化算法需求
[toc]
计划支持常用量化算法
GGML_TYPE_Q4_0(最常用,ollama latest默认类型)
量化分组格式
量化算法描述
反量化算法描述
GGML_TYPE_Q4_1(实现方式相似,可一同实现,下同)
量化分组格式
量化算法和反量化算法与Q4_0基本一致,额外多了公共偏移。
GGML_TYPE_Q5_0
量化分组格式
量化算法和反量化算法与Q4_0基本一致,额外记录了每个数据的第五个bit位的值,在反量化的时候恢复。
GGML_TYPE_Q5_1
量化分组格式
量化算法和反量化算法与Q5_0基本一致,额外多了公共偏移。
GGML_TYPE_Q8_0
量化算法和反量化算法与Q4_0基本一致,区别是q8_0使用8位记录一个数据
Ascend实现难点
带量化的融合算子
GGML_OP_MUL_MAT (核心算子,性能对整个推理影响非常大)
输入2个矩阵(src0:量化后的tensor, src1:f32或f16),量化后的数据直接相乘,结果是float类型。
GGML_OP_MUL_MAT_ID
支持多个Moe专家一起计算,计算方法与GGML_OP_MUL_MAT类似。
GGML_OP_GET_ROWS
该算子实际上做了Embedding操作,但是允许输入的tensor是量化的tensor。输出F32的tensor。
GGML_OP_CPY
Tensor拷贝,允许从F16或者F32的tensor拷贝到一个量化的tensor中。
hipudding commentedon Jul 17, 2024
aclnn只能适配部分场景的算子:
UPSCALE:需要支持非整数倍scale
CONCAT:需要支持维度不同的tensor做concat
DUP:需要支持量化,非连续,不同shape,不同数据类型之间做拷贝
ROPE:不支持n_dims < ne0的场景,不支持fs,ef等参数为非默认值场景,且算子复杂,应考虑ascendc方式实现
MUL_MAT:量化相乘不支持batch
算法有差异的算子:
ARGSORT:排序使用了不稳定算法(千问在用)
不支持的算子
flash_attention:能提速
mul_mat_id:MOE需要使用
sigmoid: 新增算子,实现简单
conv_transpose_1d: 新增算子
TOP:
MUl_MAT
ROPE
SOFTMAX(alibi)
airMeng commentedon Jul 18, 2024
excellent work! hope to get access and try it myself soon!
vulkan : do not use tensor->extra (ggml-org#9407)
github-actions commentedon Mar 9, 2025
This issue was closed because it has been inactive for 14 days since being marked as stale.
common : Fix corrupted memory error on json grammar initialization (g…