2026 年 11 月 6 日，AI 初创公司 Underdog 发布了一款标称体积仅 32MB、参数量 3100 万的端侧文本转语音（TTS）模型 Woof。为了证明它能彻底脱离云端，官方直接做了一个复古科技风的网页游戏，用户在浏览器里敲击虚拟打字机、拧动调音器，断网状态下就能实时朗读文本并生成音乐。这看起来像是端侧 AI 的又一次轻量化胜利，但拆开官方模型卡和社区独立评测就会发现，32MB 只是吸引眼球的下载包大小，它在 CPU 上的峰值运行内存最高飙到了 852MB，且热启动首音延迟长达 1.39秒。
搜这个模型的开发者最关心三件事：它到底有多轻、和现有的开源方案比强在哪、能不能直接拿来商用。答案很直接：它的声音自然度确实拿到了同类最高分，但代价是响应速度垫底、词错误率偏高，且绑着非商业许可协议。
32MB 的数字障眼法与非商用门槛
端侧模型最喜欢拿硬盘占用做文章，因为数字越小越容易传播。Underdog 标称的 32MB 对应的是单音色浏览器版本，实际下载体积为 31.7MB（参数量 3070 万），而支持双音色的可下载版本体积为 40.6MB。
真正决定一台设备能不能流畅跑起来的不是硬盘体积，而是运行时吃掉多少内存（RAM）。根据 Hugging Face 官方模型卡数据，31.7MB 的单音色版本在 CPU 上运行时，峰值内存高达 852MB；反倒是 40.6MB 的双音色版本做了优化，CPU 峰值内存控制在 402MB（在 M5 Max 单线程下吞吐量为 13.8 倍实时，单音色版为 18 倍实时）。把 31.7MB 的下载体积宣传成超轻量级，却对近 1GB 的内存峰值避而不谈，很容易让开发者错估硬件门槛。
更直接的限制在授权协议上。创始人 Sigil Wen 在宣言中反复强调打造开放模型，但 Woof 并非真正意义上的开源。官方最初公告采用 CC BY-NC 4.0 协议，而在 Hugging Face 模型卡上则标注为 Underdog Non-Commercial 1.0。无论哪个版本，核心都是非商业许可，企业或独立开发者无法直接把它免费集成到商业产品里。
独立跑分拆解：用响应速度换声音自然度
在端侧 TTS 赛道，Woof 面对的是 Piper、Kokoro、KittenTTS 等早已跑通的轻量级对手。端侧语音合成永远在体积、延迟、吞吐量和自然度之间做取舍，没有全能冠军。
把 Woof 放进社区独立基准测试 tts-bench（测试环境为 Ryzen 9 9950X3D 的 Windows CPU 后端）横向对比，它的技术取舍一目了然：
| 模型名称 | 首音频延迟 | 实时吞吐量 | 峰值内存 | 自然度 (UTMOS) | 词错误率 (WER) |
|---|---|---|---|---|---|
| Woof (双音色) | 1390 毫秒 | 6.25x | 258 MB | 4.442 | 8.2% |
| Piper | 107 毫秒 | 58.83x | 470 MB | 3.877 | 5.5% |
| KittenTTS Nano 0.8 | 288 毫秒 | 31.41x | 537 MB | 4.167 | 4.4% |
| Kokoro (82M) | 532 毫秒 | — | 1.82 GB | 4.177 | 5.4% |
从这张表能看出两个关键事实。
Woof 的优势在于声音足够好听。它的预估自然度得分（UTMOS）达到 4.442，在四款模型里排第一，且双音色版本在该测试环境下的内存压到了 258MB。如果用来做本地播客生成、长文朗读这类对延迟不敏感的任务，它的听感明显优于机械感较强的早期小模型。
但它的短板同样突出。在需要即时反馈的语音助手场景里，1.39秒的热启动首音频延迟会带来明显的对话卡顿，而老牌方案 Piper 只需要 107毫秒，几乎是秒回。同时，Underdog 官方在 500 个难例句子的自测中宣称词错误率（WER）仅为 1.42%，但在独立测试的共享提示词下，其 ASR 词错误率高达 8.2%，咬字准确度在四款模型中垫底。
- 建议.做网页端静态文本朗读或个人非商用玩具，可以优先尝试 Woof 的高自然度音色；如果是开发商业级本地语音交互界面，107 毫秒延迟的 Piper 或 15M 参数的 KittenTTS Nano 0.8 仍是更务实的工程选择。
反云端阳谋与硬件边界的冷思考
为什么一家初创公司要花大力气做浏览器里的复古打字机游戏？游戏开场白其实把话说透了，它直接弹窗警告小镇上存在侵入式的云服务商。
拿隐私当矛去刺云端巨头，最后还得由用户手里的旧硬件来买单。
Sigil Wen 创业的直接动因，是不想再用 Granola 这类依赖云端处理的 AI 会议记录工具。为了把数据所有权留在本地，Underdog 在过去几周里密集交出了三块拼图：负责听的端侧语音转文本模型 Bark（早期报道为 167MB，最新 Bark 3.0 模型卡体积为 163MB）、负责思考的 27B 本地大模型（通过 4-bit 量化权重塞进笔记本电脑运行），以及这次负责说的 31.7MB 语音合成模型 Woof。
这套组合拳拼齐了全本地的语音交互链路，直指 Muse、Instinct 和 Granola 等云端效率工具。这很像早期个人电脑对抗大型机分时系统的历史重演——每次算力向云端集中到极致，总会有人举起隐私和私有化的旗帜往终端回撤。
但今天的情况和 PC 时代不完全一样，因为移动终端的物理功耗墙摆在那里。
《孙子兵法》讲，辎重捐则军无财。端侧模型为了甩掉云端服务器的辎重，极力压缩参数体积，结果往往在真实终端算力前露怯。Sigil Wen 预言几个月内就能在人们现有的设备上跑起当今最强的模型，但现实硬件数据要骨感得多。在真实的旧款手机（Galaxy S10）独立测试中，轻量级标杆 Piper 的中位合成时间为 478 毫秒，15M 参数的 Kitten Nano v0.2 慢到了 3526 毫秒，82M 参数的 Kokoro v0.19 更是高达 8226毫秒。
在桌面端顶级处理器 Ryzen 9 9950X3D 上首音延迟尚且需要 1.39 秒的 Woof，至今还没有交出旧款移动设备上的独立验证数据。浏览器里的复古打字机确实很酷，但决定 Underdog 候补名单里那款本地应用生死的，不是桌面浏览器的演示效果，而是当这三款模型同时塞进普通人的旧笔记本和手机里时，风扇转不转得动、电池撑不撑得住。