谷歌把同声翻译塞进树莓派

谷歌用 51 亿参数做了一台离线翻译机

谷歌在 8 月 6 日展示了 Gemma Translator，一台不依赖网络、可以完成语音识别、文本翻译和语音播报的本地翻译设备。它由 Google Creative Lab 团队开发，核心硬件不是定制 AI 芯片，而是一块 Raspberry Pi 5 单板计算机；核心模型则是面向端侧设备的 Gemma 4 E2B。

Gemma Translator 是一套运行在边缘设备上的离线语音翻译参考设计。用户对着麦克风说话后，设备会在本地识别语音、生成目标语言译文，再通过扬声器播报结果；接上显示器时，屏幕还可以同时显示原文和译文。

这次发布最值得关注的地方不是谷歌又做了一台翻译机，而是它证明了完整的语音翻译链路已经可以压缩进树莓派级别的设备。过去所谓的 AI 翻译硬件，往往只是麦克风、屏幕和云端模型之间的入口，一旦网络不稳定，延迟和可用性就会迅速恶化；Gemma Translator 则把推理留在设备内部，网络从必需品变成了可选项。

不过，Gemma Translator 目前更接近开发者原型和参考设计，而不是一款已经公布价格、上市日期和量产规格的消费电子产品。谷歌此次展示的重点，是 Gemma 4 E2B、LiteRT-LM 与本地语音组件如何组合，而不是要直接挑战手机翻译应用或专业翻译机厂商。

Gemma 4 E2B 的关键不只是“小”

Gemma 4 E2B 是谷歌面向手机、浏览器、树莓派和其他资源受限设备推出的超轻量级开放权重生成式模型。按照谷歌公布的信息，它共有约 51 亿参数，但每次推理只激活约 23 亿参数，这也是名称中 E2B 所强调的有效激活规模。

“总参数”和“激活参数”之间的差异决定了这类模型的部署价值。可以把总参数理解为模型掌握的全部工具，而激活参数则是每次回答时真正拿出来使用的工具；设备需要容纳更完整的模型能力，但单次计算不必让全部参数同时工作，从而降低推理负担。

Gemma 4 E2B 并不是只会翻译的专用模型。根据谷歌发布的 Gemma 4 E2B 模型页面，Gemma 4 家族具备多模态能力，E2B、E4B 和 12B 版本支持音频输入，整个系列覆盖超过 140 种语言，并提供预训练版和指令微调版开放权重。

Gemma Translator 仍然选择了模块化语音链路，而不是让大模型包办所有环节。公开演示显示，设备将语音处理、翻译推理和音频输出拆开执行，其中 Gemma 4 E2B 主要负责语言理解与翻译，LiteRT-LM 负责端侧模型推理，Moonshine 相关本地组件参与语音处理。

这种拆分比端到端语音大模型更务实。一个模型直接完成“听懂—翻译—说出”在产品展示中很简洁，但在树莓派上可能面临更高的内存占用、更长的首包延迟和更难控制的输出；把语音识别、文本翻译、语音合成拆成流水线，则更容易逐项量化、替换和优化。

一块树莓派，跑的是完整翻译流水线

Raspberry Pi 5 是一款采用 Arm 架构处理器的单板计算机，常被用于教育、物联网、机器人和轻量边缘计算。它的意义不在于绝对性能强，而在于价格、功耗、体积和开发生态相对均衡，能代表大量没有独立高端 GPU 的真实部署环境。

Gemma Translator 的工作流程可以概括为四步：

1. 麦克风采集用户语音，并在本地完成音频预处理。
2. 本地语音组件把音频转换为源语言文本。
3. Gemma 4 E2B 通过 LiteRT-LM 生成目标语言译文。
4. 本地语音组件将译文转为音频，同时在屏幕上显示原文和译文。

LiteRT-LM 是谷歌面向边缘设备的大语言模型执行框架。它承担模型加载、内存管理和推理加速等工作，相当于 Gemma 4 E2B 与手机、电脑或树莓派硬件之间的运行层，而不是另一个翻译模型。

本地闭环带来的第一项收益是隐私。会议谈话、医疗沟通、工厂操作指令和个人旅行对话不必先上传服务器，原始语音和翻译文本可以留在设备内部，这比单纯承诺传输加密更直接。

本地闭环带来的第二项收益是可用性。地下空间、跨境列车、偏远地区、救援现场和网络受限的企业环境，恰好都是翻译需求强、云服务却最不可靠的场景；只要设备有电，离线模型就能继续工作。

本地闭环带来的第三项收益是成本可预测。云端语音识别、模型推理和语音合成通常会随调用量增长，而端侧方案的主要成本集中在硬件采购、模型适配和后续维护，持续高频使用时更容易控制长期支出。

端侧性能已经可用，但树莓派数据仍是空白

谷歌公布的 Gemma 4 E2B 测试说明，这个模型在旗舰手机和个人电脑上已经进入可交互区间。官方 LiteRT-LM 数据显示，Galaxy S26 Ultra 使用 CPU 时解码速度为每秒 47 token，首个 token 延迟为 1.8 秒；切换到 GPU 后，解码速度为每秒 52 token，首 token 延迟缩短至 0.3 秒。

不同设备上的官方测试结果如下：

| 测试设备 | 后端 | Prefill 速度 | Decode 速度 | 首 token 延迟 | 峰值 CPU 内存 | |---|---:|---:|---:|---:|---:| | Galaxy S26 Ultra | CPU | 557 token/s | 47 token/s | 1.8 秒 | 1733 MB | | Galaxy S26 Ultra | GPU | 3808 token/s | 52 token/s | 0.3 秒 | 676 MB | | iPhone 17 Pro | CPU | 532 token/s | 25 token/s | 1.9 秒 | 607 MB | | iPhone 17 Pro | GPU | 2878 token/s | 56 token/s | 0.3 秒 | 1450 MB | | Linux + RTX 4090 | CPU | 260 token/s | 35 token/s | 4 秒 | 1628 MB | | Linux + RTX 4090 | GPU | 11234 token/s | 143 token/s | 0.1 秒 | 913 MB | | MacBook Pro M4 | CPU | 901 token/s | 42 token/s | 1.1 秒 | 736 MB |

这些数字不能直接等同于 Gemma Translator 的端到端翻译延迟。用户真正感受到的等待时间还包括音频分段、语音识别、提示词预填充、译文生成和语音合成，而谷歌目前没有公布 Raspberry Pi 5 上从说完一句话到开始播报译文的完整耗时，也没有给出实时率、功耗和持续运行温度。

官方测试仍然揭示了一个重要趋势：端侧小模型的瓶颈正在从“能否运行”转向“如何把整条产品链路做顺”。每秒 25 至 56 token 的移动端解码速度足以覆盖短句翻译，真正影响体验的反而可能是语音切分是否自然、什么时候判定用户说完，以及扬声器能否及时开始播报。

Gemma 4 还引入了 Multi-Token Prediction，即多 token 预测机制。传统模型通常逐个预测下一个 token，而 MTP 会在一次计算中尝试预测多个后续 token；谷歌称这一优化可以同时加速 CPU 和 GPU 后端的解码，并做到不降低输出质量。

51 亿参数不等于翻译质量没有代价

Gemma 4 E2B 的优势是部署效率，而不是无条件胜过云端大型模型。小模型处理旅游问路、餐厅交流和固定领域短句时可能已经够用，但遇到低资源语言、强口音、多人抢话、专业术语或需要理解上下文的长对话时，模型容量和本地算力仍会限制准确率。

Gemma Translator 与常见云端翻译方案的差异可以归纳如下：

| 维度 | Gemma Translator 本地方案 | 手机端传统离线翻译 | 云端大模型翻译 | |---|---|---|---| | 核心模型 | Gemma 4 E2B，约 51 亿总参数、23 亿激活参数 | 专用机器翻译模型 | 大型通用或多模态模型 | | 运行位置 | Raspberry Pi 5 本地 | 手机本地 | 数据中心 | | 网络要求 | 无需联网 | 通常无需联网 | 通常需要稳定网络 | | 数据隐私 | 语音与文本可留在本地 | 语音与文本可留在本地 | 内容通常需要发送至服务器 | | 上下文与推理 | 具备生成式模型的上下文理解能力 | 更偏句子级映射 | 通常最强 | | 可控性 | 可替换模型和语音组件 | 受应用功能限制 | 受服务接口和策略限制 | | 主要短板 | 算力、内存与端到端延迟 | 语种和表达灵活性有限 | 网络、隐私与持续调用成本 |

生成式模型参与翻译也会带来传统翻译引擎较少面对的问题。模型可能为了让句子更自然而省略重复信息，也可能在专有名词不明确时主动补全含义；这对日常交流是润色，对法律、医疗和安全指令却可能成为风险。

离线并不自动等于可靠。真正面向生产环境的翻译设备还需要术语表、数字保护、人名地名约束、敏感场景告警、低置信度提示，以及在语音识别不确定时主动要求用户重复，而这些能力在当前演示中尚未被完整说明。

谷歌真正展示的是一套端侧 AI 模板

Gemma Translator 的战略意义大于硬件本身。谷歌把开放权重模型、端侧推理框架、语音组件和廉价单板计算机组装成一个可见、可听、可复现的产品形态，相当于给开发者展示了 Gemma 4 E2B 不只是聊天机器人底座，还能成为专用设备的语言中枢。

这套模板可以很容易地迁移到翻译以外的场景。工厂可以把它改造成离线设备维护助手，博物馆可以制作不上传游客语音的讲解终端，医院可以在隔离网络中部署基础沟通设备，机器人也可以用类似架构完成本地指令理解。

Gemma 4 家族的尺寸设计也体现了清晰的部署分层。E2B 和 E4B 面向手机与物联网设备，12B、26B A4B 和 31B 则更适合个人电脑、消费级 GPU 和工作站；开发者可以先用更大模型验证任务，再根据延迟、功耗和内存预算向小模型压缩。

| Gemma 4 版本 | 主要定位 | 典型设备 | 更适合的任务 | |---|---|---|---| | E2B | 极轻量端侧模型 | 高端手机、树莓派、IoT 设备 | 翻译、摘要、轻量助手 | | E4B | 更高能力的端侧模型 | 手机、平板、边缘计算设备 | 多模态理解、复杂指令 | | 12B | 本地通用模型 | 笔记本、消费级 GPU | 编程、推理、智能体任务 | | 26B A4B | 混合专家中型模型 | 高性能 PC、工作站 | 高质量生成与复杂工作流 | | 31B | 大型本地模型 | 工作站、服务器 | 更高精度的综合任务 |

开放权重和 Apache-2.0 许可进一步降低了二次开发门槛。对开发者而言，这意味着可以在许可范围内下载权重、量化模型、针对行业语料微调，并把模型部署到自己控制的硬件上，而不必把核心业务流程绑定在单一在线服务中。

现在还不是扔掉手机的时候

Gemma Translator 目前最有价值的身份，是一份“端侧生成式 AI 如何落地”的样板工程。它用树莓派证明本地语音翻译已经具备可演示、可交互的基础，但距离成熟商品仍缺少量产硬件设计、麦克风阵列、回声消除、续航、散热、翻译准确率和长期稳定性等关键数据。

谷歌也暂未公布 Gemma Translator 的售价、销售地区和正式上市时间。开发者不应把此次发布理解为一款马上可以购买的翻译机，而应把它看作 Gemma 4 E2B 和 LiteRT-LM 的应用展示，以及谷歌争夺端侧 AI 开发生态的一次明确表态。

这次演示最现实的结论是：小模型正在让专用 AI 硬件重新变得有意义。过去每个设备接入云端大模型就能获得能力，但也会继承网络依赖、隐私和持续成本；现在，一块树莓派加一个 23 亿激活参数模型，已经可以独立完成一项真实任务。

这次演示最需要保留的判断是：能离线运行不等于已经达到专业翻译水准。在谷歌公布 Raspberry Pi 5 的端到端延迟、语种覆盖、翻译质量测试和真实噪声环境表现之前，Gemma Translator 更适合被评价为一个方向正确、工程完成度不错的原型，而不是云端翻译服务的全面替代品。

参考来源

• IT之家：谷歌打造本地翻译机器，运行 Gemma 4 E2B AI 模型：介绍 Gemma Translator 的发布时间、树莓派 5 硬件、本地翻译流程及演示信息。
• Hugging Face：google/gemma-4-E2B：Gemma 4 E2B 的开放权重页面，包含模型架构、多模态能力、上下文长度和多语言支持说明。
• Reddit：Gemma 4 E2B 端侧使用讨论：社区用户对 E2B、E4B 在手机 CPU 环境下运行体验的讨论，仅作为实际部署反馈参考。