全部 · 2026-04-29

VibeVoice-ASR 这次把一小时播客压到 8分45秒，但门槛也被 61.5GB prefill 峰值钉死了。 我对这条的判断挺直接：它不是 Whisper 的普通替代品，而是把“转写、分离说话人、时间段结构化”塞进一个 9B 模型后的第一批可用形态。Simon Willison 跑的是 4-bit 社区量化版，文件 5.71GB，原模型 17.3GB，机器是 128GB 内存的 M5 Max MacBook Pro。这个组合转写 1 小时播客耗时 8分45秒，生成阶段内存约 18GB。听起来很漂亮，但 prefill 峰值冲到 61.5GB，已经把 32GB 笔电排除在外。很多本地 AI demo 最后都死在这里：模型权重看着小，KV cache、长上下文音频 token、prefill 临时张量一起上来，真实门槛比下载页面高一档。 这和 Whisper 的差异很关键。OpenAI Whisper 当年强在鲁棒性和分发，large-v3 大概 1.55B 参数，社区围绕 faster-whisper、whisper.cpp、mlx-whisper 做了大量优化。可 Whisper 自己不解决 diarization。实际生产里要接 pyannote、WhisperX 或自研 VAD 和对齐模块。VibeVoice-ASR 的卖点是单次处理 60 分钟音频，还直接输出“谁在说、什么时候说、说了什么”。对播客、访谈、会议纪要，这个机制比单纯 WER 低几个点更值钱。正文没披露 WER、CER、多语言分项，也没给和 Whisper large-v3、NVIDIA Parakeet、AssemblyAI、Deepgram 的对照。没有这些数，我不会把它叫成“更强 ASR”。但我会把它看成一个更顺手的长音频工作流模型。 有意思的是它的错误形态。模型把两人对谈识别成三个说话人，因为 Lenny 的开场白和广告口播录音环境不同。这类错不新，diarization 系统一直会把音色、麦克风、房间混响当成人的边界。区别在于 VibeVoice-ASR 把这个问题藏进单模型输出里。传统拼接方案里，你至少知道 pyannote 在哪一步分错了，还能调阈值、聚类参数、VAD 切片。一个端到端输出看起来干净，调试空间反而小。对个人用户这没事，对媒体库、法务记录、医疗访谈这类场景就麻烦。正文没有披露说话人一致性指标，也没有说跨切片 ID 怎么合并。它单次最多 60 分钟，超过就要自己切片，再手动对齐说话人 ID。这说明“长音频”还没有真的进入无限流式状态。 我还会盯 MIT 协议这点。微软今年把 Phi、BitNet、VibeVoice 这类小到中等模型频繁放出来，策略跟 OpenAI 当年的 Whisper 不一样。Whisper 是一次性把 ASR 社区底座打穿，很多 SaaS 公司被迫把差异化挪到工作流、合规和 UI。VibeVoice-ASR 如果质量接近商用 API，它会先打到播客工具、字幕工具、采访整理工具的底层成本。1 小时音频 8分45秒本地完成，等于个人创作者可以在无云端上传条件下跑完初稿。可这个前提是 64GB 内存以上机器。苹果 M 系列统一内存给了它一个舒服落点，普通 Windows 笔电和公司发的 32GB MacBook Pro 不够。 我对“5.71GB 量化版就能跑”这种传播口径有点警觉。权重大小不是部署成本，特别是长上下文音频模型。这里最扎眼的数字不是 5.71GB，而是 max-tokens 要从默认 8192 手动调到 32768，否则只能覆盖约 25 分钟音频。这个细节说明模型把长音频转成了很长的生成序列，使用体验还带着研究代码味。普通用户不会知道为什么半小时后开始截断。工具开发者要把 token 预算、切片、重试、说话人合并全包起来，才算产品。 所以我不把它读成“本地 ASR 已经普及”。我更愿意给它一个克制的评价：本地长音频转写终于开始从拼管线走向单模型，但硬件门槛和可控性还没跟上。Simon 的实测很好，因为它把下载页不会写的东西暴露出来了：128GB 内存机器上很快，64GB 可能勉强，32GB 基本没戏；结构化说话人输出很香，但录音环境变化会制造假说话人；60 分钟上限够播客，够不上全天会议和呼叫中心批处理。对 AI 从业者来说，这条最实用的结论是：如果你在做音频产品，别只问 WER，先问峰值内存、切片策略、speaker ID 稳定性，以及默认 token 上限会不会坑掉用户。