车载 Android（8295）本地 Qwen 模型集成方案调研文档

文档信息

  • 目标：车载端侧 Qwen 本地模型多技术路线评估，用于方案选型汇报
  • 硬件：SA8295
  • 业务底座：Koog / MCP Agent 框架
  • 评估维度：设备可用性、NPU/CPU 支持、团队自服务能力、Koog/MCP 改动量、量产友好度、工作量、当前状态、主要风险

一、方案总览表

表格

方案 ID方案主类子型设备可用性（本机）NPU 支持CPU 支持团队能否自服务Koog/MCP 改动量产友好度工作量当前状态主要风险
A.Ichroot+OllamaCPU✅ 已通❌✅8.30 tok/s✅ 已通极小（OllamaClient 内置）❌（root 强依赖）0 人天（已通）✅ 现行1.5B 能力天花板（80~85%）
A.IIchroot+LiteRT+QNNNPU⚠️ 理论可做✅✅兜底✅（不碰 AOSP）+3~5 人天❌（仍 root）7 + 人天❌ 应急chroot 跨 fastrpc 边界未验证
A.IVchroot+OllamaGPU⚠️ 需 SA8295P❌✅✅极小❌2~3 人天❌ 应急GPU 功耗高
B.Iproot+OllamaCPU❌ 需 AOSP❌✅❌不可（需 AOSP）极小✅OEM 3~4 周⏸移出 Sprint团队做不了
B.IIproot+LiteRT+QNNNPU❌ 需 AOSP✅✅❌不可—✅OEM 4 + 周⏸移出—
B.IIIproot+LiteRT+NNAPINPU❌ 需 AOSP✅✅❌不可—✅OEM 3 周⏸移出—
B.IVproot+OllamaGPU❌ 需 AOSP❌✅❌不可极小✅OEM 3 周⏸移出—
C.I静态编译 OllamaCPU⚠️ 理论可做❌✅✅（不碰 AOSP）极小⚠️4~8 周❌ 不推荐Go+CGO 坑多，维护成本高
C.II静态编译 LiteRT+QNNNPU⚠️ 理论可做✅✅✅+5 + 人天⚠️6~10 周❌ 不推荐重叠 D.II，工作量翻倍
C.IV静态编译 OllamaGPU⚠️ 理论可做❌✅✅极小⚠️5 + 周❌ 不推荐—
D.I无引擎—⛔⛔⛔——❌—❌不构成方案
D.IIApp in-process+LiteRT+QNNNPU 首选✅ 本周可 spike✅✅兜底✅（不碰 AOSP）极小（薄壳）✅✅（OEM 固化 lib）2~4 人天⏳立即可开工QNN 版本↔HTP 代际；license
D.IIIApp in-process+LiteRT+NNAPINPU⚠️ 缺后端❌ 当前✅✅极小✅2~4 人天❌ 受限OEM 必走；本机跑不出 NPU
D.IVApp in-process+LiteRT+GPUGPU 次选⚠️ 需 SA8295P❌✅✅极小✅1~2 人天❌ 次选功耗高

二、方案大类解读

A 类：chroot 容器方案（POC 预研路线）

定位：快速验证 POC，​不适合量产​，强依赖 root 权限

  1. A.I chroot+Ollama+CPU
    • 当前状态：✅ 已经跑通，作为当前基准 POC；推理速度 8.30 tok/s
    • 优点：零开发工作量，MCP/Koog 改动极少，快速验证 MCP+Qwen 本地对话链路；
    • 短板：root 依赖，​量产禁止 root​；模型上限只能 1.5B，能力上限 80~85%；仅 POC 验证。
  2. A.II chroot+LiteRT+QNN
    • 定位：应急备选；理论可行，但是 chroot 容器访问 fastrpc 高通 NPU 接口边界没有验证，风险高，依旧依赖 root。
  3. A.IV chroot+Ollama+GPU
    • 硬件依赖 SA8295P；GPU 功耗高，车载座舱场景不推荐作为主方案。

A 类共性：全部依赖 root，仅用于预研验证；不能直接量产交付。

B 类：proot 容器方案（依赖 AOSP 深度改造）

定位：需要 OEM 配合 AOSP 层面改造，团队无法独立完成，已移出当前 Sprint。

  • proot 不需要 root，但底层需要 AOSP 系统能力适配，开发排期全部由 OEM 主导，周期 3~4 周起步；
  • 团队无法自服务控制交付节奏，​当前版本不纳入本阶段研发范围​。

C 类：静态编译原生二进制方案

定位：理论可行，长期维护成本高，不推荐选型。

  • Ollama 基于 Go，静态编译 + CGO 交叉编译坑多；LiteRT+QNN 静态编译工作量巨大，和 D.II 方案工作重叠，投入翻倍；
  • 编译、版本升级、bug 修复成本高，长期维护负担重。

D 类：App 内进程方案（​量产首选路线​）

定位：推荐主方案 D.II App in-process + LiteRT + QNN

  1. D.II App in-process + LiteRT + QNN（NPU 首选）
    • 优势：
      • 无需 root、不修改 AOSP；App 进程内直接加载 QNN 库运行 Qwen 模型；
      • Koog/MCP 改动量很小，只需要一层薄壳封装；本周即可启动 Spike 验证；
      • 工作量 2~4 人天，投入低；NPU 硬件加速，模型规模不再受 CPU 限制；
    • 风险点：QNN 版本与 HTP 硬件代际兼容性、OEM 侧 QNN license 与预编译 lib 固化。
  2. D.III App in-process + LiteRT + NNAPI：本机环境缺少可用 NNAPI 后端，车载本机无法拉起 NPU，受限方案。
  3. D.IV App in-process + LiteRT + GPU：依赖 SA8295P，GPU 功耗高，仅作为次选兜底。

三、选型结论建议

  1. POC 阶段（当前）：继续使用 A.I chroot+Ollama+CPU
    • 现状可用，快速验证 MCP 多 App 工具路由、Agent、Qwen 对话业务逻辑；
    • 明确边界：A.I 只做业务层 POC 验证，​不用于量产交付​。
  2. 量产目标方案：D.II App in-process + LiteRT + QNN
    • 启动 Spike 验证，验证 Qwen 模型在 SA8295 NPU 上的推理、MCP/Koog 集成；
    • 核心收益：无 root、不侵入 AOSP，NPU 硬件加速，量产合规；
  3. 备选兜底：A.II chroot+LiteRT+QNN（仅应急，不做主力）；
  4. B 类 proot 整套方案：移出当前 Sprint，后续评估 OEM 资源后再看；C 类静态编译方案：放弃，不投入研发。

四、关键约束清单

  1. root 权限：量产版本​禁止 root​，所有 chroot 方案存在量产卡点；
  2. SA8295 硬件差异：GPU 推理依赖 SA8295P 版本；
  3. NPU 链路：高通 HTP/QNN 存在版本绑定、license、OEM lib 固化依赖；
  4. MCP/Koog 上层 Agent 业务逻辑：POC 阶段在 A.I 验证的 MCP 工具路由、多 App MCP 服务选择逻辑，​可以平滑迁移到 D.II 方案​，上层业务逻辑基本复用。

五、后续工作规划

  1. 当前：A.I chroot+Ollama POC 持续迭代 MCP 多工具路由、Agent 能力验证；
  2. 并行启动：D.II Spike 验证（App 内 LiteRT+QNN 加载 Qwen，端侧推理验证）；
  3. Spike 输出物：推理性能指标、内存占用、功耗测试、MCP 薄壳适配 Demo；
  4. 风险前置：同步对齐 OEM 确认 QNN license、HTP 固件版本、预编译 lib 交付。

六、风险汇总

表格

风险分类风险描述应对策略
POC 链路A.I 方案模型能力上限 1.5B，80~85% 能力区分 POC 业务验证 vs 模型能力；量产用 D.II 释放更大模型
NPU 硬件QNN 版本与 HTP 代际不兼容、License 问题Spike 阶段提前对齐 OEM，锁定 lib、固件版本
容器方案chroot 跨 fastrpc 访问 NPU 接口未验证仅作为应急方案，不做主力
交付节奏B 类 proot 方案依赖 OEM AOSP 改造，团队无法自控移出当前 Sprint，不作为本阶段目标
首页