finneyyan

> 今天重新编译，再push上去测试了一下。流程可以走通，只是速度很慢。这里把编译命令贴这里： > > ``` > mkdir build-android && cd build-android > cmake -H.. -B. \ > -DBUILD_SHARED_LIBS=off -DGGML_QNN_ENABLE_CPU_BACKEND=on -DGGML_OPENMP=off \ > -DANDROID_ABI="arm64-v8a" \ > -DANDROID_PLATFORM=android-31 \ > -DANDROID_NDK=$ANDROID_NDK_ROOT \...

> 看截图这里确实用到了npu/gpu/cpu QNN这个backend用到NPU的话确实是比较慢的，现在的QNN框架下，除了自己写个Op加进去可能也没有啥其他好办法优化 现在这个Log里有显示用到npu吗？qnn的npu/gpu/cpu以及非qnn的CPU调用优先级是什么样的呢，有点困惑。 另外看到您在#34 Issue中提到“添加完全独立于qnn的hexagon-npu，可操作HVX寄存器”，这里的hexagon-npu和qnn-npu有什么区别？是否可以理解为hexagon-npu是底层接口可直接操作寄存器，而qnn-npu是上层抽象，因此前者会更快？

> 你的log里面显示初始化了npu/gpu/cpu，然后llama.cpp framework会按照注册顺序去询问backends是否支持op，所以这里framework发现npu支持op，就会使用npu执行 我在llama.cpp划分子图的位置加打印看了下，确实是您说的按照注册顺序去判断当前后端是否支持op，但疑惑的是，qnn_gpu/qnn_npu/qnn_cpu这三个后端似乎是共用一套qnn接口（包括supports_op这一接口），至少我没看到这三个后端各自的op支持列表；且split出的子图是qnn_gpu / qnn_cpu / cpu这三类，没有qnn_npu.  我的问题是： 1. qnn的三个后端之间是怎么区分和管理的？在qnn sdk内部吗？ 2. 如果我想调整offload优先级，比如 qnn_gpu 和 qnn_npu 同时支持的情况下，优先放到 qnn_npu去运行，应该怎么做呢，直接调整backends注册顺序吗？

> 另外还是建议尝试用`hexagon-npu`跑，这个虽然编译环境设置麻烦点，但是性能确实好些 我在尝试使用hexagon-npu，但仍无法下载该sdk，发现可能是因为我是自己的docker开发环境，缺少systemd，导致qpm安装不完整。权限问题暂时不好解决这个问题。 请问您在How-to-Build中提供的docker build脚本是否能够自动下载相关组件？我尝试了一下，提示无法拉取chraac/llama-cpp-qnn-hexagon-builder，进您docker hub的主页看也确实没有。这个docker是否还能获取到？

> 这种情况可以直接只注册npu backend，不过因为qnn本身tensor datatype的限制，估计支持的op不多 hexagon-sdk我再尝试一下，感谢指路。 想再请教一个QNN的问题把这一块搞懂。只注册qnn_npu后发现所有算子都被offload到了CPU了，qnn_npu上没有一个算子，观察到是因为npu op support在图示位置被返回了false npu的ctx->supported_types为0，那和tensor->type按位与岂不是必定为0、不支持任何算子？相比较而言qnn_gpu的supported_types为3，还是有一些type返回true的. 这样看来npu是不支持任何算子吗…… 

> +#ifdef GGML_HEXAGON_ENABLE_QUANTIZED_TENSORS > // TODO: remove npu from here if hardware quantization is supported > dev_ctx->enable_cpu_dequantize = device == QNN_BACKEND_CPU; > +#endif 测试是可以了的，所有的MUL和ADD算子都被offload到了npu上，感谢。 MUL_MAT无法offload过去是因为我使用的量化模型吗，gpu/npu不支持量化计算？

> 测试是可以了的，所有的MUL和ADD算子都被offload到了npu上，感谢。 > MUL_MAT无法offload过去是因为我使用的量化模型吗，gpu/npu不支持量化计算？ 我使用fp16模型进行补充测试，注册gpu时mul_mat成功offload到了gpu上，且运行正确；只注册npu时显示mul_mat offload到了npu上，但推理时会崩溃

> 传入两个模型其中int8模型进行prefill，其中q4k（int4模型）模型是来进行decode阶段的 请问prefill/decode为什么要分别用一个模型呢，出于哪些方面的考虑？

原因可能在于规格不匹配。查询手册发现NPU支持的mulmat算子类型需要输入、权重、输出全部为fp16，而我只有权重是fp16，输入和输出都是fp32. 这两天我会跟进这个问题，有进展会在下面贴出

> 原因可能在于规格不匹配。查询手册发现NPU支持的mulmat算子类型需要输入、权重、输出全部为fp16，而我只有权重是fp16，输入和输出都是fp32. 这两天我会跟进这个问题，有进展会在下面贴出 1. 不确定是不是这个原因了，因为我发现当前qnn convert函数中涉及到类型的判断和转换，对于我的算子场景 `fp16 + fp32 -> fp32`，是有符合的规则会自动将src0的fp16转换成fp32. 如果convert函数没问题，似乎应该是能运行的？  2. 我在mulmat算子前后各插入一个数据类型转换算子，使得mulmat规格调整为 `fp16 + fp16 -> fp16`，此时可以正常运行 3. 观察到 `bind_tensors` 函数是将数据从 `ggml_tensor.data` 拷贝到 `qnn_rpc_buffer`，但由于 `should_use_mem_handle` 始终为false，实际并未完成这一步拷贝。那么qnn-npu每次使用数据都要在sdk内部进行自动拷贝吗？还是说它和CPU共用内存？ 4....