上期課程中我們瞭解了在驍龍 AI PC 上使用 QAI AppBuilder 工具絲滑部署AI模型的核心方法，省流版教程：
用户指南：
https://github.com/quic/ai-engine-direct-helper/blob/main/docs/user_guide.md
開源社區：
https://github.com/quic/ai-engine-direct-helper
直播問題&答疑整理
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：
- 在端側部署 CV 模型時，常見問題主要集中在兩個方面：輸入輸出數據處理不當
a.模型前後處理通常在 CPU 上執行，若數據量大，可考慮使用多線程提升處理速度。
b.對於圖像類任務，也可利用 GPU 進行圖像轉換、縮放等操作，以加速前後處理。
2.數據格式不匹配
a.需將原始數據（如圖片）轉換為模型所需的張量（Tensor）格式，並正確處理輸出張量。
b.不同模型的輸入輸出格式差異較大，可參考官方 GitHub 上的推理示例（包含二十餘個模型案例），根據需要調整數據預處理和後處理邏輯。
只要解決好前後處理邏輯，並正確適配模型格式，就能充分發揮驍龍 AI PC 的算力，開發出高性能、低功耗的端側 AI 應用。
Q4：哪一種部署方式具有更多的模型適配？
A4：
目前來看，Python 格式的模型（如 PyTorch、TensorFlow）在生態上最為豐富。
但若要在 驍龍 AI PC 的 NPU 上獲得最佳性能與最低功耗，推薦使用 QAI AppBuilder 或 QAIRT SDK 部署 二進制上下文 格式的模型。
這兩種方式中，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屏蔽了大量複雜的細節，使開發者能更專注於業務邏輯的實現。
以上內容來自2025驍龍人工智能創新應用大賽
參賽：https://a.cvmart.net/rSZB2e
