从Hugging Face刷到VibeVoice这个开源项目时我第一反应是又有人拿“长上下文”当噱头。但看完它的技术组成——“连续语音Tokenizer”“Next-Token扩散”再看到“90分钟多说话人语音合成”“60分钟长音频识别”这两组实测数据我决定把它拉下来跑一轮。跑完的感受是这个方向确实代表语音模型正在从“离散码本时代”向“连续潜空间时代”切换而且它不是只发论文是真的给了可直接复现的开源实现。这篇就当一次完整记录。我尽量把原理讲透再把部署和跑通的全过程写清楚最后把踩过的坑和排查思路整理成清单。不管你是做语音合成、ASR还是想研究连续tokenizer在多模态模型里的用法这篇应该都能帮你省不少时间。1. 先说清楚VibeVoice到底做了什么1.1 从传统语音tokenizer说起过去的语音生成模型无论是VALL-E、AudioLM还是早期基于codec的TTS都走同一条路先用一个神经音频编解码器把语音压成离散token。典型代表就是EnCodec或SoundStream它们用残差向量量化RVQ把连续声学特征映射到一组码本索引上。模型只需要预测这些索引再通过解码器还原成波形。这套方案的优点是训练稳定自回归模型可以直接套用语言模型的套路。但它有两个明显短板一是码本大小有限量化过程会把很多声学细节丢掉尤其是基频抖动、气声、音色过渡这些“细腻但关键”的信息二是码本索引之间没有天然的距离语义模型很难对“接近但不完全一样”的发音建模。你可能遇到过某些TTS在快速语速或者轻声说话时音质发糊很多时候就是离散量化把细节磨掉了。VibeVoice没有继续走这条老路。它的tokenizer输出的是连续向量不经过VQ码本直接把语音编码成一个高维潜空间序列。你可以把它理解成传统方式是把画面转成256色索引而连续tokenizer是直接保存RGB颜色值。显然后者能承载的信息量大得多下游模型也有更多发挥空间。1.2 连续tokenizer为什么能保留更多信息回到音频本身。语音包含的声学信息相当复杂音素内容、基频轮廓、说话人音色、房间混响、情感起伏。离散化不可避免要压缩压缩率一高第一波被牺牲的就是基频的精细结构和噪声成分。而连续tokenizer在训练时目标不是分类而是重构。它通过编码器-解码器结构把输入语音映射成连续向量序列再从这些向量重建波形损失函数里会要求重建后的波形尽可能接近原始信号。VibeVoice的连续语音tokenizer训练细节我看下来它用了类似流匹配或变分自编码器的思路让token序列不仅保留内容信息还保留说话人和韵律信息。这一步非常关键因为后续的多说话人合成和长音频识别都依赖这个tokenizer输出特征的完备性。如果你只是把某个离散codec换成连续向量下游模型照样能跑但效果提升主要来自tokenizer本身的保真度。这里有一个容易被忽略的点连续tokenizer的输出并不像离散token那样可以直接用交叉熵损失训练自回归模型。你需要给模型一个“预测目标”的定义方式。VibeVoice的解决方案就是下一节要说的Next-Token扩散。1.3 Next-Token扩散在语音生成里的角色Next-Token扩散这个概念简单说就是“自回归地预测下一个连续token但预测方式不是直接回归一个向量而是用扩散模型去逐步去噪”。传统自回归语音生成模型预测离散token时每个位置都是一个分类问题模型输出一个概率分布取概率最大的索引。但换成连续token后每个位置的目标是一个高维向量直接让模型回归这个向量当然也可以但实测下来结果往往过于平滑、缺少细节。扩散模型的优势在于它擅长建模高维连续分布生成结果既有全局一致性又有高频细节。VibeVoice的做法是在每一个时间步给定之前的token序列作为条件扩散模型从随机噪声出发经过若干步去噪逐步生成下一个token。这里用的不是DDPM那种独立生成整段而是“next-token式”的扩散。你可以这样理解普通TTS是一口气渲染整幅画VibeVoice是一笔接一笔地画但每一笔都用了“从草稿到精修”的过程。这种架构的好处有两点一是保留了自回归模型对长序列的建模能力信息会沿着时间步传递二是每一帧的声学细节由扩散模型补全比直接回归丰富得多。代价是推理速度变慢。好在语音token的序列长度远小于波形采样点VibeVoice在合成90分钟音频时扩散步数控制在几十步整体还在可接受范围内。2. 90分钟多说话人语音合成是怎么做到的2.1 长上下文与多说话人模型架构上的取舍以往的多说话人TTS通常限制在几十秒上下原因是Transformer的自注意力复杂度随序列长度平方增长上下文一长显存和计算量都吃不消。VibeVoice能用90分钟上下文我推测它做了三件事把语音token帧率大幅降低使用稀疏注意力或线性注意力机制以及把说话人信息以embedding形式注入到每一帧的条件中。首先是帧率。语音tokenizer的帧率直接决定序列长度。常见的离散codec帧率是50Hz到100Hz也就是每10到20毫秒一个token。90分钟音频按50Hz算就是27万个token。如果不降帧率再强的注意力机制也顶不住。VibeVoice通过下采样方式把tokenizer输出帧率控制得比较低换来的是更长的上下文窗口。低帧率带来的信息损失又靠连续tokenizer的保真度补回来。其次是注意力机制。长上下文场景基本不能用标准全注意力。VibeVoice应该是引入了窗口局部注意力和全局token相结合的结构比如每个token只关注附近若干token同时保留少量全局token传递说话人、语速、风格等信息。这也解释了为什么多说话人能稳定保持——只要全局token里包含明确的说话人表征哪怕跨越很长的文本模型也不会忘记当前应该用谁的声音。最后是说话人表示。VibeVoice没有把说话人当成单独的one-hot标签而是从参考音频里提取说话人embedding再以条件输入的方式加到每一层。这样做的价值在于你不需要预先定义固定数量的说话人任何新声音都可以通过几秒参考音频注册进去。做有声书、播客、游戏配音这类需要“克隆特定音色”的任务时很实用。2.2 合成时的控制项与输入格式我实际跑下来VibeVoice的合成入口比我想象中简单。官方仓库里的demo脚本输入是一个JSON或者脚本参数组大致包含这几类信息文本内容可以是纯文本也可以是带段落标记的文本说话人标记在文本中插入类似|speaker_1|这样的标签或者在脚本里指定speaker_id列表参考音频如果你想模仿某个具体声音给出一个3到10秒的参考音频路径扩散参数diffusion_steps、guidance_scale采样种子seed用于复现结果。这个设计对内容创作者很友好。比如你要生成一个两人对话只需要在文本里交替插入说话人标记模型会在生成时自动切换音色同时保持对话节奏自然。我试过一段30分钟的双人播客脚本切换处几乎听不出机械感比我之前用“分段合成再拼接”的方案顺滑太多。但这不意味着你什么都不用管。文本长度超过模型最大上下文时脚本会自动截断或要求你手动分段。我建议在生成超长音频之前先把文本按章节或者语义边界拆好不要给模型塞一坨超过上限的内容。分段边界选在句子结束处能明显减少上下文拼接带来的语义断裂。2.3 90分钟上下文的实操意义90分钟这个数字到底意味着什么对普通用户来说最直观的体验就是你可以一次性生成一本有声书的完整章节或者一整期播客让模型在同一个上下文里始终保持相同音色和语气。分段生成虽然也能做到这一点但在段落之间容易出现风格漂移比如语速变化、音调突然升高。对开发者和研究者来说90分钟上下文更大的价值是支持跨句子的韵律建模。语音不是孤立句子串起来的前面句子的节奏会影响后面句子的语气。短上下文模型生成时往往每一句都在“重新开始”长上下文模型则能利用前面几十句话的语境自然衔接。VibeVoice合成出来的长音频听起来更像“一个人在连续说话”而不是“一堆句子被拼在一起”。另外一个实用场景是数据标注。如果你手里有很长的语音素材想用合成方式生成带多说话人标签的训练数据90分钟一次生成意味着你能在一条样本里获得连续的说话人转换、重叠对话和上下文相关韵律。这对训练下游的说话人识别、语音识别模型非常有价值。3. 60分钟长音频识别不只是ASR3.1 长音频识别的难点显存、分段、说话人长音频识别的第一个门槛是显存。60分钟音频按16kHz采样就是576万个采样点。转成token序列后长度虽然比波形短得多但配上Transformer编码器仍然很容易让显卡爆掉。VibeVoice的做法是分段进入但保持上下文状态或者说使用了循环式注意力机制让前一段的信息能流向后面。这样既能计算长音频又不会真正把整段输入一次性塞进显存。第二个难点是说话人一致性。传统ASR只会输出文字但实际场景里你往往想知道“这句话是谁说的”。VibeVoice的识别输出不仅包含文本还包含说话人ID和时间戳。我在测试一段60分钟采访录音时它能把两位受访者和主持人的发言分开准确率比传统的“ASR独立说话人分离”方案高不少。原因就在于它的tokenizer天然包含了说话人信息识别和分离是在同一个模型里联合完成的而不是两条流水线。第三个难点是长距离指代。一个人说“我刚才提到的那件事”如果模型只看到局部文本很难理解“那件事”是哪件事。长音频识别模型因为能看到更长的上下文在转写和标点恢复时会更准确。VibeVoice在这方面的表现比我预期好尤其是代词和指代关系处理。3.2 实际使用流程与参数选择识别部分的脚本同样很简单。你需要提供一个音频文件路径以及几个控制参数。我整理一份常用参数表参数名作用我的推荐值audio_file输入音频路径无默认必填chunk_seconds内部处理的音频块长度30到60秒overlap_ratio相邻块重叠比例0.2到0.5max_frames单次传入模型的帧上限根据显存调整language输入语言代码中文用zh英文用enreturn_timestamps是否返回字级时间戳truediarize是否启用说话人识别true如果音频超过60分钟脚本会自动切块并逐块识别最后把结果合并。我不建议把chunk_seconds设得过大因为每个块内部如果出现太多说话人切换模型处理起来反而容易混淆。30秒到60秒是一个平衡点。重叠部分是关键没有重叠的话说话人的话可能刚好被切块边界劈成两半导致识别断词。设置0.2到0.5的重叠比例后结果在合并时会做去重和对齐基本不会丢字。语言参数也很重要。VibeVoice训练时可能对中英混合做了一些处理但我测试纯中文时把language显式设为zh比自动检测明显更稳。如果是粤语或其他方言建议先看官方仓库支持的语言列表不要盲试。3.3 识别结果怎么组织VibeVoice识别输出的格式是带时间戳的JSON大体结构如下{ segments: [ { speaker: spk_1, start: 12.34, end: 18.92, text: 我们先讨论一下项目排期 }, { speaker: spk_2, start: 19.05, end: 23.77, text: 好我觉得第一优先级是数据清洗 } ] }拿到这个JSON之后你可以直接转换成SRT字幕、生成会议纪要或者按说话人分片导出音频。我这次测试因为要做播客剪辑顺手写了个小脚本把speaker字段映射成固定颜色在剪辑软件里一眼就能看出每个人的发言区间省掉了手动听音频标记的环节。有一点要特别提醒时间戳的边界是按模型内部帧对齐的可能存在正负0.5秒左右的误差。如果你要用于字幕精确卡点建议再做一次强制对齐用torchaudio的forced alignment工具把文本边界校正到波形层面。4. 本地部署与实操全过程4.1 环境准备与依赖安装先说一下我的硬件环境一张24GB显存的显卡13800HX处理器64GB内存。这个配置跑VibeVoice的合成和识别都够用但合成超长音频时还是要把显存吃满。安装依赖没什么特别的。仓库用的Python版本我建议直接上3.10或3.11太老的版本会有不少包兼容问题。官方README里给了requirements.txt但我实际装的时候额外补了这几个包pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate sentencepiece pip install flash-attn --no-build-isolationFlashAttention建议尽量装上。VibeVoice在长上下文场景下对注意力计算效率很敏感不装FlashAttention的话即便能跑速度也会慢很多。如果你的显卡是A100或H100FlashAttention支持更好如果是消费级显卡只要显存够也能用。模型权重我是从Hugging Face官方仓库下的。下载后需要把权重路径配置到config里。注意仓库里区分了tokenizer、synthesis和recognition三套权重只能分开下载。识别模型的权重比合成模型小很多但也不能混着用。4.2 模型权重加载与显存估算我先把三种模型权重实际测试时的显存占用列出来方便你对照模型权重大小推理显存占用fp16说明连续语音Tokenizer约1.2GB峰值约3GB编码器加解码器合成模型Next-Token扩散约7GB生成90分钟音频峰值约16GB扩散步数越多越吃显存识别模型约3.5GB处理60分钟音频峰值约10GB分段处理显存浮动较小我测试时用了bf16混合精度显存占用基本在可接受范围。如果你用老显卡不支持bf16就得切到fp16但部分层需要做一下精度校准否则可能出现数值不稳定表现为生成音频偶尔出现爆音。一个实用建议加载模型时先把tokenizer和recognition模型加载到GPU合成模型等真要生成时再加载。不要三个模型同时常驻显存24GB显卡同时加载两个大模型时已经比较吃力了。如果你有32GB或更大显存那随意。4.3 快速跑通合成和识别安装好依赖之后跑合成的命令大概是这样的python demo_synthesis.py \ --text 这是一段测试语音用于验证VibeVoice的合成效果。 \ --speaker spk_1 \ --reference_audio ref.wav \ --diffusion_steps 30 \ --guidance_scale 1.5 \ --output out.wavdiffusion_steps是扩散采样的步数。我测试下来30步是质量与速度的平衡点。跑到50步时音质提升有限但耗时几乎翻倍。guidance_scale控制条件强度1.5到2.0比较稳超过2.5之后会有明显的音染听起来“太夸张”。如果你要的是自然说话感别把guidance拉太高。识别命令类似python demo_recognition.py \ --audio_file long_audio.wav \ --language zh \ --chunk_seconds 30 \ --overlap_ratio 0.3 \ --diarize true \ --output result.json识别脚本第一次跑的时候会自动下载一些小的辅助模型网络不好时容易卡住。建议先把Hugging Face的缓存目录配好或者提前手动下载并放到指定路径。跑完之后result.json里就能看到说话人和文本的对应关系了。不过要注意VibeVoice是一个研究性质的开源项目不是像商业ASR那样开箱即用的产品。你需要对音频格式有一点基本的处理能力。比如输入音频如果不是16kHz建议先做重采样。脚本里可能没有自动重采样逻辑依赖库也不会帮你处理。我习惯在跑之前加一步ffmpeg -i input.mp3 -ar 16000 -ac 1 input_16k.wav不转成16kHz单声道的话识别效果会打折扣。5. 常见问题与排查技巧实录5.1 显存不足与内存碎片我第一轮跑90分钟合成时显存直接飙到接近24GB上限中途还Cuda OOM了一次。后来发现是因为我把diffusion_steps设成了50又没有开显存优化。解决办法是把max_frames调低让模型自动切块生成同时开启torch.compile它能把部分计算融合掉显存占用下降不少。代码层面可以加一行model.backbone torch.compile(model.backbone)另外PyTorch的内存分配器在多次长序列推理后容易产生碎片。我建议在推理循环外加一次缓存清理torch.cuda.empty_cache()但不要每帧都清理那样反而拖慢速度。在每次完整任务结束后清理一次就够了。5.2 合成音频出现断续或音色漂移这个问题的根因通常不在模型而在输入的参考音频。如果你的参考音频里夹杂了音乐、环境噪声或者其他人的声音说话人embedding会被污染。VibeVoice生成的音频就会跟着出问题轻则音色不稳重则中间突然冒出怪声。解决方式是先把参考音频处理干净。降噪、去音乐、裁剪到3到10秒。如果参考音频里有明显的混响建议用带房间脉冲响应的工具做一个去混响效果会立刻不同。我踩过坑一开始用一段电话录音做参考生成出来的音色既不像目标说话人还带金属声。换成清晰录音之后音色一致性明显改善。还有一个容易被忽视的点参考音频的采样率要和模型要求一致。我用48kHz的参考音频结果模型生成出来的音频带着奇怪的音高偏移因为tokenizer对采样率非常敏感。统一到16kHz单声道后问题消失。5.3 识别长音频时的OOM与分段策略虽说是“60分钟长音频识别”但模型在实际实现时并不会一次读入整段。如果你直接传一个60分钟的wav脚本内部还是会按照chunk_seconds切块。我发现一个问题默认的切块逻辑在说话人切换处容易出现一句话被拆成两半前半句结尾在上一块后半句开头在下一块。即使有重叠区偶尔也会丢字。我自己的解决办法是先做一遍VAD检测也就是用silero-vad检测出语音片段的边界再把这些边界作为切块的参考点让切块位置尽量落在静音处。这样处理完之后识别错误率下降了一个数量级。官方脚本目前没有自动VAD对齐逻辑但可以在预处理环节自己加。还有一个小技巧如果音频本身是立体声且不同说话人分别在不同声道比如电话录音的左声道、右声道可以先拆分声道再分别识别。合并结果时对齐时间戳。这比让模型自己做说话人分离更稳。5.4 Tokenizer输出不匹配导致推理报错这个坑比较隐蔽。VibeVoice的三套权重是独立训练的如果你用某个版本的tokenizer配合另一个版本的合成模型很可能会出现shape mismatch或者unexpected key这类错误。我第一次跑就栽在这里下载的是仓库里最新的tokenizer权重而合成模型权重还是老的结果直接跑不起来。官方没有像Hugging Face那样严格校验版本指纹所以你需要自己记住权重的下载日期或commit哈希。建议把权重路径写进一个固定版本的config.yaml里不要随手覆盖。更好的做法是checkout到发布版tag别用main分支的权重混搭。5.5 中文标点和断句问题合成中文时偶尔会出现句尾语气生硬、断句位置不对的情况。这多半和文本里缺少标点有关。模型在训练时是按照带标点的文本学习的你给它一长串无标点字符它很难自动找到正确的换气点。我试过用市面上的标点恢复模型先给文本加标点效果立竿见影。如果你做的是中文合成文本里“的、地、得”这些虚词和句末“了、吗、呢”最好保留这能明显提升自然度。还有数字和英文单词在中文语音合成里经常出问题建议提前把“1024”转成“一千零二十四”或者按场景读法转写模型不是万能的预处理越干净生成越可控。6. 个人使用心得与下一步玩法6.1 最值得关注的三个设计连续tokenizer、Next-Token扩散、长上下文多说话人建模这三个点单拎出来任何一个都不算特别新但VibeVoice把它们整合到一个开源项目里而且给出了可复现的实现。我特别欣赏它对“连续性”的坚持。语音本身是连续物理信号硬编码成离散索引本来就是一种妥协VibeVoice绕过VQ码本直接用扩散模型建模连续潜空间算是更贴合语音信号本质的做法。对我来说这个项目最大的参照价值在于它验证了一条技术路线也就是“用连续潜空间替代离散token”可以用来指导后续更大规模语音模型的架构设计。如果你在做多模态相关工作可以把这套tokenizer插到自己的框架里让语音模态和文本模态在连续空间里对齐未必非要量化为离散token。6.2 后续可以怎么扩展我计划在几个方向上继续折腾。第一是微调一个中文小说朗读专用版本把资料素材做成带说话人标记的数据集看看长上下文的韵律建模能不能覆盖几十万字的小说章节。第二是试试点到点音频理解把VibeVoice的识别结果作为中间表示再接一层LLM做摘要、问答、关键词提取这种“音频转语义”的流水线在会议纪要场景会非常实用。第三是实验一下语音编辑。既然连续tokenizer保留了大量声学细节理论上你可以只修改局部token再通过解码器重建波形实现改一个词而不重读整句的效果。官方目前没有暴露这部分API但深入研究代码之后未必不能自己实现。另外建议你盯一下官方repo的issue区作者回复也算积极。如果你想在上面做二次开发先从tokenizer部分入手最容易看到效果。它本身就是一个独立的“连续音频编码器”完全可以单独拿出来用在其他项目上。最后再分享一个小技巧跑VibeVoice时把diffusion步数固定在前半段大、后半段小比如前20步用30步的强度后10步用小步长精修可以在不牺牲太多质量的情况下提速不少。具体参数需要根据你的音频内容做微调但整体方向值得一试。 
长河君 · 2026/11/4 20:40:02 · 阅读 1.2k VibeVoice：连续语音Tokenizer与Next-Token扩散实现90分钟长音频合成
从Hugging Face刷到VibeVoice这个开源项目时我第一反应是又有人拿“长上下文”当噱头。但看完它的技术组成——“连续语音Tokenizer”“Next-Token扩散”再看到“90分钟多说话人语音合成”“60分钟长音频识别”这两组实测数据我决定把它拉下来跑一轮。跑完的感受是这个方向确实代表语音模型正在从“离散码本时代”向“连续潜空间时代”切换而且它不是只发论文是真的给了可直接复现的开源实现。这篇就当一次完整记录。我尽量把原理讲透再把部署和跑通的全过程写清楚最后把踩过的坑和排查思路整理成清单。不管你是做语音合成、ASR还是想研究连续tokenizer在多模态模型里的用法这篇应该都能帮你省不少时间。1. 先说清楚VibeVoice到底做了什么1.1 从传统语音tokenizer说起过去的语音生成模型无论是VALL-E、AudioLM还是早期基于codec的TTS都走同一条路先用一个神经音频编解码器把语音压成离散token。典型代表就是EnCodec或SoundStream它们用残差向量量化RVQ把连续声学特征映射到一组码本索引上。模型只需要预测这些索引再通过解码器还原成波形。这套方案的优点是训练稳定自回归模型可以直接套用语言模型的套路。但它有两个明显短板一是码本大小有限量化过程会把很多声学细节丢掉尤其是基频抖动、气声、音色过渡这些“细腻但关键”的信息二是码本索引之间没有天然的距离语义模型很难对“接近但不完全一样”的发音建模。你可能遇到过某些TTS在快速语速或者轻声说话时音质发糊很多时候就是离散量化把细节磨掉了。VibeVoice没有继续走这条老路。它的tokenizer输出的是连续向量不经过VQ码本直接把语音编码成一个高维潜空间序列。你可以把它理解成传统方式是把画面转成256色索引而连续tokenizer是直接保存RGB颜色值。显然后者能承载的信息量大得多下游模型也有更多发挥空间。1.2 连续tokenizer为什么能保留更多信息回到音频本身。语音包含的声学信息相当复杂音素内容、基频轮廓、说话人音色、房间混响、情感起伏。离散化不可避免要压缩压缩率一高第一波被牺牲的就是基频的精细结构和噪声成分。而连续tokenizer在训练时目标不是分类而是重构。它通过编码器-解码器结构把输入语音映射成连续向量序列再从这些向量重建波形损失函数里会要求重建后的波形尽可能接近原始信号。VibeVoice的连续语音tokenizer训练细节我看下来它用了类似流匹配或变分自编码器的思路让token序列不仅保留内容信息还保留说话人和韵律信息。这一步非常关键因为后续的多说话人合成和长音频识别都依赖这个tokenizer输出特征的完备性。如果你只是把某个离散codec换成连续向量下游模型照样能跑但效果提升主要来自tokenizer本身的保真度。这里有一个容易被忽略的点连续tokenizer的输出并不像离散token那样可以直接用交叉熵损失训练自回归模型。你需要给模型一个“预测目标”的定义方式。VibeVoice的解决方案就是下一节要说的Next-Token扩散。1.3 Next-Token扩散在语音生成里的角色Next-Token扩散这个概念简单说就是“自回归地预测下一个连续token但预测方式不是直接回归一个向量而是用扩散模型去逐步去噪”。传统自回归语音生成模型预测离散token时每个位置都是一个分类问题模型输出一个概率分布取概率最大的索引。但换成连续token后每个位置的目标是一个高维向量直接让模型回归这个向量当然也可以但实测下来结果往往过于平滑、缺少细节。扩散模型的优势在于它擅长建模高维连续分布生成结果既有全局一致性又有高频细节。VibeVoice的做法是在每一个时间步给定之前的token序列作为条件扩散模型从随机噪声出发经过若干步去噪逐步生成下一个token。这里用的不是DDPM那种独立生成整段而是“next-token式”的扩散。你可以这样理解普通TTS是一口气渲染整幅画VibeVoice是一笔接一笔地画但每一笔都用了“从草稿到精修”的过程。这种架构的好处有两点一是保留了自回归模型对长序列的建模能力信息会沿着时间步传递二是每一帧的声学细节由扩散模型补全比直接回归丰富得多。代价是推理速度变慢。好在语音token的序列长度远小于波形采样点VibeVoice在合成90分钟音频时扩散步数控制在几十步整体还在可接受范围内。2. 90分钟多说话人语音合成是怎么做到的2.1 长上下文与多说话人模型架构上的取舍以往的多说话人TTS通常限制在几十秒上下原因是Transformer的自注意力复杂度随序列长度平方增长上下文一长显存和计算量都吃不消。VibeVoice能用90分钟上下文我推测它做了三件事把语音token帧率大幅降低使用稀疏注意力或线性注意力机制以及把说话人信息以embedding形式注入到每一帧的条件中。首先是帧率。语音tokenizer的帧率直接决定序列长度。常见的离散codec帧率是50Hz到100Hz也就是每10到20毫秒一个token。90分钟音频按50Hz算就是27万个token。如果不降帧率再强的注意力机制也顶不住。VibeVoice通过下采样方式把tokenizer输出帧率控制得比较低换来的是更长的上下文窗口。低帧率带来的信息损失又靠连续tokenizer的保真度补回来。其次是注意力机制。长上下文场景基本不能用标准全注意力。VibeVoice应该是引入了窗口局部注意力和全局token相结合的结构比如每个token只关注附近若干token同时保留少量全局token传递说话人、语速、风格等信息。这也解释了为什么多说话人能稳定保持——只要全局token里包含明确的说话人表征哪怕跨越很长的文本模型也不会忘记当前应该用谁的声音。最后是说话人表示。VibeVoice没有把说话人当成单独的one-hot标签而是从参考音频里提取说话人embedding再以条件输入的方式加到每一层。这样做的价值在于你不需要预先定义固定数量的说话人任何新声音都可以通过几秒参考音频注册进去。做有声书、播客、游戏配音这类需要“克隆特定音色”的任务时很实用。2.2 合成时的控制项与输入格式我实际跑下来VibeVoice的合成入口比我想象中简单。官方仓库里的demo脚本输入是一个JSON或者脚本参数组大致包含这几类信息文本内容可以是纯文本也可以是带段落标记的文本说话人标记在文本中插入类似|speaker_1|这样的标签或者在脚本里指定speaker_id列表参考音频如果你想模仿某个具体声音给出一个3到10秒的参考音频路径扩散参数diffusion_steps、guidance_scale采样种子seed用于复现结果。这个设计对内容创作者很友好。比如你要生成一个两人对话只需要在文本里交替插入说话人标记模型会在生成时自动切换音色同时保持对话节奏自然。我试过一段30分钟的双人播客脚本切换处几乎听不出机械感比我之前用“分段合成再拼接”的方案顺滑太多。但这不意味着你什么都不用管。文本长度超过模型最大上下文时脚本会自动截断或要求你手动分段。我建议在生成超长音频之前先把文本按章节或者语义边界拆好不要给模型塞一坨超过上限的内容。分段边界选在句子结束处能明显减少上下文拼接带来的语义断裂。2.3 90分钟上下文的实操意义90分钟这个数字到底意味着什么对普通用户来说最直观的体验就是你可以一次性生成一本有声书的完整章节或者一整期播客让模型在同一个上下文里始终保持相同音色和语气。分段生成虽然也能做到这一点但在段落之间容易出现风格漂移比如语速变化、音调突然升高。对开发者和研究者来说90分钟上下文更大的价值是支持跨句子的韵律建模。语音不是孤立句子串起来的前面句子的节奏会影响后面句子的语气。短上下文模型生成时往往每一句都在“重新开始”长上下文模型则能利用前面几十句话的语境自然衔接。VibeVoice合成出来的长音频听起来更像“一个人在连续说话”而不是“一堆句子被拼在一起”。另外一个实用场景是数据标注。如果你手里有很长的语音素材想用合成方式生成带多说话人标签的训练数据90分钟一次生成意味着你能在一条样本里获得连续的说话人转换、重叠对话和上下文相关韵律。这对训练下游的说话人识别、语音识别模型非常有价值。3. 60分钟长音频识别不只是ASR3.1 长音频识别的难点显存、分段、说话人长音频识别的第一个门槛是显存。60分钟音频按16kHz采样就是576万个采样点。转成token序列后长度虽然比波形短得多但配上Transformer编码器仍然很容易让显卡爆掉。VibeVoice的做法是分段进入但保持上下文状态或者说使用了循环式注意力机制让前一段的信息能流向后面。这样既能计算长音频又不会真正把整段输入一次性塞进显存。第二个难点是说话人一致性。传统ASR只会输出文字但实际场景里你往往想知道“这句话是谁说的”。VibeVoice的识别输出不仅包含文本还包含说话人ID和时间戳。我在测试一段60分钟采访录音时它能把两位受访者和主持人的发言分开准确率比传统的“ASR独立说话人分离”方案高不少。原因就在于它的tokenizer天然包含了说话人信息识别和分离是在同一个模型里联合完成的而不是两条流水线。第三个难点是长距离指代。一个人说“我刚才提到的那件事”如果模型只看到局部文本很难理解“那件事”是哪件事。长音频识别模型因为能看到更长的上下文在转写和标点恢复时会更准确。VibeVoice在这方面的表现比我预期好尤其是代词和指代关系处理。3.2 实际使用流程与参数选择识别部分的脚本同样很简单。你需要提供一个音频文件路径以及几个控制参数。我整理一份常用参数表参数名作用我的推荐值audio_file输入音频路径无默认必填chunk_seconds内部处理的音频块长度30到60秒overlap_ratio相邻块重叠比例0.2到0.5max_frames单次传入模型的帧上限根据显存调整language输入语言代码中文用zh英文用enreturn_timestamps是否返回字级时间戳truediarize是否启用说话人识别true如果音频超过60分钟脚本会自动切块并逐块识别最后把结果合并。我不建议把chunk_seconds设得过大因为每个块内部如果出现太多说话人切换模型处理起来反而容易混淆。30秒到60秒是一个平衡点。重叠部分是关键没有重叠的话说话人的话可能刚好被切块边界劈成两半导致识别断词。设置0.2到0.5的重叠比例后结果在合并时会做去重和对齐基本不会丢字。语言参数也很重要。VibeVoice训练时可能对中英混合做了一些处理但我测试纯中文时把language显式设为zh比自动检测明显更稳。如果是粤语或其他方言建议先看官方仓库支持的语言列表不要盲试。3.3 识别结果怎么组织VibeVoice识别输出的格式是带时间戳的JSON大体结构如下{ segments: [ { speaker: spk_1, start: 12.34, end: 18.92, text: 我们先讨论一下项目排期 }, { speaker: spk_2, start: 19.05, end: 23.77, text: 好我觉得第一优先级是数据清洗 } ] }拿到这个JSON之后你可以直接转换成SRT字幕、生成会议纪要或者按说话人分片导出音频。我这次测试因为要做播客剪辑顺手写了个小脚本把speaker字段映射成固定颜色在剪辑软件里一眼就能看出每个人的发言区间省掉了手动听音频标记的环节。有一点要特别提醒时间戳的边界是按模型内部帧对齐的可能存在正负0.5秒左右的误差。如果你要用于字幕精确卡点建议再做一次强制对齐用torchaudio的forced alignment工具把文本边界校正到波形层面。4. 本地部署与实操全过程4.1 环境准备与依赖安装先说一下我的硬件环境一张24GB显存的显卡13800HX处理器64GB内存。这个配置跑VibeVoice的合成和识别都够用但合成超长音频时还是要把显存吃满。安装依赖没什么特别的。仓库用的Python版本我建议直接上3.10或3.11太老的版本会有不少包兼容问题。官方README里给了requirements.txt但我实际装的时候额外补了这几个包pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate sentencepiece pip install flash-attn --no-build-isolationFlashAttention建议尽量装上。VibeVoice在长上下文场景下对注意力计算效率很敏感不装FlashAttention的话即便能跑速度也会慢很多。如果你的显卡是A100或H100FlashAttention支持更好如果是消费级显卡只要显存够也能用。模型权重我是从Hugging Face官方仓库下的。下载后需要把权重路径配置到config里。注意仓库里区分了tokenizer、synthesis和recognition三套权重只能分开下载。识别模型的权重比合成模型小很多但也不能混着用。4.2 模型权重加载与显存估算我先把三种模型权重实际测试时的显存占用列出来方便你对照模型权重大小推理显存占用fp16说明连续语音Tokenizer约1.2GB峰值约3GB编码器加解码器合成模型Next-Token扩散约7GB生成90分钟音频峰值约16GB扩散步数越多越吃显存识别模型约3.5GB处理60分钟音频峰值约10GB分段处理显存浮动较小我测试时用了bf16混合精度显存占用基本在可接受范围。如果你用老显卡不支持bf16就得切到fp16但部分层需要做一下精度校准否则可能出现数值不稳定表现为生成音频偶尔出现爆音。一个实用建议加载模型时先把tokenizer和recognition模型加载到GPU合成模型等真要生成时再加载。不要三个模型同时常驻显存24GB显卡同时加载两个大模型时已经比较吃力了。如果你有32GB或更大显存那随意。4.3 快速跑通合成和识别安装好依赖之后跑合成的命令大概是这样的python demo_synthesis.py \ --text 这是一段测试语音用于验证VibeVoice的合成效果。 \ --speaker spk_1 \ --reference_audio ref.wav \ --diffusion_steps 30 \ --guidance_scale 1.5 \ --output out.wavdiffusion_steps是扩散采样的步数。我测试下来30步是质量与速度的平衡点。跑到50步时音质提升有限但耗时几乎翻倍。guidance_scale控制条件强度1.5到2.0比较稳超过2.5之后会有明显的音染听起来“太夸张”。如果你要的是自然说话感别把guidance拉太高。识别命令类似python demo_recognition.py \ --audio_file long_audio.wav \ --language zh \ --chunk_seconds 30 \ --overlap_ratio 0.3 \ --diarize true \ --output result.json识别脚本第一次跑的时候会自动下载一些小的辅助模型网络不好时容易卡住。建议先把Hugging Face的缓存目录配好或者提前手动下载并放到指定路径。跑完之后result.json里就能看到说话人和文本的对应关系了。不过要注意VibeVoice是一个研究性质的开源项目不是像商业ASR那样开箱即用的产品。你需要对音频格式有一点基本的处理能力。比如输入音频如果不是16kHz建议先做重采样。脚本里可能没有自动重采样逻辑依赖库也不会帮你处理。我习惯在跑之前加一步ffmpeg -i input.mp3 -ar 16000 -ac 1 input_16k.wav不转成16kHz单声道的话识别效果会打折扣。5. 常见问题与排查技巧实录5.1 显存不足与内存碎片我第一轮跑90分钟合成时显存直接飙到接近24GB上限中途还Cuda OOM了一次。后来发现是因为我把diffusion_steps设成了50又没有开显存优化。解决办法是把max_frames调低让模型自动切块生成同时开启torch.compile它能把部分计算融合掉显存占用下降不少。代码层面可以加一行model.backbone torch.compile(model.backbone)另外PyTorch的内存分配器在多次长序列推理后容易产生碎片。我建议在推理循环外加一次缓存清理torch.cuda.empty_cache()但不要每帧都清理那样反而拖慢速度。在每次完整任务结束后清理一次就够了。5.2 合成音频出现断续或音色漂移这个问题的根因通常不在模型而在输入的参考音频。如果你的参考音频里夹杂了音乐、环境噪声或者其他人的声音说话人embedding会被污染。VibeVoice生成的音频就会跟着出问题轻则音色不稳重则中间突然冒出怪声。解决方式是先把参考音频处理干净。降噪、去音乐、裁剪到3到10秒。如果参考音频里有明显的混响建议用带房间脉冲响应的工具做一个去混响效果会立刻不同。我踩过坑一开始用一段电话录音做参考生成出来的音色既不像目标说话人还带金属声。换成清晰录音之后音色一致性明显改善。还有一个容易被忽视的点参考音频的采样率要和模型要求一致。我用48kHz的参考音频结果模型生成出来的音频带着奇怪的音高偏移因为tokenizer对采样率非常敏感。统一到16kHz单声道后问题消失。5.3 识别长音频时的OOM与分段策略虽说是“60分钟长音频识别”但模型在实际实现时并不会一次读入整段。如果你直接传一个60分钟的wav脚本内部还是会按照chunk_seconds切块。我发现一个问题默认的切块逻辑在说话人切换处容易出现一句话被拆成两半前半句结尾在上一块后半句开头在下一块。即使有重叠区偶尔也会丢字。我自己的解决办法是先做一遍VAD检测也就是用silero-vad检测出语音片段的边界再把这些边界作为切块的参考点让切块位置尽量落在静音处。这样处理完之后识别错误率下降了一个数量级。官方脚本目前没有自动VAD对齐逻辑但可以在预处理环节自己加。还有一个小技巧如果音频本身是立体声且不同说话人分别在不同声道比如电话录音的左声道、右声道可以先拆分声道再分别识别。合并结果时对齐时间戳。这比让模型自己做说话人分离更稳。5.4 Tokenizer输出不匹配导致推理报错这个坑比较隐蔽。VibeVoice的三套权重是独立训练的如果你用某个版本的tokenizer配合另一个版本的合成模型很可能会出现shape mismatch或者unexpected key这类错误。我第一次跑就栽在这里下载的是仓库里最新的tokenizer权重而合成模型权重还是老的结果直接跑不起来。官方没有像Hugging Face那样严格校验版本指纹所以你需要自己记住权重的下载日期或commit哈希。建议把权重路径写进一个固定版本的config.yaml里不要随手覆盖。更好的做法是checkout到发布版tag别用main分支的权重混搭。5.5 中文标点和断句问题合成中文时偶尔会出现句尾语气生硬、断句位置不对的情况。这多半和文本里缺少标点有关。模型在训练时是按照带标点的文本学习的你给它一长串无标点字符它很难自动找到正确的换气点。我试过用市面上的标点恢复模型先给文本加标点效果立竿见影。如果你做的是中文合成文本里“的、地、得”这些虚词和句末“了、吗、呢”最好保留这能明显提升自然度。还有数字和英文单词在中文语音合成里经常出问题建议提前把“1024”转成“一千零二十四”或者按场景读法转写模型不是万能的预处理越干净生成越可控。6. 个人使用心得与下一步玩法6.1 最值得关注的三个设计连续tokenizer、Next-Token扩散、长上下文多说话人建模这三个点单拎出来任何一个都不算特别新但VibeVoice把它们整合到一个开源项目里而且给出了可复现的实现。我特别欣赏它对“连续性”的坚持。语音本身是连续物理信号硬编码成离散索引本来就是一种妥协VibeVoice绕过VQ码本直接用扩散模型建模连续潜空间算是更贴合语音信号本质的做法。对我来说这个项目最大的参照价值在于它验证了一条技术路线也就是“用连续潜空间替代离散token”可以用来指导后续更大规模语音模型的架构设计。如果你在做多模态相关工作可以把这套tokenizer插到自己的框架里让语音模态和文本模态在连续空间里对齐未必非要量化为离散token。6.2 后续可以怎么扩展我计划在几个方向上继续折腾。第一是微调一个中文小说朗读专用版本把资料素材做成带说话人标记的数据集看看长上下文的韵律建模能不能覆盖几十万字的小说章节。第二是试试点到点音频理解把VibeVoice的识别结果作为中间表示再接一层LLM做摘要、问答、关键词提取这种“音频转语义”的流水线在会议纪要场景会非常实用。第三是实验一下语音编辑。既然连续tokenizer保留了大量声学细节理论上你可以只修改局部token再通过解码器重建波形实现改一个词而不重读整句的效果。官方目前没有暴露这部分API但深入研究代码之后未必不能自己实现。另外建议你盯一下官方repo的issue区作者回复也算积极。如果你想在上面做二次开发先从tokenizer部分入手最容易看到效果。它本身就是一个独立的“连续音频编码器”完全可以单独拿出来用在其他项目上。最后再分享一个小技巧跑VibeVoice时把diffusion步数固定在前半段大、后半段小比如前20步用30步的强度后10步用小步长精修可以在不牺牲太多质量的情况下提速不少。具体参数需要根据你的音频内容做微调但整体方向值得一试。