• 语音
• 音频
• 人工智能

VibeVoice-ASR-Streaming-7B 是一款面向实时语音转写的流式 ASR 模型，它通过 22 帧分块加 4 帧前瞻的机制，在说话的同时就能持续输出"谁说了什么"。对需要低延迟字幕、会议实时纪要的开发者来说，这是一份值得细读的流式转写方案。

VibeVoice-ASR-Streaming-7B 是什么？

一句话概括：它是一个"边听边写"的统一流式语音识别模型，核心能力包括：

• 📝流式说话人转写：音频不断到来的同时，持续识别说话人（Who）和内容（What）
• 👤自定义热词：可以注入人名、专业术语，提升领域内容识别率
• 🌍10 种语言：中、英、法、德、意、日、韩、葡、俄、西

与传统"录完整段再转写"的离线 ASR 不同，它的目标场景是实时转写——语音还没说完，文字已经出来了。

实时转写的核心难题：延迟与准确率的平衡

流式转写存在一个天然矛盾：

• 分块切得越小→ 延迟越低，但句子边界被切断，词义不完整
• 分块切得越大→ 上下文越充分，但用户要等更久才能看到文字

VibeVoice-ASR-Streaming-7B 的答案是：把音频压缩成离散的"语音帧"，再用22 帧一窗口 + 向前多看 4 帧的滑动策略，把端到端延迟压到约 3.5 秒级别。

22 帧分块：把长音频切成"小口吃"

流式处理的前提是把连续音频离散化。在 preprocessor_config.json 中可以看到两个关键参数：

由此可以算出每帧的物理时长：

1 帧 = 3200 ÷ 24000 ≈0.133 秒（133 毫秒）

1 个分块 = 22 × 0.133 ≈2.93 秒

也就是说，模型大约每 3 秒的音频就完成一次转写输出。这种"小口吃"的方式意味着：音频流到来后，最多 2.93 秒的音频积累就会触发一次解码，而不是等到整段录音结束。

4 帧前瞻：多看 533 毫秒，转写更完整

只有小分块还不够。如果严格按 22 帧切割，很多单词会恰好被切在边界上——比如一个词说了 20 帧，剩下 10 帧落在下一个窗口里，模型在第一个窗口结束时"只听到一半"，转写容易出错。

lookahead_frames: 4就是为解决这个问题而设计的：

这个设计非常克制：

• 只多看533 毫秒，延迟增加有限
• 但足以让大多数边界词完整落入当前窗口，显著提升转写准确率
• 解码窗口实际为 22 + 4 = 26 帧（约 3.47 秒）

这相当于用"半秒的未来"换"一句完整的话"，是延迟与准确率之间精心权衡的结果。

一笔延迟账：约 3.5 秒出结果的流式转写

把上面的数字合起来，就能看懂实时转写的延迟构成：

1. 音频持续流入，按 22 帧（≈2.93s）累积成一个窗口
2. 解码时再附带 4 帧（≈0.53s）前瞻上下文
3. 窗口完成后立即产出该段文字

端到端延迟 ≈ 2.93 + 0.53 ≈ 3.5 秒，且每 2.93 秒就有新一轮增量输出。对于直播字幕、会议实时纪要这类场景，这个节奏已经接近"边说边出字"的体验，同时远小于离线转写"全程等待"的模式。

配置速查：chunk_frames 与 lookahead_frames

如果你需要复现或调整这套流式参数，所有关键配置都集中在这两个文件里：

• preprocessor_config.json：chunk_frames: 22、lookahead_frames: 4、speech_tok_compress_ratio: 3200、target_sample_rate: 24000，处理器类为VibeVoiceASRProcessor
• config.json：声学/语义 tokenizer 与解码器的完整结构定义

想微调延迟体验时，调整思路很简单：调小chunk_frames会更"快"，调大lookahead_frames会更"准"。

除了分块，还有哪些低延迟设计？

分块只是显性设计，模型结构层面同样为流式场景做了铺垫（详见 config.json 与权重索引 model.safetensors.index.json）：

• 因果式编码器：acoustic_tokenizer_config与semantic_tokenizer_config均设置了"causal": true，声学与语义 token 可以逐帧因果生成，天然适配流式输入，不需要整段音频
• 双 tokenizer 架构：声学 VAE（vae_dim: 64）负责保真度，语义 VAE（vae_dim: 128）负责语义，两者通过use_semantic_feature: true联合输入语言模型
• 7B 解码器 + GQA：解码器为 28 层、hidden 3584 的 Transformer，仅 4 个 KV 头（num_key_value_heads: 4），大幅缩小 KV 缓存，对长对话流式推理的吞吐非常友好
• bfloat16 精度：tokenizer 均以 bfloat16 训练推理，降低计算与显存开销

适合哪些场景？

这套"22 帧分块 + 4 帧前瞻"的实时转写方案，特别适合：

• 🎙️会议/访谈实时纪要：持续输出带说话人的字幕流
• 💬直播字幕与客服质检：低延迟增量文字
• 🔥领域术语场景：配合自定义热词，如医疗、金融、会议姓名等

如何上手？

模型权重以 8 个分片 safetensors 形式存放（如 model-00001-of-00008.safetensors），配合 tokenizer.json 与 preprocessor_config.json 即可加载。安装与使用方法请参考仓库内的 README.md。

小结：VibeVoice-ASR-Streaming-7B 的"低延迟秘密"并不神秘——133 毫秒一帧的语音压缩，22 帧（约 2.93 秒）一个转写窗口，再向前多看 4 帧（约 0.53 秒）补齐边界，配合因果编码器与 GQA 解码器，最终换来约 3.5 秒的端到端延迟和持续滚动的实时转写输出。

• 语音
• 音频
• 人工智能