直接回答
后端初始化错误表示请求的执行路径没有进入就绪状态；它本身不能证明模型有问题、手机不支持或推理任务失败。应记录准确后端请求、运行时与原生包版本、适用的清单或打包前提、设备/ABI 身份、模型制品以及完整初始化错误阶段。应用界面的用户设置要与引擎实际初始化结果分开。如果 API 只返回成功或异常，并没有暴露最终硬件执行路径，就要将其标记为不可观察，而不是声称已经用了加速器。 按阶段检查。先确认模型文件能够找到并打开，再判断是不是后端设置问题。随后核对运行时针对该路径文档中说明的前提，例如适用的可选原生库或库目录。检查应用包或实际安装产物是否包含此执行路径和 ABI 所需的兼容文件。初始化失败可能来自库无法加载、依赖缺失或后端拒绝配置；这些都不同于引擎已启动之后的算子执行错误。LiteRT-LM Kotlin 指南展示 CPU 默认路径，也说明 GPU/NPU 设置输入，但不承诺所有设备上的配置都必然成功。 保留首次失败现场。记录应用构建、Android 版本、ABI、解析后的运行时版本、模型身份、后端请求以及脱敏错误消息。不要来回切换 GPU/NPU、删除模型或静默重试到日志已经不代表初始条件。若文档支持的 CPU 诊断路径成功，这只能说明相同制品和任务可以通过该配置继续运行，不能说明加速器兼容性或两种路径的速度差异。 回退政策应明确。应用可以根据产品行为询问用户是否切到有文档依据的路径，也可以按产品设计回退，但界面必须反映实际初始化路径。加速器请求失败后，若回退到 CPU，不能仍显示 GPU 就绪。回退路径还需要单独的任务验收；初始化成功不等于功能任务成功。所有路径都失败时，应返回分类后的初始化问题及下一步，而不是反复下载一个已经完整的模型。 不要编造厂商目录、ABI 覆盖或加速器可用性结论。准确记录核对过哪些文档和安装包结构、请求了哪些值，以及观察到什么结果。项目目前没有完整设备基准数据，因此本文讲的是故障排查与记录，不是支持列表、速度结果，也不保证每次都能回退成功。 在安装阶段也要区分构建物与设备实际获得的配置。AAB 中存在某个模块目录，并不表示特定设备的拆分 APK 已装入对应库；连接设备生成的 APK set 或真实安装拆分才能提供针对该配置的证据。若此时找不到库，应先核对 ABI、拆分选择与安装产物，再归因到后端不支持。即便依赖存在，原生创建仍可能失败，所以“文件在包里”和“初始化通过”也必须分别记录。 产品应把后端选择写成状态流，例如“请求加速器、初始化失败、CPU 回退待确认”，而不是固定徽标。用户可以了解应用将切换执行路径，开发者能保留原始失败做诊断。若产品不允许回退，就明确提示需要修复或选择其他配置，并停止创建引擎，不要显示可用。任何支持说明都应限定到确实测试过的设备、系统、ABI、运行时和模型任务。
应用请求 GPU，但引擎在推理前初始化异常
发布候选版在设置中选择了加速器。原生引擎初始化时抛错，尚未提交任务提示词。另一条路径还没试，应用界面此刻仍显示用户所选后端。
决策
保存原始失败，检查运行时文档中的依赖和 ABI 打包，区分初始化、模型加载与推理，并诚实呈现回退状态。
预期结果
支持团队能定位失败阶段；用户看到经过测试的回退或明确配置错误，而不是虚假的就绪提示。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- LITERT-01：LiteRT 介绍受支持平台的 CPU、GPU、NPU 路径；具体执行仍须按配置验证。
- BENCHMARK-01：任何运行结果主张都需要准确设备、制品、运行时、后端和失败原始记录。
只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。
实施流程
- 冻结请求和构建身份. 记录后端偏好/请求、应用构建、Android/API 版本、ABI、运行时包及版本、原生依赖、模型身份和脱敏的完整初始化错误。先保存首次状态，再更改设置。
- 独立验证制品可访问性. 确认准确模型文件存在、可读，并到达文档说明的加载边界。制品路径或格式失败应与后端初始化分开，不能靠切换加速器标志掩盖。
- 核对文档说明的原生前提. 查看运行时指南对该路径所需的可选库、清单声明或库目录要求。检查实际安装 APK/拆分是否为设备 ABI 包含原生文件；源码目录或通用调试 APK 不能证明发布安装包含它。
- 只改一个配置变量进行复现. 如果文档支持诊断后端，保留原始请求后，使用同一制品和夹具，仅改变后端字段重跑。记录引擎是否初始化、实际后端是否可观察，以及代表性任务是否完成。
- 采用可见且有限的回退策略. 已知实际路径时更新界面；无法确认时显示未确认。限制重试次数，保留原错误供支持，并在所有路径都无法初始化时提供明确修复或用户选择。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 后端请求、引擎初始化结果、观察到的执行路径、模型加载和任务结果分属不同字段/状态。
- 原生依赖与 ABI 检查基于准确安装产物，而不是源码存在或无关通用 APK。
- 回退可见且另行检查代表性任务；CPU 路径运行时不能暗示加速器成功。
- 没有准确配置记录和原始测量时，不作宽泛设备支持或速度结论。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 后端请求 | 用户设置或 EngineConfig 偏好 | 仅表示意图，不证明原生初始化完成或此路径实际执行。 |
| 初始化结果 | 引擎成功创建/初始化或返回错误 | 确认设置阶段；后续任务仍可能失败，实际硬件路径也可能未知。 |
| 观察到的任务路径 | 运行时/后端证据加代表性任务 | 是此测试配置最强的有限证据，但不是设备系列保证。 |
需要避免的失败模式
- 设置里选了 GPU，就显示 GPU 已运行。
- 后端初始化失败后盲目删除并重下模型，掩盖原始问题。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
设置中选择 GPU 是否表示模型正在使用 GPU？
不是。该设置只记录请求。初始化可能失败、发生回退，或运行时无法暴露真实执行身份。请求和观察到的状态必须分别保存。
后端初始化失败后是否应该删除并重新下载模型？
分类之前不要这样做。如果模型已成功打开而错误发生在后端建立阶段，重新下载通常无法解决缺少原生库、ABI 拆分或配置问题。
CPU 回退能被称为 GPU 初始化成功吗？
不能，它是另一条执行路径。界面状态需更新，并在回退下另行验证任务；不能把最初的加速器请求说成实际执行。结论仅对应实际观察路径。