教程
Raspberry Pi 5 跑本地 Agent：LiteRT + Gemma 实战
Google 在 8 月 11 日展示了一套很有实用价值的 Edge AI 路线：用 LiteRT 在 Raspberry Pi 5 上运行轻量 Gemma 模型，把语音、视觉、Embedding 和小型 Agent 推理全部留在本地。官方给出的 Gemma 4 E2B 数据约为 99 tokens/s 的 prefill、9 tokens/s 的 decode、约 1432 MB 峰值内存；在 Reachy Mini 语音演示中，端到端生成约 27.3 characters/s，接近每分钟 300 个英文单词。更重要的是，LiteRT 不只是跑一个 LLM：它可以让 CPU 负责 Gemma 与语音识别，GPU 持续运行 YOLO 等视觉模型，组成一个无需云 API 的本地多模态 Agent。本文从硬件、模型选择、安装命令、CPU/GPU 分工和隐私边界几个方面，给出一套可复现的 Raspberry Pi 5 Edge Agent 架构。
# Raspberry Pi 5 跑本地 Agent：LiteRT + Gemma 实战
## 文章摘要
Google 在 8 月 11 日展示了一套很有实用价值的 Edge AI 路线：用 LiteRT 在 Raspberry Pi 5 上运行轻量 Gemma 模型，把语音、视觉、Embedding 和小型 Agent 推理全部留在本地。官方给出的 Gemma 4 E2B 数据约为 99 tokens/s 的 prefill、9 tokens/s 的 decode、约 1432 MB 峰值内存；在 Reachy Mini 语音演示中，端到端生成约 27.3 characters/s，接近每分钟 300 个英文单词。更重要的是，LiteRT 不只是跑一个 LLM：它可以让 CPU 负责 Gemma 与语音识别，GPU 持续运行 YOLO 等视觉模型，组成一个无需云 API 的本地多模态 Agent。本文从硬件、模型选择、安装命令、CPU/GPU 分工和隐私边界几个方面，给出一套可复现的 Raspberry Pi 5 Edge Agent 架构。
---
“本地大模型”以前很容易让人联想到：
```text
高端 GPU
32GB / 64GB 内存
大型台式机
```
但很多真正需要 Edge AI 的场景并不追求 70B 模型。
它们更关心：
- 断网还能不能工作；
- 延迟能不能稳定；
- 摄像头数据是否必须上传云端；
- 功耗能不能压住；
- 硬件成本能不能批量部署。
例如：
- 智能摄像头；
- 机器人；
- 车间终端；
- 门店助手；
- 离线翻译器；
- 边缘网关。
这时 Raspberry Pi 5 + LiteRT + Gemma 的意义就出来了。
## 先看 Raspberry Pi 5 到底能跑到什么程度
Google 给出的官方数据里，Gemma 4 E2B 通过 LiteRT-LM 在 Raspberry Pi 5 上达到大约：
```text
Prefill: 99 tokens/s
Decode: 9 tokens/s
Peak memory: 1432 MB
```
9 tokens/s 不是云端 Ultrafast 级别。
但对一个完全本地、没有独立大显卡、功耗很低的设备来说，它已经足以支撑很多交互式任务。
Google 在 Reachy Mini 语音 Demo 中换算出的端到端输出约为：
```text
27.3 characters/s
≈ 300 words/minute
```
普通英语口语大约是 150 words/minute 左右。
也就是说，模型文本生成本身已经不一定是本地语音 Agent 的主要瓶颈。
## 模型怎么选：不是越大越好
Google 当前给 Raspberry Pi / Edge 场景列出的 Gemma 家族包括：
### Gemma 3 270M
适合：
- 分类；
- 情感分析；
- 实体抽取；
- 微调后的单任务模型。
### EmbeddingGemma 300M
适合：
- 本地 RAG；
- 语义搜索；
- 分类；
- 向量检索。
### Gemma 3 1B
适合：
- 轻量文本生成；
- 摘要；
- 多语言文本任务。
### Gemma 4 E2B
适合：
- 内存敏感设备；
- 连续监听；
- 语音/视觉边缘任务；
- 低延迟 Agent。
### Gemma 4 E4B
推理更强，但资源占用也更高。
所以边缘设备的选型逻辑应该是：
> 先用最小模型满足任务，再考虑扩大模型。
而不是先问：
> Pi 5 能不能硬塞最大的 Gemma？
## LiteRT 在这里承担什么角色？
LiteRT 是 Google 面向 On-device AI 的推理 Runtime。
它做的并不只是：
> load model → generate text。
完整能力包括：
```text
convert
quantize
benchmark
inference
CPU / GPU backend
```
这对 Edge 项目非常重要。
因为部署到 1000 台设备以后，你最怕的不是 Demo 跑不起来。
而是：
- 模型格式混乱；
- 每台设备性能不同；
- 内存峰值失控；
- 更新不可重复；
- 依赖太重。
统一 Runtime 会直接降低运维难度。
## 安装 LiteRT CLI
Google 当前给出的入门方式非常直接：
```bash
python -m venv .venv
source .venv/bin/activate
pip install litert-cli
```
准备 Hugging Face Token：
```bash
export HUGGING_FACE_HUB_TOKEN=
```
然后可以直接运行 LiteRT 社区仓库中的 Gemma 模型。
概念命令如下：
```bash
litert lm run \
--from-huggingface-repo=litert-community/gemma-4-E2B-it-litert-lm \
gemma-4-E2B-it.litertlm \
--prompt="Summarize the latest sensor alert in 3 bullets."
```
对于多模态输入，还可以传 attachment。
## 不要一上来就做“全能 Agent”
边缘设备更适合 Narrow Agent。
例如工厂设备诊断：
```text
温度传感器
振动数据
故障码
↓
本地规则 + Embedding 检索
↓
Gemma E2B
↓
输出：
- 可能原因
- 检查步骤
- 是否需要停机
```
这比让 Pi 5：
> “像 ChatGPT 一样什么都回答”
更有商业价值。
## CPU 和 GPU 应该怎么分工？
Pi 5 的一个有趣点是：
CPU 的通用计算能力很强，而 GPU 更适合持续并行的视觉 / 音频任务。
Google 的 Reachy Mini Pipeline 采用类似结构：
```text
Camera
↓
YOLO Object Detection
↓
GPU 持续运行
Microphone
↓
Moonshine ASR
↓
CPU
Transcript + Visual Metadata
↓
Gemma 4 E2B
↓
CPU
Response
↓
TTS
↓
CPU
```
关键思想是：
> 不要让所有模型抢同一个计算资源。
## 为什么视觉任务放 GPU 更合理？
摄像头可能 10～30 FPS 连续输入。
如果每帧 Object Detection 都抢 CPU，Gemma 的推理延迟会出现明显抖动。
更合理的是：
```text
GPU
→ 持续视觉感知
CPU
→ 语言推理 / ASR / 编排
```
Agent 最终只接收最新视觉结构化结果：
```json
{
"objects": [
{"label": "person", "position": "left"},
{"label": "box", "position": "center"}
]
}
```
没必要把每一帧都交给 LLM。
## 本地 Agent 最重要的优势：数据不离开设备
很多 Edge AI 场景的数据非常敏感。
例如：
- 车间摄像头；
- 家庭音频；
- 医疗设备；
- 门店客流；
- 工业数据。
云端方案通常是：
```text
Sensor
↓
Internet
↓
Cloud Model
↓
Result
```
本地方案：
```text
Sensor
↓
Pi 5
↓
Local Model
↓
Result
```
网络甚至可以默认关闭。
这直接减少：
- 隐私暴露；
- 云 API 成本；
- 网络不可用风险。
## 但“离线”不等于“安全”
本地 Agent 仍然要防：
- 模型文件被替换；
- SD 卡被读取；
- 本地 API 无认证；
- Prompt Injection；
- Agent 误操作 GPIO / 机械设备。
因此需要：
```text
Model Hash
Signed Update
Local Auth
Tool Allowlist
Physical Safety Limit
```
如果 Agent 可以控制真实硬件，软件权限必须比普通聊天机器人严格得多。
## 给本地 Agent 加 RAG：EmbeddingGemma 很合适
假设设备维护手册有 500 页。
不要把全部文档塞进每次 Prompt。
可以：
```text
Manual
↓
Chunk
↓
EmbeddingGemma 300M
↓
Local Vector Store
```
用户问：
> “E37 报警是什么意思？”
设备本地：
```text
Embed Query
↓
Search Top-K
↓
Gemma E2B 结合检索结果回答
```
全流程不需要云端。
## Agent Tool 设计应该非常克制
比如机器人可以有：
```text
look_left
look_right
move_head
speak
read_sensor
```
不要直接给：
```text
shell_exec
```
如果确实需要系统操作，应再加一层受控 Tool API。
例如：
```text
LLM
↓
set_led(color="red")
↓
Tool Validation
↓
GPIO
```
不要：
```text
LLM
↓
生成任意 Python
↓
直接访问 GPIO
```
## 性能测试不要只看 Tokens/s
Edge Agent 至少看：
```text
Cold Start
Prefill
Decode
Peak RAM
CPU Usage
Temperature
Power
First Audio Latency
End-to-End Task Time
```
Pi 5 长时间高负载还要看：
> Thermal Throttling。
如果 Demo 前 1 分钟很快、跑 30 分钟后降频，生产体验仍然会出问题。
## 推荐的最小实战项目：离线语音设备助手
可以做：
```text
Microphone
↓
Moonshine / Local ASR
↓
Intent
↓
EmbeddingGemma 检索本地手册
↓
Gemma 4 E2B
↓
回答 + Tool Call
↓
Local TTS
```
Tool 只开放：
```text
read_sensor
show_status
set_indicator
```
不开放系统 Shell。
这已经是一个完整的、可离线运行的 Edge Agent。
## 什么时候 Pi 5 不够？
如果你的任务需要：
- 大模型长推理；
- 高频高清多摄像头；
- 高质量实时语音全双工；
- 大上下文；
- 复杂 Vision-Language Model；
Pi 5 很快会到上限。
这时可以考虑：
- Hailo AI HAT；
- NVIDIA Jetson；
- NPU 设备；
- Edge + Cloud Hybrid。
Google 也已经预告 LiteRT 将进一步支持 Hailo 加速器。
## 最终判断
Raspberry Pi 5 上 9 tokens/s 的 Gemma 并不会替代云端 Frontier Model。
但这根本不是 Edge AI 的目标。
Edge AI 真正要解决的是：
```text
低延迟
+ 离线
+ 隐私
+ 低成本
+ 可批量部署
```
当 Gemma 4 E2B 能在约 1.4GB 峰值内存内运行，而 LiteRT 又能把视觉、语音、Embedding 和语言模型编排在同一块小板子上时，很多过去必须连云的 Agent 场景开始具备完全本地化的可能。
对于机器人、工厂终端、智能摄像头和离线助手，这比“再跑一个聊天 Demo”重要得多。
想继续了解 Edge AI、本地模型、Gemma 和 Agent 实战，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续整理能真正跑起来的硬件、模型和工程组合。