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还是8G2.1 树莓派5是更舒服的起点但4B也不是不能玩跑本地大模型内存带宽往往比 CPU 主频更关键。模型权重在推理过程中需要反复读写带宽越高单位时间内能吞吐的数据越多。树莓派5在 CPU 性能和内存带宽上都比 4B 有明显提升跑 Qwen 这类语言模型时体验会好很多。手头只有4B也可以只是要把模型量级和任务预期降下来。不要指望 4B 跑7B 模型还能流畅交互那会卡到没法用。关键点树莓派4B树莓派5CPU4核 Cortex-A72性能偏老4核 Cortex-A76单核和内存表现更稳内存类型LPDDR4LPDDR4X带宽更高PCIe 扩展无原生 PCIe有原生 PCIe可接 SSD 或加速卡本地模型体验能跑适合 1.5B 级小模型更适合 1.5B 到 3B 量化模型供电要求5V/3A 左右相对宽松5V/5A对电源质量更敏感如果只是学习验证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部署本地量化版还是云端API4.1 本地部署是第一优先因为车上网络不可控在隧道、地库、高速移动过程中网络随时可能中断。如果你的车载 AI 完全依赖云端 API断网就等于系统整体失明。所以车载场景里本地部署是更合适的路线模型权重直接放在树莓派上推理过程不依赖外网哪怕车上完全没网核心问答和控制能力仍然能用。树莓派上跑 Qwen最常用的方式是先下载量化后的模型文件再用本地推理框架加载。量化模型会把原来的高精度权重转换成更紧凑的表示比如热词里常见的q4_k_m就是 4 bit 量化的一种格式。量化后模型体积变小内存占用降低速度也比加载原始精度更快代价是回答质量会有一定下降。模型体积和内存的关系可以按这个量级估算一个 1.5B 参数的模型量化到4bit左右权重文件大约 1GB3B 模型大约 2GB7B 模型大约 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. 视觉感知和控制链路摄像头加STM325.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 30STM32 解析后把风扇调到 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 的终点不是替代驾驶员而是让普通开发者理解边缘设备上大模型落地的真实边界。踩过一圈下来我最大的感受是真正需要花时间的从来不是某个模型有多强而是模型、摄像头、控制板、电源和日志能不能稳定串成一条链。先跑通单条指令再逐步扩展很多看起来复杂的问题都会变得清楚。如果你也想复现我建议按这个顺序来硬件到位后先测摄像头和模型加载再接入控制端最后做集成和长时间稳定性测试。