音频进去，工具调用出来：Whistle 只有 16.9 MB，比 Whisper base 小 8.6 倍

我们对语音转写早就默认了三件事：得联网，得盯着一个进度条，得按分钟付钱。三件事摞在一起，无数个”给产品加个语音控制”的需求，是在评审会上被自己人砍掉的。

烦就烦在等：转写从来不是终点

先说结论：Whistle 的价值在转写之后的那三步。

转写出来的那行字本身没有用。你要的是后面的事，把这句话变成一次关灯、一条工单、一次数据库查询。

传统做法是四个人传话。第一个人把声音写成字，第二个人把字擦干净塞进提示词，第三个人拿着提示词去问模型，第四个人把模型回的那坨东西解析成能直接执行的结构。每传一次就漏一点东西，每传一次多一段网络往返。最先阵亡的是专有名词，客户名字、产品型号、街道名，传完一圈已经改了姓。

Whistle 的思路不是把第一个人训练得更准，是把后三个人请走。

先说清楚：Whistle 到底是个什么东西

它是一个能塞进固件里的语音识别模型，不是一个云端服务。这句话是后面所有判断的地基。

Whistle 由 Cactus Compute 出品，2026 年 10 月 2 日发布。整个东西是一个 16.9 MB 的文件，纯 CPU 跑，零外部依赖。输入要求很朴素：16 kHz 单声道，一次最多 30 秒。

语言支持七种：英语、德语、法语、西班牙语、意大利语、荷兰语、波兰语。默认自动检测，也可以直接写 language="de" 这类参数强制指定。

中文不在里面。这句我放在第二章就说破，免得你读完两千字才发现白高兴。如果你的全部场景是中文转写，现在就可以关掉这篇，去看之前写的 VibeASR.cpp 那篇本地 CPU 转写文章，那条路子对中文更友好。

三步跑通：装包、一行转写、三个真有用的参数

安装就一行命令，包名是 cactus-needle，当前版本 3.1.3，别去找别的名字。

pip install cactus-needle

转写也只要一行。

import needle

print(needle.transcribe("clip.wav")["text"])
# turn off the kitchen lights

这里有个容易忽略的点：返回值不是只有一行字，还有四样东西，分别是转写文本、检测到的语言、首 token 毫秒数、之后解码的 tokens/秒。后两个是做容量规划时要盯的，别浪费它们。

三个值得动手的参数，用好了能顶一半后处理代码。

word_timestamps=True：返回每个词的 start / end / probability，做字幕、做高亮、做质检都要它。
keywords=[…]：关键词偏置，把你给的名字、地名、产品词在解码时加权，小模型就不再把专有名词念错。
language=”xx”：自动检测偶尔会摇摆，明确语种的场景直接指定，省得猜。

另外几个入口知道存在就行：needle.Whistle() 是同一个模型的对象形式，用来 embed(audio) 取语音向量，或者持有一份调过的 .cact；needle.stream(chunks) 做实时流式转写，它两遍结果一致才提交一个词；命令行里 needle whistle playground 从麦克风直接转写，needle whistle compare 把 Whistle 和 Whisper、Moonshine 放在同一段音频上一起打分。还有一个偏工程的开关，--audio-depth N 让解码器只跑 N 层，同一份权重换一档算力。

四步流水线压成一次调用：Whistle 与 Needle 共用同一个 C++ 引擎

别盯着转写：音频进去，工具调用出来

这是整件事最值钱的一节，也是最容易被人滑过去的一节。

同一家厂商还有一个叫 Needle 的工具调用模型，8 到 29 MB。官方的说法是，它 121M 参数的那个版本，做的运算量只相当于一个 50M 模型。真正的关键在下一句：Whistle 和 Needle 共用同一个 C++ 引擎、同一个 .cact 容器、同一套量化。

共用意味着可以这样调用：

needle --model needle3.cact --model whistle.cact --tools tools.json --audio clip.wav

返回的是单个 JSON 对象。工具调用在里面，语音相关的字段也在里面，后者统一带 audio_ 前缀。转写文本全程留在引擎内部不外泄，也不需要你转手。

四步流水线，压成一次调用。

这里有个细节我觉得比体积更重要：解码会偏向你 schema 里枚举过的选项值。音频里说到的那个值，会按你 schema 的拼写被转写出来。你在 tools.json 里写的是 "kitchen"，它就不会给你写成 “kichen”。这一步过去要靠提示词工程加一堆纠错规则硬凑。

整台引擎对外只有三个 C 函数：needle_load、needle_transcribe、needle_embed。三个函数，两个模型，一进一出。想在手表或者树莓派上放一个听懂人话的 Agent，这份 API 短到你当天就能读完，这一点我在写 MiniCPM5-2B 那篇端侧 Agent 文章时还没敢想。

两个小细节：决定它能不能上线

参数表上的东西看一眼就会，把 demo 和生产分开的是这两条。

关键词偏置是刚需，不是彩蛋

小模型念错专有名词是常态，算不上 bug。keywords=[...] 做的事很直接，在解码阶段把你给的名字、地名、产品词加权。做之前，客户名和产品型号全靠事后纠错；做完之后，那段纠错代码基本可以删掉。值不值得用取决于一件事：你的词表是不是稳定的。

遇到静音它闭嘴

Whistle 碰到静音和稳态噪声，返回的是空转写，不会硬编一句话出来。看着不起眼，这条其实是能不能挂在常开麦克风上的前提。一个会脑补的模型，你永远不敢让它二十四小时开着。

四个坑：中文、30 秒、会议、厂商自测

限制都写在明面上，我把它们按杀伤力排个序。

坑 1：中文不在列表里

现象是喂中文进去得不到可用的中文文本。根因很简单，官方支持的七种语言里没有中文，跟模型大小无关。解法也简单，中文场景别选它，换别的方案。

坑 2：一次只有 30 秒

现象是长音频放进去，超出部分不处理。根因是模型输入窗口的上限就是 30 秒。解法是切片，逐段转写再拼接。切片这里有个讲究，按静音切能保证词不被切断，硬按秒数切一定会切坏一些词。

坑 3：会议录音别用它

现象是多人录音质量明显下滑。根因是它不做说话人分离，官方给的数据是会议场景准确率约 74%，在 AMI 测试集上落后 Whisper base。解法是访谈、例会、圆桌这类音频走别的路线，别硬上。

坑 4：数字全是厂商自测

现象是速度和准确率都很漂亮。根因是口径由厂商自己定，单机型 Apple M4 Pro，各家官方 runtime 的默认设置，没有第三方复现，对比对象还是 Whisper base，更大的 Whisper 模型准确率远高于 base。解法是把这些数当成”值得自己跑一遍”的信号，不要当成结论。

16.9 MB 的分量：它面向的是手表、车机、树莓派和浏览器

别急着高潮：16.9 MB 的分量，和一张五胜三负的成绩单

16.9 MB 不是压缩魔术，它是一个信号：这个模型被设计成设备的一个输入层。

跟 Whisper base 的 145.3 MB 比，小了 8.6 倍，首 token 快 6.6 倍。这两个数是一套的，体积小才敢常驻内存，常驻内存才有可能做输入层。

速度这块，厂商给的是 10 秒音频在 Apple M4 Pro 上的成绩：Whistle 首 token 11.1 ms，之后 1319 tokens/秒。同场对比，Whisper base 是 73.2 ms、266 tokens/秒，Moonshine tiny v2 是 22.8 ms、262 tokens/秒。

还有一个数很讨喜：首 token 时间跟着片段长度走，5 秒是 5.9 ms，10 秒是 11.1 ms，30 秒是 36.3 ms。它不把音频补齐到 30 秒，你说得短，它就花得少。

准确率方面，厂商用 Whisper 自己的 normalizer 在完整测试集上打分，总共 86,174 条语音。这个口径比抽样评测体面。

赢的五个：LibriSpeech test-clean、LibriSpeech test-other、SPGISpeech、Earnings-22、FLEURS 平均。输的三个：TED-LIUM、AMI、MLS 平均。

五胜三负，离碾压差得远。读这张成绩单的正确姿势是：它在朗读式、单人、有稳定领域词汇的音频上很强；到了演讲、多人会议、多说话人平均的场景，还打不过 Whisper base。

部署面是它最不张扬的优势。引擎预编译覆盖 17 个目标，macOS、Linux、Android、iOS、watchOS、Windows on ARM、RISC-V、MIPS、浏览器（WASM）、WASI 都在名单里。权重和平台引擎在 huggingface.co/Cactus-Compute/whistle，演示和架构说明在 cactuscompute.com/whistle。授权这块，按公开资料是 Apache 2.0、商用无收入上限，具体以官方发布的 LICENSE 为准。