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，系統會根據優先級排隊或分時調度。建議在應用層做串行化處理，避免多線程併發搶佔導致延遲抖動。