谷歌端侧语音提供系统 API 与模型部署两条路

离线语音交互，正在从单独的识别、朗读能力，走向手机上的完整对话流程。按原文转述的 Google 2026 年 11 月 10 日公告，Google AI Edge Gallery 已加入端侧语音识别和语音合成，再配合本地语言模型，听、理解、回答都可以不联网。

对开发者更有价值的变化，是语音功能的接入方式和成本结构。不过，作者没有上手测试，文中的速度、准确率和功耗数字均来自 Google。读这篇，应该把已经公布的能力与等待验证的效果分开。

Android 的 0 MB，为什么不能套到 Web 上

这次发布有两条路线，决定了谁来分发模型、谁来维护更新。

Android 走系统能力。ML Kit 新增的 GenAI Speech Recognition 和 Text-to-Speech APIs，通过 AICore 使用 Google 管理的模型。Google 宣称，这条路线给 APK 增加的体积是 0 MB，模型在后台更新，设备支持时可使用 NPU、TPU 硬件加速。

这里的 0 MB 指 APK 增量。模型由系统侧管理，不能理解成设备完全不需要模型存储，也不能据此推断所有 Android 手机都支持。

跨平台路线则由应用接入开放权重模型。MediaPipe Tasks 和 LiteRT 使用 .litertlm 包，把模型所需的子图、分词器和声音嵌入装进单个文件，覆盖 iOS、macOS、Windows、Linux 和 Web。识别模型包括 Parakeet-TDT 0.6B，合成模型包括 PocketTTS 100M、Kokoro-82M 和 Phonon 31M。

Hugging Face LiteRT Community 还列出了 Whisper、Qwen3-ASR、Moonshine、Qwen3-TTS 和 Matcha，供开发者选择。但这些模型不能自动套用公告中其他模型的性能数字。

跨平台支持解决了可运行的问题，模型下载、存储和更新仍然是应用需要承担的工作。

完整对话还需要理解和生成文本：Android 可搭配 Gemini Nano，跨平台可搭配 Gemma 4。语音识别负责听，语言模型负责理解和回答，语音合成负责读出来。任何一个环节调用云端，都不能再把整条流程称为完全离线。

100 ms 开口，不等于 100 ms 完成回答

Google 给出的识别指标是：支持 100+ 种语言的实时流式转写，处理速度达到实时的 10 倍，约 300 ms 转写 3 秒语音；FLEURS 基准上的词错误率为 8.0% 至 9.0%，端到端语音翻译等待时间减少 35% 至 44%。

这些数字回答的是不同问题。处理速度快，说明模型能较快消化音频；词错误率描述识别结果；翻译等待时间还涉及其他处理步骤。它们不能合并成一句「对话响应只要 300 ms」。

合成侧采用紧凑的少步扩散模型，Google 宣称约 100 ms 开始出声，生成 24 kHz 音频的速度最高达到实时的 50 倍，一段 27 秒的文本朗读约用 500 ms 合成完成。它提供 8 种表现性声音、21 个区域设置，相比传统自回归 TTS，设备活跃功耗降低超过 50%。更轻的 Phonon 31M 则被称为能在多数设备上做到低于 100 ms 的首段音频延迟。

最容易误读的是 100 ms。它指首段音频出现的时间，不包含用户说话、识别、语言模型生成回答的全部耗时。

原文没有提供完整的测试硬件、统一测试条件或独立复测。开发者可以把这些数字当作选型线索，不能直接写进自己产品的性能承诺。Google 同时强调延迟与功耗，确实切中了手机场景，但实际体验仍要落到具体设备上。

离线语音能改变哪些产品体验

云端语音通常要经历麦克风采集、上传、服务端处理、返回和播放。端侧处理去掉了网络往返，也不再按语音分钟数支付云 API 费用。

它减少的是网络依赖和服务费用，计算、耗电、存储以及适配成本仍然存在。音频是否始终留在本地，也取决于应用有没有额外上传录音、转写结果或日志。

Google 的 XR Language Teacher 展示了较完整的使用方式：摄像头对准路牌或菜单，用户开口提问，应用结合视觉与语言理解，给出本国语言解释和当地语言发音，整条流程在本地完成。地下车站、境外市场等弱网地点，正是这种能力容易体现价值的地方。

AI Edge Gallery 内的 AI Chat 则提供听写、按句同步朗读和浮动 TTS 播放栏。对程序员而言，参考实现里一个细节比演示更实用：合成语音前清理 Markdown，并跳过代码块，避免把反引号和源码逐个念出来。

作者据此提出了仓库清单、巡检记录、旅行语言辅导、私人语音日记和儿童阅读辅导等方向。这些是产品设想，原文没有给出上线结果。尤其是「实时纠正发音」，不能仅凭支持流式转写就认定已经具备，仍需验证模型能提供什么判断依据。

我的判断

我认同作者把重点放在部署方式上。对于弱网、双手忙碌或希望减少录音外传的应用，语音成为本地能力，价值可能比某项基准领先更直接。

但「最便宜、最私密」需要限定范围。本地执行可以省掉按分钟计费，也能减少数据外传路径；跨平台模型分发、设备适配和维护却会产生另一组成本。隐私承诺更需要检查整条数据流，不能只看模型在哪里运行。

质量判断也要留余地。作者认为小模型在重口音、多人重叠说话和噪声环境中难以匹敌云模型，这是一项合理的风险判断，但文章没有提供对应的对照数据。它不能作为所有模型、所有场景下的确定结论。

是否值得采用，应该由目标设备上的完整任务表现决定。

纯端侧适合强调离线可用的任务；端侧优先、必要时转云端，也是可比较的方案，只是回退时必须重新说明数据去向。公告没有最低设备规格列表，AICore 和硬件加速支持也并不普遍，现阶段尤其不适合把旗舰机演示推广到全部用户。

能拿来做什么

• 先用 Android 或 iOS 最新版 Google AI Edge Gallery 体验 XR Language Teacher 和语音 AI Chat，断网后测试安静、噪声和口音场景，分别记录识别耗时、回答等待时间与首段音频延迟。
• 给已有聊天界面增加朗读时，可以参考其开源实现的流式 ASR、双语 TTS 切换和按句同步播放，先处理 Markdown 清理、代码块跳过及播放控制这些基础体验。
• 做 Web 原型时，可先尝试浏览器中的 MediaPipe ASR、TTS tasks，再评估 .litertlm 的实际下载体积和加载耗时。Android 的 0 MB 宣传不能用于估算网页成本。
• 准备面向多种设备上线时，应先明确支持范围，并验证内存、耗电和长时间运行表现。Google 提到的 Developer Device Platform 提供 200+ 台物理设备，可作为实机测试入口；原文未说明其使用条件。