直接回答
NPU 验证是对完整的模型、运行时和设备路径做测试，而不是查手机营销规格。先确认所选运行时和委托是否能请求 NPU 路径，再记录模型文件和所需操作，针对目标配置测试初始化与执行，并保存实际使用后端的证据或发生的回退。设备里有 NPU，并不代表特定模型、运行时、算子、驱动或委托组合都能在 NPU 上运行。反过来，依赖库存在或任务成功，也不能证明计算由哪个处理器执行。 要区分四种结论：硬件存在、框架公开某种运行路径、图中操作被委托覆盖、以及某个记录工作负载实际观察到的执行。厂商委托通常受厂商运行时和支持范围约束。Google 的 LiteRT NPU 概览介绍了厂商特定的委托路径，但不是所有手机或所有模型操作的通用支持名单。LiteRT-LM 的配置文档可以让应用请求某个后端，但配置只是一次运行的输入。委托初始化错误、不支持的操作、模型转换限制、驱动失败以及静默或显式回退都应保留为数据，而不是把结果改写成“NPU 已支持”。 有用的测试先固定模型文件和运行时，记录系统版本、设备身份、模型输入输出契约。只有同一模型和任务也能在 CPU 或其他已知路径运行时，才把它作为明确标注的比较项。接着请求 NPU 路径，运行同一固定样例，并收集能够真实表明所选后端的运行时日志或诊断。如果库没有可靠的后端确认，就记录这一限制，描述为“NPU 已请求，执行未确认”。不能从响应更快、电量看似更低、某设备系列或 UI 开关推断实际执行路径。 测试要分开记录委托创建、模型加载、首次调用、重复调用与关闭。后端可能在推理前初始化失败，单个操作也可能回退或留在其他委托上。记录任务是否完成、输出是否通过同一验收标准以及发生了什么回退。若唯一成功结果来自 CPU 回退，任务可能仍能使用，但它不是 NPU 结果。若任务失败，应保留失败样本；不能悄悄从统计范围里删掉不支持的操作而不解释范围变化。 没有对应设备实测记录时，不要发布具名手机兼容结论，也不要把厂商示例中的基准数字转换成 Cove 性能。NPU 可用性和实际产品行为可能随库、模型、操作系统、驱动和制品变化。负责任的总结应说明测试的具体组合、是否有明确后端执行证据、跑了哪个工作负载，以及哪些部分仍未知。 验证流程：先冻结设备、系统、运行时、委托、模型修订与工作负载；其次核对图需要的操作、形状、数据类型和预处理，再读官方支持限制；然后一次只请求一条后端路径，并分别记录初始化、执行、回退与结果验收；最后重复任务、测试取消和清理，关闭引擎，并按最窄范围写结论。任何未测设备都应保留为未分类，而不是默认为兼容。
委托开关不能独自回答 NPU 问题
团队在 Android 构建里开启加速选项，并在一台较新的手机上成功推理一次。运行时没有清楚报告所用后端，团队也未测试不支持的操作、回退或第二台设备。
决策
使用固定配置完成后端专属测试；除非运行时提供可靠证据，否则将实际执行标为未确认。不要把结果写成营销兼容承诺。
预期结果
团队可以说明某个工作负载是否完成、有什么后端证据，以及哪些配置仍未知。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- 精确模型和运行时身份
- 委托后端及操作覆盖依据
- 实际执行与回退记录
设备兼容结论须绑定具体设备、系统、模型、运行时、后端和工作负载，不能靠参数量推测。
实施流程
- 固定模型、设备和运行时. 记录准确设备型号、系统构建、模型修订、输入契约、运行时与委托版本、转换设置及请求后端。模型系列名称或手机名称本身不是测试配置。
- 对照官方操作覆盖范围. 把图所需操作、数据类型、形状和预处理与所选厂商委托文档逐项核对。区分“文档描述了硬件路径”和“图中的所有操作都由该路径覆盖”这两种证据。
- 收集后端与回退证据. 运行固定样例，并分别保存初始化、加载、首次调用、重复调用、输出验收、委托诊断和回退记录。如果运行时不能确认实际执行，就明确保留未确定状态。
- 重复、关闭并限定结论. 重复相同工作负载，执行取消和清理，关闭引擎，再只对记录的配置写结论。CPU 回退可能仍是有效产品路径，但不是 NPU 执行证明。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 记录包含模型、运行时、委托、设备、系统和工作负载身份。
- 根据运行时证据标为已请求、已观察或未确认，不根据速度或机型品牌推断。
- 回退与失败仍可见，不被扩写为普遍设备支持结论。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 手机规格列出 NPU | 硬件存在证据 | 不能证明委托存在、图被覆盖或模型实际执行。 |
| 应用接受后端开关 | 配置请求证据 | 表示应用请求一条路径，不说明任务由哪个后端运行。 |
| 运行时报告固定样例后端 | 单个配置的执行证据 | 只支持所记录的模型、运行时、系统、设备和工作负载。 |
需要避免的失败模式
- 根据手机品牌宣称支持
- 把后端配置当成实际运行证据
- 删除失败样本后再概括结论
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
- Google LiteRT overview
- Gemma run guide
- Google AI Edge LiteRT NPU 委托文档
- Google AI for Developers Gemma 运行指南
- Google AI Edge LiteRT-LM Kotlin API
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
手机里有 NPU，模型就一定会用吗？
不会。还需匹配厂商委托、操作覆盖、运行时、驱动、模型制品和具体工作负载。设备规格只描述一种潜在硬件能力，不能证明应用的推理请求实际走了 NPU。
比较速度能识别 NPU 是否工作吗？
不能可靠识别。时延可能受预热、调度、热状态、缓存和回退影响。后端身份应来自运行时诊断或其他可复现执行信号，而不是单次更快结果。
没有后端遥测时应该怎么写？
可以写“NPU 已请求；实际执行未确认”，并注明模型、运行时、设备和任务。不要把不确定性改成设备支持徽章、兼容结论或性能承诺。