开源轻量语音模型Whistle发布：16.9MB装进CPU，语音识别不再依赖云端

2026年10月2日，Cactus Compute正式发布开源轻量语音模型Whistle，整个模型仅16.9MB，可在纯CPU环境下零依赖运行，支持七种语言转写、词级时间戳和语音嵌入三项任务。开源轻量语音模型Whistle发布的核心理念是将语音识别能力压缩到可以嵌入任何设备的程度，从根本上改变语音AI的部署逻辑。

一、16.9MB意味着什么：从“能不能跑”到“随便跑”

过去几年，语音识别领域的主流叙事围绕精度展开。Whisper Large v3以8.09亿参数和99种语言支持占据了开源语音识别的头部位置，但模型体积动辄数百MB乃至数GB，部署时对内存和算力的要求让大量边缘设备望而却步。Whisper base作为轻量方案的入门选择，也需要145.3MB的存储空间。

16.9MB是什么概念？它比大多数手机App的图标资源包还小。一个完整的语音识别模型——包含前端信号处理、编码器、解码器、词表——全部塞进不到17MB的单文件里，在CPU上以零外部依赖的方式运行。模型的量化精度被压到2到4比特，这是它能在如此极端的体积下保持可用精度的关键工程选择。

Cactus Compute在官方发布中明确将Whistle的适用场景定位为手机、可穿戴设备、机器人、智能家居、汽车电子和微控制器。这个定位本身就说明了问题：不是“在服务器上跑得好”，而是“随便什么设备都能跑”。

二、三项任务，一次推理

Whistle在单次推理中完成三件事，全部在设备本地执行，不产生任何网络请求。

2.1 语音转文字

输入16kHz单声道音频，单次最长30秒，输出文本转写结果。支持英语、德语、法语、西班牙语、意大利语、荷兰语和波兰语七种语言，语言自动检测，无需手动指定。当音频为静音时，模型返回空转写而非编造内容——引擎在解码器启动前先测量音频的响度范围，低于阈值则直接返回空结果，不进入束搜索。

2.2 词级时间戳

每个词附带起始时间、结束时间和概率值，对齐信息来自解码器自身的注意力机制，而非外挂强制对齐工具。这意味着应用层可以实现逐词高亮、按词定位、按词切割等精细操作，而无需引入额外的对齐模型。

2.3 语音嵌入

编码器输出每80毫秒一行的向量表示，可用于语音匹配和检索，完全不需要解码出文本。这个能力在声纹验证、相似音频检索等场景中具有直接的工程价值。

三项任务共享同一次前向传播，这种设计思路在端侧模型中并不常见。大多数方案要么只做转写，要么将嵌入提取作为独立的预处理步骤。Whistle将三者统一到一个推理流程中，减少了重复计算。

三、架构解析：从头设计的“小骨架”

3.1 不是剪枝，是重新设计

Whistle的架构选择值得深究。市面上大多数轻量模型走的是“压缩大模型”的路线——剪枝、蒸馏、量化，把一个预训练好的大模型削小。Whistle采取的策略完全不同：从头训练一个结构上就不一样的模型。

编码器由八个Simple Attention块堆叠而成，采用了两个不常见的设计：四路mHC残差通道和Monarch Hadamard MLP替代标准前馈网络。注意力机制是非因果的——第3秒的帧可以看到第12秒的帧。这在流式场景中是不可接受的，但在处理完整30秒音频时，全局注意力带来的精度优势是实实在在的。

3.2 前端降采样：性能的关键分水岭

音频信号经过标准前端处理：25毫秒窗口、10毫秒步长、80维log-mel特征，频带限制在250-3500Hz。30秒音频产生3000帧，然后一个128通道、kernel为9的卷积stem连续三次降采样，将帧数压缩到375帧，每帧对应80毫秒。

这个降采样是整个流水线的性能分水岭。之后的编码器和解码器都在375帧的尺度上运行，解码器需要处理的位置数直接少了一个数量级。首token延迟之所以能压到11.1毫秒，这个设计居功至伟。

3.3 解码器的“聪明”之处

解码器同样是八层Laddered Simple Attention结构，宽度512，8个query头对2个KV头，Q/K/V上各挂一个3-tap因果卷积，第3层和第7层插入engram查表。

真正为语音新增的设计每层只有一处：门控交叉注意力。每个解码器层通过一个可学习的门控从编码器读取信息，K和V来自当前音频片段。关键在于这个投影只在音频到达时计算一次——375帧跨8层投影完成后缓存，整个解码过程复用。开5个beam的代价是5份短转写缓存，而不是把音频过5遍。这个设计的工程价值在于将跨模态注意力的开销移出了搜索循环。

3.4 灵活的深度选择

解码器支持在加载时选择2到8层之间的深度，每个深度都是独立训练的模型，而非推理时切层。编码器从不解剖：八个块在任何深度下都完整运行。这给了开发者在精度和速度之间灵活取舍的空间——低功耗设备选浅层，性能充裕的设备选深层。

四、性能实测：和主流模型横向对比

以下对比数据来自Cactus官方基准测试及第三方实测验证，在Apple M4 Pro CPU上运行10秒音频。

数据来源：

在精度方面，Whistle在LibriSpeech test-clean、SPGISpeech、Earnings-22和FLEURS平均上取得了领先的WER表现，但在TED-LIUM、AMI和MLS平均上落后于Whisper base。这种“各有胜负”的格局是合理的——Whistle用16.9MB的体量在多个核心基准上追平甚至超越了一个大它8.6倍的模型。

一个值得注意的细节是延迟随音频长度的变化模式。Whisper因为将输入始终填充到30秒，首token延迟是一条平线，不随音频长短变化。Whistle的延迟跟随片段长度：5秒音频时5.9毫秒，10秒时11.1毫秒，30秒时36.3毫秒。对于短语音场景（如语音指令、语音备忘录），Whistle的延迟优势更加明显。

五、与Needle共用引擎：一个二进制做两件事

Whistle与Cactus自家的文本模型Needle共用同一套C++推理引擎、同一份量化格式、同一个.cact容器。这意味着已经运行Needle的设备不需要引入第二个运行时，把whistle.cact放到同一目录即可工作。

更深层的意义在于架构层面的复用。解码器模块与Needle完全一致，只是层数不同——它们共用代码，而非复制后修改。这种设计哲学使得一个二进制文件可以同时完成语音转文字和文本到工具调用的全过程。官方文档中给出的示例很直观：./needle --model whistle.cact --audio clip.wav，一个命令把音频片段直接变成结构化的工具调用。

对于嵌入式开发而言，这意味着固件体积的显著节省和系统复杂度的降低。一个引擎，一份量化工具链，一套部署流程。

六、七个语言的选择逻辑与中文缺席

Whistle支持英语、德语、法语、西班牙语、意大利语、荷兰语和波兰语。这个语言列表反映了Cactus Compute的市场判断：欧洲主要语言优先覆盖，这些语言在汽车、工业设备和消费电子出口市场中覆盖面最广。

中文目前不在支持列表中。考虑到中文语音识别市场的竞争格局——国内已有多个成熟的商业API和开源方案——Cactus选择先覆盖欧洲语言、再考虑中文的策略是可以理解的。从技术架构看，Whistle的词表包含8192个文本片段加上七个语言token，扩展到中文需要重新训练词表和调整tokenizer。

从中文开发者的角度看，Whistle的价值目前更多体现在技术参考层面：它的架构设计思路、量化策略、跨模态注意力缓存方案，都值得国内做端侧语音识别的团队研究和借鉴。

七、隐私优先的工程范式

Whistle的全部处理在本地CPU完成，不产生任何网络请求。这个特性在特定场景下具有不可替代的价值。

一位开发者在社区分享了他的使用案例：用Whistle接管了家里的Echo Show智能音箱，所有语音处理在本地CPU完成，完全不再连接亚马逊服务器，识别结果直接接入Home Assistant做家庭自动化。另一位开发者在Hacker News讨论中提到，Whistle在英语上的识别准确率令人意外地好，体积小到足以嵌入键盘、网页应用和低功耗硬件。

在免费容器部署场景中，Whistle的优势同样明显。Railway平台上已经有用户将Whistle部署为语音转文字API服务，因为Whisper的数GB内存占用无法适配免费容器的资源限制。

这些案例揭示了一个更宏观的趋势：语音识别正在从“调用云端API”转向“本地内置能力”。当模型小到可以随应用一起分发时，隐私、延迟、成本这三个维度的优势会同时释放。

八、深度见解：语音AI的“晶体管时刻”

8.1 从规模竞赛到效率竞赛

过去几年语音AI的主线是“更大、更强、更多语言”。Whistle代表了一条不同的路径：不是追求SOTA精度，而是在可接受的精度范围内实现极端的效率。16.9MB这个数字的意义不在于它比谁小，而在于它跨过了一个心理阈值——小到可以嵌入任何有CPU的设备，小到不再需要权衡部署成本。

当模型的存储占用从数百MB降到十几MB时，部署决策的逻辑发生了质变。过去是“这个设备有没有足够的资源跑语音识别”，现在是“既然不占地方，为什么不加上”。这种从“可选功能”到“默认能力”的转变，才是Whistle真正的冲击力所在。

8.2 非因果注意力的取舍智慧

Whistle选择非因果注意力编码器，这是一个有意识的取舍。流式识别需要因果注意力来支持逐帧输出，但Whistle的目标场景是30秒以内的短音频片段——语音指令、语音备忘录、短消息。在这个场景下，全局注意力带来的精度提升远大于流式能力的缺失。这种“明确不做什么”的设计克制，比“什么都能做”更有工程判断力。

8.3 端侧模型的生态杠杆

Whistle与Needle共用引擎的设计，展示了一种被低估的竞争力：生态协同。单个模型再优秀也只是工具，但当语音模型和文本模型共享同一套推理引擎、同一套部署工具、同一份量化格式时，它们构成了一个平台。开发者选择Whistle不仅是因为它小，更是因为它能无缝接入已有的Needle工作流。这种生态粘性在开源社区中的影响力可能比模型精度本身更持久。

8.4 对行业的启示

Whistle的出现说明，端侧语音识别已经进入了一个新的阶段。前几年的端侧模型更多是“能跑就行”，精度妥协较大。Whistle在16.9MB的体积下，在多个核心基准上追平了145.3MB的Whisper base，这说明“小”和“准”之间的权衡曲线正在被重新绘制。

对国内开发者的启示在于：端侧语音识别的技术路线已经不再是简单地把云端模型压缩，而是需要从架构层面重新设计。Whistle的卷积降采样、门控交叉注意力缓存、可调解码深度等设计，都指向一个方向——为端侧场景量身定制的架构，比压缩通用架构更有效。

九、快速上手

安装只需一行命令：pip install cactus-needle。基础安装支持16kHz WAV或原始采样数据，其他采样率和麦克风采集需要额外安装[mic]扩展。

基本使用流程非常简洁：导入needle库，调用transcribe方法传入音频文件路径，返回包含文本、检测语言、首token延迟和解码速度的结果字典。首次调用会下载并缓存模型文件，缓存后的模型文件大小为16,919,407字节，与官方标称的16.9MB完全吻合。

对于需要关键词偏置的场景，Whistle支持传入用户常说的名称、地点和产品词，通过Aho-Corasick自动机在束搜索过程中提升这些词的解码概率。这在语音指令场景中尤为实用——确保设备名、人名等关键实体不被识别错误。

FAQ

Whistle和OpenAI的Whisper是同一个模型吗？

不是。Whistle是Cactus Compute于2026年10月发布的独立语音识别模型，与OpenAI的Whisper没有技术继承关系。两者是竞争关系，Whistle在体积上仅为Whisper base的约九分之一。

Whistle支持中文吗？

目前不支持。Whistle支持英语、德语、法语、西班牙语、意大利语、荷兰语和波兰语七种语言，中文尚未在支持列表中。

16.9MB的模型精度够用吗？

取决于场景。在LibriSpeech test-clean、SPGISpeech、Earnings-22和FLEURS基准上，Whistle的WER优于Whisper base；在TED-LIUM、AMI和MLS上略逊。对于语音指令、短消息转写等常见端侧场景，精度是足够的。

能在手机上运行吗？

可以。Whistle设计目标就是手机、可穿戴设备、机器人、智能家居和微控制器。它只需要CPU，不需要GPU，不需要网络连接。

Whistle是免费的吗？

Whistle采用Apache 2.0许可证开源发布，可自由使用和修改。

如何参与贡献或获取支持？

模型权重托管在Hugging Face平台的Cactus-Compute/whistle仓库中，推理引擎和平台适配代码在GitHub的cactus-compute/needle仓库中，可通过标准开源协作流程参与。

Whistle和THU-SPMI的Whistle有什么关系？

两者是不同的项目。清华大学THU-SPMI实验室有一个同名的多语言语音识别研究项目（Conformer编码器+CTC训练，模型大小90MB-543MB），与Cactus Compute的Whistle在架构、体积和目标场景上完全不同。搜索时需要注意区分。

静音或嘈杂环境下表现如何？

Whistle在静音时会返回空转写而非编造内容。引擎在解码器启动前测量音频响度，低于阈值直接返回空结果。嘈杂环境下的表现取决于信噪比，官方未公布专门的噪声鲁棒性基准数据。