骁龙大赛复赛线上答疑闭门会第1期｜ Q&A 汇总

极市平台 2026-01-28 15:12:45

一、模型库&模型转换问题

Q1：目前支持的模型比较少，VLM / ASR / Embedding / Rerank 都没有，项目功能受限怎么办？
A1：目前QAI AppBuilder已支持多种大语言模型，最新更新包括：

Qwen2.5-VL 多模态模型
BGE-Base-Zh-V1.5
目前排序模型 (Rerank) 也已经进入准备阶段。

Q2：官方模型库（Hugging Face / 模型广场）没有我需要的模型，还能参赛吗？
A2：当然可以。建议开发者首先参考 QAI AppBuilder代码示例与相应资源。如果模型不在以下官方渠道中：

Hugging Face Qualcomm 官方模型库
模型广场
选手可采用以下策略确保可运行：核心模型运行在 NPU、辅助模型运行在 CPU / GPU上、也可采用端云结合方案。赛事评估不强制要求所有模型必须跑在 NPU 上。
重点考察的是：👉 参赛作品是否真实使用了端侧 NPU 能力，并能清楚说明模型部署策略与取舍理由。

Q3：模型转换失败，QNN SDK 版本应该怎么选？对设备和平台有要求吗？
A3：模型转换过程中可能会出现兼容性问题，这主要和所使用的 QNN SDK 版本以及目标设备平台有关。首先，需要确认要在什么设备上进行转换，是 ARM 平台还是Android设备，以及具体型号（如 8750、8850）。注意不同平台和 SDK 版本之间的兼容性存在差异。
如果你在模型转换阶段遇到问题，建议优先使用 QNN SDK 2.37.1。
如果使用 2.38.0 或更高版本的库，有时也可以成功，但某些情况下会出现转换失败的问题。早期版本（如 2.38.0）在转换模型时已知会遇到问题，因此不建议使用。需要注意的是，即便模型是用更早版本的 SDK（如 2.34、2.35、2.37）转换得到的，在大多数情况下也可以在 2.38.0 的 QAI AppBuilder 中正常运行，但老旧模型（如 2.2x 版本）出现问题的概率较高。
建议流程：

使用 QNN SDK 2.37.1 转模型
使用 QAI AppBuilder 2.38.0 运行模型
如果在转换过程中需要排查问题，可以将命令行中的 loglevel 设置为 verbose，这样可以输出完整的转换过程信息，比默认的 error 级别更容易发现潜在问题。
如果在使用 2.37.1 版本后仍然无法完成转换，请在官方论坛提交 issue，我们会跟进处理，帮助排查兼容性问题。

二、环境问题

Q4：近期高频环境问题
A4：

QAI AppBuilder 与 SDK 版本匹配问题

目前 SDK 整体是高版本向下兼容的，例如常见的 2.37、2.38 版本在实际使用中均可以正常向下兼容。
不同模型往往会对工具链版本有明确要求，这类信息通常会在对应 GitHub 仓库的 README 中标注清楚。建议选手在使用模型前，优先对照官方文档确认推荐或要求的版本组合。

关于不同平台环境文件拷贝与设备适配的问题

这是当前选手遇到较多的实际问题之一。不同平台对应的文件版本并不相同，例如 Windows 平台通常使用 v73，而 Android 平台（如 8750 设备）对应的是 v79。这类文件需要选手自行从对应目录中复制，并正确放置到工程中指定路径，加载到 qailibs 相关目录下。
如果文件版本或路径不正确，可能会导致模型加载失败或运行异常。

关于 LangFlow 在性能测试场景下的使用方式问题
LangFlow 更适合用于流程验证和功能联调，而不是作为严格的性能评估工具。如果选手更关注模型在端侧的实际推理性能，建议优先通过 WebUI 方式进行查看，因为 WebUI 能展示更完整的性能参数。LangFlow 在整体架构上与 WebUI 基本一致，但控制区并未开放所有性能相关配置项。
关于 LangFlow 对模型规模和类型支持的限制问题
当前 LangFlow 默认更偏向支持 1B 级别模型。如果选手希望加载更大规模的模型，或使用其他类型的大语言模型，需要在 OneFlow 或 Flows 的配置文件中进行相应修改。通过调整配置，仍然可以支持更多模型类型，但需要选手自行完成相关设置。
关于模型文件格式混用带来的问题
在 PC 赛道中需要特别注意模型的最终使用格式。有些模型通过 API 下载后得到的是 bin 文件，而部分论坛或网站提供的模型则是 dlc 格式。实际运行阶段通常使用的是 bin 文件，如果拿到的是 dlc 格式模型，需要先完成模型转换，再生成目标设备可用的 bin 文件，不能直接混用不同格式。
关于模型下载和转换过程中网络环境影响的问题
部分模型资源托管在Amazon 网络上，如果在下载或模型转换阶段出现异常，很可能与网络不稳定有关，不一定是工具或配置问题。建议选手在遇到相关情况时，优先确认网络环境是否稳定，科学上网，再继续排查其他技术细节。

Q5：ONNX / QNN 环境配置失败，经常报错，Python 版本怎么选？
A5：对于大多数参赛选手，建议优先使用 x64 Python（如 Python 3.12 x64）：

兼容性更好
第三方扩展更齐全
ONNX 等依赖更稳定
ARM64 Python 对性能更友好，但部分扩展仍不完整，更适合有经验的开发者。同时，高通在 GitHub 上也提供了第三方开源仓库，已经整理了一批可直接使用的 arm64 Python 扩展，如果选手在该仓库中能找到所需依赖，是可以直接使用的。

Q6：C++ 版本和 Python 版本的 QAI Service 有什么区别？使用 C++ 版本是否会限制客户端语言？
A6：目前重点维护的是 C++ 版本，但需要强调的是：
Service 是后台服务，与客户端语言无关
无论后台是 Python 还是 C++：

客户端可以用 Python
也可以用 C++、Curl 等方式调用
API 是 OpenAI-compatible 的 HTTP 接口

你可以把它理解成“本地运行的云服务”。

早期在开发这一服务时，出于开发效率和易用性的考虑，优先采用了 Python 实现，因为 Python 在接口封装和 API 调用上相对更简单。随着功能逐渐稳定，并被更多项目和厂商使用，对性能和稳定性的要求不断提高，后续开发了 C++ 版本，以满足更高性能场景下的需求。

从维护策略上看，当前主要维护和持续迭代的是 C++ 版本，新功能也都会优先集成到 C++ 版本中，包括后续的多模态能力。Python 版本目前更新频率较低，不再作为功能扩展的重点。

需要特别说明的是，使用 C++ 版本的 service 并不会对客户端的开发语言产生任何限制。无论后台运行的是 Python 版本还是 C++ 版本，对外暴露的都是 OpenAI 兼容的 API 接口，基于 HTTP 协议提供服务。对于客户端而言，并不需要关心服务端的实现语言，可以使用 Python、C++，甚至直接通过 curl 等命令行方式进行调用。
可以将该 service 理解为一个运行在本机的“云端服务”。

就像调用 OpenAI 的远程接口一样，客户端只需按照接口规范进行访问即可。因此，在本地启动 C++ 版本的 QAI API Service 后，GitHub 仓库中已有的 Python 客户端示例都可以直接使用，不需要额外调整。

从实际测试结果来看，C++ 版本在性能和稳定性方面表现更优，更适合长期使用或对性能有要求的场景，这也是当前将主要精力集中在 C++ 版本维护和功能扩展上的原因。

三、设备异构问题

Q7：复赛作品中可以使用第三方推理框架或第三方模型方案吗？是否必须使用高通官方 SDK？
A7：复赛阶段的核心要求是，参赛作品中至少有一部分模型需要真实运行在端侧 NPU 上。至于具体通过哪种方式、使用哪套 SDK 或推理框架，并没有强制限制。
无论是使用高通官方提供的 SDK、工具链，还是使用支持高通 NPU 后端的第三方推理框架，只要能够证明模型确实运行在 NPU 上，都是可以接受的。

更推荐优先使用高通提供的方案：
如果使用高通官方提供的 SDK 和方案，在开发和调试过程中遇到问题，能够获得更直接、更完整的技术支持，整体风险和排查成本会更低。
目前官方提供的方案已经覆盖了大多数常见的模型部署和应用场景，后续在功能完善和问题支持上也会持续跟进。如果官方方案已经能够满足项目需求，建议优先使用官方方案，这样在复赛阶段的稳定性、技术支持和问题响应上会更有保障。

Q8：应用中有多个模型，其中部分模型无法在端侧转换或运行，这会影响最终评估吗？是否必须把所有模型都在 NPU 上跑？
A8：在端侧应用中，如果你的程序使用了多个模型，可能会遇到部分模型无法成功转换或在 NPU 上运行的情况。这种情况是可以接受的，不必因为部分模型无法在端侧运行而放弃整个应用。
官方允许部分模型在 NPU 上运行，其他模型运行在 CPU 或 GPU 上。在最终评估时，只要应用中已经有模型使用了 NPU，就符合端侧运行的要求。

此外，如果应用中确实涉及多个模型同时运行，需要合理分配计算资源。NPU 是单核单线程设备，如果把过多任务都调到 NPU 上，反而可能导致性能下降。因此，可以考虑异构部署：将部分模型放在 NPU 上运行以体现设备优势，同时将其他模型放在 CPU 或 GPU 上，以保证整体性能和响应速度。选手们在复赛作品文档中也可以突出说明下采用的这类设计策略。

总体原则是，应用中尽可能有一部分模型在 NPU 上运行，展示端侧设备的优势；同时，可以结合云端运行能力更强的模型，以实现性能与即时响应的平衡。