​先记一句话：​不依赖高通的现成封装，自己基于 QNN 底层 API，把 Qwen 大模型做转换、量化、图优化和硬件调参，最终稳稳跑在 SA8295 车机的 HTP（NPU）上，做车机端本地大模型推理。简单说就是——自己动手，把车机这颗 NPU 用到极致。

先记住一句话，别被名词吓到

这套方案里其实只有三个角色：Qwen 是那棵大模型，HTP 是车机芯片里专门算 AI 的"小马达"（NPU），QNN 是芯片厂商给开发者的底层接口。所谓"自研"，就是不让现成的第三方框架代劳，而是由我们自己的代码，从模型到硬件一步一步接管。

下面这张图是整条链路：你问一句，Qwen 大模型在车机本地被加载，经过自研推理框架调度，通过 QNN 翻译成 HTP 能执行的指令，最后由这颗 NPU 算完并把结果交回给你。

三个词，逐个拆开讲

名词是什么打个比方
Qwen通义千问开源大模型，我们这个项目就是在车机本地跑它，做语音助手、座舱问答。要端上桌的"那道菜"。
HTP高通车规芯片（SA8295）里的 Hexagon NPU，专门算 AI 张量，又快又省电。专用炉灶，火候足、耗能低。
QNN高通 AI Engine Direct 底层 C/C++ 推理 API，提供 CPU/GPU/HTP 三种后端，把神经网络图下发到硬件执行。一套标准厨具和操作手册。
自研不用现成的 ONNX Runtime / QNN delegate 等封装，自己手写上层推理框架，接管模型加载、token 流式输出、KV 缓存和内存调度。自己当大厨，自己掌握火候。

"自研" + "调HTP"，到底在干什么

这一部分讲的是工作量。自研不是一句话，而是下面六个步骤，环环相扣，共同决定大模型跑得快不快、稳不稳、省不省。

六个步骤逐个说明：

步骤动作为什么重要
1 模型转换把 Qwen 从 PyTorch 转成 ONNX，再转成 QNN 认识的图格式。QNN 只认自己的格式，这一步是入口。
2 量化压缩做 INT4 / INT8 静态量化，并用校准数据恢复精度损失。让模型变小、跑得快，是大模型在车机落地的关键。
3 图优化算子融合、替换，不支持的算子自动回退到 CPU。避免整图卡死，保证每个算子都有去处。
4 HTP 调参调整 VTCM 片上内存、KV 缓存位置、HTP 性能档位等硬件参数。直接决定延迟和内存占用。
5 Profiler 找慢点用 QNN 的性能分析工具定位瓶颈算子，逐项优化。不靠猜，用数据说话。
6 车机稳定性处理 DSP 异常恢复、功耗与响应平衡，适配安卓 / QNX 环境。车机要长期跑，稳定是第一优先级。

为什么自研，不用现成方案

市面上有现成的推理框架和高通封装，上手快，但把控制权也交出去了。两者取舍如下：

现成方案（直接调封装）自研 QNN 调 HTP
上手快、开发量小，但受第三方框架限制，难以精细控制 KV 缓存、token 调度和内存管理。自己接管 QNN 生命周期、图构建、输入输出和上下文管理，能直接和 HTP 硬件打交道。
控制力弱，较难榨干 SA8295 HTP 的算力，性能提升有天花板。延迟更低、内存占用更小，可针对 Qwen 的 Attention 算子做硬件级适配。
对功耗档位、DSP 崩溃恢复等车规痛点，缺乏精细控制。可精细控制功耗档位，处理 SSR 自动恢复，保证座舱助手长期稳定。
代价：工程量大，要吃透 QNN 底层 API、HTP 硬件约束和 Hexagon 算子限制。代价：开发周期长，需要投入专职调优，但对要求苛刻的车机场景更可控。

在安卓车机上，有什么特殊之处

  • ​跨处理器通信：​安卓侧 APP 跑在应用处理器（AP），HTP 实际跑在 CDSP（Hexagon DSP），AP 和 DSP 之间要通过 QNN 做跨核通信与共享内存。
  • ​冷启动优化：​车机讲究快速响应用户，通常要提前做模型预编译（AOT 生成 context binary），避免上车后在设备上 JIT 编译带来卡顿。
  • ​资源与功耗平衡：​座舱场景既要响应快，又不能拖累整车功耗，需要精细控制 HTP 性能档位（如 burst / balanced / power_saver）。
  • ​稳定性优先：​车规环境要求 DSP 出问题能自动恢复，保证语音助手和座舱问答不宕机。

总结：一句话记住

自研 QNN 调 HTP = ​自己动手，把 Qwen 大模型从模型转换到硬件调参全程接管，让它在车机 NPU 上跑得又快、又省、又稳。​自研的代价是工程量大，收益是把 SA8295 这颗 HTP 的算力真正用到极致。

如果大家对其中某个环节（比如 INT4 量化、KV 缓存优化、HTP 性能档位）想深入了解，我们可以在下一步调研里单独展开。

首页