Qualcomm AI Hub 与犀牛派 X1：从官方模型本地运行到中国站接入实测

[m0_62771201]

 

实测记录｜2026 年 11 月 10 日。MobileNet 本地记录采集于 11 月 5 日，中国站设备与 QAIRT 清单查询于 11 月 9 日。本文整理已有实验，没有为写稿追加推理或云端作业。

拿到搭载 QCS8550 的犀牛派 X1 后，我希望借助 Qualcomm AI Hub，减少模型获取、转换和部署时的摸索。但在实际使用之前，有两个问题需要分开回答：官方提供的模型产物能否在手中的板卡运行？登录 Workbench 后，账号是否真的能选择 QCS8550 作为云端目标？

这次得到的答案是：一个 AI Hub MobileNet-v2 TFLite 产物已经在 X1 上完成 CPU 和 DSP 配置路径的本地调用；中国站账号此次返回的设备清单里没有 QCS8550。

两项结果描述的是不同环节。它们帮助我确定了 AI Hub 现在能为这块开发板提供什么，以及后续云端对照还需要补齐什么。

从模型资源和云端工作台两条入口开始

AI Hub Models 提供模型实现、预优化产物和性能资料；Workbench 提供面向云端托管设备的编译、性能分析与推理作业；Apps 则提供部署应用示例。官方 FAQ 对这些入口作了区分。Qualcomm AI Hub 官方说明

对 X1，我先走了下面这条路径：

AI Hub Models 预导出 MobileNet-v2 TFLite 产物
    → 核对文件哈希、输入输出与量化参数
    → X1 现有 AidLite 运行环境
    → CPU / DSP 配置路径分别调用
    → 回收原始输出，比较数值与图委派记录

这条路径用到了官方模型资源，下载的模型并非本次在自己的 Workbench 账号中编译。它已经能够检验一个实际问题：外部模型产物能否被当前板端环境加载和调用。

一个官方模型产物，怎样落到本地环境

本次使用 AI Hub Models v0.65.0 对应的 MobileNet-v2 TFLite w8a8 产物。为了避免测试过程中模型或输入悄悄变化，我固定了文件身份，并记录接口：

项目	本次使用的内容
模型	MobileNet-v2，TFLite w8a8
模型 SHA-256	ba4c39fdda9a3a5b0a6f69a6c7542aba57fbabfced91fb37086298461fdeaf06
输入	image_tensor，UINT8 [1,224,224,3]
输出	class_logits，UINT8 [1,1000]
测试输入	固定的合成 RGB 字节，共 150,528 bytes

模型相关元数据标注 QAIRT 2.50；板端使用已有 AidLite 环境，本地 delegate getter 返回的编译标签对应 QNN 2.31。这两项信息分别描述产物资料和本地库身份，不能据此认为板上安装了 QAIRT 2.50 完整 SDK，也不能只按版本号大小判断文件必然兼容或不兼容。

实际记录显示，同一模型与输入在 CPU 配置下完成加载、一次 invoke 和输出读取，随后在普通账号的 DSP 配置路径下也完成了一次调用。重启后，同一普通账号下的 CPU 调用再次完成，输出逐字节复现此前 CPU 结果。

记录	请求路径	单次 invoke 区间
SAMPLE-06	CPU，ADB 身份	11.490105 ms
SAMPLE-07	DSP，普通账号	0.852604 ms
DIAG-08	CPU，重启后普通账号	10.159375 ms

每条记录只有一次调用，没有预热或重复分布，执行时刻、启动状态和环境也没有全部控制。因此，这些数值只说明具体调用的观察结果，不能用于计算芯片加速倍数、P95 延迟或端到端帧率。DSP 路径还单独记录了约 410.824 ms 的模型加载区间，invoke 时间没有包含它。

跑通之后，继续核对输出和委派范围

CPU 与 DSP 返回的 1000 个 UINT8 元素中，788 个不同，最大绝对量化差为 9；两路首个 argmax 索引都是 549。重启后的 CPU 输出复现了原 CPU 结果，CPU 与旧 DSP 输出的差异仍然存在。

合成图案没有预期类别，argmax 相同无法证明分类准确率通过，CPU 输出也不能自动成为真值。后续使用 Google LiteRT 参考 kernel 执行同一量化图和输入，结果与板端 CPU、DSP 仍分别有 702、775 个元素不同。这轮工作描述了三条数值路径的差异，尚未确定哪一路符合任务要求，也没有在看到结果后补定通过阈值。

执行覆盖另做了一次原生 benchmark 诊断：原始 108 个 TFLite 节点全部委派给一个 TfLiteQnnDelegate 分区，执行计划为 [108]，没有留下独立的 TFLite builtin CPU 节点；输出逐字节复现此前 DSP 结果。

这为“模型交给了哪个分区”提供了直接证据。但图委派范围与分区内部的物理执行归属仍有区别，当前结果还不能证明 QNN 内部没有 CPU 辅助工作。文章能报告本地调用和图委派观察，数值正确性与完整硬件归属需要继续验证。

中国站接入：先遇到客户端版本限制

随后，我登录 AI Hub Workbench 中国站，并查询设备和 QAIRT 清单。这一步没有上传模型、数据或提交编译、推理、性能分析作业。

使用 qai-hub 0.57.0 时，服务返回 HTTP 409，明确说明该服务支持的客户端版本为 <0.56.0。保留原环境，另建隔离环境安装 qai-hub 0.55.0 后，设备与框架两项查询均返回 HTTP 200。

这次错误出现在客户端与服务端的版本检查阶段，并非模型编译失败。它也提醒我：照着其他版本客户端的示例操作之前，要先核对所访问站点支持的版本和接口。

这是 2026 年 11 月 9 日的接入记录。读者复现时，应以当时服务返回的要求为准，0.55.0 只是本次成功使用的版本。

账号清单里没有 QCS8550，应该怎样理解

此次中国站账号返回四个目标：

设备	芯片	返回的系统属性
Snapdragon X Elite CRD	SC8380XP	Windows 11
Snapdragon 8 Elite QRD	SM8750	Android 15
Dragonwing RB3 Gen 2 Vision Kit	QCS6490	qc_linux 1.6
Dragonwing IQ-9075 EVK	QCS9075	qc_linux 1.7

设备名称和属性中均未匹配 QCS8550，也没有 QCS8550 (Proxy)。QAIRT 清单返回 2.45、2.48、2.49，其中 2.49 标记为 default 和 latest；此次清单未列出 2.31 或 2.50。

这份清单只代表该账号、该区域、该次查询的结果。 国际站账号能否选择 QCS8550，本次没有查询。没有提交作业，也就没有取得自己的云端编译或性能评测结果。

与此同时，官方固定版本 MobileNet-v2 v0.65.0 的 perf.yaml 中存在 QCS8550 (Proxy) 记录及 QAIRT 2.50 标签。官方模型性能资料

模型资料覆盖某个平台，与当前账号能够调度该平台，是两个需要分别核对的事实。官方设备文档也把 get_devices() 作为查询可用设备的入口，并说明 Proxy 使用替代设备，实际硬件的性能和准确率可能与公布记录不同。Workbench 设备说明

因此，我暂时无法在这个中国站账号中完成“选择 QCS8550、提交云端评测、再与 X1 对比”的链路。这不影响前面已取得的特定模型本地调用证据。

下一步先解决目标，再做云端对照

对这块 X1，AI Hub 已经提供了一个有用的模型起点：我可以从确定身份的官方产物开始，核对接口、执行路径和输出，减少自行获取与转换模型的工作。

接下来若要做云端对照，首先需要确认所用账号和区域确实提供 QCS8550 或官方明确适配的目标，再核对产物格式、运行时和测试配置。当前清单里的其他芯片可以用于学习 Workbench，但不能直接替代 X1 的同平台对照。

尤其不能仅凭两款芯片同为 Hexagon v73，就认定其 QNN context 可以互换。官方 FAQ 说明 context binary 与目标 SoC 有关；TFLite、ONNX Runtime 产物在 Proxy 到实际设备的部署中有不同的适配机制，最终仍需在本地核验。Proxy 产物部署说明

本地正确性验证则需要另立实验：选择有预期输出的真实输入或匹配的源模型参考，在运行前定义比较指标、误差阈值和调用上限。已有合成输入记录继续作为接口和诊断证据保存。

这些工作为未来机器人推理后端积累模型身份、接口与失败处理经验。ACT 移植和 Qualcomm Backend 接入仍按原有阶段安排推进，本次实验没有改变 Runtime 的开发与验收状态。

本文的 MobileNet 运行、输出比较和账号目录数据来自本地归档。上述官方链接用于说明平台、格式和公开模型资料；本文新增实验的去标识附件尚未公开上传。