Raspberry Pi 5 上跑本地 Agent 已经不是玩具：Gemma 4 E2B 9 token/s、峰值内存 1432MB，真正有意思的是 CPU/GPU 分工

Google 最近公开了一套 Raspberry Pi 5 上的 Edge AI 实现。

如果只是说：

大模型可以在树莓派上跑

已经不算新鲜。

这次真正值得看的是它给出了比较完整的运行数据和任务拆分。

Gemma 4 E2B 在 Raspberry Pi 5 上通过 LiteRT-LM 运行时，Google 给出的 CPU 性能是：

Prefill：
99 tokens/s

Decode：
9 tokens/s

Peak Memory：
1432 MB

在 Reachy Mini 语音 Demo 里，端到端文本生成速度约：

27.3 characters/s
≈ 300 words/min

Google 给的对比是，正常人类说话大约：

150 wpm

也就是说，它已经进入一个非常实际的范围：

能不能做本地实时 Agent

不再只是“能不能把模型加载起来”。

9 token/s 到底够不够

如果你习惯云端旗舰模型：

9 token/s

看起来不快。

但要看任务。

一个本地设备 Agent 的输出往往不是长篇文章。

例如：

检测到前方有人
向左转 15 度

或者：

门口检测到包裹
已保存事件

这类输出只有十几个 Token。

9 token/s 完全可以接受。

真正决定体验的是：

Prefill
ASR
视觉
Tool Latency
TTS

整体流水线。

Edge Agent 和云 Agent 的设计目标完全不同

云 Agent 通常优化：

能力上限
复杂推理
大上下文
工具数量

Edge Agent 更关心：

低延迟
隐私
断网可用
功耗
内存
持续运行

所以不要拿同一套 Benchmark 评价。

一个 2B 模型在云端和旗舰模型比 Coding 分数没有意义。

如果它能在：

1.4GB 左右峰值内存

下持续做本地语音、视觉和动作编排，它解决的是另一个问题。

Reachy Mini 最有意思的是并没有“所有东西都丢给 CPU”

Google 的 Pipeline 是：

Camera
↓
YOLO Object Detection
GPU

Speech
↓
Moonshine ASR
CPU

Reasoning & Action
↓
Gemma 4 E2B
CPU

Text-to-Speech
↓
CPU

也就是：

视觉持续任务放 GPU
LLM 和总体编排放 CPU

这是一种很实用的异构设计。

Raspberry Pi 5 的 CPU 和 GPU 并不是“谁更强就全给谁”。

它们适合不同负载。

为什么视觉放 GPU 很合理

摄像头是持续流。

例如：

30 FPS

如果每一帧都占 CPU 做 Object Detection，会持续争夺：

LLM
ASR
系统调度

的计算资源。

把视觉模型放到 VideoCore VII GPU，可以让 CPU 保留给：

语言模型和 Agent Runtime

这比追求单个模型最高吞吐更重要。

Edge Agent 最适合 Event-driven，而不是“每帧都问大模型”

差的架构：

每一帧
→ LLM
→ 判断要不要行动

一定浪费。

更合理：

Vision Model
↓
检测事件
↓
Event Filter
↓
必要时唤醒 LLM

例如：

person_entered
package_detected
unknown_object
voice_command

只有高层事件进入 Gemma。

一个本地 Agent Pipeline

Sensors
↓
Small Specialized Models
↓
Event Bus
↓
Policy
↓
LLM
↓
Local Tool
↓
Action

专用模型负责感知。

LLM 负责：

解释
计划
选择动作

这比让 LLM 做每一步感知更高效。

我会把本地 Agent 拆成三个优先级

Tier 0：不需要 LLM

例如：

温度超过 80℃
立即停机

直接规则。

不要问模型。

Tier 1：小模型

例如：

分类
实体抽取
唤醒词
视觉检测

用轻模型。

Tier 2：LLM

只有：

多条件判断
自然语言理解
复杂动作选择

再调用 Gemma。

这叫：

Compute Escalation

和云端模型路由其实是同一个思想。

本地 RAG 也开始变得实际

Google 同时列出了：

EmbeddingGemma 300M

用于：

RAG
Semantic Search
Classification

这意味着一个完全离线设备可以做：

本地文档
→ Embedding
→ Local Vector Search
→ Gemma 回答

不需要把数据发到云端。

在：

工厂
医疗设备
门店
现场维修

这种场景很有价值。

但本地 RAG 的存储设计比云端更重要

设备磁盘和内存有限。

不要把几十万 Chunk 全塞进去。

更适合：

业务需要的 Local Working Set

例如维修终端只同步：

当前设备型号
最近故障
维修手册
当前工单

而不是整个企业知识库。

这也是 Edge Agent 很重要的设计原则：

Context Locality

Edge 的隐私优势是真实的，但别写成“绝对安全”

Google 强调：

fully offline
zero cloud dependencies
data privacy

在架构层面确实有巨大优势：

摄像头
语音
本地文件

可以不离开设备。

但本地并不等于自动安全。

还要防：

设备被偷
磁盘读取
恶意 USB
固件
模型文件篡改
本地日志
物理调试接口

所以需要：

磁盘加密
Secure Boot
Signed Model
最小权限
日志清理

离线 Agent 最大的问题其实是“怎么更新”

云端模型升级：

服务端换版本

设备端：

10000 台设备
分布在不同地方

升级就是另一回事。

必须管理：

Model Version
Runtime Version
Policy Version
Skill Version

所以每台设备要有：

Edge Manifest

一个 Edge Manifest

device_id: store-0218
runtime: litert-2.x
model:
  name: gemma-4-e2b
  version: v3
policy: store-assistant-v8
skills:
  - inventory-read-v4
  - device-control-v2

出现事故时必须知道：

哪些设备跑哪个版本

Canary 在 Edge 场景更重要

不要：

10000 台设备同时升级

可以：

10 台实验设备
↓
100 台
↓
1000 台
↓
全量

观察：

Crash
Memory
Temperature
Latency
Battery/Power
Task Success

模型升级也属于 Firmware-like Release。

还有一个容易忽略的问题：热

Raspberry Pi 持续跑：

ASR
视觉
LLM
TTS

不只是算力。

还有：

温度
功耗
Throttling

一个 Demo 跑 10 分钟没问题，不代表全天运行稳定。

所以 Edge Benchmark 至少应该持续：

2—8 小时

观察：

P95 Latency
Peak Memory
Thermal Throttling
Crash

而不是只记录第一次输出速度。

Agent Tool 也应该优先 Local-first

例如机器人动作：

turn_head
move
play_audio

本地 Tool。

不要为了调用一个动作还绕：

Device
→ Cloud
→ API
→ Device

否则：

断网

就完全失效。

Cloud 更适合：

模型更新
集中分析
非实时数据同步
复杂任务升级

可以做 Edge → Cloud Escalation

本地 Gemma 先处理。

遇到：

不确定
复杂
需要大量知识

才升级云模型。

Local Agent
↓
confidence < threshold
↓
Cloud Frontier Model

这样兼顾：

隐私
成本
能力

但升级之前要做数据过滤

不要把本地完整摄像头流直接上传。

只上传：

必要文本
事件摘要
经过裁剪的图片

这叫：

Privacy-preserving escalation

LiteRT CLI 也开始变得适合 Agent 化

Google 现在把：

convert
quantize
benchmark
inference

聚合到 LiteRT CLI。

甚至提供 Coding Agent 可以使用的 Skill。

这意味着以后 Edge ML 工程也可能被 Agent 自动化：

模型下载
→ 转换
→ 量化
→ Benchmark
→ 选配置

但最终部署仍然应该经过 Gate。

不要让 Agent 自动把一个没测过的量化模型直接发到所有设备。

一个 Edge Model Gate

edge-gate:
  max_peak_memory_mb: 1800
  minimum_decode_tps: 7
  max_crash_rate: 0
  max_temperature_c: 80
  task_success_min: 0.90

只满足：

能跑

远远不够。

我最看好 Edge Agent 的几个场景

不是手机聊天。

而是：

工厂设备助手
门店终端
机器人
现场巡检
离线翻译
隐私语音
智能摄像头
车载

这些场景本来就需要：

低延迟
本地数据
断网可用

云模型很难完全替代。

Gemma 4 E2B 在 Raspberry Pi 5 上 99 token/s Prefill、9 token/s Decode、1432MB 峰值内存这几个数字，让本地 Agent 终于开始有一个比较具体的工程锚点。

但我真正觉得值得学的是那套 Pipeline：

GPU 持续做视觉
CPU 做语言和编排
小模型处理高频感知
LLM 只处理需要推理的事件

Edge Agent 不是把云端 Agent 缩小以后塞进设备。

它需要重新设计：

哪些任务根本不需要 LLM
哪些应该小模型做
哪些值得升级大模型
哪些必须留在本地

把这四个问题想清楚，本地 Agent 才真正开始像产品，而不是树莓派上的一个模型 Demo。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/