周末把吃灰很久的树莓派 4B 翻了出来折腾了两天终于让它从一块“落灰板子”变成了一台 7×24 小时不睡觉的 AI 牛马。其实就是把本地大模型、Agent 脚本和定时任务全部塞进这块小 ARM 板子里让它替我做文本总结、日报生成、定时提醒、内容归类这些重复劳动。整个过程踩了不少坑也摸到了一些很实在的调优参数。如果你手里也有一块树莓派 4B或者想搞一台低功耗本地 AI 服务器这篇内容可以直接当成一份避坑笔记来看。我先把结论放前面树莓派 4B 跑 AI 不是玄学内存版本和模型选择是关键。8GB 版本的 4B 跑量化后的 3B、7B 参数模型做文本类任务完全够用4GB 版本只能用 1B、3B 模型扛不住多轮对话。功耗控制得当的话整机待机 5W 左右跑推理时也就 10W 上下一个月电费都不够买杯奶茶。所以我选择在它上面做本地化、低功耗、隐私可控的 AI 小服务而不是再去折腾云服务器。下面我按折腾顺序拆开写从方案选型、系统安装、模型部署到 24 小时稳定运行每个环节都会说明我为什么这么选以及哪些地方容易翻车。1. 项目定位与方案拆解1.1 为什么要把树莓派变成 AI 牛马先说清楚“AI 牛马”这个定位。我理解中的“牛马”不是简单地跑一个聊天机器人挂在那里而是让它做一堆默默无闻、重复度高的杂活比如每天早上把几个信息源的标题汇总成简报把一堆杂乱文本分类归档定时把会议录音转成文字草稿或者监听某个文件夹、有新增文件就自动调用模型处理。树莓派低功耗、能 24 小时开机、可玩性高正好适合干这种“不出彩但持续产出”的活。如果直接买云服务器一个月几十块钱起步还得考虑数据隐私。如果只为了跑模型一台二手 x86 小主机功耗又偏高。树莓派 4B 是折中方案ARM 架构性能确实弱但内存带宽和 CPU 算力跑小模型勉强能看而且折腾过程本身也是一种乐趣。这里提醒一下如果你手里的是 2GB 或 4GB 版本别强行去跑 7B 模型否则系统直接卡死或者 OOM连最基本的 SSH 运维都成问题。1.2 整体方案选型与软件栈我最终的软件栈是 Ubuntu 22.04 LTS Docker Ollama Open WebUI Python 脚本。没选树莓派官方系统主要是为了跑 Docker 和内核模块更省心。Ubuntu 22.04 的 ARM64 支持已经很成熟软件源里直接有 Docker 的仓库ollama 官方也提供 Linux 安装脚本整体兼容性比 Raspberry Pi OS 清爽很多。Ollama 负责模型加载和 API 调用底层是 llama.cpp 那套量化推理逻辑。Open WebUI 负责日常对话入口算是给模型套了一个好看的皮肤。Python 脚本调度 Agent 任务比如定时写文件、定期调用 Ollama 的 API 完成特定指令。为什么不用纯 Python 去加载模型因为树莓派这种 ARM 设备纯 Python 推理性能远不如 llama.cpp 这类高度优化的 C 推理框架Ollama 本质上已经帮我把这块优化关系处理好了。这里还有一个很关键的选择模型跑在 CPU 上。树莓派没有 NVIDIA GPUOllama 会自动走 CPU 推理。CPU 推理不是不能用关键是模型参数量别选太大。我在 8GB 版上用 qwen2.5:3b 和 llama3.2:3b生成速度大约 8~12 token/s做文本摘要、小规模对话完全够用。如果你只是做简单的关键词提取甚至可以用 qwen2.5:1.5b速度能冲到 15 token/s 以上。1.3 树莓派 4B 与云服务器/台式机的对比维度树莓派 4B云服务器家用台式机功耗5W~10W不计服务商电费待机 30W推理 100W成本板子 300~600 元一次投入月租 50~200 元原本就有的设备可不计可玩性极高GPIO 可扩展低只能运维中受限于硬件AI 算力弱CPU 推理视配置而定有独显更好隐私性高数据不出门中考虑平台信任高我个人的建议是别拿树莓派和带独显的台式机比推理速度它的价值在于“低功耗常驻”和“随手扩展”。当你想让 AI 帮你干活又不希望一台高功耗机器在书房里嗡嗡响树莓派就是最合适的那个。另外树莓派的 GPIO 还能接传感器、按钮我后面甚至做了个物理按键触发 AI 任务的小玩具这就是它能当“牛马”的额外优势。2. 硬件准备与系统安装2.1 硬件清单与引脚图速览先看下我实际用的硬件列表树莓派 4B这里强烈建议 8GB 内存版本。官方 5V/3A USB-C 电源杂牌电源容易造成电压跌落直接导致系统重启。64GB A2 级 microSD 卡或者直接上 NVMe/SSD 扩展板。散热风扇或铝合金散热壳。跑模型时 CPU 温度可以到 70~80℃没散热会降频。一个 5V 风扇接在 GPIO 的 4 脚5V和 6 脚GND或者 2 脚5V和 39 脚GND。“树莓派 4B 引脚图”我直接给几个核心点新手最容易搞错物理引脚第 2 脚和第 4 脚都是 5V 输出风扇正极接这里。物理引脚第 6 脚、第 9 脚、第 14 脚等是 GND风扇负极接其中一个即可。第 3 脚和第 5 脚是 I2C 的 SDA 和 SCL可以接 OLED 显示屏但不建议给风扇供电用。GPIO 逻辑电压是 3.3V不能直接驱动大部分 5V 继电器需要加三极管或继电器模块。我实际把风扇接到 5V 和 GND 后又用 PWM 线接在第 12 脚GPIO 18上写了个脚本让他测温调速这样晚上书房里不会一直嗡嗡响。这里有个小经验接好线后先别急开机用万用表量一下 5V 和 GND 是否短路通电瞬间冒烟这种事多半是电源线接反了。2.2 刷写 Ubuntu 22.04 与初始化设置下载 Raspberry Pi Imager选择 Ubuntu 22.04 LTS 64-bit 镜像。注意选 64 位 ARM 版本不要选 32 位。写入 SD 卡前Imager 界面里有几个设置项值得动手改开启 SSH。设置用户名和密码。配置无线网络SSID 和密码提前填好。如果你用有线网这一步可以跳过。首次启动后第一件事是执行系统更新sudo apt update sudo apt upgrade -y接着安装基础工具sudo apt install -y curl git vim htop tmux i2c-tools再配置一下 GPU 内存分配。树莓派 4B 上GPU 和 CPU 共享内存跑 AI 推理时图形渲染没必要占太多内存。编辑/boot/firmware/cmdline.txt把gpu_mem128加到一行后面。我实际设成了gpu_mem64或者干脆不设因为这是无头服务器不需要桌面环境。如果以后要接 HDMI 显示器再调回 128MB 也不迟。还有一个经常被忽略的地方禁用不必要的蓝牙和 WiFi 省电模式。既然是 24 小时在线设备网络稳定性至关重要。用rfkill查看蓝牙状态如果不常用蓝牙就顺手禁掉避免不稳定的驱动影响整体电源管理。2.3 为什么是 Ubuntu 22.04 而不是 20.04 或官方系统我在热词里看到有人搜“树莓派 4B 安装 Ubuntu 22.04”和“树莓派 4B 安装 Ubuntu 20.04”。我的建议很明确能用 22.04 就别用 20.04。20.04 的内核版本偏旧对树莓派 4B 的某些硬件支持不如 22.04 完善而且 Docker 和 Ollama 的兼容性测试基本都围绕新系统做。树莓派官方系统的优势是开箱即用但它的桌面组件和预装软件比较多在一个只跑服务的板子上属于一种浪费。Ubuntu 22.04 LTS 相比 20.04 有更好的 ARM64 软件生态可以直接用官方源安装 Docker也能正常跑高版本 Python。如果你对 Linux 运维不熟可能会觉得 Ubuntu Server 少了图形界面有点慌但相信我树莓派跑服务用命令行效率高得多。3. 部署 AI 运行环境3.1 安装 Ollama 与模型拉取Ollama 装上很简单curl -fsSL https://ollama.com/install.sh | sh装完确认服务状态systemctl status ollama.service拉取模型ollama pull qwen2.5:3b这一步会从模型仓库下载量化后的模型文件大概 2GB 左右看网络情况等一会儿。这里我踩过一个坑一开始直接拉 7B 模型比如qwen2.5:7b在 8GB 树莓派上也能载入但生成速度掉到 3~4 token/s多轮对话后内存占用飙升直接让系统进入 swap 地狱。换回 3B 模型之后体验完全不一样。如果你只有 4GB 内存建议拉qwen2.5:1.5b或llama3.2:1b。日常总结、分类、格式化输出这些任务1.5B 模型也足够没必要逞强跑大模型。Ollama 默认监听localhost:11434要让局域网内其他设备访问需要设置环境变量sudo systemctl edit ollama.service写入[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434然后重启服务sudo systemctl daemon-reload sudo systemctl restart ollama这里要提醒一下把服务暴露到局域网后最好加一层访问控制。最简单的方法是在 Nginx 反代后面加 basic auth或者只允许局域网网段。不要裸奔在公网端口上否则别人能直接调用你的模型垃圾请求能把树莓派跑死。3.2 快速测试模型 API模型拉取完成后先直接用 curl 测试一下curl http://localhost:11434/api/generate -d { model: qwen2.5:3b, prompt: 用一句话说明什么是人工智能, stream: false }如果返回 JSON 里包含response:...和done:true说明核心推理链路已经通了。这里我建议把stream设置成false方便在脚本里拿到完整结果如果追求首字响应速度再改回流式模式。实际使用时不要每次请求都重新加载模型。Ollama 的默认行为是把模型保持常驻内存一段时间但如果内存紧张它会自动把模型卸载。树莓派上跑小模型常驻一个 3B 模型内存占用约 2.5~3GB剩下给系统用刚刚好。要想多个模型同时加载内存会吃紧最好不要这么做。3.3 部署 Open WebUI 作为对话界面虽然我是以 Agent 脚本为主但一个可视化聊天界面还是必要的方便临时对话和测试 prompt。我用 Docker 跑 Open WebUIdocker run -d \ --name open-webui \ --restart always \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main启动后访问http://树莓派IP:3000首次注册一个管理员账号。在设置里把 Ollama Base URL 改成http://host.docker.internal:11434Docker 容器里面就能访问宿主机的 Ollama 服务了。这一步可能会遇到一个经典问题容器起来后打开页面一直转圈。多半是内存不够Open WebUI 底层要跑 Python 后端和一堆 API 服务内存占用轻松到 1GB 以上。再加上 Ollama 的模型驻留8GB 内存会变得很紧张。我的做法是限制容器内存docker update --memory1g --memory-swap1g open-webui这样至少不会让 Docker 容器把系统内存吃干。3.4 编写第一个“牛马”任务脚本聊天界面只是入口真正让它当牛马的是定时任务。我写了一个 Python 脚本每天早上读取一个文件夹里的文本文件调用本地模型生成五条摘要然后输出到一个 Markdown 文件。简化版逻辑是这样的import requests import datetime import pathlib OLLAMA_URL http://localhost:11434/api/generate def summarize(text: str) - str: payload { model: qwen2.5:3b, prompt: f请对以下内容做三点摘要不超过100字\n{text}, stream: False, options: {temperature: 0.3, num_predict: 300} } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) resp.raise_for_status() return resp.json().get(response, ) def main(): today datetime.date.today().isoformat() folder pathlib.Path(data_input) output_file pathlib.Path(fsummary_{today}.md) lines [] for file in folder.glob(*.txt): content file.read_text(encodingutf-8) lines.append(f## {file.name}\n\n{summarize(content)}\n) output_file.write_text(\n.join(lines), encodingutf-8) if __name__ __main__: main()然后用 systemd timer 定时调度或者直接写个 crontab0 8 * * * cd /home/pi/ai-worker /usr/bin/python3 worker.py worker.log 21这个脚本看起来简单但有几个细节值得注意。第一timeout一定要设置默认 API 请求会长期挂起如果模型加载中偶发卡住脚本就僵在那里。第二temperature调低到 0.3 左右摘要类任务不需要模型发挥想象力低温度输出更稳定。第三输入文本长度要控制3B 模型的上下文窗口有限超过 2000 token 会把回复质量拉得很差。4. 24 小时稳定在线的调优与监控4.1 开机自启与进程守护Ollama 安装后自带 systemd 服务默认开机自启。Open WebUI 我用--restart alwaysDocker 也会盯着它。唯一需要自己写服务的就是各种自定义 Agent 脚本。我写了一个 systemd 服务[Unit] DescriptionAI Worker Afternetwork-online.target ollama.service Wantsnetwork-online.target [Service] Typesimple Userpi WorkingDirectory/home/pi/ai-worker ExecStart/usr/bin/python3 /home/pi/ai-worker/worker.py --loop Restartalways RestartSec30 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target这个服务的核心是--loop模式让 worker 一直循环监听某个目录或某个队列。文件变了就调用模型处理完写入结果。生产环境里如果某个任务卡住systemd 的Restartalways会让它在 30 秒后重新拉起比裸跑 Python 省心得多。部署命令是sudo cp ai-worker.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable --now ai-worker4.2 内存清理与 Swap 策略8GB 内存看起来很多但 Ollama 驻留模型 Docker 容器 Python 脚本加起来空闲内存很快见底。我在实际使用中观察到的内存分布大概是这样的组件内存占用系统基础服务1.0~1.5GBOllama 常驻模型2.5~3.0GBOpen WebUI0.8~1.2GBPython worker 脚本0.3~0.5GB剩余可用1.0~3.0GB4GB 版本就别指望能同时跑这些我建议 4GB 版只保留 Ollama而 Open WebUI 换成一个极简的前端或者干脆只用 API。Ubuntu 默认可能没有配置 swap 文件。我个人建议给树莓派配一个 4GB 的 swap 文件防止内存突增导致 OOM但不要依赖它跑模型。创建 swapsudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile为了让重启后自动挂载在/etc/fstab里加一行/swapfile none swap sw 0 0这里有个分寸感swap 用太多反而拖垮性能因为树莓派是 SD 卡或 SSDswap 的随机读写速度远不能和内存比。我把它当作“保命符”而不是“加速器”真正让模型能跑起来的关键还是模型选小一号。4.3 温度监控与过热降频树莓派 4B 高性能工作时发热很明显。跑 3B 模型推理时 CPU 满载温度 80℃ 以上很常见。当芯片温度超过 85℃ 时固件会自动降频到 600MHz生成速度会极其感人。我推荐在 shell 里直接看温度vcgencmd measure_temp或者持续监控watch -n 2 vcgencmd measure_temp如果没有散热风扇至少要加散热片加铝壳。我用的方案是 PWM 风扇加一个简单脚本用 GPIO 引脚输出 PWM 信号控制转速低温时转速低、高温时转速高。脚本核心是读温度、写 PWM 值逻辑不复杂但效果明显跑模型时温度稳定在 65~70℃风扇噪音也不大。还有些人喜欢超频到 2.0GHz 以上我个人不建议在 AI 工作负载上超频。树莓派 4B 超频提升有限但稳定性下降明显24 小时开机场景稳定优先。4.4 数据持久化与备份策略SD 卡最怕断电和频繁写入。树莓派跑 AI 服务虽然 Ollama 的模型是只读文件但日志、数据库、Docker 卷会不断写入。为了减少掉盘风险我做了两件事一是把 Docker 数据、关键目录挂到 SSD 扩展盘二是定期备份配置文件和模型清单。如果你不想加 SSD至少要把日志重定向到 tmpfs 或限制日志大小sudo nano /etc/systemd/journald.conf修改SystemMaxUse200M MaxRetentionSec7d系统日志无节制增长时间长了会写满 SD 卡。Ollama 的模型缓存、Open WebUI 的数据库如果都在 SD 卡上建议每周备份一次到局域网 NAS 或另一边机器rsync -av /home/pi/ai-worker/ backupnas:/backup/ai-worker/别小看这一步树莓派断电次数多了之后SD 卡真的会毫无征兆地变只读。我吃过这个亏重装系统不可怕可怕的是模型提示词和脚本没有备份。5. 常见问题与排查技巧实录5.1 问题速查表症状可能原因解决办法SSH 连接不上电源电压跌落导致重启循环换电源或检查 USB-C 线是否支持 5AOllama 拉模型超时网络不稳或镜像源问题重试或手动下载模型文件后导入模型生成速度极慢散热不足导致降频加风扇检查温度是否超过 82℃打开 Open WebUI 白屏内存不足被 OOM限制 Docker 容器内存或增加 swap定时任务不执行cron 环境变量缺失脚本头部写上#!/usr/bin/env python3路径用绝对路径局域网无法访问 APIOllama 只监听 localhost修改 systemd 环境变量OLLAMA_HOST0.0.0.0:114345.2 我踩过的一个大坑Ollama 模型驻留导致系统卡死第一次我把llama3.2:7b拉下来以为 8GB 内存能轻松扛住。结果加载完模型内存直接爆到 7.6GB系统开始疯狂使用 swapSSH 敲个命令要等半分钟。我当时的排查思路是先看htop发现绝大部分内存被一个名为ollama_llama_server的进程占用。解决方式很简单用 3B 模型替代 7B 模型同时设置 Ollama 的并发参数量ollama run qwen2.5:3b在模型交互界面用/set parameter num_ctx 2048限制上下文长度。上下文越长模型要缓存的历史 token 就越多内存占用增长非常快。我实际把上下文控制在 2048日常任务完全够用。另一个经验是设置 Ollama 环境变量OLLAMA_NUM_PARALLEL1强制一次只处理一个请求。树莓派 CPU 本来就弱多个并发请求会让 token 生成互相抢资源最后谁都跑不快对实时性要求不高的任务宁可排队也不要并发。5.3 AI 幻觉在本地小模型上更明显这里要聊一下“AI 幻觉”。小模型参数少知识截止日期早很多细节记不住很正常。如果让qwen2.5:3b直接回答特定事实它一本正经编出来的概率非常大。我找了一个很具体的问题测试模型会把不存在的库名说得有模有样。应对方式不是换更大的模型树莓派也换不起而是改变使用方法提供上下文把外部资料贴到 prompt 里让模型基于给定的内容做总结而不是让它凭记忆输出。降低温度温度设置接近 0输出稳定性会好很多。用结构化 prompt强制模型按“原文依据 结论”的格式输出方便我事后校验。对关键数字和事实不轻信脚本里做规则校验比如去重、比对时间戳、检查文件是否存在。真实场景里我让模型写日报摘要、整理周报、分类邮件这种低风险任务没问题。但如果是让它直接生成一个可执行命令去操作服务器我会在脚本层加一层白名单校验只允许执行预先定义好的几条命令。这种“AI 给建议代码做拦截”的思路才是把小模型用在生产任务里的正确姿势。5.4 无桌面环境下调试的几条实用命令因为是纯命令行环境调试手段有限这几条命令我几乎每天都在用# 实时看 CPU 和内存 htop # 看 Ollama 日志 journalctl -u ollama.service -f # 看 Docker 容器状态 docker logs -f open-webui # 特定时间窗口的系统日志 journalctl --since 10 minutes ago如果 API 请求特别慢先在另一台电脑上 curl 一下看是网络问题还是模型推理问题time curl http://树莓派IP:11434/api/generate -d {model:qwen2.5:3b,prompt:hi,stream:false}time命令会输出总耗时如果模型本身就耗时 10 秒那就是硬件瓶颈脚本层面再怎么优化也没用。6. 写在最后的实际操作体会两天折腾下来我觉得“树莓派 4B 变成 24h 在线的 AI 牛马”这个目标完全可行但需要正视硬件的边界。我现在的使用场景是早上自动汇总 RSS 信息源白天监听一个共享文件夹有新文件就调用模型做内容抽取和标签分类晚上把一天处理的条目整理成清单发到我手机。它确实像一个任劳任怨的牛马每天在旁边默默地干活而且电费几乎可以忽略不计。最后再分享一个小技巧如果你想让树莓派上的 AI 服务更像一个“帮手”而不是“聊天框”可以在 Python 脚本里把每个任务的输入输出都留痕。比如我给每个任务分配一个 ID把 prompt、原始文件、生成结果、耗时全部记录在结构化的 log 里。这样即使模型某天输出质量变差也能快速定位是哪一步出了问题而不是对着黑盒子瞎猜。树莓派可以慢但不能乱稳定可控才是长期在线的关键。如果你也准备动手我的建议是先从一个小任务开始比如让它每天整理一个文件夹里的文件摘要别一上来就想着搭全套智能家居、语音助手、自动化工作流。把第一步跑稳了后续的扩展自然水到渠成。这块小板子的上限不高但作为 24 小时在线的 AI 牛马它已经远远超出了我当初对它的期待。