VibeVoice:7.5Hz 帧率换来 90 分钟单遍语音
vibevoice
微软的开源前沿语音模型家族,仓库 microsoft/VibeVoice(MIT,54,531★,经 GitHub API 核)。它作为一条资产收录而不是拆成三条,因为 TTS、Realtime 与 ASR 共用同一个技术内核:声学与语义两个 tokenizer 都是连续的,帧率压到 7.5Hz。7.5Hz 是全部能力的来源——90 分钟音频在 25Hz 下是 135,000 个 token、进不了 64K 上下文,7.5Hz 下是 40,500 个,所以「单次合成 90 分钟」与「单遍转写 60 分钟」是同一件事的两个方向。五条产品线各有上限:TTS-1.5B 单次 90 分钟、最多 4 个说话人;Realtime-0.5B 首包约 300ms;ASR-7B 单遍 60 分钟、直接输出「谁 / 何时 / 说了什么」、支持自定义热词与 50+ 语言;ASR-Streaming 边说边出文本;ASR-BitNet 用异构量化把 4.62GB 压到 1.58GB、3+ CPU 线程 RTF < 1、不需要 GPU。ASR 那条线最值得记:传统长音频转写是切片、识别、分离、对齐四步串联,全局上下文在切片处就丢了,而 VibeVoice-ASR 把识别、分离与时间戳联合成一次生成,这对会议记录与客服质检是决定可用性的一项。架构是 next-token diffusion:LLM 管对话走向,diffusion head 管声学细节,长对话的轮次一致性是语言问题,交给 LLM 才拿得到 4 个说话人 90 分钟不串味。⛔ 有一条必须如实记录:2025-09-05 团队把 VibeVoice-TTS 的代码从仓库移除,原文说明是发现了与其声明意图不一致的使用实例;权重仍在 HF 但仓库 Quick Try 写着 Disabled、官方推理脚本不在仓库里,今天的 TTS 路径来自社区复现,模型页明写不建议未做进一步测试就用于商业场景。团队此后的公开动作全在 ASR 侧,所以可商用的一侧是 ASR 而不是 TTS。它在别人评测表里的位置也要如实转述:CosyVoice 3 的 README 列了它,test-zh CER 1.16 / SS 74.4、test-en WER 3.04 / SS 68.9,同表 CosyVoice3 base 是 1.21 / 78.0——短音频零样本克隆不是它的赛道,它该被比的三项是单次能生成多长、能不能保持 4 个说话人不串、能不能一遍处理 1 小时会议音频,这三项开源侧几乎找不到对手。边界:TTS 无官方推理路径;MIT 覆盖代码不覆盖模型页的使用限制;长音频的失败是全局的,90 分钟单遍没有坏一段重跑一段的补救面;官方在 Risks and Limitations 里点名深度伪造并要求披露 AI 参与。置信度 B(confirmed):确认的是帧率换算、各产品线公开上限、代码下架与许可边界这些可核对的文档事实,不是音质。
- 置信度
- 已确认
- ≥2 个独立来源,或经 harness 复现通过
- 关键指标
- 单次长音频上限(TTS 4 说话人 / ASR 单遍)
- 已确认 · 2026-09
- 成熟度
- 研究
- 研究 → 演示 → 产品 → 生产
编辑判断评为 B 档(confirmed),理由不是复现了 90 分钟长音频,而是这条结论有三重非同源证据:VibeVoice-TTS 技术报告被 ICLR 2026 接收为 Oral(第三方评审),VibeVoice-ASR 于 2026-03-12 进入 Azure AI Foundry Labs(第一方托管产品面,不是 demo 页),并在 2026-03-06 进了 Hugging Face Transformers 正式 release(第三方库集成)。仓库本身 54,531★、MIT 许可、最近一次 push 是 2026-09-03(经 GitHub API 核)。没有跑过一次 90 分钟合成,也没有复算 ASR 的 DER / cpWER,所以给不到 A 档。
它值得进音频域梯顶的理由与跑分无关,而是它把「长音频」这条别人绕开的轴做到了产品级。今天绝大多数 TTS 的单次上限在几十秒到几分钟,超长内容靠切片再拼,拼接点会出现音色漂移、韵律断裂与说话人错乱。VibeVoice 的做法是从帧率下手:声学与语义两个连续 tokenizer 都跑在 7.5Hz,于是 90 分钟音频只有约 4 万个 token(同样内容在 25Hz 下是 13.5 万、在 50Hz 下是 27 万),ASR 侧 60 分钟音频也能塞进 64K 的上下文里单遍处理。这不是工程 trick,而是把上下文预算换算成长度的第一性设计,也是它能一次合成 4 个说话人 90 分钟对话、一次转写 1 小时会议并给出「谁在什么时候说了什么」的物理前提。
选型时最该认清的一条是它的短音频跑分并不领先。FunAudioLLM 在 CosyVoice 3 的评测表里列了它:test-zh CER 1.16 / SS 74.4、test-en WER 3.04 / SS 68.9,VibeVoice-Realtime 的 test-en WER 2.05 / SS 63.3——相似度低于 CosyVoice3 的 78.0 / 71.8,英文错误率也明显更高。那张表出自竞争对手,方向上对 VibeVoice 不利,反而增加了它的可信度。结论是清楚的:要做几十秒的高保真音色克隆,不要选它;要做一小时以上的多说话人播客、有声书、长会议转写,它是开源里几乎没有对手的一档。
第二条必须如实写:2025-09-05 微软把 VibeVoice-TTS 的代码从这个仓库里移除了,官方说明是发布后发现了与其声明意图不一致的使用方式,仓库表格里 TTS 的 Quick Try 一栏至今写着 Disabled,权重仍留在 Hugging Face。这意味着今天要用 TTS 那条线,推理入口来自社区复现与 HF 权重,而不是官方维护的脚本;官方精力明显转到了 ASR(2026-01 发布、2026-07 出 BitNet 边缘引擎、2026-09 出流式版)。加上模型页明写「仅供研究与开发用途,不建议在未做进一步测试的情况下用于商业或真实场景」,以及它继承基座 Qwen2.5-1.5B 的偏见与错误,把它归在 research 成熟度档。可商用的一侧是 ASR,不是 TTS——这是这条资产最重要的边界,别被「微软开源语音大模型」的标题带过去。
它解决的问题:长音频是语音模型真正的上下文边界
VibeVoice 是微软的开源前沿语音模型家族,仓库 microsoft/VibeVoice(MIT,54,531★,最近 push 2026-09-03,本站经 GitHub API 核)。它的自我定位不是「又一个 TTS」,而是同时覆盖合成与识别两条线的一族模型:TTS 负责长音频多说话人合成,Realtime 负责流式低延迟,ASR 负责一小时级长音频的结构化转写。三条线共用同一个技术内核,这也是本站把它作为一条资产收录而不是拆成三条的原因。
它要解决的问题很具体:语音模型的上下文是按帧率烧掉的。一段音频要变成 LLM 能处理的序列,先得过 tokenizer,而主流语音 token 的帧率在 25Hz 到 50Hz 之间。把长度换算一下就明白为什么长音频一直是行业空白:
| 帧率 | 90 分钟音频的 token 数 | 60 分钟音频的 token 数 | 能否进 64K 上下文 |
|---|---|---|---|
| 50Hz(常见离散码本) | 270,000 | 180,000 | 否 |
| 25Hz(CosyVoice2/3 一档) | 135,000 | 90,000 | 否 |
| 7.5Hz(VibeVoice) | 40,500 | 27,000 | 是(60 分钟单遍) |
7.5Hz 是这条家族全部能力的来源。官方对它的设计说明是:声学与语义两个 tokenizer 都是连续的(不是量化成离散码本),在超低帧率下仍能保住音频保真度,同时把长序列的计算量压下来。有了这个前提,「单次合成 90 分钟」与「单遍转写 60 分钟」才是同一件事的两个方向,而不是两个独立的工程壮举。
三条产品线:各自的上限与延迟
| 模型 | 规模 | 能力 | 关键数字 | 官方入口状态 |
|---|---|---|---|---|
| VibeVoice-TTS-1.5B | 1.5B | 长音频多说话人合成 | 单次 90 分钟、最多 4 个说话人、支持跨语言与自发哼唱 | 权重在 HF;仓库内代码已于 2025-09-05 移除,Quick Try 标注 Disabled |
| VibeVoice-Realtime-0.5B | 0.5B | 实时流式合成 | 首包约 300ms、支持流式文本输入、长音频约 10 分钟 | HF 权重 + 官方 Colab 可跑 |
| VibeVoice-ASR-7B | 7B | 长音频结构化转写 | 单遍 60 分钟、输出「谁 / 何时 / 说了什么」、支持自定义热词、50+ 语言 | HF + Transformers 正式 release + Playground + 微调代码 |
| VibeVoice-ASR-Streaming | - | 边说边转写 | 音频到达即出文本(按 chunk 发),10 种语言,支持热词 | 2026-09-03 发布,含 vLLM 服务化文档 |
| VibeVoice-ASR-BitNet | - | 纯 CPU 边缘推理 | 异构量化 I8_S + I2_S 把 4.62GB 压到 1.58GB,3+ CPU 线程 RTF < 1,不需要 GPU | 2026-07-23 发布,VibeASR.cpp 引擎 + HF 权重 |
ASR 那条线的输出形态值得单独说一句。传统长音频转写的做法是切片 → 逐片识别 → 说话人分离 → 时间戳对齐,四步串起来,全局上下文在切片处就丢了,跨片的说话人编号会漂。VibeVoice-ASR 把 ASR、说话人分离与时间戳联合成一次生成,直接吐结构化结果,并且能吃用户提供的热词与背景信息(专有名词、人名、术语),这对会议记录、访谈整理、客服质检这类真实场景是决定可用性的那一项。
技术内核:next-token diffusion 与它的基座
架构上它是 next-token diffusion 框架:一个 LLM 负责理解文本上下文与对话走向(谁在说话、该接什么情绪),一个 diffusion head 负责生成高保真声学细节。分工的意义在于,长对话里的「轮次一致性」是语言问题而不是声学问题,交给 LLM 才拿得到 4 个说话人 90 分钟不串味的结果;而音色细节交给扩散头,才不必为了保真把帧率提上去。TTS 版本的基座是 Qwen2.5-1.5B,官方在风险声明里明确写了「继承基座模型的偏见、错误与遗漏」。
如实记录:2025-09-05 的 TTS 代码下架
这条必须写清楚,否则读者会按「微软开源的 90 分钟 TTS」去规划产品。仓库 News 里的原文说明是:VibeVoice 是一个面向语音合成社区协作的开源研究框架,发布之后团队发现了与其声明意图不一致的使用实例,由于负责任的 AI 使用是微软的指导原则之一,他们把 VibeVoice-TTS 的代码从这个仓库移除了。结果是:
- 权重仍在 Hugging Face(
microsoft/VibeVoice-1.5B),但仓库表格的 Quick Try 一栏写着 Disabled; - 官方维护的推理脚本不在这个仓库里,今天的 TTS 使用路径来自社区复现;
- 模型页明写「不建议在未做进一步测试与开发的情况下用于商业或真实场景,本模型仅供研究与开发用途」;
- 团队此后的公开动作全在 ASR 侧:2026-01 发布 ASR、2026-03 进 Transformers 与 Azure AI Foundry Labs、2026-07 出 BitNet 边缘引擎、2026-09 出流式版。
本站把这条资产归在 research 成熟度档、audio 能力域,同时把「可商用的一侧是 ASR」写进水位判断,就是为了避免这个落差。滥用风险不是抽象的:官方在 Risks and Limitations 里直接点名深度伪造与虚假信息,并要求使用者确保转写可靠、核对内容准确性、避免误导性使用、在分享 AI 生成内容时披露 AI 参与。
它在别人评测表里的位置
FunAudioLLM 在 CosyVoice 3 的 README 评测表里列了 VibeVoice,数字对 VibeVoice 不利,所以我们照原样转述:test-zh CER 1.16 / SS 74.4,test-en WER 3.04 / SS 68.9;VibeVoice-Realtime-0.5B 的 test-en WER 2.05 / SS 63.3。同表里 CosyVoice3 base 是 1.21 / 78.0 与 2.24 / 71.8,VoxCPM 是 0.93 / 77.2 与 1.85 / 72.9。短音频零样本克隆不是它的赛道,把它放在这个赛道上比是错的用法。它该被比较的维度是:单次能生成多长、能不能保持 4 个说话人不串、能不能一遍处理 1 小时会议音频——这三项上开源侧几乎找不到对手。
边界与失败模式
五条。TTS 无官方推理路径,依赖社区复现,升级与安全修复不会自动跟上。研究用途声明,商用需自行做合规与测试,不能引用仓库许可(MIT 覆盖代码,不覆盖模型页的使用限制)。短音频相似度不占优,做音色克隆优先看 CosyVoice 3 或 Eleven v4。继承基座偏见,Qwen2.5-1.5B 的错误与遗漏会带进来,长音频里表现为某些段落的用词与情绪偏移。长音频的失败是全局的:90 分钟单遍生成没有切片那种「坏一段重跑一段」的补救面,一次跑崩就是整条重来,这在成本上要先算清楚——ASR 侧同理,60 分钟单遍的显存与时间开销都高于切片方案,BitNet 那条 CPU 路径(RTF < 1、3+ 线程)是目前唯一把它压到边缘设备上的官方答案。