潜江市网站建设_网站建设公司_版式布局_seo优化

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：

1. 对于大模型，上下文在内存中会占用KV Cache，长度与内存大小直接相关。必须在性能和内存消耗之间找到最佳平衡点，设定合理的上下文长度硬限制。
   可以采用滑动窗口机制，当上下文超出限制时，清理掉最旧的、信息价值最低的部分。
   可以引入策略将旧的聊天历史或不重要的文档压缩成摘要，用更少的token存储核心信息，释放原始token占用的KV Cache。
2. 对于程序中使用了多个不同模型（如图像识别模型、文本理解模型、推荐排序模型等）的场景，应实施自动化模型生命周期管理。
   对于长时间未被调用的模型，自动将其卸载，彻底释放其占用的内存资源。将所有模型的加载和卸载操作统一管理，避免不同模块重复加载相同模型，实现内存共享和复用。
3. 针对程序实现的内存泄漏问题，在python代码中，避免循环引用的代码实现。
   通过手段调用gc.collect积极地回收内存。
   确保系统级资源（文件句柄、网络连接、数据库连接、线程/进程句柄、C++扩展中的原生内存分配等）在使用完毕后，通过close/release/delete等操作被显式释放。

以上内容来自2025骁龙人工智能创新应用大赛