Q1：老師，想問問在 NPU 上部署 LLM 或多模態模型時，有什麼選擇模型規模、架構或量化策略的經驗可以給備賽選手參考嗎？
A1：
在本地部署大模型時，最核心的限制通常是設備資源，因此一般優先選擇小型或輕量級模型，例如 1B 以下參數規模。對於 7B 模型，通常需要 16GB 以上內存才能穩定運行。除了模型權重本身的佔用，還需要考慮上下文長度，因為更長的 context 會顯著增加推理過程中的額外內存開銷。因此在資源有限的情況下，需要同時權衡模型參數量和所需的上下文長度。
關於架構，如果是 MoE（稀疏專家）結構，它對內存帶寬和調度能力依賴更高，需要硬件具備足夠支持才能發揮性能。
在量化策略上，本地 NPU 上部署 LLM 時推薦量化，可以大幅縮小模型體積、減少內存佔用，並提升推理速度，同時精度損失在可控範圍內。像應用寶的“智能啓動台”使用的混元 0.5B 模型就是 INT8 量化版本。
如果是針對特定任務的場景，可以採用 LoRA 微調，通過在較小的基礎模型上提升特定任務能力，就能在低資源開銷下獲得比 7B 模型更好的定製化效果。應用寶實際應用中，0.5B 模型 + LoRA 微調後的效果已經優於一些更大模型。同時，如果有多任務需求，還可以採用“動態加載適配器”的方式，按需加載不同任務的 LoRA Adapter，進一步減少內存佔用。
Q2：想問問實際項目落地中，把 AI 能力整合到傳統業務（如應用寶的分發、推薦、安全等）時，最大的工程挑戰是什麼？我們比賽中也想把 AI 能力嵌入已有應用，使用 QAI AppBuilder 時應該優先考慮哪些工程點（如進程隔離、資源調度、模型熱加載等）？
A2（講師回覆整理）：
將 AI 能力融入傳統業務時，最大的挑戰主要來自工程層面的適配與優化。
首先是硬件利用。需要合理調度 CPU、GPU、NPU 等不同加速單元，讓模型推理髮揮最佳性能。高通的 SDK 已經做了不少 NPU 方向的優化，如果未來能實現多硬件協同調度，會進一步提升能力。
第二是功耗與發熱。在本地設備上，如果頻繁進行推理，即使是 NPU 也會產生較高功耗和發熱。因此產品層面需要減少不必要的推理任務，並依據設備狀態做動態調度，例如僅在電源充足、接入電源時執行高負載推理。
第三是數據安全與隱私。即便是本地部署，也需要遵守隱私與合規要求，對於採集的數據必須做脱敏處理。對於個性化需求，可以利用用户本地數據進行持續學習或微調，無需上傳數據到雲端。
Q3：應用寶的產品裏，NPU 推理和 CPU 推理是怎麼做 fallback 的？
A3：應用寶針對驍龍pc適配的版本，只支持NPU推理
Q4：如果圖庫很大（比如 10 萬張圖），怎麼優化檢索速度？要不要建索引或者用向量數據庫？
A4：針對10萬張級別的大規模圖庫檢索，我們的優化核心策略是採用向量數據庫配合高效的索引機制。
我們選擇使用開源向量數據庫LanceDB作為向量數據的存儲與管理平台。LanceDB原生支持暴力搜索和 近似最近鄰索引 兩種檢索模式。
在標準的PC硬件環境下，暴力搜索的耗時在毫秒級別，這個性能水平能夠滿足絕大多數實時檢索的應用需求。
如果面臨的更大規模數據，創建索引可以顯著提升搜索速度，但在構建和更新索引時會產生額外的時間開銷。
因此，建議根據實際數據量、向量維度、對查詢延遲的嚴格要求以及可接受的索引構建耗時進行綜合權衡。
Q5：CLIP 模型的文本編碼器和圖像編碼器，在 NPU 上是分開推理還是融合推理？哪個效率更高？
A5： CLIP可以可以分開做，也可以放到一起進行推理，看具體的use case。
Q6：ARM 架構跟 x86 在 AI 推理上有啥本質區別？應用寶遷移到 ARM 遇到過兼容性問題嗎？
A6：在 AI 推理層面，ARM 和 x86 架構並沒有根本性的本質區別。底層設備架構（指令集、內存模型等）的複雜細節已經通過上層 SDK和操作系統進行了良好的封裝和屏蔽。無論是 ARM 還是 x86，最終的推理核心計算（矩陣乘法、卷積等）都依賴於它們各自的向量化/SIMD 單元（如 x86 的 AVX 系列、ARM 的 NEON/SVE），這些差異主要體現在性能和功耗上，而非“本質”的算法或功能實現上。
應用寶在遷移到ARM架構時，遇到的主要兼容性挑戰集中在指令集上。儘管基於ARM的Windows提供了指令翻譯來運行大部分x86應用程序，但這種模擬並非完美。某些高性能、專用的指令集不支持，比如AVX-512指令集。如果x86版本程序使用了這類指令集，那麼在 ARM 平台上就需要重新編譯
因此我們應用寶在遷移ARM時，使用了原生ARM64架構，對所有的代碼都在ARM架構下重新編譯。
Q7：自定義模型轉換這塊，如果 CLIP 用了自己微調的版本，轉換流程會不會很複雜？
A7：微調fine-tune只是針對model，轉化流程不會有變化。
Q8：多語言文本檢索（比如中英文混合），CLIP 的效果怎麼樣？要不要針對性優化？
A8：支持多語言需要fine-tune CLIP模型，這部分需要根據use case進行調整，對於高通的工具而言，轉換流程上不會有差異。
Q9：圖像預處理這塊，Resize 和 Normalize 在 NPU 上能加速嗎？還是隻能 CPU 處理？
A9：Resize NPU也可以做，但是速度不會特別快，建議放CPU做比較好。Normalize NPU支持。
Q10：老師能分享一下應用寶在內存管理上的經驗嗎？怎麼避免長時間運行內存泄漏？
A10：
- 對於大模型，上下文在內存中會佔用KV Cache，長度與內存大小直接相關。必須在性能和內存消耗之間找到最佳平衡點，設定合理的上下文長度硬限制。
可以採用滑動窗口機制，當上下文超出限制時，清理掉最舊的、信息價值最低的部分。
可以引入策略將舊的聊天曆史或不重要的文檔壓縮成摘要，用更少的token存儲核心信息，釋放原始token佔用的KV Cache。 - 對於程序中使用了多個不同模型（如圖像識別模型、文本理解模型、推薦排序模型等）的場景，應實施自動化模型生命週期管理。
對於長時間未被調用的模型，自動將其卸載，徹底釋放其佔用的內存資源。將所有模型的加載和卸載操作統一管理，避免不同模塊重複加載相同模型，實現內存共享和複用。 - 針對程序實現的內存泄漏問題，在python代碼中，避免循環引用的代碼實現。
通過手段調用gc.collect積極地回收內存。
確保系統級資源（文件句柄、網絡連接、數據庫連接、線程/進程句柄、C++擴展中的原生內存分配等）在使用完畢後，通過close/release/delete等操作被顯式釋放。
以上內容來自2025驍龍人工智能創新應用大賽
