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