直接回答
端侧 AI 设备矩阵应是一组可以追溯的测试记录，而不是从芯片规格表复制出来的兼容列表。每一行都应标明一台准确设备及软件配置、一项模型制品、一个运行时版本、一条被请求且在可观察时记录实际执行证据的路径，以及一项固定任务和清楚的验收标准。结果只适用于这一行。如果设备、系统构建、制品量化方式、运行时、提示模板或后端发生变化，就应创建新行，而不是默默复用旧的通过记录。这样矩阵才能支持工程判断，同时限制结论外推。 先记录可以直接核实的信息：产品和设备标识、制造商报告的型号、Android 版本和 API 等级、支持的 ABI、应用构建、运行时包及解析后的版本、准确制品来源或可用的摘要，以及任务夹具版本。不可获得的信息要填未知；不能根据营销名称推断加速器，也不能由芯片系列推断性能。除非运行时提供实际执行证据，否则不能把请求使用 GPU/NPU 的偏好写成已确认路径。Google LiteRT-LM 运行指南介绍运行时和加速路径，但文档中存在某条路径并不能证明特定应用配置真的使用了它。 收集结果前先定义任务。文本摘要、OCR 和语音转写不是可互换的工作负载证据。应记录输入模态、预处理版本、提示或模板、输出解析器、计时起止边界和验收标准。尽量使用经过审阅的合成夹具。结果可以是通过、失败、根据现有证据不支持、未运行或无法判断；不要用一个绿色“设备支持”格子，把制品验证、模型加载、任务完成和输出校验等不同阶段混成一件事。 矩阵必须保留失败与缺失数据。每条记录要有稳定运行 ID、时间、执行者或自动化版本、采集到的原始测量、错误类别和恢复结果。项目基准政策要求结果主张记录设备、芯片、系统、制品、运行时、后端、输入、时间、内存、热状态和失败结果。缺乏原始测量时，矩阵仍可帮助管理复现和覆盖面，但不能据此支持数字化性能标题。设备级观察应与设备档位汇总分开；档位需要明确成员规则，并为所做主张收集足够数据。 用矩阵规划下一次实验，而不是制造虚假的确定性。如果两行之间同时存在多项变量差异，结果无法定位是哪一项引起行为变化。条件允许时，增加只改变一个维度的对照行，保留之前证据，并重复那些会影响发布决策的测试。交付物应是可审核的测试记录，说明实际测试过什么、哪些地方仍未知，而不是宣布所有带特定芯片的设备都能运行所有端侧模型。 对外总结可以按问题来组织：在哪个系统版本、哪种应用构建、哪个精确制品和运行时组合下，哪个固定任务通过或失败；执行后端是否有证据；错误发生在哪个阶段。若只在实验室设备运行过，就清楚说这是实验室配置，不暗示用户购买同类硬件即可复现。测试矩阵用于限定并改进验证，不负责猜测市场中尚未测试设备的能力。
一台手机通过，却被用来批准整个设备系列
发布评审只有一条来自熟悉芯片型号手机的端侧推理通过记录。团队没有锁定模型摘要、运行时版本、系统构建或后端执行证据，现在需要规划可辩护的验证矩阵，而不是承诺超出已测试配置的支持。
决策
每次运行都作为独立配置行；未知字段明确标出，并将任务验收与设备系列结论分开。
预期结果
评审人能识别实际覆盖、缺失维度和下一项有价值实验，不会把单次通过当作兼容认证。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：项目基准策略要求结果记录设备、芯片、系统、制品、运行时、后端、输入、计时、内存、温度和失败。
- GEMMA-MOBILE-02：官方资料介绍 LiteRT-LM 及其执行路径；文档存在不代表具体配置已运行该路径。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 定义证据的最小单位. 每行代表准确的设备、系统、制品、运行时与任务配置，附稳定运行 ID，并对表结构编号。制品、运行时、系统构建、提示词、模态或后端请求变化时，都建立新行。
- 记录身份与来源. 记录设备型号及相关构建属性、Android/API 等级、支持 ABI、应用构建、运行时坐标及解析版本、制品版本/格式/量化方式，以及真实存在时的可信摘要。缺少证据就标未知，不从家族名补全。
- 区分请求执行与观察执行. 将后端设置偏好或请求与运行时执行证据放在不同字段。运行时不暴露后端身份时标为未确认；不能根据芯片宣传词或界面开关猜测 NPU/GPU 支持。
- 冻结任务与验收契约. 标明模态、输入夹具、预处理、提示/模板、解码配置、解析器版本和预期属性。文本、图片、音频测试应分开；模型能加载却未通过输出断言，不算该功能通过。
- 保留失败并复查覆盖. 记录通过、失败、未运行、无法判断、错误阶段、取消/恢复情况及现有原始数据。比较行之前先列出变量差异，再用覆盖矩阵选择受控后续测试，并把结论限定在证据支持的范围。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每行结果都绑定准确设备、系统、应用、制品、运行时、执行路径证据、任务及夹具版本。
- 后端请求和实际观察结果分开记录；证据不可用时标未知，而非自行推断。
- 失败、取消、未运行和无法判断的配置清楚可见，不会在缺少标准时混成支持/不支持。
- 摘要或兼容描述写明测试范围，不从芯片系列或单台手机进行泛化。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 芯片规格表 | 收集厂商标注的芯片与加速器名称 | 适合做设备盘点，不能证明运行时执行、制品兼容或任务验收。 |
| 单设备冒烟测试 | 一项准确配置与一个代表性任务 | 适合验证该行和早期集成，不足以支撑整个设备系列或普遍模型支持。 |
| 有版本的证据矩阵 | 多行准确配置、来源、结果与原始记录 | 支持限定范围的覆盖说明和有控制的后续实验；汇总仍受已有样本限制。 |
需要避免的失败模式
- 用芯片系列或营销名称代替真实设备和软件配置记录。
- 把后端请求或一次冒烟通过汇总成全设备兼容结论。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
一台手机通过，是否证明同芯片系列都支持？
不能。具体设备实现、系统构建、内存压力、运行时版本、模型制品和任务路径都可能不同。除非有证据支持更大的分组，否则通过结果只属于对应记录配置。
请求 NPU 后能把它写成实际使用 NPU 吗？
不能。请求值和运行时观察要分开记录。运行时没有暴露执行身份时，应写未确认，不能用设备标签或偏好证明；未知值要明确保留。
没有原始基准日志，可以先建矩阵吗？
可以用来跟踪覆盖面和类别结果，但数字化性能主张需要带有配置与测量字段的可复现原始记录。缺失项应标为未知，而不是估算。