指南

你的 Mac 在设备上转录音频时，究竟发生了什么

“设备端 AI”是贴在一套具体而相当有趣的工程之上的营销词。下面是完整的流水线，从文件到文字。

30 August 2026

现在每个应用都说自己是"设备端"完成的。值得知道这实际上包含些什么，一方面是因为它解释了本地转录为什么这么快就变好了，另一方面是因为这正是"一个你能验证的说法"和"一个你无法验证的说法"之间的区别。

下面就是这条流水线，按顺序。

第 1 步：一切都变成 16 kHz 单声道 #

Whisper，也就是几乎所有这类应用使用的语音识别模型，只接受一种输入：每秒 16000 个采样、单声道、取值在 -1 到 1 之间的浮点数。

所以任何转录工具做的第一件事，就是把你音频的大部分扔掉。你 48 kHz 的立体声录音会被缩混并降采样。视频文件会被提取音轨，画面丢弃。

这听起来很有破坏性，其实大体上不是：人类语音位于 8 kHz 以下，而根据奈奎斯特极限，16 kHz 的采样率足以完整捕捉它。你失去的是音乐质量，不是可懂度。

实际后果是：你那份昂贵的 96 kHz 录音在这一步没有带来任何好处，而一个压得很糟的文件也不会因此得到挽救。

第 2 步：语音活动检测决定什么值得转录 #

第二个小得多的模型会先运行，标出音频中哪些部分含有人声。

常用的模型是 Silero VAD——不到一兆，它只回答一个问题：在细密的时间网格上，这里是不是语音。

它的存在有两个理由。它让处理更快，因为解码静音是白费功夫。更重要的是，它避免了这样一种失败模式：Whisper 拿到不含语音的音频后照样生成文字并陷入循环。正是 VAD 让现代的本地转录不再产出成页的重复短语。

第 3 步：音频变成一幅图像 #

Whisper 消费的不是波形，而是一幅 log-Mel 频谱图：一个二维图像，横轴是时间，纵轴是按人耳听感刻度排布的频率，亮度是能量。

这是现代语音识别中真正的观念跃迁。一旦音频成了图像，你就可以对它使用为计算机视觉打造的那套机器——而接下来发生的正是这件事。

第 4 步：编码器运行，理想情况下跑在 Neural Engine 上 #

Whisper 是一个由两半构成的 transformer。编码器读取频谱图，把它变成对所说内容的一种稠密数值表示。这是费劲的那一半——在固定大小的输入上进行大量规则的矩阵乘法。

而这恰恰是 Apple 的 Neural Engine 为之而生的：芯片上的一个专用模块，以极快的速度和极低的功耗做一类很窄的算术。它不是通用的——你不能在上面跑任意代码——但 transformer 编码器正好是它的形状。

要把编码器放上去，需要提前把模型编译成 Core ML 的格式（.mlmodelc）。这样做的应用会随模型权重一并附上一个 Core ML 编码器，而在同一台硬件上，这是"快的本地转录应用"和"慢的"之间最大的速度差别。

第 5 步：解码器跑在 GPU 上 #

解码器产出真正的文字，一次一个 token，每个都以此前的全部内容为条件。

这一半是顺序的，所以不适合 Neural Engine 那种面向批处理的设计。它转而通过 Metal 在 GPU 上运行。在 Apple Silicon 上，GPU 与 CPU 共享内存，所以模型权重不必跨总线复制——这在很大程度上解释了 Apple Silicon 为什么在本地推理上表现超出其体量。

第 6 步：时间戳出自同一个过程 #

Whisper 会在词语之间穿插输出特殊的时间戳 token。这就是你能拿到时间合理的 SRT 而不是一整堵文字墙的原因——时间信息是从同一遍解码中掉出来的，而不是来自单独的对齐步骤。

当 VAD 跳过了静音时，这些时间必须被映射回原始录音，否则第一个间隙之后的每一个时间戳都会是错的。

模型，以及它为什么比听上去要小 #

Whisper 的 Base 模型有 7400 万参数。以全精度存储大约是 140 MB，其中大部分对这个用途来说是冗余的。

量化用更少的比特来存储每个权重。在 q5_1 模型里，权重是 5 比特，加上每个块一个小的缩放值和偏移量——大致相当于每个权重 6 比特，而不是 16 比特。结果约为 60 MB，而在普通语音上，准确度差异难以察觉。

这对手机很重要，因为在手机上，140 MB 的下载量和与之相称的内存开销是实打实的代价。这也是为什么对于"我该用哪个模型"，老实的答案通常比人们以为的更小。

长文件，以及内存为什么是难点 #

Whisper 的 API 接受一段连续的采样缓冲区。两小时的 16 kHz 音频大约是 470 MB 的浮点数，再加上一个规模相当的频谱图。

在 Mac 上没问题。在 iPhone 上，这已经足以让应用被系统终止——这就是为什么有些移动端转录应用悄悄限制文件长度。

解决办法是分窗口转录：把解码后的音频放在磁盘上，一次映射一段，转录它，释放它。这样内存峰值取决于窗口而不是文件。微妙之处在于从哪里切——在词中间切开，每个边界处就会出现一句破碎的话，所以合理的实现会在重叠区域内最安静的位置切分，并把每个窗口的时间戳移回原始时间轴上。

这些为什么与你有关 #

从上面这条流水线可以推出三件事，它们不是营销说辞：

**它在没有网络时也能工作。**上面没有任何一步需要网络。这一点三十秒就能验证——我们写了怎么验证，其中包括不需要信任我们的测试。

**你的录音不会成为任何人的训练数据。**这不是因为本地应用承诺不拿你的音频去训练，而是因为你的音频从来没有出现在可能被拿去训练的地方。

**速度取决于你的硬件，而不是别人的排队队列。**本地转录在 Apple Silicon 上的速度是实时的好几倍，始终如此，周日凌晨三点也一样，而且没有速率限制。

简短版本 #

音频被降采样为 16 kHz 单声道，语音检测剥离掉没有语音的部分，剩下的变成频谱图，一个 transformer 编码器在 Neural Engine 上处理它，解码器在 GPU 上生成文字并穿插时间戳，而量化让模型小到足以让这一切都装进一部手机。

这里没有一步需要服务器，而这正是全部意义所在。