树莓派5 8G跑Ollama：打造低功耗私有大模型推理节点

不是标题党，我是真的在树莓派5 8G版上把 Ollama + LLM 跑起来了，而且不是只跑了个hello world，是当生产工具用了一段时间。这块小主机加一张TF卡，没有GPU、没有独显，完全靠CPU推理，最后跑出接近每秒十来个token的生成速度，能在局域网里给手机、电脑、Home Assistant提供大模型API。这个结果挺反直觉的，毕竟大家印象里“大模型”三个字总跟算力绑定，但实测下来，只要选对模型、做好路径和镜像配置，树莓派5 8G确实能成为一个低功耗的私有推理节点。

这篇就把我踩过的坑和完整复现路径写出来：从无屏幕烧录Ubuntu Server、SSH连接、装Ollama、解决模型下载慢、改模型存储路径，到实测不同模型的token/s、开放局域网API、再接一个Web UI，全流程覆盖。如果你手里正好也有树莓派5 8G，或者正打算入一块，看完可以直接照着做。先说清楚：这是一个以CPU推理为基础、以量化模型为载体的项目，目标是“够用”，不是“跑分”。

1. 树莓派5 8G版跑模型前，先纠正三个刻板印象

很多人在“树莓派跑LLM”这件事上，第一反应要么是不可能，要么是跑去跪求大佬继续超频。这两个方向都跑偏了。先把底层逻辑摆清楚，后面安装和调参才不会稀里糊涂。

1.1 8G内存到底能装下什么量级的模型

树莓派5 8G版的系统启动后，干净的系统大概吃掉1GB到1.5GB内存，剩下可用内存大约在6.5GB到7GB。这个数字直接决定了你能拉多大的模型。Ollama生态里的模型普遍是量化过的，不是原始FP16权重。参数量1B的模型量化后大约占1GB，3B大约2GB，7B大约4.7GB。所以你单纯问“8G内存能不能跑7B”，答案是能装下，但装得下不等于跑得动，更不等于体验好，因为除了模型本身，推理还需要额外的KV Cache和中间缓冲。上下文长度设得越长，KV Cache占的内存就越多。我实测默认4096上下文下跑7B，内存基本顶格，系统剩余不到500MB。结论很简单：8G版是树莓派5四个版本里唯一适合跑LLM的版本，它能托底7B，但舒适区是3B及以下。如果你手里是4G版，建议直接选1.5B以下模型，否则加载完模型系统就没内存了，卡到怀疑人生。

1.2 真正的瓶颈是内存带宽，不是CPU主频

这是整个项目最重要的认知。大模型在CPU上推理时，每个token的生成都要把模型所有参数读一遍，所以内存带宽决定了速度上限。树莓派5用LPDDR4X内存，双通道理论带宽大概在17GB/s左右。我经常看到有人在论坛里问“超频到3GHz是不是能变快”，方向错了。以3B模型举例，量化后权重2GB，如果目标是每秒生成10个token，意味着每秒要从内存里读20GB权重，早已超过17GB/s的带宽上限，CPU主频再高也只能干等内存。这也是为什么树莓派5跑0.5B模型能到30 token/s，跑7B只有个位数——不是偷懒，是带宽不够。理解了这一点，你就能理解为什么Ollama官方推荐树莓派环境用“更小模型+量化格式”，而不是强行上大模型。

1.3 和树莓派4、台式机的差距到底在哪

树莓派4B也是能跑Ollama的，但体验差很多。4B的内存是LPDDR4，带宽约12.8GB/s，CPU是四核Cortex-A72，主频和IPC都不如A76。同样跑qwen2.5:3b，树莓派4大概只有个位数token/s，而5代能跑到接近10。树莓派5提升最大的是CPU和内存带宽，再加上PCIe接口，可以直接挂NVMe SSD，模型加载速度完全不在一个量级。但如果你把它跟一台普通台式机比，差距依然巨大。桌面级CPU双通道DDR4带宽通常25GB/s起步，多核算力更是树莓派的好几倍。所以准确地说，树莓派5 8G跑LLM的定位是“低功耗、低噪音、常在线的小型推理节点”，不是台式机的替代品。把它想成家里的路由器那么个角色：不追求最强，但要一直在线，随叫随到。

2. 基础环境搭建：无屏幕装 Ubuntu 并锁好性能上限

要让树莓派5稳定跑LLM，系统选择很关键。我用的是Ubuntu Server 24.04 LTS arm64，不是树莓派官方桌面系统。桌面版启动后内存占用多出1GB以上，这1GB在别的场景不算什么，但跑大模型时就是能不能加载7B模型的分界线。Ubuntu Server无桌面，系统干净，apt源里软件也全，适合做这种“无人值守服务”。

2.1 Raspberry Pi Imager 无屏幕烧录 Ubuntu Server

就算你没有显示器、键盘，也能完成安装。用Raspberry Pi Imager：设备选树莓派5，操作系统选“Other general-purpose OS”下的Ubuntu Server 24.04 LTS（64-bit）。点右下角齿轮进入高级设置，提前开启SSH，并写WiFi账号密码，也可以顺便配一个静态IP，省得每次找地址。烧录完成后，TF卡塞进树莓派5，通电等一两分钟，然后从路由器后台或者局域网扫描工具里找到设备的IP，直接SSH登录。

这里有两个细节非常关键。第一，Ubuntu Server必须选64位版本，Ollama只提供aarch64的二进制，32位系统装不上。第二，升级内核前先跑一遍apt update和apt upgrade，树莓派5在较老的内核上可能有性能和稳定性问题，我一开始没升级，跑模型时偶发卡顿，升级后明显改善。如果你用的是树莓派官方系统，也建议切换成64位模式，别再用32位镜像。

2.2 开机后第一件事：检查电源和温度

树莓派5对电源要求比前代严格不少，官方推荐5V/5A，也就是25W。很多老款手机充电器电压不够或者电流不足，会导致一种非常隐蔽的故障：系统看起来正常，但CPU被限制在低频率，跑模型速度直接腰斩。SSH登录后先执行：

vcgencmd get_throttled

返回0x0表示电源、温度都正常。如果输出不是0x0，比如0x50000，说明出现过欠压现象，需要换电源和更好的USB-C线。接下来看温度：

vcgencmd measure_temp

跑LLM时CPU是持续满载的，温度一旦到85度，树莓派会自动降频。我刚开始只配了一个普通散热片，结果跑3B模型时经常掉速，后来换成官方主动散热器，温度稳定在60度出头，速度才算稳住。所以我强烈建议，跑LLM这件事，散热不是可选项，而是必选项。

2.3 把模型库存放位置挪到外接 SSD

TF卡有两个问题：读写速度慢，寿命也撑不住频繁读写模型文件。系统可以先放TF卡，但模型库建议放到外接SSD上。树莓派5支持PCIe，用官方M.2 HAT可以插NVMe SSD，也可以更省事地用USB 3.0接口挂一块移动固态。

把SSD格式化并挂载，我是这样做的：

sudo mkfs.ext4 /dev/sda1 sudo mkdir -p /mnt/ssd sudo mount /dev/sda1 /mnt/ssd echo '/dev/sda1 /mnt/ssd ext4 defaults,nofail 0 0' | sudo tee -a /etc/fstab

第二组命令把挂载写进fstab，noFail参数能避免SSD没插时系统起不来。这一步的收益在拉取大模型时非常明显：一个2GB的模型从SSD加载进内存只要十几秒，放TF卡上就要将近一分钟。后面配置Ollama路径时会用到这个挂载点。

3. Ollama 安装与模型下载加速：最容易卡住的环节

Ollama是目前我在ARM设备上看到对开发者最友好的LLM运行时。它支持Linux aarch64架构，安装和使用都非常直接。这个项目最大的门槛反而不在“跑模型”，而在“拉模型”，因为官方仓库在直连时经常没有速度。这一章把安装、手动部署、路径迁移和镜像加速一次讲完。

3.1 官方一键脚本安装过程

官方提供了一条命令安装：

curl -fsSL https://ollama.com/install.sh | sh

脚本会检测ARM架构，下载对应安装包，解压到合适位置，并注册systemd服务自动启动。装完后执行：

ollama --version

看到版本号比如ollama version 0.5.6就算成功。我建议装完顺手跑一下systemctl status ollama，确认服务是active状态。如果这一步没问题，基本就可以开始拉模型了。不需要额外安装Python、CUDA之类的依赖，这算Ollama最方便的地方，对新手极其友好。

3.2 下载太慢时的手动安装方案

上面那行命令看着简单，实际在国内网络环境下，脚本会卡在“Downloading ollama…”这一步，下载半天没动静。我试了两次都失败，最后改用手动安装：在能访问GitHub或已做好同步的镜像站点，下载名为ollama-linux-arm64.tgz的安装包，传到树莓派后解压部署。

sudo tar -C /usr/local -xzf ollama-linux-arm64.tgz sudo useradd -r -s /bin/false -m -d /usr/share/ollama ollama sudo install -o ollama -g ollama -m 755 /usr/local/bin/ollama /usr/local/bin/ollama

手动安装的二进制本身是完整的，但systemd服务不会自动注册，需要手动创建一个/etc/systemd/system/ollama.service文件，里面写ExecStart、User、Group、Restart等基础配置。更省事的办法是等网络恢复正常后，再跑一次官方脚本，它会检测到已安装的二进制，自动补齐服务配置。手动安装的价值在于：它让你理解Ollama本质上就是一个静态二进制加一个服务管理脚本，遇到任何安装问题，都能从这条路径绕过。

3.3 修改 OLLAMA_MODELS：模型路径迁移

默认情况下，模型文件会存到~/.ollama/models，或者/root/.ollama/models。这个路径有两个问题：一是放在TF卡上，读写慢；二是TF卡空间小，7B模型放一两个就满了。用systemd方式管理Ollama时，正确改路径的方法是：

sudo systemctl edit ollama

在打开的override文件里写：

[Service] Environment="OLLAMA_MODELS=/mnt/ssd/ollama/models"

保存退出后执行：

sudo systemctl daemon-reload sudo systemctl restart ollama

然后ollama list确认模型目录已经切换。迁移已有模型很简单，直接把旧目录里的文件移动到新路径下即可，Ollama会按manifests和blobs的结构自动识别。这一步做完，模型库读写速度立刻提升，再用ollama pull拉大模型时，耐心会好很多。

3.4 模型仓库加速：OLLAMA_BASE_URL 的配置

Ollama拉模型默认去的是官方model registry，网络条件不理想时，经常卡在“pulling manifest”或者“pulling xx%”上，速度以每秒几十KB计算。解决思路是把模型仓库指向可访问的镜像地址。Ollama支持通过环境变量OLLAMA_BASE_URL覆盖registry地址：

sudo systemctl edit ollama

override文件里加：

[Service] Environment="OLLAMA_BASE_URL=https://你的镜像地址"

镜像地址可以是公共镜像站，也可以是自己在局域网内用Nginx给registry搭的简单反代。配置完成后重启服务，再执行：

ollama pull qwen2.5:3b

速度会有质变，几分钟内能把3B模型拉完。这个环境变量只影响“从远端拉模型”的环节，本地模型加载、API调用都不受影响，所以可以放心配置。如果某个镜像不稳定，换一个就行，不需要重新覆盖其他配置。

4. 8G 内存下的模型选型清单：从 0.5B 到 7B 的取舍

模型选型是这个项目里直接决定体验的一步。选大了，内存爆掉或者速度拉胯；选小了，回答质量惨不忍睹。我按实际场景和内存余量，把候选模型整理成一份可以直接抄作业的清单。

4.1 为什么量化格式比参数量更重要

大模型原始训练权重一般是FP16，也就是每个参数占2字节。1B模型FP16就要2GB，3B要6GB，7B要14GB，树莓派8G内存根本塞不下。Ollama能跑起来，靠的是量化，把权重压缩成INT4、INT8等低精度格式，牺牲少量精度换取可运行性。比如Qwen2.5 7B的Q4_K_M量化版只有4.7GB左右，精度损失在一般问答场景里感知不明显。

所以挑选模型时，不要只看参数量，更要看模型的量化标签。Ollama的默认标签通常是官方推荐的量化格式，比如qwen2.5:3b对应的就是适合CPU推理的版本。如果你在图里看到某个模型标着fp16，别碰，8G内存基本跑不动。选模型前多用ollama show 模型名查看实际文件大小和参数量，别凭名字猜。

4.2 适合树莓派5 8G的模型推荐表

这是我实测过后整理出来的一份参考表格：

如果只让我选一个作为日常主力，我会选qwen2.5:3b。它在中文理解和指令跟随上的表现，比同量级的Llama 3.2更稳，生成速度也在可接受范围内。如果你主要跑英文、且对速度要求更高，llama3.2:3b和gemma2:2b都值得一试。

4.3 7B模型“能跑但不舒服”的真相

7B模型在树莓派5 8G版上是能加载的，但交互体验很难受。我用deepseek-r1:7b试过一次，生成一段100字的中文回答需要等待将近一分钟，相当于三秒蹦一个字。这个速度放在批量处理、定时任务里没问题，但要是当聊天机器人，用户提问后等60秒才看到回答，完全不现实。

问题出在内存带宽和预填充速度。7B模型每次生成一个token都要过一遍4.7GB权重，再加上Prompt预填充阶段会占用大量内存和计算时间，输入越长，首字延迟越大。所以我的建议是：8G版树莓派日常主力模型控制在1.5B到3B之间，7B留作夜间批处理任务或者“给朋友演示推理过程”的场景。想追求流畅度，就要舍得放弃尺寸。

5. Ollama 实际推理测评：速度、延迟与局域网调用

前面讲的都是准备，这一章进入硬核实测。我以qwen2.5:3b为主力模型，跑了完整一轮基准测试，也测了其他几个模型做对比，最后把Ollama开放成局域网服务，实现了手机平板直接调用。

5.1 用 qwen2.5:3b 做一次完整基准测试

测试环境：树莓派5 8G版、Ubuntu Server 24.04、Ollama 0.5.6、模型库在外接NVMe SSD上。在SSH终端里执行：

ollama run qwen2.5:3b

进入对话后输入“用一句话介绍你自己”。从按下回车到第一个字符出现，大约1.5到2秒，这个延迟叫首字延迟。之后生成速度稳定在9到11 token/s，也就是一秒大约蹦十个汉字。对聊天场景来说这个速度属于“能用”：“它在思考，但你等得起”。

再试一个长Prompt：要求写一篇200字的活动通知。首字延迟会从1.5秒拉到3秒以上，因为CPU需要先把整个输入预填充一遍，之后生成阶段速度没有明显变化，还是每秒十个token左右。这说明在树莓派环境下，首字延迟和生成速度是两码事，用户感知最强的其实是首字延迟，长Prompt场景下尤其明显。

5.2 四个模型的横向对比结果

我把四个代表性模型都跑了一遍，数据如下：

0.5B和1.5B的体验完全不同，前者速度快但回答经常答非所问，后者已经能流畅处理日常对话，中文效果也能接受。3B的速度开始明显放慢，但模型能力有了质变，适合做摘要、改写、意图提取这种需要一点理解能力的任务。7B的token/s掉到个位数，内存占用却顶到6.8GB，说明它已经把8G内存榨干了。

5.3 把 Ollama 变成局域网 AI 网关

Ollama默认只监听本机地址，想让它被局域网内其他设备调用，需要改一个环境变量：

sudo systemctl edit ollama

override文件里加：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

重启后，任何同一局域网里的设备都可以通过http://树莓派IP:11434访问Ollama的API。手机、电脑上可以装LM Studio、Chatbox之类支持自定义API地址的客户端，直接把地址指向树莓派。我实测用curl请求：

curl http://192.168.1.100:11434/api/generate -d '{"model":"qwen2.5:3b","prompt":"你好","stream":false}'

返回的JSON里带上了生成的完整内容。这个场景对家里有智能家居或者NAS的人来说非常实用：树莓派7x24小时低功耗在线，随时可以被局域网里的各种设备调用，本质上就是一个私有AI网关。

5.4 挂一个 Web UI，脱离终端聊天

在终端里聊模型始终不够方便，于是我给树莓派挂了一个Open WebUI，用浏览器随时访问。最省事的方式是用Docker：

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui --restart always \ ghcr.io/open-webui/open-webui:main

然后在Web UI的后台设置里，把Ollama API地址填成http://树莓派IP:11434。这样多设备访问统一走Web页面，聊天历史也有独立存储，比在终端里翻上下文舒服太多。如果不想装Docker，Open WebUI也提供Python的pip安装方式，只是依赖会多点，树莓派5完全能带得动。

6. 运行期调优：让 token/s 再往上走一截

一个项目做到“能跑”只是第一步，真正好用还要压榨性能。我前后调了好几天，发现影响体验的主要是Ollama的缓存策略、上下文长度、并发限制和系统散热。

6.1 调整 OLLAMA_* 环境变量：内存与并发的取舍

Ollama有几个环境变量直接影响内存占用和并发行为：

• OLLAMA_CONTEXT_LENGTH：上下文窗口长度，默认4096。减到2048可以显著降低KV Cache内存占用，速度也有10%到20%的提升。要看你实际任务所需，如果只是短问答，2048完全足够。

• OLLAMA_NUM_PARALLEL：并行请求数，默认会根据内存自动调。树莓派这种内存紧俏的场景，强制设成1更稳，否则多个请求同时进来，内存会瞬间爆掉，甚至触发系统swap，那体验就直接崩了。

• OLLAMA_MAX_LOADED_MODELS：最大同时加载模型数，设为1。如果同时加载多个模型，内存会不够用，反过来还要反复卸载加载，等于自己给自己制造卡顿。

配置方式跟前面一样，在systemd override文件里写Environments，然后重启。我实测砍掉并行和常驻多模型的设置后，3B模型生成速度大概能再快10%，更重要的是内存剩余从紧绷变成“有冗余”，系统稳定性好了很多。

6.2 系统层优化：温度、频率、后台服务

树莓派5默认的CPU调频策略是ondemand，负载上来才拉高频率，响应上会有延迟。可以强制切到performance模式，让四核A76始终运行在高频，代价是功耗和发热都会上升。

临时切换可以执行：

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

想永久生效，可以写一个systemd service在启动时执行这条命令。另外，Ubuntu Server上默认的snapd、unattended-upgrades这类后台任务，在内存紧张时也建议关掉：

sudo systemctl disable --now snapd.service sudo systemctl disable --now unattended-upgrades.service

最后再检查一下散热。连续跑7B模型时，如果散热不好，CPU温度会顶到85度，然后降频，速度掉得你心疼。我装了官方风扇，还额外在fstab里把SSD设为nofail，确保硬盘拔掉也不影响开机。实时看温度可以用：

watch -n 2 vcgencmd measure_temp

温度超过70度就得警惕，超过80度基本已经在降频了。用散热风扇或者主动式散热马甲，把这个温度压下来，token/s会明显回升。

6.3 常见报错速查表

最后整理一张报错速查表，都是我在这个项目里实际踩过或者高频看到的问题：

报错不可怕，关键是要有一套定位逻辑：先看服务状态，再验证模型名，接着看磁盘空间和内存，最后排查网络。按这个顺序走，绝大多数问题都能定位到明确的环节。

最后说说我自己的感受。树莓派5 8G版 + Ollama + LLM这个组合，既不是“跑大模型”的玩具，也不是能替代生产服务器的神器，而是一个非常适合“常在线、低功耗、私有部署”的小型推理节点。我用它主要做了三件事：给Home Assistant提供意图识别和文案生成接口，在宿舍局域网里搭了Open WebUI做家庭问答服务，还有深夜离线跑一些文本批量处理任务。每次看到这个不到几百块的小板子安安静静吐出流畅的中文，还是很感慨的。如果你手里也有一块树莓派5 8G，别一直放在角落吃灰，从装Ollama开始，你会打开很多新的玩法。