Whistle：16.9MB 的语音识别，11 毫秒开口说话
Cactus 发布端侧语音识别模型 Whistle：16.9MB、纯 CPU、首 token 11ms，多项榜单超越 Whisper base。访谈聊小模型的工程取舍、HN 评论区的幻觉与流式之争，以及语音直达工具调用的新玩法。
这周 HN 上最热的技术帖之一，来自一家叫 Cactus 的小公司：他们发布了一个叫 Whistle 的语音识别模型，整个模型只有一个 16.9MB 的文件，跑在 CPU 上无任何依赖，首个 token 11 毫秒就出来。帖子拿了 500 多分、100 多条评论，评论区从 benchmark 打到幻觉，从 Parakeet 打到口音问题，相当热闹。我请来老朋友林跃——在一家做端侧推理的公司负责模型压缩和部署，Whisper、Moonshine、Parakeet 他都亲手跑过。我们聊了聊 16.9MB 是怎么做到的，HN 评论区吵的几个点到底站不站得住，以及一个被低估的杀手场景。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 林跃，先给没看原文的人一句话：Whistle 到底是个什么东西，凭什么能上 HN 首页第一？
林跃： 一句话：它把 Whisper base 干的活，塞进了一个 16.9MB 的文件里，还更快。Whisper base 是 145MB，Whistle 是它的九分之一；在 LibriSpeech、SPGISpeech、Earnings-22 几个榜上词错率反而更低；十秒音频在 M4 Pro 的 CPU 上，首 token 11 毫秒，解码速度每秒 1300 多个 token，是 Whisper 的五倍。评论区最高赞之一说得很到位：这么小，可以整个塞进 CPU 的 L3 缓存里，做成常开的 always-on 功能。这就是它上首页的原因——不是又一个大模型，是"小"本身成了新闻。
小听： 16.9MB 这个数字确实反直觉。语音识别这两年给人的印象是越大越准，Whisper 一路做到 large-v3。Whistle 的架构有什么不一样？
林跃： 它走的是"小而专"的路子。前端是经典的 16kHz 单声道、80 维 log-mel 频谱；编码器是 8 个轻量注意力 block，用了一种叫 Monarch Hadamard 的结构代替标准前馈网络，省参数；解码器做了个有意思的设计叫 ladder——从 2 层往上每一层深度都被当成独立模型训练过，加载时可以用一个参数选解码器跑几层，编码器永远全量跑。简单说就是：精度和速度的旋钮交给了部署的人，手机上手表上都能调。
小模型的艺术，是把每一 MB 都花在刀刃上。
小听： 评论区第一盆冷水泼得挺准：有人拿它转了一集电视剧，模型时不时会卡住，反复输出"Thank you."，长达 60 秒的对话全变成谢谢——这不就是 Whisper 的老毛病吗？
林跃： 对，这就是自回归解码器的经典幻觉，Whisper 用户太熟了：静音段或低置信度时模型塌缩到高频短语上。Whistle 其实做了针对性处理——引擎会在解码前测整段音频的响度范围，低于阈值直接返回空转录，连 beam search 都不进。但电视剧这种"有声音但模型听不懂"的中间地带，静音检测救不了，beam search 还是会塌。评论区这个反馈的价值在于提醒一件事：榜单上的词错率，和真实世界的"不翻车率"是两回事。
小听： 第二盆冷水是关于流式的：网页 demo 只能录完一段再出结果，没有边说边出的实时字幕。有人说这是通用语音 App 的刚需，也是他继续用 Deepgram 云端服务的原因。
林跃： 这个批评打中了，但要分两层看。Whistle 的架构里注意力是非因果的——3 秒的帧可以 attend 到 12 秒的帧，这种双向结构天生不适合严格流式，它瞄准的是"30 秒以内一遍过"的场景：语音备忘录、会议片段、语音指令。而 Deepgram 那种云端流式，拼的是网络延迟和运维。小模型的真正战场不在"替代云端流式"，而在云端到不了的地方：没网的工厂、要过隐私合规的医疗录音、手表和 MCU。用云端标准要求端侧模型，属于拿错了尺子。
小听： 评论区还有一组经典对比：Parakeet。有人说 Parakeet 是精度上的金标准，但想把它嵌进自己的 App 里特别痛苦，各种 ONNX、whisper 实现不统一；而 Whistle 这类小模型"开箱即嵌"，能达到 80% 的效果。这 80% 的说法你认吗？
林跃： 认，而且这 80% 恰恰是产品意义所在。Parakeet 精度高，但它是个研究向的发布，部署是开发者的脏活；Whistle 反过来，模型、引擎、C API、pip 包、十七个平台的预编译二进制全给你铺好了，pip install 就能转写。开发者真正要的不是榜单第一，是"周五下午能跑起来"。16.9MB 的另一个含义是分发成本：嵌进 App 包体积几乎无感，OTA 更新一次喝杯咖啡就下完了。大模型拼的是上限，小模型拼的是"被用起来的概率"。
小听： 有条评论我印象很深，有人说语音转文字真正的挑战从来不是体积，是他 84 岁中风后的父亲——口齿不清，Windows 自带语音输入倒是能用了，但每一声咳嗽叹气全被写进文档。这让我想到：我们是不是一直在优化错误的目标？
林跃： 这条评论是全场最有分量的一条。它点出了转录（transcription）和听写（dictation）是两种产品：前者要一字不差，后者要"把嗯嗯啊啊吞掉、把口误自动修正、把标点听出来"。Whistle 这类通用 STT 模型做的是前者，而那位父亲需要的是后者。技术圈有个老毛病：把"体积小、速度快"当成普适的进步，但用户要的是"别把我爸的咳嗽写进自传"。模型能力曲线的形状，决定了它服务谁——Whistle 的形状是"快、轻、可嵌入"，它的用户是开发者，不是那位父亲。认清这一点，才能把模型放到对的位置。
小听： 语言支持也是个槽点：只支持英、德、法、西、意、荷、波七种语言，有人试了日语直接被转成乱码西班牙语，西班牙语用户自己都吵起来了——马德里的说挺好，墨西哥的说检测不对。
林跃： 7 种语言、8192 的词表，这就是 16.9MB 的代价：容量就这么多，每加一种语言都是从别处抢来的。西班牙语那个争论特别典型——"西班牙语"不是一种口音，卡斯蒂利亚、墨西哥、委内瑞拉在声学上差很多，小模型的容量先扛不住的就是方差大的语言。好消息是它的语言是作为 token 检测的，架构上加语言不难；坏消息是，在体积约束下，"支持"和"好用"之间永远有 gap。中文用户先别急，排队去吧。
小听： 聊点乐观的。原文里我最喜欢的其实不是模型本身，是那个"一个二进制干两件事"的设计：同一个 C++ 引擎，同时加载 Whistle 和他们家的文本模型 Needle，对着麦克风说"关掉厨房的灯"，直接返回一个 function call 的 JSON。语音到工具调用，中间没有转写文本经手。
当语音不再经过云端，指令就成了本地函数。
林跃： 这才是 Whistle 真正的野心。传统语音助手链路是：STT 云服务 → 文本 → LLM API → 工具调用，三次网络往返，延迟、费用、隐私全是坑。Whistle+Needle 把整条链压进一个本地二进制：音频进去，JSON 出来，audio_text、audio_language、confidence、function_calls 一次给齐。对智能家居、车机、机器人这种场景，这是质变——断网也能用，延迟从秒级降到毫秒级，隐私合规天然通过。16.9MB 的 STT 在这里不是主角，是让"端侧语音智能体"闭环的最后一块拼图。
小听： 最后一个问题，给中文开发者一句实用的：Whistle 这类模型，什么情况下值得动手试，什么情况下别浪费时间？
林跃： 三种情况值得试：第一，你在做需要离线语音的硬件或 App，手表、车机、会议盒子，16.9MB 塞进去无压力；第二，你想做"语音直达功能"的端侧智能体，它的 tool call 链路是现成的；第三，你在乎隐私合规，音频不出设备是最好的合规故事。三种情况别碰：要做中文——现在还没支持；要做长音频流式会议转写——30 秒上限和"Thank you."幻觉会教你做人；要服务口音很重或发音障碍用户——先去看听写类方案，别指望通用 STT 救场。一句话：小模型不是大模型的缩水版，是另一种物种，别用旧尺子量它。
Whistle 最大的意义可能不在 16.9MB 这个数字，而在它证明了一件事：语音识别的"够用线"正在快速下移。当一个塞进 L3 缓存的模型能在常用榜单上打平 145MB 的 Whisper，端侧语音就从"将就着用"变成了"默认选项"。云端 STT 不会消失，但"先问本地行不行"会成为越来越多架构评审的第一个问题。本文观点仅代表访谈角色设定，原始讨论见参考链接。