谷歌（Google）的 EmbeddingGemma 2 原本是一个嵌入模型，我们把它改成了语音转文字模型：在基础版 MacBook Air 上，一小时音频约 13 秒即可处理完，完全在本地运行。EmbeddingGemma 2 是多模态嵌入模型，文本、图像、音频和视频处于同一个共享空间；说出某个单词时，它的音频会落在对应文字附近，于是我们尝试直接从该空间中读取单词。
正文
Google 的 EmbeddingGemma 2 是一个嵌入模型。我们把它改成了语音转文本模型：在基础款 MacBook Air 上，约 13 秒处理一小时音频，并且完全在本地运行。
免费下载 Mac 版 v1.6 · macOS 14+ · Apple Silicon；首次启动时会下载模型（715 MB）。
嵌入模型能转录语音吗？
EmbeddingGemma 2 是一个多模态嵌入模型：文本、图像、音频和视频都在同一个共享空间里。说出一个词，它的音频会落在对应书面词的附近。
于是我们尝试直接从那个空间里读出词。
工作原理
- EmbeddingGemma 2 的音频编码器保持原样。
- 一个小型读取器把每一小段音频移入模型的文本空间。
- 在约 229,000 个英文单词中，最接近的那个词胜出，这些片段便成为转录文本。
- 一个极小的附加模型加上标点和字母大写。
只有读取器经过训练：在 8×H100 上训练不到两小时，使用的是开放许可的英文语音。基础模型从未被训练用于语音转文本。
速度如何？
| 模型 | 运行平台 | Mac | 速度 | | --- | --- | --- | --- | | Embedding Gemma Transcribe | Neural Engine | 基础款 M3 MacBook Air，8 GB | 288×：1 小时音频用 12.6 秒 | | IBM Granite Speech 5.0 TurboCTC | GPU（MLX） | 基础款 M3 MacBook Air，8 GB | 约 150×：1 小时音频用 25.7 秒 | | NVIDIA Parakeet TDT 0.6B v3（FluidAudio） | Neural Engine | M4 Pro | 156× | | NVIDIA Parakeet TDT 0.6B v3（FluidAudio） | Neural Engine | M5 Pro | 335× | | Phonon-2，Parakeet v3 的一个微调版（FluidAudio） | Neural Engine | M5 Pro | 480× |
× 实时倍速：每秒处理对应多少秒音频。第 1–2 行：我们在同一台基础款 M3 MacBook Air 上的测试。第 3–5 行：FluidAudio 公布的基准测试，测试在更大、更新的 Mac 和不同音频上进行。这只是粗略参考，并非同等条件下的排名。
当前水平
目前它的词错误率约为 5%，而领先语音模型为 2–3%。我们相信，训练得更好的读取器可以缩小这一差距；这就是下一次迭代要做的事。
使用方法
放入音频文件，或者按住 Right Option，说话后松开，即可向任意应用听写。它在 Mac 的 Neural Engine 上运行；你的音频永远不会离开这台设备。
评论
讨论整体兴奋但迅速转向落地条件：多数人在追问是否开源、是否支持非英语、以及在真实 Apple Silicon 设备上究竟多快；分歧主轴在于 embedding 共享向量空间这条路究竟只是巧妙实验，还是应该在 Gemma 音频编码器上直接训练 CTC 头做成更强方案。作者承认准确率仍不及云端模型，但认为够日常使用。
认为用 embedding 共享向量空间做转写是巧妙实验，但准确率仍有差距
- 不少人对把 Embedding Gemma 2 中文本和音频共享向量空间的特性用于音频转文本感到兴奋；作者说明这最初只是验证可行性的实验，速度只是副作用，准确率够日常使用但还达不到云端模型水平，词错率还能靠更多样训练数据改善，并承诺几天内开源整个项目。（较多人） > 这最初只是想验证文本和音频在 Embedding Gemma 2 里共享同一向量空间，能不能借此把音频转成文本；速度只是副作用，不是目标。（@Shershah1024）
希望尽快支持印地语、韩语等非英语语言
- 多位用户希望不止支持英语，点名印地语+英语混合、韩语等场景；有人分享自己用现有方案转录 90 分钟印地英混合音频要花一个多小时，认为若能把大体量音频转写做到近乎即时，就会从“数量提升”变成解锁新工作流的“质量提升”。（较多人） > 如果这个项目能原生支持更多语言就好了，我现在处理 90 分钟的印地语+英语混合音频要花一个多小时。（@Imustaskforhelp）
要求开源、公开模型与参数规模以便复现对比
- 多人追问 GitHub 或开源链接、各部分及整体的参数量与量化情况；有人本来想做基准测试，但发现对方并未放出模型，也不想从应用包里提取，于是放弃测试；作者回应会尽快开源整个项目。（较多人） > 他们似乎没有放出模型，我也不想从应用包里提取，所以这次我不测了。（@llimllib）
认为 Apple Silicon 上的本地极速转写已有吸引力，但仍需服务器化和严谨对比
- 多位用户在 Apple Silicon 上实测：33 分钟音频约 6.75 秒完成，和 MacWhisper/Parakeet3 的约 7.5 秒接近；也有人好奇这种极速是否意味着要把音频按约 200 倍速“播放”给模型，还是另有推理机制；还有人指出 Apple 设备端转写在自己更强机器上比宣传慢约 3 倍但错误率不错，并给出命令行基准；若不能作为服务运行，本地极速的意义也会被质疑。（较多人） > 我在 M4 Mac Mini（24GB）上转写 33 分钟纯音频只花了 6.75 秒，MacWhisper/Parakeet3 大约 7.5 秒。（@bigtex）
质疑 embedding 路线是否最优，建议在音频编码器上训练 CTC 头
- 少数人没有停留在“酷不酷”，而是追问转写质量和路线：有人直接问准确率如何；有人认为更合理的是在 Gemma 的音频编码器上训练 CTC 头，很可能得到更好结果和更快推理；也有人怀疑对纯音频任务使用多模态模型是否过于浪费，或反过来问多模态是否确实帮助了准确率与速度。（少数人） > 在 Gemma 的音频编码器上训练 CTC 头，很可能得到更好的结果和更快的推理。（@mikemzz1）
有价值的补充
- 一个值得记住的判断框架：当某个能力比现有方案快上一到两个数量级，它就不再只是“更快”，而会让原本不可行的工作流变得可行；本地近乎即时的转写可能因此打开新用法。
- 作者还计划发布基于同一思路的 TTS 版本，说明文本与音频共享向量空间的技巧可能反过来用于语音合成。
- 若想自行对比，可关注是否有人把 Apple 设备端转写模型封装成命令行基准；等该项目开源后，就能用同一套流程做横向评测。