谷歌端侧语音工具补齐离线识别与合成

Google AI Edge Gallery 把语音识别、端侧语言模型和语音合成接成了一条本地流水线：用户边说边出文字，模型在设备上回答，再把答案读出来。作者想证明，离线 AI 的交互已经可以从打字聊天，走向看着实物提问、听双语讲解。

对程序员更有参考价值的是背后的工程分工：Android 优先调用系统语音能力，跨平台应用使用独立语音模型，聊天界面则按句调度朗读。不过，文中的速度和功耗数字来自 Google 报告，不能直接当成自己应用的性能承诺。

语音能直接交给模型，为什么还要拆流水线

原文承认，Gemma 4 这样的多模态模型可以直接处理音频。但他们团队仍提供了模块化方案：自动语音识别（ASR）负责听，Gemini Nano 或 Gemma 4 等端侧小语言模型（SLM）负责理解，文本转语音（TTS）负责说。

这样做是为了优化延迟，并让开发者能单独替换语音模型。识别支持哪些语言、合成用什么声音，也就不必完全绑定语言模型。

XR Language Teacher 展示了这条流水线的用途。用户把摄像头对准菜单、路牌或物体，开口询问它是什么、该怎么购买。ASR 实时输出问题，问题与摄像头画面一起交给模型：Android 使用 Gemini Nano，其他平台使用 Gemma 4。

双语讲解的关键是结构化输出。模型用用户的母语解释，同时单独标记外语短语；TTS 根据标记切换声音和口音，界面再显示词汇卡。它需要语言模型输出可供程序消费的语言边界，不能只生成一整段文字，让朗读端自己猜。

这个展示可独立运行在手机上，也能延伸到智能眼镜。原文描述的是由配对手机承担本地推理，并没有说所有模型都运行在眼镜里。

Android 的便利来自系统，跨平台的灵活来自模型

两条路线解决的是不同的部署问题。

面向旗舰 Android 设备，作者推荐 ML Kit GenAI Speech Recognition API 和 ML Kit GenAI Text-to-Speech API。底层模型由 AICore 和 Google 的端侧语音服务管理，支持后台更新，并在可用时使用 NPU、TPU 加速。应用无需自行管理模型下载，两个系统语音模型给 APK 增加的体积是 0 MB。

0 MB 指的是 APK 增量，不是模型不占设备存储和运行内存。

Google 报告的 ASR 指标包括：覆盖 100+ 种语言，在 FLEURS 上的词错误率（WER）为 8.0%～9.0%，处理速度达到实时的 10 倍，约 300 ms 处理 3 秒语音；端到端语音翻译等待时间减少 35%～44%。这里的 10 倍是处理吞吐，不能直接理解为用户说话到屏幕出字只需固定的几十毫秒。

TTS 使用紧凑的少步扩散模型，约 100 ms 开始发声，以最高 50 倍实时速度生成 24 kHz 音频，提供 8 种表现力声音、覆盖 21 个地区语言设置（locales），并内置提示音（earcon）支持。原文给出的例子是约 500 ms 合成一段时长 27 秒的语音；相较传统自回归 TTS，设备活跃功耗降低超过 50%。这些数字对应不同指标，不能合并成一句「整个语音助手百毫秒响应」。

跨平台路线则使用 MediaPipe Tasks，覆盖 iOS、macOS、Windows、Linux 和 Web：

• MediaPipe Speech Recognition (ASR) Task 封装音频分帧、可配置的语音活动检测（VAD）和解码，支持实时流式、整句批处理、混合识别。混合模式会先显示实时文字，再在说话结束后修正整句。
• MediaPipe Text-to-Speech (TTS) Task 提供声音选择和低延迟流式音频输出，展示模型包括多语言 PocketTTS 100M、Kokoro-82M，以及轻量英语模型 Phonon 31M。原文称 Phonon 在多数设备和平台上的首段音频时间（TTFA）低于 100 ms。

两者底层都由 LiteRT 支撑。需要控制语音处理细节或接入自定义模型架构时，也可以直接使用 LiteRT。

部署上的一个实用设计，是把编码器、解码器、分词器，以及 TTS 所需的发音词典、声音嵌入、声码器等组件，打包进单个 .litertlm 文件。随应用提供的模型包括 Parakeet-TDT-0.6B-v3、PocketTTS 100M、Phonon 31M 和 Kokoro-82M；前文的 Parakeet-TDT 0.6B 在这里给出了具体版本。

原文还提到，拥有 10K+ 关注者的 Hugging Face LiteRT Community 正在扩充模型目录，包括 ASR 模型 Whisper、Qwen3-ASR、Moonshine，以及 TTS 模型 Qwen3-TTS、Matcha。目录里有模型，不代表它们已经在所有平台上获得相同的性能验证。

聊天朗读的难点，是让生成和播放配合起来

AI Chat 的实现比「给答案加一个播放按钮」更值得参考。

他们团队把 ASR、TTS 流水线、预设声音和已下载语言包集中放进 Model Management。用户可以开启「Auto-play TTS」，也能点击某条回答的扬声器按钮，打开浮动播放条。播放时，界面实时高亮当前句子，用户点击其他句子即可跳转。

这里需要同时处理内容清洗和任务调度。模型回答通常含 Markdown，代码块和表格直接读出来很难听懂。开源参考实现展示了如何移除 Markdown 语法、跳过代码和表格等不适合朗读的块，再按句安排合成。

语音回答需要独立的内容处理和播放状态，不能只把聊天字符串交给 TTS。

按句调度还有资源上的考虑：语言模型正在生成 token 时，TTS 也可能争用算力和内存。原文把句子级合成作为减少争用的工程做法，但没有给出调度算法、队列大小或并发参数，团队仍需结合模型和设备实测。

我的判断

我认同它把语音交互拆成可替换组件的方向。对于已经有文本聊天能力的应用，这提供了一条逐步增加语音输入、朗读和双语切换的路径。尤其是 Markdown 清洗、句子定位、播放状态这些细节，比单独展示模型跑分更接近产品开发。

但模块化方案并不自动优于原生音频多模态模型。原文没有提供两条路线在延迟、识别质量或资源占用上的完整对照，因此「拆开更好」仍是带有具体目标的工程选择。

性能数据也有边界。文章给出了 FLEURS 错误率、合成速度和功耗降幅，却没有完整交代测试设备、各语言结果及比较基线。嘈杂环境中的中文、前端术语和中英混说能识别到什么程度，文中没有说清。

Android 路线还需先核实目标设备支持情况。原文强调旗舰设备和系统服务，却未列出完整兼容清单。跨平台部分所说的紧凑内存占用、与 SLM 平稳共存，也缺少逐设备数据。

相较云端语音方案，本地方案明确展示了离线工作的价值；至于识别质量、维护成本和整体体验谁更好，文章没有提供云端对照，不能替它下结论。

能拿来做什么

• 已有 AI 聊天界面的团队，可以先参考 AI Chat 的朗读实现，把 Markdown 清洗、代码和表格跳过、句子高亮及点击跳转做完整，再评估自动播放。
• 面向 Web 或桌面应用，可以用 MediaPipe Tasks 的混合识别模式验证输入体验，重点检查用户说话时的临时文字，以及结束后的整句修正是否影响编辑操作。
• 面向 Android 产品，应先核实 ML Kit 两个 GenAI 语音 API 在目标设备上的可用性，再测试首次出字、首次出声和连续对话体验。原文提到 Google Cloud 的 Developer Device Platform 支持在 200+ 台真实物理设备上测试，可作为验证渠道之一。
• 做双语讲解时，可以让模型通过结构化输出标记外语片段，再由 TTS 切换声音和口音。参考实现交给 Google Antigravity 等 coding agent 辅助改造后，仍要检查语言标记与实际朗读是否一致。