2026年10月2日，Cactus Compute 正式开源专为手机、可穿戴设备与微控制器设计的端侧语音识别模型 Whistle。该模型文件体积仅有 16.9 MB，无需外挂依赖即可在 CPU 上独立运行，甚至能与该团队的端侧工具调用引擎 Needle 编入同一个 C++ 二进制文件中，直接实现音频输入到工具调用的流水线输出。
官方给出的基准数据显示，Whistle 在 Apple M4 Pro 上处理 10 秒音频的首字延迟低至 11.1 ms，解码吞吐达到 1,319 tokens/s，并在多个公开测试集上击败了体积极其庞大的行业标杆 OpenAI Whisper base。然而，将一个语音识别模型压缩至不到 17 MB 并宣称全方位超越前代，往往意味着在精度、架构兼容性与评估口径上做出了极其激进的取舍。拨开跑分层面的技术包装，Whistle 更像是一个高度定制的工控与短指令中枢，而非真正通用的语音识别替代者。
算子复用与 17 MB 的压缩账本
Whistle 能塞进只有 16.9 MB 的单一二进制文件，核心并不在于提出了全新的语音感知机理，而在于对既有推理架构的极简剪裁。它全面复用了 Needle 运行时的 Monarch Hadamard MLP 与 Simple Attention 算子，权重采用 2–4 bit 的 Cactus Quants 格式压缩，并以 Apache-2.0 协议分发。
在音频处理管线上，16 kHz 的单声道输入经过卷积前端后，被剧烈下采样为每 80 毫秒仅留 1 帧的特征序列。面对一段 30 秒的音频，系统最终只向编码器输入 375 帧数据。解码器端则设计了门控交叉注意力机制，当音频送达时仅对 8 层网络执行一次投影缓存，后续的 5-beam 束搜索直接读取该缓存展开，避免了多轮解码对整段音频特征的重复计算。为了解决小模型在专有名词上容易失准的通病，Whistle 还内置了 Aho-Corasick 自动机，在搜索过程中动态提升预设关键词的对数概率。
轻量化不是凭空创造精度，而是用精细的工程剪裁换取边缘硬件的生存空间。
官方数据表明，配合这套关键词偏置算法，LibriSpeech clean 评测集的词错率可以从 4.73% 压降至 2.93%。这种针对特定短语的定向纠偏，使模型在词表受限的环境下展现出极高的执行效率。
跑分卸妆：不对等基准与复杂场景短板
纸面数据的优异表现往往掩盖了严苛的测试限制。Cactus Compute 宣称 Whistle 在大部分指标上优于体积为其 8.6 倍 的 Whisper base，但两者的横向对比建立在显著的测试异构之上。Whistle 运行在自身深度优化的 C++ 引擎与 2–4 bit 量化权重下，而作为对照组的 Whisper base 采用的是 74M 参数的 FP32 原始浮点版本，对标的 Moonshine tiny v2（34M 参数，WER 为 12.00%）采用的则是 INT8。
| 模型 | 存储体积 | 格式/精度 | LibriSpeech Clean | TED-LIUM (演讲) | AMI (会议噪声) |
|---|---|---|---|---|---|
| Whistle | 16.9 MB | 2–4 bit | 4.31% | 7.61% | 26.07% |
| Whisper base | 145.3 MB | FP32 | 4.5% 左右 | 5.0% | 21.5% |
| Moonshine tiny v2 | 41.9 MB | INT8 | 未公布多语 | 未公布多语 | 未公布多语 |
当测试脱离相对干净的朗读样本、进入复杂声学环境时，模型抗噪能力的短板便暴露出来。在长演讲场景的 TED-LIUM 测试中，Whistle 词错率为 7.61%，落后于 Whisper base 的 5.0%；在多人重叠谈话与高环境噪声的 AMI 会议集上，Whistle 的词错率升至 26.07%，同样显著弱于 Whisper base 的 21.5%。即便在涵盖 6 种语言的 MLS 多语平均测试中，Whistle 的词错率（24.9%）依然落后于对手（23.2%）。
开源社区在多语言实测中的反馈也出现分化。尽管模型名义上覆盖英、德、法、西、意、荷、波 7 种语言，并在 FLEURS 均分测试拿到 21.4% 的成绩，但开发者在非英语指令（如法语长句）下的真实识别表现极不稳定，缺乏在远场拾音与重口音场景下的泛化韧性。
- 提醒.纯净测试集的低词错率不能直接等同于抗噪鲁棒性，严苛工业环境下的听写表现仍需独立三方验证。
语音直通指令链与端侧隐蔽代价格
Whistle 真正的产品野心并非做一个通用听写听筒，而是充当端侧设备的控制核心。通过与 Needle 引擎无缝组装，开发者只需一条命令就能让系统吞入原始音频并直接返回解析后的 JSON 函数调用。这种设计省去了传统方案中“音频转文字、文字进程间跨应用序列化、再喂给大模型提取参数”的臃肿链路。
虽然单二进制设计减少了资源开销，但也将整条控制流推向了更高风险的境地。当下游的 Needle 引擎接收转录结果时，其参数解析稳定性依然存疑。在多工具并发的非英语评测中，Needle 多次暴露出参数幻觉与指令漂移缺陷；且在移动设备如 Android Termux 环境下，载入崩溃的社区报告也尚未清零。一旦超轻量语音端在前序识别中遗漏或误读单个动词，由于缺乏中间校验层，这种误差将直接击穿防线，引发物理外设的误操作。
与此同时，对于追求绝对数据主权的嵌入式开发者，其闭源成分与隐私机制也需要审慎评估。该项目的底层 C++ 引擎目前以预编译二进制形式提供，核心训练代码未完全开源；其配套的 Python 开发包在默认状态下会采集带有版本号与匿名 ID 的遥测日志，必须显式配置系统环境变量 NEEDLE_TELEMETRY=0 或 DO_NOT_TRACK=1 才能彻底切断网络回传。
- 结论.将 Whistle 用作扫地机、智能开关等固定关键词控制，其极小体积能带来显著优势；但在长语音输入与复杂的容错链条下，它仍难撼动成熟工业方案的防线。