树莓派车载AI实战：用Qwen打通感知、理解与控制的完整链路

Qwen 在树莓派上跑车载 AI，这个组合听上去有点极限：一边是资源受限的 ARM 单板，另一边是对话、理解、视觉都要兼顾的大模型。但最近看到有开发者把完整项目放上了 Show HN，实际拆开看，它并不是要在车里装一套全自动驾驶系统，而是把树莓派当作车载助手的中枢，用 Qwen 做自然语言理解和简单推理，摄像头做视觉感知，再通过 STM32 或传感器控制车上的一些外设。这个方向很适合树莓派玩家、嵌入式开发者和边缘 AI 学习者。它最有价值的地方在于：用一份不算高的硬件成本，把大模型、视觉、控制三条链路整合到一辆小车上，验证边缘设备到底能把多少 AI 能力真正落地。

下面按我实际复现和改造的顺序，把预期管理、硬件选型、环境准备、模型部署、外设接入、性能判断和坑点拆开讲。

1. 先搞清楚"树莓派车载 AI"到底解决什么问题

1.1 车载 AI 不等于自动驾驶，先把这个预期拉平

很多人在看到"车载 AI"四个字时，第一反应是自动驾驶。这个项目离自动驾驶还非常远。树莓派的算力上限摆在那里，实时目标检测、路径规划、多传感器融合、大规模模型一起跑，并不现实。

更现实的定位，是一个能够听懂指令、看懂画面、响应查询、控制外设的车载助手原型。它可以做这类事情：

• 驾驶员说"帮我看一眼后方画面"，系统调用摄像头抓拍，再让 Qwen 生成简短描述。
• 驾驶员说"把风扇转速调低一点"，系统把指令解析成动作，通过 GPIO 或串口控制 PWM 风扇。
• 驾驶员问"保养手册里说机油多久换一次"，系统从本地知识库里检索，再用 Qwen 组织答案。
• 传感器读到车内温度过高，系统主动播报提示，并建议降窗或开启风扇。

这些能力听起来不夸张，但放在一辆由树莓派驱动的车上，已经足够覆盖"车载 AI"的第一版。项目能被放到 Show HN 上，说明它是一个可运行的原型。原型能跑通，比功能堆满更值得关注，因为问题难点从来不在单独某个模型，而在整条链路能不能稳定串起来。

1.2 拆开看，这是一套感知、理解、控制的三层结构

我用过不少边缘 AI 项目，最容易翻车的是一上来就把模型、摄像头、电机全接好，然后发现不知道从哪里调试。这个 Show HN 项目的结构其实很清楚，拆成三条链路：

感知层：摄像头采集图像，温度、电压等传感器读车辆状态。感知层负责把物理世界变成数据。

理解层：Qwen 处理自然语言，把"打开风扇"这种口语翻译成特定动作指令，把图像数据变成可阅读的描述，把知识库检索结果组织成回答。理解层是这个项目最核心的部分。

控制层：树莓派通过 GPIO、UART 或 I2C 把指令变成电平、PWM 信号，驱动风扇、舵机、显示屏等设备。为了让执行更可靠，很多方案会引入 STM32，树莓派负责决策，STM32 负责底层执行。

这三层可以独立调试，最后再融合。这个顺序也应该是你复现时的顺序。先确认摄像头能出图，再确认模型能回答，接着确认外设能被驱动，最后才把三件事通过程序串起来。跳着来，后面遇到问题很难定位。

2. 硬件选型：树莓派5还是4B，内存4G还是8G

2.1 树莓派5是更舒服的起点，但4B也不是不能玩

跑本地大模型，内存带宽往往比 CPU 主频更关键。模型权重在推理过程中需要反复读写，带宽越高，单位时间内能吞吐的数据越多。树莓派5在 CPU 性能和内存带宽上都比 4B 有明显提升，跑 Qwen 这类语言模型时体验会好很多。

手头只有4B也可以，只是要把模型量级和任务预期降下来。不要指望 4B 跑7B 模型还能流畅交互，那会卡到没法用。

如果只是学习验证，4B 完全够。如果想把原型长时间放在车上跑，树莓派5加8GB内存是比较稳妥的起点。热词里有人问"具身智能小车树莓派需要4G还是8G"，我的结论很直接：预算允许就选8GB。模型加载进内存后，剩余空间还需要留给系统、摄像头缓冲和推理上下文，4GB 会比较紧张。

2.2 内存、存储、摄像头和散热，每一项都要单独过一遍

内存决定模型能跑多大。8GB 版本可以装下量化后的 3B 模型，并在运行模型的同时保留系统余量。4GB 版本跑 3B 模型，内存会非常紧张，一旦触发换页，速度会断崖下降。

存储决定稳定性和速度。车载环境有震动，TF 卡容易出现坏块或接触问题。有条件的话，通过树莓派5的原生 PCIe 接口外接一块 SSD 会更稳，安装系统和读取模型都快很多。如果坚持用 TF 卡，至少选 A2 等级的高质量卡，并做好备份。

摄像头模块，常见选择是 OV5647 这类 CSI 接口摄像头。CSI 接口带宽稳定、延迟低，比 USB 摄像头更适合视频流采集。树莓派5的 CSI 接口排线方向与 4B 不同，接线时要注意，插反或者没插到底都会导致摄像头无法识别。

电源和散热必须提前处理。树莓派5 官方推荐 5V/5A 电源，但车上取电环境比较复杂，点烟器转换模块质量参差不齐，电压跌落时会出现各种怪问题。散热方面，加一个导热外壳加 PWM 风扇很必要，尤其是把设备放在密闭的车内空间。用树莓派的 GPIO 控制 PWM 风扇，可以在温度低时停转，温度高时再加速，比一直全速转要安静得多。

3. 系统环境：从刷镜像到稳定运行

3.1 镜像选择和基础配置，先把底座打稳

系统镜像我建议直接用 64 位的 Raspberry Pi OS，或者你熟悉的 Ubuntu Server。跑模型要用 64 位系统，因为大模型框架和工具链在 64 位环境下更成熟，依赖也更全。Raspberry Pi OS 的图形界面在车载场景里可以不做主力，开发调试时开一下 VNC 远程查看就行。

装完系统后，第一步不是装模型，而是整理软件源。树莓派默认的软件源在国外，国内下载依赖包很慢，先改成国内镜像源，后面装 OpenCV、Python 库、推理框架都会顺手很多。具体做法就是把/etc/apt/sources.list里的默认地址替换成可用镜像，然后执行sudo apt update。这个动作看起来基础，但它能省掉大量等待时间。

开发阶段建议开启 SSH 和 VNC。SSH 用来远程执行命令，VNC 用来查看桌面界面。我一般会用 VS Code 的 Remote SSH 插件直接连接树莓派，在宿主机上写代码、同步文件，改完直接在树莓派上运行，开发效率高很多。VNC 的作用是处理需要图形界面的操作，比如看摄像头预览、调试显示界面。

3.2 车载场景的稳定性，比功能更早设计

车载环境和桌面开发完全不同。震动、断电、高温、网络抖动，都会让一个"在桌面跑得好好的"程序崩溃。所以环境层面要提前做几件事：

把车载 AI 主程序注册成 systemd 服务，开机自启动。不要依赖手动在终端敲命令，车一通电，系统起来后程序要能自动拉起，这才能接近真实车载体验。

给程序加上日志输出，并把日志写到本地文件。日志里至少要记录：收到什么指令、调用哪个模型、用了多长时间、结果是否成功。后续排查问题，靠日志比靠猜有效得多。

考虑文件系统保护。频繁断电容易损坏 TF 卡，有条件可以把系统改为只读挂载，或者把日志写到内存盘，重启后清空。至少要做到程序崩溃后可以快速重启，而不是每次断电都要重新刷镜像。

车载网络也很重要。如果车里有稳定的手机热点，树莓派可以连接热点上网，方便拉取数据和调用远程服务。但不要依赖网络，后面讲模型部署时会专门说。

4. Qwen部署：本地量化版还是云端API

4.1 本地部署是第一优先，因为车上网络不可控

在隧道、地库、高速移动过程中，网络随时可能中断。如果你的车载 AI 完全依赖云端 API，断网就等于系统整体失明。所以车载场景里，本地部署是更合适的路线：模型权重直接放在树莓派上，推理过程不依赖外网，哪怕车上完全没网，核心问答和控制能力仍然能用。

树莓派上跑 Qwen，最常用的方式是先下载量化后的模型文件，再用本地推理框架加载。量化模型会把原来的高精度权重转换成更紧凑的表示，比如热词里常见的q4_k_m就是 4 bit 量化的一种格式。量化后模型体积变小，内存占用降低，速度也比加载原始精度更快，代价是回答质量会有一定下降。

模型体积和内存的关系可以按这个量级估算：一个 1.5B 参数的模型，量化到4bit左右，权重文件大约 1GB；3B 模型大约 2GB；7B 模型大约 4GB 以上。这还没算运行时上下文和系统开销。所以树莓派8GB内存版本，比较合理的区间是 1.5B 到 3B 模型；7B 模型就算勉强加载进去，速度和稳定性也不会让人满意。

我在第一次复现时，建议从最小的模型开始，比如 0.5B 或 1.5B 的量化版本。目标不是得到最强回答，而是先把调用链路跑通：框架加载模型、发一条消息、拿到回复、退出释放资源。链路通了，再换更大的模型对比效果。

4.2 云端API更适合原型验证，不适合长期车载运行

如果你只是想快速验证"Qwen 能不能理解我的指令"，直接用云端 API 是最快的方式。注册账号、配置 API Key、写几十行代码，就能得到一个效果不错的对话模型。API 方式推理速度通常很快，模型版本也最新，适合功能原型期。

但放到车上长期运行，云端 API 有几个问题：延迟受网络影响，费用会随调用量增长，数据离开本地也会引入隐私问题。还有一个细节是，云服务的区域和接口地址不同，按终端提示配置好 API Key 后，要确认调用的区域和服务类别与自己环境一致。这个环节不难，但要注意，否则会出现鉴权通过但模型回答不正常的怪问题。

更可靠的架构是本地优先、云端备用：本地小模型先响应大部分请求，只有遇到明显超纲的问题，或者本地回答置信度不高时，才调用云端模型。这个架构代码复杂度会增加，但也更接近真实产品。如果没有特别强的需求，我建议先别引入云端，把本地模型跑稳再说。

4.3 模型选择不要只看参数，还要看速度和效果平衡

0.5B 和 1.5B 级别的模型在树莓派上响应很快，但复杂指令理解能力弱，容易出现答非所问。如果只是做"开风扇、拍照、查温度"这类固定指令，小模型完全够。3B 级别是树莓派5的甜点区，速度和效果比较均衡，能处理更自然的口语表达。7B 级别在树莓派5上属于"验证级"，适合摆好外壳、通电测一下能力上限，不适合做成常驻服务。

我自己的判断标准很简单：单条指令能在几秒内返回，连续操作后内存不持续增长，温度不飙升，就算达到可用线。如果为了追求质量把模型换成 7B，结果每次都等十几秒还经常内存不足，那反而没法用。车载 AI 要的是稳定响应，不是分数最高。

5. 视觉感知和控制链路：摄像头加STM32

5.1 摄像头采集与视觉理解，不要一上来就跑大模型

摄像头负责把真实路况和车内画面变成数据。OV5647 这类 CSI 摄像头通过排线连接树莓派，采集延迟低，适合做实时画面输入。驱动层有两类选择：一类是直接用 picamera2 库，它专门用于树莓派 CSI 摄像头；另一类是 OpenCV 的 VideoCapture，适合接 USB 摄像头。这里最容易踩的坑是 CSI 摄像头在 OpenCV 里默认支持不稳定，建议先确认硬件接口和驱动方式，再决定用哪套代码。

有了画面，下一步是理解。很多人会想直接把画面丢给 Qwen 多模态模型，让它描述。但多模态模型在树莓派上同时跑，内存和算力压力很大，推理时间会拖得非常长。更务实的做法是分层处理：先用轻量目标检测模型把画面里的目标提取出来，比如检测到"人""车辆""路障"，再把这些标签和位置信息组合成文字，交给 Qwen 生成自然语言描述。

YOLOv5 这类检测模型在树莓派上能跑，但帧率不会高。实测时要降低分辨率，比如处理 640x480 甚至更小，并且不要每帧都检测。典型做法是每隔几秒拍一帧做检测，或者收到指令时才拍照分析，这样既能保证功能，又不会长时间占满 CPU。

5.2 控制外设：树莓派负责决策，STM32负责执行

树莓派的 GPIO 可以直接控制舵机、LED、风扇，但如果你要让系统更可靠，最好把底层执行放在 STM32 或树莓派 Pico 上。原因很直接：树莓派跑着 Linux 和模型，一旦模型推理卡死或系统负载过高，直接操作 GPIO 的任务也会被拖住。STM32 作为独立执行端，接收树莓派发来的简单指令，然后自己产生 PWM 信号或读取传感器，即使树莓派端程序崩溃，执行端还能停留在安全状态。

树莓派和 STM32 的通信方式常见有 UART 串口和 I2C。UART 最简单，适合传输短指令，比如发送"fan_on 30"，STM32 解析后把风扇调到 30% 的 PWM 占空比。热词里有人问树莓派如何与 STM32 通信、树莓派 Pico 怎么控制舵机，这些问题本质都是同一个协议问题：双方约定好波特率、数据帧格式和校验位，剩下的就是解析和执行。

在车载 AI 里，执行层要加安全逻辑。我的建议是：AI 生成的动作指令必须经过白名单，只允许控制灯光、风扇、显示设备、提示音这类低风险设备。涉及行车安全的动作不要自动执行，至少要预留人工确认。把 AI 限制在"建议"和"低风险控制"范围内，比给 AI 全部控制权安全得多。

6. 实测怎么看：启动、响应速度、资源占用和稳定性

6.1 先跑通一条最小任务，再谈批量

第一次测试不要接任何外设，先把模型服务跑起来，发一条简单指令，比如"你好，你现在能做什么"，记录从发送到返回的时间。为什么先做这个？因为这一步能验证整个软件链路是否正常，包括模型加载、上下文配置、输出解析和内存释放。如果这步没过，后面接摄像头、接线控，出现问题时根本分不清是模型问题还是外设问题。

跑通后，再逐步加外设。加完摄像头后，测试"拍照并描述画面"；加完 STM32 后，测试"打开风扇 30%"；最后再模拟完整场景"驾驶员发出复合指令，系统同时完成感知、判断和控制"。每一层都单独验证过，最后集成时才不会乱。

6.2 判断"能用"的三个标准

我判断一套车载 AI 原型能不能继续往下做，不看功能列表，只看三个指标：

第一，成功率。连续跑20条指令，无论是问答还是控制，失败或超时的次数必须很低。偶尔失败可以接受，但如果高频失败，说明链路不稳定，继续堆功能只会更糟。

第二，连续任务稳定性。连续运行一段时间，观察内存是不是持续增长。模型推理框架如果存在内存泄漏，跑一段时间后系统会因为内存不足杀掉进程，表现出来就是"一开始正常，用着用着没反应了"。这类问题要靠日志和内存监控来定位。

第三，断电恢复能力。车载设备不能指望司机熟练操作命令行。模拟一下突然断电，再通电，看系统能不能自动启动、程序能不能自动运行，摄像头和外设能不能自动重新初始化。

6.3 性能优化不是无脑换大模型

速度慢，先看模型量级和量化位数，再看推理框架的线程数和批处理设置。模型从 1.5B 换成 3B，速度会下降；同样的模型量化位数越低，运行越快，但质量也会下降。树莓派上没有 N 卡，不能靠 CUDA 加速，更多要靠 CPU 多线程和合理的量化配置。

输出质量差，先看模型本身能力，再看 Prompt 写得是否清楚，最后才考虑微调。不要把推理参数乱调，比如把温度调得过高，回答会变得不稳定。命令解析失败，优先检查输入文本和输出解析逻辑，很多时候不是模型不行，而是模型给出的文本里带了多余空格、标点或者换行，程序没有处理好。

7. 常见问题排查：现象、原因、处理顺序

7.1 硬件类问题：绿灯闪、过热、摄像头不识别

树莓派绿灯闪烁是很多人第一次玩就遇到的坑。绿灯在启动阶段闪烁是正常的，但如果系统运行中反复闪，甚至启动起不来，大概率是供电不足。换一个输出电流更大的电源，换一根质量好一点的 USB-C 线，减少 USB 外设，通常能解决。

摄像头不出图，先确认排线连接方向和深度，再检查系统是否启用了摄像头接口。在 Raspberry Pi OS 里，CSI 摄像头需要确认/boot/config.txt或/boot/firmware/config.txt中的摄像头配置。然后用libcamera-hello或rpicam-hello先测试原生摄像头输出，再接 OpenCV。如果原生命令正常，说明摄像头没问题，问题在应用层。

过热降频也是车载场景常见的。树莓派负载高时温度上升，系统会自动降频，表现为推理速度变慢。解决办法是加散热片、加风扇，并在程序里定时读取温度日志，温度持续过高时降低检测频率或模型负载。

7.2 系统类问题：VNC打不开、中文乱码、软件源更新失败

VNC 打不开不要先怀疑网络。先到树莓派上确认 VNC 服务是否启动，再看当前用户是否登录了图形桌面，最后才检查防火墙和路由器端口。很多时候是因为树莓派处于无人值守状态，图形会话没有建立，VNC 连接自然失败。

中文乱码主要集中两个地方：系统界面乱码和模型输出乱码。系统界面乱码，安装中文字体并设置locale即可。模型输出乱码，重点检查终端编码、Python 进程的PYTHONIOENCODING，以及日志文件是否统一用 UTF-8。Qwen 输出本身是中文，编码统一后乱码问题基本消失。

修改软件源后更新失败，可能是镜像源地址不对，也可能是密钥没有更新。不要只盯着一家镜像，换一个可用镜像，把源文件里的地址重新替换，然后执行sudo apt update看具体报错。注意，这里说的是普通软件源配置，不涉及任何网络代理工具。

7.3 模型类问题：加载卡死、内存不足、回答不稳定

模型加载卡死，第一看内存。用free -h查看系统当前空闲内存，模型权重、上下文和系统其他进程加起来超过物理内存时，系统会疯狂使用 swap，表现为极慢甚至卡死。解决方法是换更小的模型、更低的量化位数，或者关闭不必要的图形界面服务。

回答不稳定，表现为同一句话多次问结果不一致。先看推理温度等参数是否设置过高，接着说 Prompt 是否写清楚要求，最后看量化版本是否对该任务支持不好。如果命令解析要求严格，最好让模型输出 JSON 格式，再用代码解析，而不是让模型输出自然语言后靠字符串匹配。

依赖包问题也很常见。树莓派上装 Python 库时，经常遇到编译报错或者版本冲突。建议创建独立的 Python 虚拟环境，把推理框架、OpenCV、串口库都装在虚拟环境里，避免污染系统环境。报错信息里提到缺哪个库就装哪个，但要注意不同仓库里的包名，有些包在主源里叫一个名字，在 Python 里又有一个名字。

8. 从Demo到生产化：可以继续扩展的方向

8.1 给车载AI加上知识库：Embedding 加 Milvus

如果车载 AI 只能聊天，实用性有限。一个更容易落地的扩展方向，是把车辆说明书、保养手册、历史维修记录导入知识库，让 Qwen 变成一本"能对话的车辆手册"。

流程是：先把文档切分成短文本块，用 Embedding 模型转换成向量，存入向量数据库。收到问题时，先在向量库里检索最相关的文本片段，再把这些片段拼进 Prompt，交给 Qwen 生成回答。这样的回答有据可依，比模型凭空编造可靠得多。

向量库的选择上，Milvus 是常见方案。如果后端是 Java 技术栈，可以借助 LangChain4j 来封装 Embedding、向量存储和模型调用，调用示例在社区里已经很常见。车载场景可以先在小样本数据上验证检索准确率，再逐步扩充知识内容。

8.2 领域微调：用LoRA让Qwen更懂你的指令

通用模型有时理解不了车主的特殊说法。比如你希望它听到"开空调"就执行风扇调速，但模型可能只是聊了一遍怎么开空调，没有真正触发控制动作。这时候可以准备一批"指令-动作"数据，用 LoRA 做低成本微调，让模型更懂你的指令格式。

LoRA 微调的好处是不用重新训练整个模型，训练成本和数据量都相对低。实践时要注意：微调后的模型需要再导出成树莓派能运行的量化格式，然后部署到推理框架里。训练阶段的框架和推理阶段的框架要匹配，否则会出现加载失败或行为异常。

我建议微调前先做好两件事：一是把指令种类收敛，不要一上来就做几十个意图；二是把输出格式固定成规范 JSON，让模型学会"输出结构化指令，而不是自然语言回答"。固定输出格式，对后续代码解析帮助非常大。

8.3 开发过程本身也可以用AI辅助

做这类项目，代码量不小。GPIO 控制、串口解析、摄像头调用、模型调用，每个模块都有很多样板代码。写这些代码的过程中，可以结合 Qwen Code 这类编程辅助工具，快速生成初稿。

但要注意边界。AI 生成的 GPIO 初始化、串口配置这类硬件相关代码，不能直接照搬。外设时序、厂商数据手册、树莓派不同版本之间的引脚差异，都可能让"看起来对的代码"跑不起来。把 AI 生成的内容当作初稿，人工逐行审核后先做小范围验证，再把代码接到主程序里。

8.4 安全边界和正确预期

最后必须说清楚：这是一个学习项目和开发原型，不是可以上路运营的自动驾驶系统。即使功能越来越多，AI 也应该被限制在"建议"和"低风险控制"范围内。操作行车相关设备时，保留人工确认机制。

系统日志要记录对话内容、控制指令、执行结果和异常状态，方便出问题后复盘。把 AI 能力、控制范围、安全兜底三条线分开，整个项目才能做得更大而不失控。树莓派车载 AI 的终点，不是替代驾驶员，而是让普通开发者理解边缘设备上大模型落地的真实边界。

踩过一圈下来，我最大的感受是，真正需要花时间的从来不是某个模型有多强，而是模型、摄像头、控制板、电源和日志能不能稳定串成一条链。先跑通单条指令，再逐步扩展，很多看起来复杂的问题都会变得清楚。如果你也想复现，我建议按这个顺序来：硬件到位后先测摄像头和模型加载，再接入控制端，最后做集成和长时间稳定性测试。