finneyyan

> 但性能非常差，大约只有CPU的十分之一。看到此前社区中有提到 convert 和 bind_tensors 耗时很长，但我的算子场景中并不是，绝大多数都是execute本身的耗时 如果这个测试没有问题，我很费解为什么execute耗时这么长，高通官方不是标称它们的NPU性能非常强吗？这中间是差在哪里，还能怎么优化呢？

> 你好，性能问题可以follow下这个thread哈，qnn的convert确实性能比较差 疑问就在这里， 我实测发现自己的场景下 convert 和 bind_tensors 耗时并不是很长，绝大多数都是execute本身的耗时。如果我的测试没问题，这么差的耗时和官方标称性能主要是差在哪里呢（**这是我最关心的问题：NPU为什么会这么慢，是本身就慢、llama.cpp框架引入的额外耗时、还是使用配置上的问题**）？ 我倒是看到了一些可选配置，但因为不熟悉所以也无法判断是否可以通过调整配置来优化性能 ``` if (device == QNN_BACKEND_NPU) { // TODO: fix graph config here for NPU std::vector graph_configs; auto hvx_config = make_graph_config(&kDefaultHvxConfig); graph_configs.push_back(&hvx_config);...

> 这里禁用这个rpc buffer的原因是，只在每个tensor里面使用rpc buffer，会无可避免的多一次memcpy，而如果直接把ggml tensor的data直接给qnn，有可能他会有更优的解决方案。 您是说把数据地址送到qnn sdk中，让其自行处理吗？这种方式会比手动拷贝到npu内存更好吗？ > 我将mulmat的 fp16 weight 放到CPU内存和QNN内存作对比（分别走CPU的.alloc_buffer和QNN的.alloc_buffer），发现二者最终的性能完全一致，这似乎不符合直觉 我又看了下qnn的.alloc_buffer，发现里面实际并没有分配npu内存，这可能是我上述尝试失败的原因。我查询到npu使用的内存是VCTM而非和CPU共用DDR，所以npu的内存管理都是在SDK内部进行的吗？

> 可以看下qnn内部打印的event的log 请问这个是怎么开启的，我没有看到这些log信息

我的耗时数据比您的更夸张，(1536x1536)*(1536*1)的f16 mulmat算子，没有dequant环节 QNN accelerator (execute) time, duration: 2.608 ms QNN (execute) time, duration: 5.268 ms 中间的gap全是RPC通信耗时和QNN框架耗时，这合理吗 ``` [profiler][MUL_MATf16_1536x1536f16_1536f16]print_profile_events start ---------------- [profiler][MUL_MATf16_1536x1536f16_1536f16]event[0]: Number of HVX threads used, count: 4 [profiler][MUL_MATf16_1536x1536f16_1536f16]event[1]: RPC...

> One thing comes to my mind is the fast rpc overhead, thought we can have some optimization here, but have a question: did you get those timeout from the...

About optimizing `llama-cli` performance, I have some ideas: 1. Figure out the extra time about `ggml_backend_sched_split_graph` 'clear_tensors' and `ggml_gallocr_init_tensor`, they are too exaggerated. But I know little about Hexagon and...

A new test: When I enable FA, llama-cli decoding perf from 0.84 tok/s to 1.1 tok/s. split-graph stage: ``` ggml_backend_sched_split_graph cost 144.407 ms -> 130.47 ms clear_tensors cost 269.318 ms...

> Hi [@finneyyan](https://github.com/finneyyan) , wanna ask something before another testing, for the benchmark, are you running with the release build, right? Yes, the debug build-type is much more slower

> Reuse compute graph maybe helpful. I find ggerganov has done something about this but not merged yet (https://github.com/ggml-org/llama.cpp/pull/14482). I'll try it. It has been merged today. I simply merge...