【常见问题与解答】2025 骁龙人工智能创新应用大赛

[csdnsqst0050]

   

技术文档

WoS AI 应用程序开发指南

• https://docs.qualcomm.com/bundle/publicresource/topics/80-62010-1/ai-app-development.html?product=1601111740057789

QAI AppBuilder

1. QAI AppBuilder - https://github.com/quic/ai-engine-direct-helper
2. QAI AppBuilder 文档
   • WoS：https://docs.qualcomm.com/bundle/publicresource/80-94755-1_REV_AA_QAI_AppBuilder_-_WoS.pdf
   • Mobile & ONNX RT：（待更新）
3. 大语言模型系列(1): 3分钟上手，在骁龙AI PC上部署DeepSeek!
4. 大语言模型系列(2): 本地 OpenAI 兼容 API 服务的配置与部署
5. QAI AppBuilder 快速上手(1): 环境配置
6. QAI AppBuilder 快速上手(2): 图像超分应用实例
7. QAI AppBuilder 快速上手(3): 图像修复应用实例1
8. QAI AppBuilder 快速上手(4): 图像超分应用实例2- Real_esrgan_general_x4v3
9. QAI AppBuilder 快速上手(5): 图像分类和识别应用实例
10. QAI AppBuilder 快速上手(6): 图像分割应用实例
11. QAI AppBuilder 快速上手(7):目标检测应用实例
12. QAI AppBuilder 快速上手(8): 图像修复应用实例2
13. QAI AppBuilder 快速上手(9): 人体关键点检测应用实例
14. QAI AppBuilder 快速上手(10): 图像生成应用实例

公开课材料

大赛公开课之一 -  高通技术公司AI工具链介绍

Qualcomm AI Engine direct (Qualcomm AI Software Stack) – 文档

• 公开文档 | CLI 工具文档 | C API 文 | API 使用和推理引擎实现示例

大赛公开课之四 – 高通AI模型开发部署工具包概述

QAIRT SDK分析和调试 – 文档

• 公开文档 | QNN HTP 配置文件与 QNN HTP Optrace 文档 | QAIRT Visualizer 文档 | QAIRT Python API 文档

欢迎浏览与了解更多 Qualcomm AI Engine direct 中的高级用例！

 

常见赛事问题

 

技术问题解答

大赛公开课一：

Q1：在“AI影像”方面，用 NPU （如HTP）处理实时视频超分或降噪，和 CPU/GPU 相比最大的优势是什么？

A1：NPU 最大的优势是低功耗和高速度。它在处理定点模型时比 CPU 快得多，也比 GPU 更高效。GPU 主要处理浮点计算，若要跑定点模型会比较麻烦。NPU 在实时超分 (super resolution) 和降噪 (denoise) 方面已经有成熟商用案例，尤其在功耗和实时性能上优势明显。

 

Q2：Qualcomm AI Stack 里有没有比较实用的工具可以帮助提升模型在手机端的推理速度？

A2：Qualcomm AI Stack 中工具有很多。如果跑浮点模型 (FP16) ，可以直接在端侧运行；跑定点模型时，我们支持 INT4、INT8、INT16 等多种量化精度。精度位数越低，速度通常越快。另外，我们在端上也提供多种功耗模式（burst、power_saver、default），在不同模式下模型的运行时间会有所不同。整体来说，Qualcomm的工具链已经比较成熟完善。

 

Q3：用SDK的离线工具做模型量化的时候，是不是主要就是在精度和性能之间做取舍？还有别的要注意的吗?

A3：确实，模型量化的核心是在精度与性能之间做平衡，但在使用离线工具时，还有一些细节需要注意。SDK 提供两种方式：在线 (online prepare) 和离线 (offline prepare)。在线模式的优势是操作简便，不需要考虑具体平台差异，模型可以直接在端侧运行，但执行速度相对较慢。离线模式则是在 PC 上先对模型进行序列化处理，把模型的算子、指令和数据结构化后再加载到设备内存 (DDR) 与计算单元 (VTCM) 执行，运行速度更快，也更利于优化。不过这种方式需要根据目标平台的指令集和硬件特性进行调整。在实际使用中，开发者除了关注精度和性能的权衡外，还应注意目标平台兼容性（确保序列化模型与硬件匹配）、数据分块与优化方式（不同算子可能需要单独优化）、以及配置参数（如 DDR 与 VTCM 交互效率、SOC 设置等）。总体来说，离线量化能带来显著的性能提升，但需要根据平台特性做好前期优化和验证。

 

Q4：有转换好的qwen3的模型吗？或者转换好的模型去哪里下载呢？

A4：关于LLM大模型，或者说LVM就是大语言和视觉模型，可以在 Hugging Face 或 模型广场 上面直接下载，如 Qwen-2-7B、Phi-3.5、Stable Diffusion 1.5、ControlNet 等，上面基本都能直接找到并使用。

 

Q5：既然AI Runtime Stack是通用的，那把手机上优化好的模型搬到车机上，主要会遇到哪些坑啊？需要特别注意啥？

A5：理论上可以无缝迁移，但要注意车机平台的硬件架构（如 NPU 类型、算子支持度）可能不同。有些算子在车机上不支持，需要改用 FP 实现。

 

Q6：实际开发中，从模型转换到最后在NPU上跑起来，哪一步最容易踩坑或者最耗时间啊?有啥经验分享吗?

A6：整体来看，最容易出问题、也最花时间的环节是模型转换和量化阶段。在开发流程中，如果直接使用现成模型（例如从 Hugging Face 或 模型广场 下载的 MobileNet、超分、去噪模型），通常比较顺利；但如果是自己训练的模型，再转成 Qualcomm AI Runtime 支持的格式，这一步可能会花费较多时间。转换阶段常见的问题主要集中在算子兼容性，不同框架导出的模型若使用了不支持的算子，就容易出现转换失败。建议在 PC 端先搭好 Runtime 环境，确保模型能正确运行，同时对照官方文档中的算子支持列表进行检查。如果模型成功转换，接下来就是量化阶段。需要注意的是：如果进行后量化 (post-training quantization) ，建议准备几百到上千条有代表性的数据进行校准，数据越多精度越稳；如果在训练阶段已插入 fake quant 节点或导出了 encoding 信息，转换时可直接读取量化参数，能有效避免精度损失。

在调试时若发现推理结果异常或精度偏差较大，第一步应回溯检查模型转换和量化环节。高通也提供了逐层对比工具（如 QL、QAIRT），可 layer-by-layer 地分析输出差异，快速定位问题。总体来说，模型转换、算子兼容性和量化数据准备是最容易踩坑的部分，若这几步处理得当，后续在设备端部署通常会非常顺利。

 

Q7：SDK 都有啥工具可以帮我们部署模型呀？

A7：我们提供多种工具：低级 C++ API、Python 接口（QAI AppBuilder），以及离线模型转换、量化优化工具。开发者可根据项目选择端侧或 PC 端部署方式。

 

Q8：老师能讲讲吗，Qualcomm AI Stack里那个性能最好的API是啥?叫啥名字来着?

A8：我们主要有两种 API：1、C++ API：AI Runtime 的 examples 里有完整示例，可通过 CMake 编译，跨平台兼容性好；我们是提供CMakelist，也提供Makefile，这两种根据开发者的喜好可自行选择，两种都能编译。我们是这一套API在Android上是用NDK来编译，在PC上我们是用Visual Studio来编译，或者用CMakelist，CMakelist是我们推荐的，因为CMakelist可以可以跨平台，所以如果要用C++编译，我们是推荐CMakelist，CMakelist 在Linux平台，在我们的PC平台，或者是我们的高通的arm的PC，在X86的PC，C++就是CMakelist 这三种平台是可以同时兼容而且并不需要做过多的修改。2、Python API（QAI AppBuilder）：封装程度更高，用几行代码就能跑，但集成灵活性略低。一般推荐使用 CMake + C++ 版本，性能更强。开发者也可以根据习惯和场景来选择。

 

Q9：在 AI PC 上推理时，输入输出是否支持零拷贝？内存是 CPU 的内存吗？

A9：在 Mobile 端，我们是支持 Zero Copy 的。Zero Copy 的原理是数据可以直接从 CPU 注入到 NPU 的 RPC memory（也就是 CDSP 内存），通过 FastRPC 通道实现高速传输，避免了多次内存拷贝。

而在 AI PC 上，我们采用微软的 MCDM 驱动体系，取代了原先的 FastRPC。MCDM 本身就等价于 Zero Copy，它能让数据直接送入 NPU 驱动，因此不再单独提 Zero Copy 的概念。AI PC 使用的内存依然是 DDR 内存，NPU 与内存之间通过 DDR 与 VCTM（片上内存）交互。我们还提供了相应的分析工具，可以观测到 DDR 与 VCTM 之间的 spill/fill 操作，帮助开发者分析性能瓶颈，例如当预期 10 毫秒的任务实际耗时 80 毫秒时，可以据此定位问题。

 

Q10：Qualcomm AI Stack 有没有工具让开发者更方便地部署模型？

A10：有的。AI Runtime Stack SDK 分为两部分：一是 QNNAPI 的 low-level API（C++代码），支持 Android 和 PC；二是 Python 工具 QAI AppBuilder，它封装了 QNN 接口，用起来更简单。开发者可以根据自己的习惯选择使用哪种接口，两者都能支持端侧部署。

 

Q11：模型量化数据量有要求吗？

A11：我们建议提供足够多能覆盖数据范围的数据量。

 

大赛公开课二：

Q1：在使用 QAI AppBuilder 进行模型部署时，如果模型体积较大或计算量较高，有哪些常用的优化手段可以提升在 NPU 上的推理性能？

A1：模型体积越小，推理速度通常越快。针对大模型或计算量较高的模型，可以通过量化（Quantization）来优化性能，例如将模型从 FP32 精度转换为 INT8 或 INT4。
这样不仅能显著减少模型体积、降低内存占用，还能减少数据传输带宽，提高在 NPU 上的执行效率。当然，量化也会对精度带来一定影响，因此通常需要进行量化感知训练（QAT）或后量化精度调优。
此外，在某些复杂场景下，也可以结合 CPU、GPU 与 NPU 的算力，让不同任务在最合适的硬件单元上执行，从而获得整体最优性能。

 

Q2：部署完模型后，怎么快速验证它是否正常运行、性能是否达标？有没有推荐的评估方法？

A2：部署完成后，可以通过运行推理测试并保存输出结果来检查模型功能是否正确。
对于性能验证，QAI AppBuilder 提供了 profiling level 参数，可在配置函数中设置性能分析等级。
将日志等级（log level）设为 info，推理时系统会自动打印出模型加载时间、推理耗时等性能数据。
通过这些日志即可快速判断模型是否运行正常、性能是否达标。

 

Q3：如果把 CV 模型落到终端设备上，有哪些常见的坑是开发者容易踩到的？有没有一些实战经验可以分享？

A3：

1.  在端侧部署 CV 模型时，常见问题主要集中在两个方面：输入输出数据处理不当
   1. 模型前后处理通常在 CPU 上执行，若数据量大，可考虑使用多线程提升处理速度。
   2. 对于图像类任务，也可利用 GPU 进行图像转换、缩放等操作，以加速前后处理。
2. 数据格式不匹配
   1. 需将原始数据（如图片）转换为模型所需的张量（Tensor）格式，并正确处理输出张量。
   2. 不同模型的输入输出格式差异较大，可参考官方 GitHub 上的推理示例（包含二十余个模型案例），根据需要调整数据预处理和后处理逻辑。

只要解决好前后处理逻辑，并正确适配模型格式，就能充分发挥骁龙 AI PC 的算力，开发出高性能、低功耗的端侧 AI 应用。

 

Q4：哪一种部署方式具有更多的模型适配？

A4：目前来看，Python 格式的模型（如 PyTorch、TensorFlow）在生态上最为丰富。但若要在 骁龙 AI PC 的 NPU 上获得最佳性能与最低功耗，推荐使用 QAI AppBuilder 或 QAIRT SDK 部署 QNN 二进制上下文 格式的模型。这两种方式中，QAI AppBuilder 操作更简便，同时在“模型广场”上已有数百个经过转换的 QNN二进制上下文 模型可直接下载使用。若开发者有自训练的模型，也可根据官方文档自行转换为 QNN 格式进行部署。

 

Q5：用 QAI AppBuilder 跑大语言模型（LLM）时，怎么让内存占用更小、速度更快？有优化技巧吗？

A5：大语言模型通常参数量庞大，内存占用和推理速度主要取决于模型规模：

1. 优化方向包括：选择合适规模的模型：在满足任务需求的前提下尽量使用小模型，可显著降低内存占用并提升速度；
2. 使用量化模型：在 NPU 上运行的 LLM 通常经过 INT8 或 INT4 量化，较 FP32 模型体积更小、速度更快，同时节省内存与带宽。

 

Q6：本地跑 AI 模型和放在云端相比，各有什么优缺点？

A6：云端运行模型的优势在于可以支持更大、更复杂的模型，因为云端算力更强，生成效果通常也更好。不过，这也意味着需要通过网络传输数据，响应速度会受到延迟影响，而且涉及的数据隐私需要额外考虑，同时大多数情况下还需要支付云服务费用。
相比之下，本地端侧运行模型的优势在于延迟低、响应快，数据和指令不必经过网络传输，隐私和安全性更高，而且运行成本几乎为零，非常适合需要离线处理或涉及敏感数据的应用场景。但端侧设备的算力和内存有限，因此模型规模和复杂度通常比云端受限。

 

Q7：如果要同时跑好几个模型，QAI AppBuilder是怎么分配资源的呢?会不会卡?

A7: QAI AppBuilder 采用多进程架构来高效分配资源并防止应用卡顿。
其核心机制是能够将AI模型加载并运行在独立的后台服务进程中。在初始化模型时，通过指定不同的进程名称（proc_name），可以将计算密集型的推理任务从主应用（尤其是UI线程）中剥离出去。
这种设计的优势体现在：

1. 资源隔离：每个模型或每组模型在独立的进程中运行，内存和计算资源相互隔离。单个模型的异常不会影响主应用或其他模型的稳定性。
2. 避免UI卡顿：对于图形界面应用，AI推理在后台进程中执行，UI线程仅负责任务分发和结果回收，从而确保了用户界面的流畅响应。
3. 并行处理：操作系统能够将不同的模型进程调度到多个CPU核心上执行。结合骁龙芯片上AI硬件（如HTP）的并行处理能力，可以实现真正高效的多模型并行推理。

因此，通过合理利用其多进程能力，QAI AppBuilder 可以有效管理多个模型的资源调度，避免因AI计算导致的应用卡顿。

 

 

Q8：支持的模型有什么限制吗?模型大小和性能要怎么平衡?

A8: QAI AppBuilder 对模型的支持能力主要继承自底层的 Qualcomm Neural Network (QNN) SDK。

1. 模型格式与算子：平台支持通过QNN工具链转换后的主流模型格式（如ONNX, TensorFlow等）。模型能否成功运行，关键在于其内部的所有计算算子（Operations）是否被目标硬件后端（如HTP, CPU）所支持。
2. 模型大小：模型体积主要受限于目标设备的物理内存（RAM）。过大的模型可能导致加载失败或运行时内存溢出。

平衡模型大小与性能的策略：

• 量化（Quantization）：此为最核心的优化手段。通过将模型权重从FP32转换为FP16或INT8等低精度格式，可显著减小模型体积、降低内存占用并大幅提升在HTP等专用硬件上的推理速度。
• 模型架构选型：优先选择为移动和边缘设备设计的轻量化网络架构，例如MobileNet、EfficientNet等。
• 模型优化技术：可以结合使用剪枝（Pruning）、知识蒸馏（Knowledge Distillation）等先进技术，在保持精度的同时进一步压缩模型。

总的来说，平衡的关键在于应用有效的量化策略和选择合适的轻量级模型架构。

 

Q9：我们项目只是用到一个小模型效果，用 QAI AppBuilder 上手会不会很复杂？

A9: 上手不复杂。QAI AppBuilder 对核心API进行了高度封装，旨在简化AI模型的部署流程。对于仅使用单个小模型的项目，集成过程非常直接。
以Python接口为例，开发者仅需几步即可完成集成：

1. 配置环境：通过QNNConfig.Config()接口一次性完成底层库路径和运行后端的配置。
2. 模型初始化：通过继承QNNContext类并传入模型名称和路径，即可轻松完成模型的加载。
3. 执行推理：直接调用Inference方法，传入输入数据，即可获得推理结果。
4. 资源释放：对象的生命周期结束时，资源会自动被回收和释放。

相较于直接操作底层的QNN C API，AppBuilder屏蔽了大量复杂的细节，使开发者能更专注于业务逻辑的实现。

 

Q10：在Windows和Android平台上使用，配置、接口或者调试方式有什么区别吗？

A10：是的，在不同平台上使用时，配置、接口和调试方式均存在差异，需要遵循各平台的开发规范。

1. 配置区别：
   • Windows：主要涉及Python运行环境的依赖配置，以及确保QNN SDK相关的DLL库文件路径正确。
   • Android：需要在Android Studio项目中配置NDK，并通过CMake或ndk-build来集成C++核心库。依赖的库文件（.so）需要打包到APK中。
2. 接口语言与形式：
   • QAI AppBuilder 提供统一的 C++ 核心接口和 Python 封装接口。
   • 在 Windows 平台，开发者通常会优先选择使用便捷的 Python 接口进行快速开发和集成。例如：

     # Windows Python 示例
     lamadilated = LamaDilated("lamadilated", model_path)
     output_data = lamadilated.Inference(input_data, input_mask)

   • 在 Android 平台，应用层（通常是Java/Kotlin）需要通过JNI（Java Native Interface）来调用 C++ 接口。因此，Android平台的开发主要围绕C++ API进行。例如：

   • // Android C++ 接口调用示例
     bool result_init = ModelInitialize("model_name", "path/to/model");
     bool result_infer = ModelInference("model_name", inputBuffers, outputBuffers, outputSize);

3. 调试方式：
   • Windows：可使用Visual Studio进行C++底层代码的断点调试，或使用VS Code等工具进行Python层的调试。
   • Android：需使用Android Studio配合ADB进行调试。C++原生代码的调试需要配置好NDK调试环境，并通过logcat查看日志输出。

 

Q11：做带界面的AI应用时怎么让AI推理和UI界面配合得更流畅啊?

A11：核心策略是将AI推理任务与UI线程彻底分离，QAI AppBuilder为此提供了完善的支持。

1. 后台进程推理：利用平台的多进程架构，将模型加载和推理操作放在独立的后台服务进程中执行。这从根本上避免了计算密集型任务阻塞UI线程。
2. 性能模式管理：在执行关键推理任务前，可调用SetPerfProfileGlobal(PerfProfile.BURST)等接口临时提升硬件性能，缩短推理耗时。任务完成后再释放，以平衡性能与功耗。
3. 高效数据传输：对于大数据量的场景（如视频流），可以使用平台提供的ShareMemory（共享内存）机制，避免在进程间进行大规模数据拷贝，降低延迟，提升整体效率。

通过综合运用后台异步推理、性能动态管理和高效数据传输这三大策略，可以确保AI功能与UI界面的流畅配合。

 

Q12：QAl AppBuilder主要用什么语言啊?是Python吗还是其他的?

A12：QAI AppBuilder 是一个以C++为核心，同时提供Python接口的混合语言项目。

• 核心实现：所有与底层QNN SDK的交互、硬件控制、多进程通信等核心功能，均由C++ 实现，以保证最高的运行效率和平台兼容性。这部分被编译为原生动态库。
• 上层接口：为了提升开发效率和易用性，项目通过pybind11技术，将C++核心功能封装成了一个易于调用的Python模块（qai_appbuilder）。

因此，开发者可以根据项目需求和平台特性灵活选择：在需要极致性能或进行底层开发的场景（如Android App）下使用C++接口；在追求快速开发和集成的场景（如Windows应用原型）下使用Python接口。

 

Q13：老师如果要把QAI AppBuilder做的应用上线，安全性和稳定性方面要注意啥?

A13：将应用推向生产环境时，必须在稳定性和安全性上进行周全考虑。

稳定性保障：

1. 健壮的错误处理：对所有API调用（模型加载、推理等）进行全面的返回值检查和异常捕获，设计合理的失败处理逻辑（如重试、降级、日志记录），防止应用意外崩溃。
2. 严格的资源管理：确保模型资源在使用完毕后能被正确释放，防止内存泄漏。特别是在服务进程中，要对资源生命周期进行精细管理。
3. 进程守护与恢复：主应用应具备监控后台推理服务进程状态的能力。一旦服务进程异常退出，应有机制能自动拉起或重建服务，保证AI功能的可用性。
4. 全面的压力测试：在上线前，模拟高并发、长时运行等极限场景进行压力测试，确保系统在高负载下的稳定表现。

安全性加固：

1. 模型保护：AI模型作为核心资产，应考虑加密存储。在加载时于内存中进行解密，防止模型文件被轻易窃取和滥用。
2. 安全IPC通信：保护主应用与推理服务进程之间的通信信道，设置正确的访问权限，防止被其他恶意应用注入恶意数据或窃取推理结果。
3. 输入数据校验：对所有输入到模型的数据进行严格的合法性校验，防止通过构造恶意输入引发程序崩溃或执行意外代码，防范拒绝服务（DoS）攻击。
4. 应用加固：对最终发布的应用程序包（如APK或EXE）进行代码混淆和加固，提高逆向工程的门槛。 

 

大赛公开课三：

Q1：GenieAPIService 调用本地NPU上的大语言模型时，对设备有什么性能要求？内存或算力要达到什么水平？

A1：目前，只要是骁龙AI PC，都能够运行 GenieAPIService 调用本地 NPU 的大语言模型。市场上在售的骁龙 AI PC 都可以满足模型运行的基本条件。至于内存需求，主要取决于想要运行的模型大小，以及系统本身在待机状态下的可用内存。一般来说，如果运行 7B 级别的大语言模型，在系统占用较低的情况下，16GB 内存的设备即可满足推理需求；如果配备 32GB 内存，则运行会更加流畅稳定，模型加载速度也会更快。

 

Q2：在 PC 端完成了模型调试，想把项目迁移到手机上继续开发，需要改动的地方多吗？在跨平台部署时，如果 Android 端和 PC 端的 SDK 版本或驱动不同，模型精度或性能会有差异吗？

A2：这个问题可以分两部分来看。首先是从 PC 迁移到手机端时的改动量，这与开发方式有关。
如果是传统的计算机视觉 (CV) 类模型，在 PC 上使用 C++ 开发且没有依赖系统特定的功能库（例如Windows平台相关的库），那么迁移到手机端相对容易。如果应用中使用了依赖于特定平台的接口或功能，则需要针对这些部分进行适配。如果是在 PC 上通过 Python 开发的应用，直接在手机端运行的情况会比较少见。也可以考虑使用跨平台框架，例如 Flet，这类框架能让 GUI 应用既能在 PC 上运行，也能打包成 APK 部署到 Android 设备上。但是否满足具体项目需求，仍需开发者自行评估。
对于使用 Python 实现的推理逻辑，在迁移到手机端时，通常需要将模型的前后处理逻辑和界面部分改写为 C++ 或 Android 的 Java 实现。
如果是大语言模型 (LLM) 类应用，且通过 GenieAPIService 实现的，那么迁移工作量较小，主要是把 GUI 客户端改为基于 Android框架的版本，服务端部分可以直接在后台运行。
第二个问题关于跨平台部署时 SDK 或驱动版本差异的影响。Android 和 PC 端的驱动确实存在差异，但如果应用是通过我们提供的标准 QAIRT SDK 运行时库和 QAI AppBuilder 接口来实现模型加载与推理，两端是兼容的。同一模型在两个平台之间迁移时，建议尽量使用相同版本的 QAIRT SDK 运行时库和 QAI AppBuilder 工具，这样能避免不必要的问题。模型精度基本不会因为版本差异而变化，性能主要取决于不同平台 NPU 的算力。

 

Q3：在 Android 端用 QAI AppBuilder 跑模型时，如果模型比较大，比如超 1GB 的 LLM，怎么在内存和加载速度之间做平衡？

A3：根据我们的经验，在较新的骁龙移动平台上运行 3B 或 7B 的大语言模型都是可行的。以 7B 模型为例，通常需要 4 到 5GB 的内存空间。对于聊天类或文本生成类应用，这样的规模在 PC 或手机端都能流畅运行。加载速度和推理响应时间在多数情况下都能满足实时交互的需求。只要设备内存充足且系统资源占用不高，就可以实现较好的模型加载和响应性能。

 

Q4：请问在移动设备NPU上能跑多大参数量的LLM?比如7B、13B模型可以吗?

A4：在最新一代的骁龙移动平台上，运行 7B 或 8B 规模的大语言模型没有问题，推理性能表现也很不错。如果模型规模进一步扩大，比如 13B 级别，那么在移动端运行的难度会显著增加，对内存和带宽的要求也更高。目前建议移动端主要运行 7B 以下的模型，能够兼顾响应速度和能耗控制。

 

Q5：老师您好！请问这些技术可以用来做本地AI助手吗？

A5：完全可以。通过我们提供的 GenieAPIService，就能在骁龙 AI PC 或移动端设备上直接运行本地大语言模型。实现过程非常简单。
首先，将编译好的 GenieAPIService APK 安装到目标设备上；其次，按照文档指引将模型文件复制到指定目录，并完成基础配置；最后，启动服务即可在端侧 NPU 上运行大模型。值得一提的是，GenieAPIService 的接口设计与 OpenAI 的 API 兼容，因此可以直接在本地环境中调用相同的接口完成模型推理。
开发者只需要在自己的 GUI 应用中调用相关接口即可触发推理过程。推理采用流式输出方式，模型的回答会像在线聊天一样逐字生成，这种实时输出体验非常适合本地 AI 助手类的应用场景。

 

Q6：如果遇到模型在NPU上运行出错,有什么常见的调试方法和工具推荐吗?

A6：常见调试方法与工具：
1. 启用 QNN 日志（设置环境变量 QNN_LOG_LEVEL=DEBUG，输出模型加载、张量处理、推理执行日志）；
2. 用 QNN Profiler 工具，查看 NPU 算力占用、层执行状态，定位算子不兼容或张量维度不匹配问题；
3. 用仓库tools/convert/model_check.py验证模型格式；
4. 核对输入输出：数据类型（FP16/INT8）、维度需与模型元数据一致；
5. 确认 SDK 与驱动版本匹配；
6. 参考 samples 中的错误处理逻辑，排查资源不足、模型路径错误等问题。

 

Q7：老师请问CV模型在NPU上运行的实时性如何?能达到实时视频处理的帧率吗?

A7：CV 模型在 NPU 上的实时性表现优异，多数场景可满足实时视频处理。轻量 CV 模型（如 BEiT 分类、MobileNet 适配版）帧率可达 60fps+；目标检测（YOLO 轻量版）30-45fps。骁龙 PC / 新一代手机 NPU（如 X Elite）支持 Burst 模式和多图并行优化，1080p 分辨率下，主流 CV 任务（分类、检测、分割）可稳定达到 30fps 以上的实时标准。复杂模型经量化优化后，仍能平衡精度与帧率，完全适配实时视频处理需求。

 

Q8：想问实际开发中,模型量化对精度有影响吗?有什么好的平衡策略吗?

A8：量化会带来轻微精度损失，可通过以下策略平衡：
1. 优先使用高通 QNN 量化工具（支持 PTQ/INT8），关键层（输出层、回归层）保留 FP16；
2. 用覆盖业务场景的校准数据集优化量化参数，避免分布偏移导致的精度衰减；
3. 直接选用Hugging Face (https://huggingface.co/qualcomm) 或 模型广场 (https://www.aidevhome.com/data/models/) 预量化模型，已验证精度损失可控；
4. 采用混合量化：核心层 FP16、普通层 INT8，若精度下降超阈值，可减少量化范围；
5. 量化后通过准确率、mAP 等指标验证，确保满足业务要求。

 

Q9：想问一下,QAl AppBuilder和Android Studio是什么关系?需要同时安装使用吗

A9：两者无强制依赖，无需同时安装，是协作关系。QAI AppBuilder 是高通 NPU 模型部署工具集，负责推理逻辑适配、模型转换与执行；Android Studio 是 Android 开发 IDE，负责 UI 搭建、权限管理（如 NPU 访问权限）、APK 打包。Android 端开发时，可通过 JNI 将 QAI AppBuilder 的 C++ 推理库集成到 Android Studio 项目，或使用前者提供的 Android 端 samples 模板；纯 PC 开发仅需 QAI AppBuilder，Android Studio 仅在需开发移动端应用时使用。

 

Q10：GenieAPlService支持哪些主流的LLM模型?Llama、Gemma这些都可以部署吗?

A10：GenieAPIService 支持主流开源 LLM 的 QNN 适配版，包括 Llama 3.1/3.2（7B/4B）、Qwen2 7B SSD、 Phi3.5等。
1. 模型格式为 QNN 兼容格式（含.bin 权重、tokenizer.json、配置文件）；
2. 可以从aidevhome.com下载预适配模型。

 

Q11：通过GenieAPlService调用本地NPU运行的LLM,相比云端API有哪些优势和劣势?延迟能降低多少?

A11：优势：离线运行无网络依赖、数据本地留存保护隐私、无调用次数 / 成本限制、低延迟（7B 模型单轮响应 100-300ms）；
劣势：模型规模受限（主流支持 7B/8B）、需自行维护模型更新。
相比云端 API，延迟降低 60%-80%（云端网络良好时 500-1500ms，网络差时差距更大）。复杂多轮对话中，本地 NPU 的低延迟优势更明显，但大模型部署受限于本地硬件算力与内存。

 

Q12：对于隐私敏感的应用场景,端侧部署是不是更有优势?性能损失可以接受吗?

A12：对于隐私敏感场景（如医疗数据处理、金融隐私信息分析、个人私密交互），端侧部署的优势极为突出。依托 QAI AppBuilder 的本地 NPU 推理能力，所有数据全程在设备内处理，无需上传云端，彻底规避网络传输中的数据泄露风险，也无需依赖第三方服务器，完全符合隐私保护法规（如 GDPR、个人信息保护法）对数据本地化的要求，从源头筑牢隐私安全防线。

性能损失方面完全可接受：高通 NPU 的异构计算架构 + QAI AppBuilder 的深度优化（如 Burst 模式、算子适配、混合量化），能最大程度抵消端侧部署的性能损耗。实际使用中，多数场景（如本地 AI 助手对话、隐私数据分类）的响应速度、推理帧率与云端差异极小，无明显感知，完全能平衡隐私安全与使用体验。

 

Q13：请问用ONNX Runtime部署模型,需要对原始模型做特殊转换吗?流程复杂吗?

A13：通过ONNX Runtime部署模型，不需要对原始模型做转换，使用标准的ONNX模型就可以直接部署运行。

 

大赛公开课四：

Q1：使用 Qualcomm AI Stack 做端侧部署时，如果模型精度出现下降，该从哪些环节排查？量化、算子兼容性、编译参数之间有什么调优建议？

A1：出现精度下降时，通常需要做逐层对比，确认从哪一层开始偏差。可以检查该层的量化参数（如 encoding 是否异常）、activation 的分布，以及该层在量化转换过程中的输出情况。根据这些信息进一步定位是否是量化参数、算子支持情况或中间结果导致的问题。
 

Q2：能否用一个真实的模型部署流程来解释 QAIRT 各模块如何协同工作？例如从 PyTorch 模型到最终在设备上运行，会经历哪些步骤？

A2：以 PyTorch 模型为例，流程通常是：
1）先将 PyTorch 模型导出为 ONNX；
2）使用 qairt-converter 转换成浮点 DLC；
3）对 DLC 进行量化，使其能够运行在 HTP 上；
4）使用 QNN 的 context / binary generator 工具将量化后的模型生成最终的 Bin 文件；
5）该 Bin 文件就是最终部署到设备端运行的模型。
 

Q3：设备端跑多模态或个性化的 GenAI 应用时，延迟有时候会比较高。有没有推荐的优化方法？比如模型拆分、缓存策略、或者 Python API 的调用方式有没有最佳实践？

A3：可以先确认语言模型是否已成功从多头转换成单头；其次适当减小 context length可明显提升速度；另外增加如 SSD 这类并行投机解码策略，也能加速 token 的生成过程。
 

Q4：GenAl新特性里，有没有一些针对Stable Diffusion这类文生图模型的特殊优化?比如推理速度或者内存占用方面的

A4：对于 Stable Diffusion，我们会先检查模型是否也从多头成功转为单头，同时也有一些蒸馏(distillation)策略，可减少生成步骤，从而提升推理速度。
 

Q5：老师，当模型部署到手机上之后，效果和在PC上不一样，咱们的调试工具有没有什么“一键诊断”之类的便捷功能，帮我们快速定位问题？

A5：目前没有“一键诊断”工具。如果遇到精度问题，主要还是需要逐层检查，通过层级输出对比来定位是哪一层的计算出现偏差。
 

Q6：老师，GenAl在端侧的个性化微调 (Fine-tuning) 具体是怎么实现的?需要的数据量和训练时间大概是什么量级?在手机上能完成吗?

A6：目前还是不支持端侧训练的。
 

Q7：QAIRT 2025 相比之前的版本，对开发者来说最直观、最明显的提升是什么?

A7：最明显的提升是整合了 QNN 和 SNPE，同时新增了大量 Python API，使转换、调试都更方便。现在既能支持传统模型，也能支持大模型的转换，调试工具也比之前版本更完善。
 

Q8：QAIRT 的生态建设如何？是否有类似 Hugging Face 的社区，能找到已优化并可直接在骁龙平台运行的模型?

A8：可以选用高通Hugging Face (https://huggingface.co/qualcomm) 或 模型广场 (https://www.aidevhome.com/data/models/) 的预量化模型。
 

Q9：QAIRT 支持所有主流 AI 框架，是不是表示 TensorFlow、PyTorch 这类模型可以开箱即用？还需要额外转换吗？

A9：需要经过 converter、量化流程和 context/binary generator 等步骤，转换完成后才能在 HTP 上实际运行。
 

Q10：新模型比如GLM4.6，YOLO13，也可以直接转换和量化么？

A10：可以的，这些模型都有过部署。
 

Q11：端侧 GenAI 的隐私保护是如何实现的？模型和数据是完全离线的吗?

A11：是完全本地化的。模型与用户数据都在设备上运行，不依赖网络，也不会与云端交互，因此隐私能得到很好保障。
 

Q12：HTP 是否有计划支持 grouped quantization？

A12：支持per channel和blocked quantization，不知道跟你所表达的grouped是不是一个概念。
 

Q13：做性能分析时，可视化工具能否看到每一层在 NPU 上的耗时和内存占用？

A13：可以。工具能够显示每一层的执行耗时，以及具体的内存读写情况，并以 summary 文件的形式呈现，方便开发者优化。
 

Q14：除了常规算子融合、量化外，QAIRT 2025 在编译器上是否有独特优化策略？

A14：是的，可以配置不同的优化编译选项。
 

Q15：目前端侧运行大语言模型 (LLM) 是否靠谱？例如 7B 模型在最新骁龙平台上的 token 速度、功耗大概是什么水平？

A15：目前在第五代骁龙8至尊版上主要以3B和4B模型为主；在PC端，7B模型大致是 20 Token/s。

 

大赛公开课五：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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