ShareAI · 技术与分享

车机端侧 RAG 选型实录

2026-10-16T07:55:06.802Z

一句话结论

"切本地 RAG 会更快"是个错觉。 我们 AiosAgent 主链路 11.4 秒一次完整对话，RAG（embed）只占 5.2 秒，剩下 6.2 秒全在 1.5B 本地模型 CPU 解码。把 RAG 砍到 0 也只省 45%，而且切本地大概率会让 LLM 变慢——因为两个模型抢同一组 CPU 核心。

真要快，做这三件事：流式输出（TTFT 3s → <500ms）、砍 Planner 循环（5 轮 → 1 轮）、LLM 量化（1.5B → 1.5B-Q4）。

但本地 RAG 仍有它的位置：离线、隐私、延迟稳定性。这三件事值得做。

下面把账算清楚。

在高通 SA8295P（Hexagon V73）上跑 LiteRT-LM + QNN

2026-10-16T07:55:06.847Z

摘要：把 LiteRT-LM 接到 App 进程内走 QNN/HTP 真·出字，理论上在 Snapdragon 8 Gen 2/3 上能跑；但当目标是车机 SoC SA8295P（Hexagon V73）时，会撞上 Google 2026-01 公开承认的"SA8295P not ready yet"。本文把从注册 Qualcomm ID、下载 QAIRT、推库、对接 LiteRT-LM、到 NPU 真·出字判据的全过程按时间线复盘一遍，附原始证据与下一步可破局路径。

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

2026-10-16T07:55:06.867Z

文档信息

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

一、方案总览表

表格

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

车载aios agent预研架构方案

2026-10-16T07:55:06.874Z

AIOS 应用系统架构与详细设计（终态架构视角）

一汽智能座舱 AI Agent（AIOS） —— 一份面向研发与分享的全应用系统架构文档

版本：当前阶段（2026-10，基于实读代码）｜形态：内部技术分享，经脱敏可对外发布参照基线：../AIOS_终态目标.md（终态目标设计，本文 §0 与其对齐）配套深读：../端云双栈LLM架构设计/（端云 LLM 接入专项）

安卓车机 Qwen+QNN 自研方案，到底在讲什么？

2026-10-16T07:55:06.903Z

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

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

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

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

三个词，逐个拆开讲

| 名词 | 是什么 | 打个比方 | |

轻量服务器建站的几个踩坑点

2026-10-16T07:55:06.907Z

记录下用阿里云轻量应用服务器搭博客时遇到的几个真实坑。

坑 1：ufw 不是标配

轻量服务器（Alibaba Cloud Linux 3）默认没有 ufw。外部防火墙在控制台，不在服务器里。折腾半天才发现安全组要手动放行 443。

坑 2：acme.sh 默认 CA 是 ZeroSSL

新版 acme.sh 默认走 ZeroSSL，国内网络偶尔会卡。指定 --server letsencrypt 切回 LE，稳很多。

坑 3：Nginx 1.30+ 不再支持 `listen ... http2`

# 旧写法（仍工作但报 warn）
listen 443 ssl http2;

# 新写法
listen 443 ssl;
http2 on;

坑 4：rsync 同步需要写对路径

# 错的：多一层目录
rsync ... docs/.vuepress/dist/ user@host:/var/www/blog/

# 对的：直接同步内容到目录
rsync ... docs/.vuepress/dist/ user@host:/var/www/blog/

注意结尾的 /，带 / 是同步目录内容，不带 / 是同步目录本身。

坑 5：公安备案 30 天内必须做

工信部备案通过后 30 天内必须做公安备案，否则被查到会下架。阿里云一般有邮件提醒，记得处理。

ShareAI 上线了

2026-10-16T07:55:06.915Z

这是我第一个真正意义上的个人技术博客。

为什么做这个站

公众号文章写完了就埋没在时间线里，没有可检索的归档
朋友圈和推特长内容承载不住
想要一个我能完全掌控的写作空间

技术选型

VuePress 2 + 自定义主题（仿美团技术博客的视觉风格）
Nginx 托管静态文件
acme.sh 自动续期 SSL 证书
rsync 一键同步到服务器

接下来的计划

写一篇《AI 工程化的三个关键原则》专栏开篇文章
写一篇《Vue 3 + TypeScript 最佳实践》系列开篇
把之前公众号的存货迁移过来

域名 shareai.icu，有兴趣可以订阅 RSS。