VibeVoice-ASR-Streaming-7B：会议没结束，先看到谁说了什么

想在讨论进行时跟上发言，只有一份会后生成的录音转写还不够。VibeVoice-ASR-Streaming-7B 值得认识的地方，是音频还在传入时就分块输出文字，并把“谁说的”一起带出来。对会议字幕和访谈跟读，这意味着读者可以沿着发言顺序阅读，而不只是等结束后得到一大段文本。

微软仓库把这次流式 ASR 发布记在 2026 年 9 月 3 日。本文对应的是这个确切的 Streaming-7B 型号：它做语音识别，不是名字相近的实时语音合成模型；也不能把非流式版本整段处理长录音的能力全部搬过来。

从麦克风到逐块字幕

官方文档给了一个容易理解的入口：启动本地 FastAPI 演示后，打开浏览器页面，既可以录麦克风，也可以选文件。录音期间保持 WebSocket 连接，音频持续进入，文字随模型的音频块输出。另一个文件推理入口会在每块结果产生时打印出来。因此，“流式”说的是边接收边交付，文件作为输入也可以用来检查这条过程。

以两人讨论的教学情境看，读者希望看到的是某位发言者说完一段，字幕出现这段话及对应的说话人标签，再接上下一位的发言。这里的说话人归属帮助区分轮次，并不自动知道参会者真实姓名。把标签与姓名对应、确认交叠发言，仍是会议应用需要另外处理的工作。

官方模型页截图。看左侧的 Who、What 与 Customized Hotwords：三者对应本文的阅读主线；下方是架构示意。这张图用于辨认型号与能力入口，不是中文会议转写效果截图。打开完整截图。

为什么字幕仍然要等一小段

chunk 是模型一次接收并处理的音频块，lookahead 是额外向后读取的一段声音。后者让模型在作出当前判断时多拿到一点后续语音，代价是需要等待这些声音到达。因此，“边说边出”不等于每个字发音刚开始就立刻显示。

官方文档特别说明，两者从检查点的 preprocessor_config.json 读取，使推理保持训练时的分块设置。此次读取的配置是 22 个 chunk 帧和 4 个 lookahead 帧。普通读者不必调这些数字，但做字幕服务的人要知道：它们不是可以任意缩小而保持同样效果的界面刷新选项。模型计算、音频传输和页面显示还会增加等待，配置值也不是完整服务的延迟实测。

这会影响采用方式。现场跟读关心新文字何时出现，正式纪要还关心人名、数字和发言归属是否准确；两种成果可以共享转写材料，却不应采用同一套交付要求。

热词解决的是词汇线索

会议里反复出现项目名或技术名词时，可以提供自定义词汇。文件示例使用 --context_info "Microsoft,VibeVoice" 给识别过程加入领域线索；文档把它解释为与非流式模型类似的热词机制。

如果团队要转写包含内部项目名的讨论，可以先准备相关词汇再试录一小段。这是由官方接口推导的使用方式，不是本文已经完成的中文测试。热词也不等于强制替换文本：它帮助模型偏向特定词，并不能保证听不清的名字必然识别正确。模型卡列出中文、英语等十种语言，语言覆盖同样不能替代对实际口音、噪声和抢话场景的核验。

从哪里开始尝试

模型卡提供权重、代码和在线演示入口，本地文档则提供完整运行路径。愿意接入的开发者可以先从官方麦克风演示理解输出节奏，再决定是否接入自己的会议界面。官方推荐 NVIDIA 容器环境，要求安装项目与音频解码所需的 FFmpeg；它不是下载一份字幕文件就能完成的桌面工具。

代码和模型卡标注 MIT，许可之外仍有计算资源成本。仓库同时把项目定位在研究与开发，建议实际应用前进一步测试。对只想立即得到可交付会议纪要的人，这些条件比模型名字中的参数规模更重要；对正在寻找“现场文字加说话人”基础能力的团队，它提供了一个具体、可检查的起点。

参考资料

• Streaming-7B 官方模型卡
• 官方流式使用文档
• 官方发布记录与项目说明
• 此次检查点的预处理配置