端侧 AI Unsupported Operation 错误诊断

直接回答

应把 unsupported operation 错误看作某个明确边界上的失败，而不是“这台手机跑不了该模型”的同义词。先保存准确报错，以及运行时明确给出的操作或子图名称（如果有）。记录制品身份、格式、转换来源、运行时版本、请求后端和失败阶段。为某一运行时或委托路径转换的模型，可能含有另一后端不能执行的操作；请求使用加速器并不代表它真的运行了。先保留失败配置，再尝试回退，否则原始原因可能被覆盖。 模型容器与委托概念要分开。LiteRT-LM 有自己的打包格式和 API；针对 TensorFlow 运算的 LiteRT 转换文档适用于那个转换工作流，不能不加区分地复制到 LiteRT-LM 环境。如果错误发生在打开制品时，先归类为格式或加载边界；若容器已打开但某个操作在执行时失败，就记录操作名、计算图阶段和后端路径；若任务开始前初始化就失败，则应单独调查运行时或原生库设置。不要只因其他类似措辞的问题提到过某个依赖，就无证据地添加它。 用受控复现测试：固定制品、输入夹具、提示词、应用构建、运行时和后端请求；先跑失败路径，再仅在该制品和运行时明确支持时，使用一种诊断路径比较。比较阶段和输出时，不要将不同后端说成等价。如果 CPU 运行成功、另一条路径报告操作问题，这只缩小了路径差异，并不能证明所有加速器都不支持，也不能证明 CPU 更快。如果所有路径都在推理前失败，操作覆盖未必是原因。 只有错误分类之后才能决定恢复方法。可能的处理包括选择兼容且有文档依据的制品，采用受支持的执行路径，使用适用工具链重新构建或转换，或明确向界面返回不支持状态。应用不能静默回退，而界面仍显示用户原来请求的后端。若要发布操作支持列表，必须绑定有版本的制品、运行时、后端和真实测试证据。项目尚无完整设备基准数据，因此本文是错误排查方法，不是模型覆盖或性能结论。 有用的错误记录应包括脱敏原始消息、运行时确实报告的操作名、制品与转换身份、运行时/后端事实、任务阶段、尝试过的恢复和结果。普通诊断不要收集用户提示词或生成文本。如果运行时没有暴露操作名，就记录不可观察；不能只从一条堆栈帧猜算子。这样才能把具体操作不支持与后端初始化失败、制品损坏、JNI 异常、tokenizer 错配和任务质量问题区分开。 恢复结论也应能回答“恢复了什么”。若换到其他路径后加载和固定任务都通过，可以说明该配置下恢复；若仍未完成任务，就只能说初始化成功，不能叫功能就绪。若不同路径产生不同结果，保留每条运行轨迹并记录请求与观察到的执行方式。错误页面应提供可理解的下一步，而非让用户反复下载同一个文件。所有公共表述都需要准确说明制品、运行时和路径范围。

制品能打开，但某条执行路径报操作不支持

团队将候选模型导入 Android 应用。容器看起来可读，但固定任务在一个后端路径上报告不支持操作。另一个配置尚未测试，团队需要避免把一条错误泛化成设备不兼容结论。

决策

捕获准确操作、制品/转换身份、运行时、后端请求与失败阶段；之后仅使用同一夹具比较有文档依据的诊断路径。

预期结果

团队能判断失败发生在路径特定阶段还是更早的加载阶段，并把恢复与公开结论限定于实际观察证据。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• LITERT-01：LiteRT 面向受支持平台提供 CPU、GPU、NPU 执行路径；不能由文档路径推导具体模型已运行。
• BENCHMARK-01：项目要求结果主张具备精确设备、制品、运行时、后端及失败记录。

只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。

实施流程

1. 保留首次失败现场. 保存脱敏的准确错误、堆栈阶段、应用构建、制品来源、运行时版本、后端请求和固定输入标识。原始配置记录完成前，不要换模型或同时改多项设置。
2. 定位失败阶段与操作. 判断错误来自容器打开、引擎初始化、计算图准备还是任务执行。只有运行时明确报告操作名时才记录；泛化错误或原生堆栈不足以凭空确定算子。
3. 核对制品和转换路径. 记录源模型、转换工具与版本、输出格式、量化或委托目标元数据（若有），以及真实存在的可信摘要。将 LiteRT 转换器操作文档与 LiteRT-LM 容器假设分开。
4. 执行受控对照. 仅当制品和运行时支持时，使用同一制品与夹具跑有文档依据的诊断后端。一次只改变一个变量，保留原错误，并分别比较加载阶段、任务完成和输出断言。
5. 透明选择恢复方法. 选择有文档依据的兼容制品/路径，使用适用工具链重建，或展示分类后的不支持状态。应用换执行路径时，若能观察就显示实际路径；不能把请求值冒充实际执行。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 记录区分容器打开、引擎初始化、计算图/操作和任务阶段，不把所有错误合并成设备不支持。
• 复现过程固定制品、转换、运行时、后端请求和夹具身份。
• 回退是显式测试后的决定，不会静默改变界面展示的后端。
• 公共结论限定于准确测试的制品/运行时/路径，不编造通用算子或设备支持列表。

决策对照表

需要避免的失败模式

• 把 unsupported operation 直接翻译成“手机不兼容”。
• 将 LiteRT 转换器的 Select TF Ops 说明盲目套用于 LiteRT-LM 容器。

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Google LiteRT overview
• Cove 基准测试方法
• LiteRT-LM Kotlin API 与运行时设置
• LiteRT Select TensorFlow operators 转换指南

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题