Microsoft 今年 1 月发布的 VibeVoice，正在被开发者拿来验证一个很现实的问题：本地机器能不能可靠转写长播客、访谈和会议录音。开发者 Simon Willison 在 Mac 上用 uv、mlx-audio 和 4bit MLX 版本跑通了一小时播客，给出的结果是：能用，而且速度已经接近生产场景；但硬件门槛和长度限制也很明确。

这件事重要的地方，不在于又多了一个开源 ASR 模型，而在于它把两个过去常常分开的能力放在了一起：speech-to-text 和内置 speaker diarization。也就是说，模型不只生成文字，还能给片段打上 speaker_id。对需要处理敏感访谈、内部会议或播客素材的人来说，本地推理意味着录音不必先上传到云端。

VibeVoice 已经能做本地长音频转写，但不是低配机器的活

VibeVoice 是 Microsoft 发布的 Whisper 风格语音转文字模型，采用 MIT 许可。Willison 这次没有直接使用约 17.3GB 的 microsoft/VibeVoice-ASR，而是使用 Hugging Face 上 mlx-community/VibeVoice-ASR-4bit，模型约 5.71GB，更适合 Apple Silicon 上的 MLX 推理。

他的命令核心参数包括：--model mlx-community/VibeVoice-ASR-4bit、--audio lenny.mp3、--format json、--max-tokens 32768。测试机器是 128GB M5 Max MacBook Pro，一小时音频处理耗时 524.79 秒，约 8 分 45 秒。

项目实测数据对读者的含义
4bit MLX 模型大小约 5.71GB下载和本地部署成本可接受
原始 VibeVoice-ASR约 17.3GB量化版本明显降低门槛
一小时音频耗时约 8 分 45 秒高配 Mac 上已具备实用速度
工具报告峰值内存30.44GB不能按普通轻量工具理解
Activity Monitor 观察prefill 约 61.5GB实际内存压力可能更高

这个速度不能外推到所有 Mac。M5 Max、128GB 内存和 MLX 优化共同构成了测试条件。换成低内存 MacBook Air、Intel Mac 或未针对 MLX 优化的环境，体验可能完全不同。

JSON 和说话人标签让它接近编辑工作流

VibeVoice 的输出不是一整段文本，而是对象数组。每个片段包含 text、start、end、duration 和 speaker_id。Willison 还把结果放进 Datasette Lite 浏览，按 speaker_id 分面查看。

这对播客编辑、研究助理和开发者很实用。过去使用 Whisper 或云端转写服务时，说话人分离往往要额外接 pyannote.audio、AssemblyAI、Deepgram 等工具或服务。VibeVoice 把 diarization 放进模型本身，减少了后处理链条。

但 speaker_id 不是“认出某个人”。它只是把声音聚成不同说话人标签。Willison 的结果里出现了三个说话人：对谈中的两人，以及主持人在片头和广告口播中的另一种声音状态。这说明模型能区分声纹或音色变化，也说明用户仍要人工校对标签与真实人物的对应关系。

真正的限制在一小时、token 和切分对齐

当前 VibeVoice 不能直接处理任意长度音频。Willison 的原始播客约 99.8 分钟，工具提示超过约 59 分钟上限后会裁切，因此只转写了前一小时。

另一个容易踩坑的参数是 --max-tokens。不设置时默认 8192，大约只够 25 分钟音频。Willison 把它调到 32768，才覆盖一小时内容。这不是小细节，而是决定长音频是否完整输出的关键。

如果要处理两小时会议或完整播客，现实做法仍是切分音频，最好保留约一分钟重叠，避免切点处词句被截断。随后还要把多个片段里的 speaker_id 对齐；第一段的 speaker 0，不一定等于第二段的 speaker 0。

横向看，Whisper 的优势仍是生态成熟、部署经验多；云端转写服务的优势是省硬件和省维护。VibeVoice 的位置更像一条折中路线：愿意折腾本地工具链、又在意隐私和成本的开发者，会先受益。企业要把它放进正式流程，还得看稳定性、批处理能力和跨硬件表现。