16.9MB 的语音识别模型：Whistle 把 Whisper 塞进了耳机

一个 16.9MB 的文件，就能在手机上离线转写七种语言的语音——首字延迟 11 毫秒，解码速度 1319 token/秒。Cactus Compute 发布的 Whistle 不是又一个”云端语音识别 API”，而是把整个 ASR 管线压缩到了一块 MCU 芯片能跑的尺寸。音频数据从头到尾不离开设备，这在隐私敏感的场景里不是加分项，而是准入条件。

16.9MB 意味着什么

对比一下：Whisper base 是 145.3MB，Moonshine tiny v2 是 41.9MB。Whistle 只有 Whisper 的十一分之一。这意味着它可以塞进 TWS 耳机的闪存、手表的 RAM、甚至树莓派 Pico 级别的微控制器。Cactus 的工程团队给 Whistle 做的不是”模型压缩”那种粗活——他们复用了自家 Needle 引擎的架构：8 层 Simple Attention 编码器 + 8 层 Laddered Simple Attention 解码器，用 Monarch Hadamard MLP 替代传统 FFN，用 engram 查找表替代部分注意力头。

精度没有因为小就打折

这是最反直觉的部分。在 LibriSpeech test-clean、SPGISpeech、Earnings-22 和 FLEURS 平均上，Whistle 的 WER（词错误率）比 Whisper base 更低。只有 TED-LIUM、AMI 和 MLS 上 Whisper base 占优——但后者是 145.3MB 的模型，跑在 17 倍体积的硬件上。

解码效率的差距更夸张：Whistle 1319 token/s vs Whisper base 266 token/s，5 倍。原因在架构层面——Whistle 的交叉注意力投影在音频片段到达时一次性计算（375 帧 × 8 层），然后整个解码过程复用。5 个 beam 搜索只需要 5 个短的转录缓存，而不是对音频跑 5 遍。Whisper 则把每段输入都 pad 到 30 秒，所以首字延迟是平的；Whistle 的延迟跟随片段长度：5 秒音频 5.9ms，10 秒 11.1ms，30 秒 36.3ms。

一个引擎，三种加载方式

Whistle 最务实的设计决策是和 Needle 共用同一个 C++ 引擎、同一个量化容器。这意味着一个 17 个平台的预编译二进制（macOS、Linux、Android、iOS、watchOS、Windows on ARM、RISC-V、MIPS、浏览器 WASM）就能同时加载 LLM 和语音模型。`needle_load`、`needle_transcribe`、`needle_embed` 三个 C API 就是全部的语音接口，不读环境变量，所有行为都是编译期默认值或显式命令行参数。

对嵌入式开发者来说，这意味着”在设备上跑 AI”从概念验证变成了工程现实。智能音箱、车载语音助手、机器人——这些场景过去要么依赖云端 API（延迟 200ms+，隐私风险），要么用 Whisper 的本地推理（145MB，手机都嫌大）。Whistle 把体积砍到 17MB 以下，把延迟压到 11ms，把语言数拉到 7 种——它填的恰好是”够小到塞进硬件、够准到不用云端”这个空档。

对开发者的实际意义

如果你在做智能家居、可穿戴设备或者任何”语音是主要交互方式”的产品，Whistle 的出现改变了技术选型的天平。以前你的方案可能是”本地唤醒词检测 + 云端 ASR + 本地 TTS”，现在可以全部本地化：唤醒、转写、甚至 embedding 提取（每 80ms 一帧的 encoder 输出）都在芯片上完成。网络断了，语音功能不降级，只是少了一些云端才能做的高级能力。

Cactus 同时开源了 Web 演示——在浏览器里按住麦克风说话，16.9MB 模型在 WASM 里跑，音频不离开你的标签页。这个 demo 本身就是一个能力证明：如果浏览器里能跑，MCU 里就更不是问题。

核心观点：Whistle 的核心价值不是”更小的 Whisper”，而是证明了 ASR 可以在 17MB 内做到生产级精度。如果你的产品需要离线语音能力，现在值得评估把 Whisper 替换成 Whistle 的成本——引擎 API 只有三个函数，迁移成本可能比想象的低得多。