折腾了一个周末我把树莓派 4B 变成了 24h 在线的 AI 牛马——这不是标题党是真事。起因挺朴素主力笔记本白天写代码晚上还要处理定时脚本、跑点小任务风扇一转就是一整夜电费倒是小事关键是吵、构件发热、SSD 寿命肉眼可见地掉。我就想能不能找一台几十块的设备不关机、不折腾、安安静静挂在墙角专门替我干那些重复性的“牛马活”顺带还能接个大模型当半个助理。刚好手头有一块吃灰的树莓派 4B于是花了一个周末把它从“积灰板”变成了 24 小时在线的本地 AI 小工。这篇文章不是要吹树莓派能跑出 4090 的效果恰恰相反我是想分享一个务实的路线在内存只有 8GB、算力约等于手机芯片的板子上怎么选模型、怎么搭推理服务、怎么让它真正干活以及连续运行之后踩到的一堆坑。适合正在犹豫“要不要折腾树莓派跑 AI”的人也适合已经有板子但不知道用来干嘛的朋友。我会尽量把每一步的理由和实测结果都写清楚方便你直接抄作业。1. 为什么是树莓派 4B低功耗 AI 的性价比账1.1 先算一笔账云主机 vs 旧笔记本 vs 树莓派开始动手之前我列过一张对比表。很多人一听“本地跑 AI”第一反应是租云主机或者用家里的旧笔记本这两个方案我都试过各有各的问题。云主机的最省心但贵不是主要矛盾数据会离开你的机器。对于一个要处理个人笔记、待办清单、家庭内部消息的助手很多数据其实不适合放到云上。再说 GPU 云主机按月几百块买树莓派能买十块了。旧笔记本的方案倒是便宜可功耗太难看普遍 30W 到 60W相当于常年亮着一盏很亮的白炽灯风扇和发热也忍不了。更麻烦的是笔记本会定期休眠你总不能为了保持“在线”去改 Windows 电源计划。树莓派 4B 刚好卡在甜点上整机功耗 3W 到 8W性能比想象中强4 核 A72主频 1.8GHz社区资料多出了问题至少有十万篇教程垫背。价格方面8GB 版新的大概三四百块闲鱼就更便宜。如果你手头有 4GB 版也能玩但我下面会讲内存是这台 AI 牛马的命门8GB 是底线。方案整机功耗24 小时电费/月性能数据隐私省心程度云主机由实例决定贵几十到几百元高依赖云端高旧笔记本30W-60W15-30 元中本地低得防休眠树莓派 4B 8GB3W-9W3-5 元中低本地高直接塞角落有人会问那二手瘦客户端、软路由、电视盒子呢这些我也折腾过最大的问题是 AI 生态不统一安装一个 Python 环境都费劲。树莓派的系统镜像、编译工具链、arm64 优化都做得比较成熟这是它的隐形优势。1.2 8GB 版本是底线硬件清单这里抄作业如果你决定入坑我的建议是直接把目标锁定为 8GB 内存版。跑本地模型时光把模型权重加载进去就已经是 1GB 起步再加 Python 进程、系统缓存、日志缓冲4GB 版本跑 Qwen 1.5B 都会频繁碰内存墙6GB 版本虽然勉强但也不宽裕。我现在的组合如下树莓派 4B 8GB官方 5V/3A 电源或者质量靠谱的 5V/3A USB-C 电源主动散热风扇或者官方散热套件32GB 以上的 microSD 卡仅用于引导一块闲置 SATA 固态硬盘 USB 3.0 硬盘盒用来装系统一张稍好点的网卡自带不用额外买这个组合的核心思路是SD 卡只是“开门钥匙”正式系统放在 USB 外接 SSD 上。原因有两个性能和寿命。SD 卡的随机读写太慢加载大模型时会拖后腿而且反复写入小文件特别伤卡24 小时在线的系统一两周就能把卡写穿。SSD 虽然也是二手闲置的但寿命强几个量级性能也更好。2. 系统安装与 SSD 启动让 AI 牛马跑得久而不是跑得快2.1 为什么选择 Ubuntu 22.04 而不是桌面版树莓派官方推荐的是 Raspberry Pi OS但我的诉求比较偏开发者向要长期跑 Python 服务、要快速装 Docker、要尽量跟云服务器操作习惯一致。Ubuntu Server 22.04 LTS 的 arm64 版本在树莓派 4B 上支持得很好内核较新apt 软件源里直接有 python3-venv 和主流编译工具省了不少手工折腾。为什么不选 Ubuntu 23.04 或 24.0422.04 是 LTS做 24 小时运行的底座我更看重稳定性而不是追新内核。这个心态也是整台“牛马机”的定位它要像服务器一样默默工作不需要天天刷版本。2.2 从 USB SSD 启动的完整步骤这个环节的坑比较多我按最终验证可用的顺序走一遍用 Raspberry Pi Imager 烧录 Ubuntu Server 22.04 到固态硬盘。注意“存储卡”选项选择你的 USB 硬盘盒而不是 microSD 卡。这一步不需要额外操作Imager 会自动分区并写入引导。如果树莓派插着这个板子直接开机没反应先拔掉 SSD找一张 SD 卡烧录同一个 Ubuntu 镜像是启动一次。开机后执行下面的命令升级引导程序让树莓派 4B 支持从 USB 设备启动sudo apt update sudo apt install -y rpi-eeprom sudo rpi-eeprom-update -a sudo reboot关机拔掉 SD 卡插上 USB SSD 开机。正常情况下会从 SSD 启动系统盘就是那块硬盘。检查方法很简单df -h / lsblk看到根目录挂载在/dev/sda1或类似设备名就说明 SSD 成功接管了系统。如果 SSD 在 USB 3.0 接口上不稳定可以把启动顺序配置为“先 USB 启动再 SD 卡”但现实中我建议直接让 SD 卡彻底缺席反正系统在 SSD 上SD 卡拿掉还少一个故障点。2.3 内存和 Swap8GB 内存其实不够用8GB 听起来不小但 Linux 系统本身加缓存就得吃掉 2GB加载一个 1.5B 参数的模型要 1.5GB 左右再加推理过程中的中间缓冲区、Python 服务、日志很快就接近上限。所以最正确的第一步不是优化代码而是配一个 swap 文件。我把 swapfile 放在 SSD 上大小给了 8GB。很多人的问题是默认 swap 只有 100MB 左右模型一加载内核直接 OOM Kill 进程轻则服务死掉重则整个系统卡死。sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab还要注意一个参数vm.swappiness。树莓派跑模型时如果内核太积极地换页SSD 会被频繁写入反而拖慢性能。我调成 10意思是尽量让数据留在物理内存实在不够才用 swap。echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf sudo sysctl -p调完 swap 之后模型加载失败的问题基本消失但并发请求还是会卡这个话题留到第 5 节讲。3. 本地大模型引擎选型llama.cpp 是树莓派的最佳搭档3.1 Ollama、Hugging Face、llama.cpp 怎么选现在想在本地跑大模型主流的工具就那么几个Ollama、llama.cpp、Transformers。Ollama 胜在安装简单一条命令就能跑起来默认也有 OpenAI 兼容 API。但它的树莓派 arm64 支持一直处于“实验性”阶段部分模型的量化格式对低配 CPU 不友好而且底层封装的自由度低。如果你想在树莓派上长期造轮子我不推荐它作为主力。Hugging Face Transformers 是最通用的选择只要有你需要的模型都能跑。问题是它默认走 PyTorch内存开销大加载一个 1.5B 模型到树莓派上可能就要 4GB 起步而且没有针对 CPU 推理的改名级别优化速度反而极慢。最后是 llama.cpp。它是纯 C/C 实现专为 CPU 推理设计走的是 GGUF 量化格式。模型权重可以从 4bit 压到 2bit内存占用大幅下降。它的llama-server子命令自带 HTTP 接口和 OpenAI 兼容的 API可以直接被 Python 脚本调用。对于树莓派这种“小脑壳”我最终选了 llama.cpp而且很满意。3.2 编译与模型下载实操编译前先装依赖否则后面的 server 模式会缺组件sudo apt install -y build-essential cmake git curl libcurl4-openssl-dev python3-venv然后拉代码、编译git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 4-j 4是因为树莓派 4B 只有 4 个核心再多也只是看着热闹。编译完成后重点的二进制文件有两个llama-cli命令行聊天的和llama-serverHTTP 服务的。模型方面首选从 Hugging Face 下载 GGUF 格式。我用的是 Qwen 系列主要是因为中文效果好生态也成熟。下载命令类似cd ~/models wget https://huggingface.co/Qwen/Qwen2.5-1.5B-Instruct-GGUF/resolve/main/qwen2.5-1.5b-instruct-q4_k_m.gguf如果你的网络环境对 Hugging Face 不太友好换成镜像站也可以但注意校验文件是否完整我因为中断过下载导致模型文件不完整加载时直接报错。3.3 几款小模型的实测对比我对着表格连续跑了一天拿它们分别做中文问答、摘要和简单的函数调用测试数据如下模型量化文件大小加载后内存占用生成速度tok/s中文表现可用度Qwen2.5-0.5B-InstructQ4_K_M约 0.4GB约 1.5GB10-14略弱但能懂简单命令Qwen2.5-1B-InstructQ4_K_M约 0.8GB约 2.2GB7-10一般轻量任务Qwen2.5-1.5B-InstructQ4_K_M约 1.1GB约 3GB5-7明显更好推荐Qwen2.5-3B-InstructQ4_K_M约 2.2GB约 4.5GB2-4好但慢勉强可用Llama-3.2-1B-InstructQ4_K_M约 0.9GB约 2.3GB6-9英文好中文弱备选我的最终选择是 Qwen2.5-1.5B-Instruct-Q4_K_M中文质量可以接受速度也在“能等”的区间5 到 7 token 每秒一句话大概两三秒出来用来做定时摘要和工具调用完全够。如果你手头的任务更偏英文或者代码片段Llama-3.2-1B 是更好的选择。3B 模型我试过不是不行而是生成一段 300 字的摘要要等将近两分钟这个体验在“牛马”场景里太煎熬。不过你要是做离线的论文解析、长文档总结慢一点倒无所谓内存也勉强够。4. 把 AI 牛马派上用场定时任务、文件整理与局域网聊天4.1 确定牛马的岗位说明书“牛马”这个词有点戏谑但定位很准确它不是聊天机器人是替我干杂活的工具。我给它定的岗位职责有三条定时生成我的每日待办摘要从本地 Markdown 文件读任务生成优先级列表监控下载目录自动分类重命名文件并用一句话解释这个文件是什么提供一个局域网内可访问的聊天页面让我在手机和电脑上随时问它问题这三件事的共同点是不需要实时响应、不需要高端性能、需要稳定在线。树莓派 24 小时挂机正好满足。4.2 用 llama-server 搭建本地 API编译出来的llama-server可以直接提供服务cd llama.cpp/build/bin ./llama-server \ -m ~/models/qwen2.5-1.5b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ -t 4 \ -c 4096 \ --no-mmap参数拆解一下-t 4表示用满 4 个 CPU 线程-c 4096是上下文长度树莓派上设 8192 会导致初始化变慢4096 是性能和容量的折中--no-mmap可以避免模型文件被整块映射到内存减少内存紧张时的崩溃概率。启动成功后可以用 curl 快速试一下接口curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen,messages:[{role:user,content:你好介绍一下你自己}]}如果返回正常的 JSON说明本地服务已经跑起来了。这个时候局域网内任何设备都能通过http://树莓派IP:8080访问这个 API手机、笔记本都行。4.3 一个简单的工具调用循环模型再强如果只能聊天那还是“聊天牛马”不是“干活牛马”。要让 AI 直接操作树莓派我写了一个很朴素的工具调用循环用户请求进来先让模型判断要不要调用某个工具如果要就执行工具并拿到结果再把结果交回模型总结。我用的是最原始的 JSON 输出解析没有上重框架原因是树莓派跑不动太重的 Agent 框架。下面是核心逻辑的简化版import requests import json import subprocess def call_llm(messages): resp requests.post(http://localhost:8080/v1/chat/completions, json{model: qwen, messages: messages}) return resp.json()[choices][0][message][content] def run_tool(tool_name, args): if tool_name read_file: with open(args[path], r) as f: return f.read() elif tool_name list_dir: return str(subprocess.check_output([ls, args[path]]).decode()) # ... 其他工具 prompt 你是家庭助手。如果用户要求查看文件或目录输出 {tool: read_file, args: {path: /path/to/file}} 否则正常回答。 user_msg 看看 /home/pi/todo.md 里有哪些任务 messages [{role: system, content: prompt}] messages.append({role: user, content: user_msg}) resp call_llm(messages) try: tool_call json.loads(resp) tool_output run_tool(tool_call[tool], tool_call[args]) messages.append({role: assistant, content: resp}) messages.append({role: user, content: f工具结果{tool_output}请总结}) print(call_llm(messages)) except json.JSONDecodeError: print(resp)别指望 1.5B 模型每次都规规矩矩输出 JSON所以代码里务必加异常处理。如果连续解析失败就用正则把花括号内容掐出来能做但效果一般。更好的方案是给模型提供 few-shot 示例把“函数调用”的格式写死在 system prompt 里实测能把成功率从 60% 提到 85% 左右。4.4 定时调度和消息推送工具调用循环写完剩下的就是挂个 cron。比如每天早上 8 点生成待办摘要我会在/etc/cron.d/下新建一个文件内容类似0 8 * * * pi /home/pi/agent/daily_report.sh /var/log/agent.log 21daily_report.sh里做的事情是读取todo.md调用本地 LLM API 生成一段“今日重点”再通过微信或邮件推送给自己。因为模型是本地的推送什么内容都完全私有不会经过第三方接口。文件整理服务我用的是一个简单的inotifywait脚本监控~/Downloads目录新增文件后休眠 10 秒防止文件还在写入然后调用模型判断这个文件属于哪类、建议叫什么名字再用 Python 的os.rename移动。效果不算惊艳但配合 1.5B 模型足够识别“发票PDF”“截图PNG”“合同DOCX”这些大分类了。局域网聊天页面就更简单了写一个几十行的 Flask 应用把浏览器的请求转发给 llama-server渲染一个简洁聊天框。想加用户体系、知识库、语音输入都行但我的原则是让它先跑三个月稳定下来再逐步加功能。5. 连续运行两三天的稳定性考验实测数据与问题排查5.1 温度、功耗和内存表现这一节的数据来自我这个周末结束后的连续运行记录使用的是树莓派 4B 8GB Ubuntu 22.04 Server无桌面环境。指标待机一份请求处理中CPU 占用1%-5%100%四核满内存占用约 2.1GB约 5.8GB温度38-42℃55-62℃整机功耗3.2W-3.8W7.8W-8.6W在没有主动散热的情况下满载温度能冲到 75℃ 以上CPU 会降频到 1.2GHz 左右推理速度肉眼可见变慢。加装风扇后温度稳定在 60℃ 附近速度基本不掉。功耗这个数据让我很满意按 8W 算24 小时是 0.2 度电左右一个月 6 度电按普通居民电价就是三四块钱等于养了一个永远不哄不闹的小员工。内存方面模型加载 3GB 左右系统与缓存占 2GB再加上一个 Flask 服务常态在 5.8GB 附近。如果跑两个模型同时加载内存会立刻逼近 7GBswap 就开始频繁写入。所以我后来定了一个规矩同一时间只跑一个模型另一个模型切换时先停旧的再加载新的。5.2 一次 OOM 事故的完整排查链路连续跑到第三天的时候llama-server 突然没有任何响应用curl请求直接超时。我的第一反应是看进程ps aux | grep llama-server结果进程不见了。再查系统日志journalctl -k --since 10 minutes ago | grep -i oom日志里明确写着“Out of memory: Killed process ... (llama-server)”。原因不难理解模型本身 3GB并发请求一多每个连接的上下文缓冲区又要占几百 MB几个请求同时进来8GB 物理内存加上 8GB swap 都顶不住内核就挑了个最占内存的进程杀掉。修复方案有三个缺一不可把并发数限制住。llama-server 支持--parallel 1同时只处理一个请求。听起来很蠢但这是树莓派上保证不 OOM 的关键。把-c上下文长度降回 4096避免每个请求分配 8K-token 缓冲区。给 llama-server 增加系统守护崩了可以自动重启。我写了个 8 行的 systemd service执行Restarton-failure设置RestartSec5。改完之后又跑了三天没再发生 OOM。这里也提醒一句在生产环境看到“自动重启”别觉得丢脸对低配设备来说能让服务快速恢复比让它永远不崩更重要。5.3 提升长期稳定性的设置除了内存我还做了几个小优化关闭 Wi-Fi 电源管理。树莓派默认可能启用省电模式导致网络偶尔断流。日志轮转。journalctl --vacuum-size100M定期清理避免日志写满 SD/SSD。设置定时重启周期。我给了它每周 4 点重启一次用 cron 执行sudo reboot配合 systemd 自启整个系统每个周期都是一副新面孔。这些设置单独看都很琐碎但叠加起来一台“牛马机”才能真正做到 24 小时不需要人盯着。6. 这周末踩过的五个坑以及我后来的修复6.1 电源供电不足导致随机重启第一次插上移动硬盘和风扇时树莓派频繁重启。一开始以为是系统问题折腾了半天装了三遍系统最后用dmesg才看到供电警告电压掉到 4.9V 以下。树莓派 4B 的官方电源是 5V/3A但 USB 硬盘、风扇、Wi-Fi 都要从这个口取电。修复很简单换回官方电源并且把不必要的外设拔掉。移动硬盘如果必须用优先选带独立供电的硬盘盒不要指望树莓派那点 USB 电流养所有设备。6.2 Swap 写爆 SD 卡第一次没配 swap 时系统直接 OOM。配了 swap 后我又自作聪明把它放在 SD 卡上结果运行一天后 SD 卡读写非常慢用iostat看发现 swap 在不断换页。SD 卡本身就是闪存介质频繁小写入寿命下降很快。后来把 swapfile 挪到 SSD 上问题立刻解决。如果你手头没有 SSD至少也把 swap 放成 2GB 大小并调低 swappiness能缓解但不能根治。6.3 编译环境缺少依赖server 模式没法用这个坑特别隐蔽。第一次编译 llama.cpp 时我记得只装了build-essential结果编译完成后发现llama-server的 HTTP 接口完全没有可用。查了 CMake 输出才知道GGML_CURL选项没打开因为系统缺少libcurl4-openssl-dev。重新安装依赖后需要删掉 build 目录重新编译rm -rf build cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 4所以如果你也要编译务必先把所有依赖装齐再开始否则就是白跑半小时。6.4 多进程抢占内存我有段时间同时跑着 llama-server 和 Python Agent各占各的模型实例结果两者加起来内存直接爆掉。后来改成统一架构Python 只是客户端只负责调度和工具调用所有模型请求都走同一个 llama-server 进程。这样内存始终只占一份模型权重也更容易做并发控制。6.5 中文模型乱码问题用 Qwen 时遇到一个很尴尬的现象模型回答里偶尔出现“???”。排查到最后不是语言模型问题而是终端环境编码llama-server 在systemd服务环境里的LC_ALL没设成 UTF-8导致响应中的中文被替换成了乱码。在 systemd 配置里加上EnvironmentLC_ALLC.UTF-8 EnvironmentLANGC.UTF-8重启服务之后中文恢复正常。这个问题坑了我大半天属于那种不查日志根本想不到的类型。折腾完这一趟我最大的感触是本地 AI 的价值不在于跑多好的模型而在于让模型真的住进你的环境里随叫随到、低功耗、数据不出屋。树莓派 4B 跑 Qwen 1.5B 确实算不上快但它能在一个角落安静地待一年替你把重复性的事情一件件做掉这种“牛马”精神反而是很多云端服务做不到的。最后再分享一个我至今还在用的技巧每天睡前对着树莓派的聊天页面说一句今天的备忘第二天早上的日报会准时把整理好的内容推到我手机里。这个组合我已经连续跑了两周没出过任何岔子。下一步我准备给它加一个 USB 麦克风阵列试试本地语音交互等项目稳定了再回来填坑。