骁龙大赛-技术分享第5期干货汇总来啦——直播问题&答疑整理

1. 在 QAI AppBuilder 中部署模型时，哪些情况会导致模型“不兼容”？如何判断模型能否在 NPU 上运行？

答复：没有“不兼容模型”这种说法，理论上所有能够通过TensorFlow，PyTorch 或 ONNX Runtime推理的模型，都可以转换成 QNN 上下文二进制格式并运行在NPU上的。
大家容易遇到的比较难处理的问题通常不是模型能不能转换，不是模型能不能跑在NPU上，难点在于如何把模型量化成更小的精度的模型并且能够保证精度不会损失过多。量化成更小的精度意味着可以占用更小的内存，运行更快，但过度优化容易导致精度损失，需要花更多时间去优化，让损失降到合理范围。

2. 通过 LangFlow 调用本地模型是否会带来额外延迟？如果延迟比较高，可以怎么优化？

答复：通过 LangFlow 调用本地模型，模型本身不会产生额外延迟，但 LangFlow 内部的实现有可能会导致模型的输出不能及时显示到 LangFlow 界面上，这完全取决于 LangFlow 内部的实现。如果要优化的化，更多的还是从 LangFlow 这个开源框架的角度去优化。

3. LangFlow 构建的流程如果要嵌入本地应用（桌面端或移动端），有没有推荐的接入方式？

答复：通过 LangFlow 构建的模型应用需要运行的话，首先需要 LangFlow 在后台运行。LangFlow 可以把我们自己搭建的 Flow 导出成基于 Web 的 API，自己的应用程序可以通过这些 API 来调用我们在 LangFlow 中创建的 Flow 提供的功能。

4. 多模态模型（如 CLIP、Whisper）如何使用 AppBuilder 部署？是否有现成的案例？

答复：这两个模型，我们在 QAI AppBuilder GitHub (https://github.com/quic/ai-engine-direct-helper) 上正好都有相应的例子，这些例子不需要任何修改，可以直接运行，可以去我们的 GitHub 上获取代码，尝试一下。

5. 本地大模型的首 token 延迟一般能做到多少？是否能支持实时对话？

答复：由于我们 NPU 架构设计的特性，对于用户输入内容的处理非常快。而且在对话的场景中，用户一次输入的 tokens 不会太多，所以首 tokens 延迟应该不会成为对话场景的瓶颈。

6. 如果模型结构是自定义的（非主流架构），在 NPU 上部署会不会很困难？是否支持自定义算子？

答复：我们的 QAIRT 是支持自定义算子的，正如第一个问题中提到的，只要模型能够通过TensorFlow，PyTorch 或 ONNX Runtime推理，基本都能转换到 NPU 上来运行。

7. AppBuilder 是否支持模型蒸馏或知识蒸馏？

答复：请注意， QAI AppBuilder 是专门用来在高通平台的 NPU 上加载模型并进行推理的工作，不支持训练模型或对模型进行蒸馏。

8. GitHub示例代码里的性能benchmark靠谱吗?实际项目中能达到那个水平吗？

答复：仅供参考。Benchmark通常在“理想环境”（清空后台、散热良好、特定系统版本）下测得。实际项目中受限于设备散热、后台负载和系统资源竞争，性能通常会打折，建议预留 10%-20% 的余量。

9. 老师能讲讲模型转换的完整pipeline吗?从训练到部署中间有哪些坑要注意？

答复：流程通常是：训练(PyTorch/TF) -> 导出(ONNX) -> 量化/转换(QNN工具链) -> 端侧部署(.qnn/.so)。
坑： 最常见的是算子不支持（导致回退CPU，极其缓慢）和量化掉点（精度损失严重，需校准数据调优）。

10. 老师 AppBuilder跟其他推理引擎(比如TensorRT、OpenVINO)相比，在骁龙平台上的优势在哪？

答复：核心优势是硬件原生支持。TensorRT 专为 NVIDIA GPU 设计，OpenVINO 专为 Intel 芯片设计，它们无法调用骁龙的 NPU。QAI AppBuilder/QNN 是骁龙 NPU 的原生指令集，能效比和速度是最高的。

11. LangFlow跟传统的LangChain比，在本地部署上有啥优势?灵活性会不会差一些？

答复：优势在于可视化，降低了原型搭建和调试的门槛。灵活性确实不如纯代码（LangChain），对于复杂的自定义逻辑，LangFlow 可能需要手写 Custom Component（自定义组件）来实现。LangFlow中很多可视化组件其实是直接调用LangChain实现的。

12. 遇到内存溢出或者显存不足有没有动态batch、gradient checkpoint这些技术可以用？

答复：Gradient Checkpoint 是训练技术，推理阶段用不上。 推理阶段显存不足，建议使用：模型量化（INT8/INT4）、分块推理、或者限制上下文（Context）长度。动态 Batch 主要提升吞吐量，对降低单次请求的峰值显存帮助有限。

13. NPU的算力跟最新的GPU比怎么样?适合跑Transformer架构的模型吗？

答复：绝对算力低于桌面级独立显卡，但能效比（性能/功耗）远超 GPU。NPU 非常适合 Transformer，因为其专门针对 Transformer 核心的大规模矩阵乘法做了硬件级优化。

14. 边缘设备上部署这套方案，稳定性和功耗表现如何?适合24小时运行吗？

答复：NPU 的功耗远低于 CPU 和 GPU，发热较小，理论上非常适合 24 小时常驻运行。但实际稳定性还取决于设备的被动散热设计，如果散热不佳，长时间满载可能会触发降频。

15. NPU的调度机制是怎样的?会不会互相抢资源？

答复：会有资源竞争。NPU 资源通常由底层驱动（QNN/Hexagon）管理。如果多个应用或多个模型同时请求 NPU，系统会根据优先级排队或分时调度。建议在应用层做串行化处理，避免多线程并发抢占导致延迟抖动。