- 微软 2026 年 9 月 3 日开源流式语音识别模型 VibeVoice-ASR-Streaming，放出 7B 与 1.5B 两档权重，MIT 许可证，技术报告为 arXiv:2609.02812。
- 论文自述其为首批基于 LLM 的端到端流式说话人归因 ASR 方案之一：语音边进、转写边出，每个音频块输出“谁说了什么”，不再单独跑说话人分离（diarization）。
- 发布配置为 22 帧（2.9 秒）音频块加 4 帧（0.5 秒）lookahead，预期说话人归因延迟 2.00 秒；同一论文实测 Azure Conversation Transcriber 为 8.21 秒、Google Cloud Speech-to-Text 为 9.12 秒。
- 5 个评测集平均 WER/CER 24.66，在对比系统中最低：Gemini 3.5 Transcribe Live 为 25.23，ElevenLabs Scribe v2 Realtime 为 41.39；说话人归因在 13 个设置中 12 个最好或并列最好。
- 边界要一起看：MLC 九语平均上 Gemini 3.5 Transcribe Live（13.73）领先该模型（17.09），评测录音截断到 8 分钟，语言覆盖 10 种，离线版 VibeVoice-ASR 支持 50+。
- 支持自定义热词，transformers 一行加载，也可用 vLLM 部署为 WebSocket / OpenAI 兼容服务；7B 权重 BF16 约 17.3 GB。
VibeVoice-ASR-Streaming 是什么：边听边出“谁说了什么”
给会议转写或语音助手做实时字幕，屏幕上要滚动的不只是文字，还有“这句话是谁说的”。传统管线分两步：先由 ASR 把语音转成文字，再跑一个说话人分离模型，把每句话对回说话人。两个模型串行，延迟相加，对齐环节还会出错。
VibeVoice-ASR-Streaming 把这两步合成一个模型。输入是连续的音频流，输出是逐块到达的转写文本，每段文字前面带说话人标签——语音还在进，文字就出来了。论文（arXiv:2609.02812，微软研究院 Furu Wei 团队）自述它是首批基于 LLM 的端到端流式说话人归因 ASR 方案之一。权重 2026 年 9 月 2 日上传 Hugging Face，仓库更新日志标注 9 月 3 日发布。
它和 2026 年 1 月开源的离线版 VibeVoice-ASR-7B 是两条产品线：离线版一次处理最长 60 分钟音频，输出带时间戳的 Who / When / What 结构化转录，支持 50+ 语言；流式版把语言广度收到 10 种，换实时输出，面向实时助手和语音 Agent 的低延迟场景（来源：GitHub README）。
核心技术：音频块、lookahead 与已生成文本交错输入
第一个设计是流式交错输入。模型既不等整段音频，也不逐字听：语音被切成固定长度的块，发布配置为 22 个 latent frame（一帧 133.3 毫秒，约 2.9 秒）。每次输入模型的是三样东西交错而成的序列——当前音频块、4 帧（0.5 秒）lookahead 音频、已生成的历史文本。模型每隔约 2.9 秒输出一段带说话人标签的文字，上下文由历史文本接住，不需要重听全程。
这像同声传译：译员等讲话人多说半句再开口，那半句就是 0.5 秒 lookahead，够模型确认当前的说话人和词边界。论文消融实验给了数字——lookahead 从 0 帧加到 4 帧，13 个设置的平均 cpWER 从 35.88 降到 31.55（数值越低越好，来源：论文 Table 7）。
延迟是按公式算出来的：预期算法延迟等于块长的一半加 lookahead，22 帧配置即 1.45 + 0.5，约 2.00 秒。论文另测了 15 帧（2.0 秒块）小配置，延迟 1.53 秒，但发布权重为 22 帧配置，checkpoint 只能按训练时的块几何运行。作为对照，论文在同一标准下实测 Azure Conversation Transcriber 延迟 8.21 秒、Google Cloud Speech-to-Text 为 9.12 秒，且 Google 的转写标签有 42.6%–67.9% 会在 16.5–31.3 秒后被修订（来源：论文实验章节）。
第二个设计是说话人归因的端到端统一。传统管线里 diarization 是独立模型，两步误差会叠加：ASR 转错字，diarization 还要把错字对到人。VibeVoice-ASR-Streaming 把说话人标签当作生成序列的一部分，转写和归因一次完成。收益集中在会议音频：AliMeeting cpWER 39.80（Azure Conversation Transcriber 为 52.25）、AISHELL-4 为 28.70（32.51）、AMI-IHM 为 27.48（31.90）、AMI-SDM 为 39.01（41.40），13 个设置中 12 个最好或并列最好，对 Azure Conversation Transcriber 领先 2.39–12.45 个点（来源：论文 Table 2）。
性能与边界：会议场景最强，多语言平均还没赢 Gemini
先把正面数字摆全。5 个评测集（MLC-Challenge、AliMeeting、AISHELL-4、AMI-SDM、AMI-IHM）的平均 WER/CER，VibeVoice-ASR-Streaming 7B 为 24.66，低于 Gemini 3.5 Transcribe Live 的 25.23、GPT Realtime Whisper 的 39.31、GPT Live Transcribe 的 40.55、ElevenLabs Scribe v2 Realtime 的 41.39（来源：论文 Table 1）。会议基准 AISHELL-4、AliMeeting、AMI-IHM 的单项第一也全是它。
把会议集拿掉、只看 MLC 九语平均，排序反转：Gemini 3.5 Transcribe Live 为 13.73，该模型为 17.09；AMI-SDM 单项也是 Gemini 以 27.18 领先。它的优势来自多说话人会议音频，不是所有声学条件下的全面领先。选型时拿自己的音频分布对号入座，平均分只作参考。
三个工程边界要说清。其一，流式有代价：对照离线版，cpWER 上升 5.13–6.67 个点、WER 上升 0.75–3.53 个点（论文 Table 4），录音不需要实时时，离线版更准。其二，评测录音截断到 480 秒（8 分钟），更长的连续会话官方没有给数字，上线前要自测，vLLM 部署的 --max-model-len 也限制单会话时长。其三，1.5B 版本 22 帧配置的平均 cpWER 为 44.31，与 7B 的 31.55 相差 12.76 个点（论文 Table 5），轻量部署要重新算延迟与准确率的账。
语言覆盖 10 种：中、英、法、德、意、日、韩、葡、俄、西，中文、日语、韩语按字符评估。论文解释了上限来源：训练依赖 Qwen3-ForcedAligner-0.6B 的词级对齐能力。要小语种，回到离线版的 50+ 语言。
快速上手：一行 pipeline 到 vLLM 服务
前置条件：NVIDIA GPU。7B 权重 BF16 约 17.3 GB（Hugging Face 卡片把参数量标为 9B，safetensors 权重共 86.7 亿参数），之外还有 KV cache 和激活的开销，24 GB 级显卡是现实的起点。官方在 NVIDIA PyTorch 容器 24.07–25.12 上做过验证；flash-attn 可能需要手动安装；ffmpeg 必装。
拉代码装环境：
最快验证，一行加载（来自 Hugging Face 模型卡）：
麦克风实时体验，浏览器打开 http://localhost:7870，边说边看转写（官方文档用法一）：
文件推理与热词。--context_info 注入人名、术语、品牌名，识别会向这些词倾斜（官方文档用法二）：
生产部署走 vLLM：官方基于 vllm/vllm-openai:v0.14.1 镜像，入口为 vllm_plugin/scripts/start_streaming_server.py，暴露 WebSocket /v1/stream（先发 JSON 配置、再推 float32 PCM、最后发 "end"）、POST /v1/transcribe 整文件转写，以及 OpenAI 兼容的 /v1/chat/completions。前缀缓存让每个块复用之前所有块的 KV cache，会话变长，单块成本不涨。
官方文档点名的三个坑：数据并行 --dp 不可用，后来的音频块会被轮询到没见过前文的副本上，多卡用 --tp 2，或每卡一个服务、按会话路由；报 "is not a streaming checkpoint" 说明 checkpoint 缺 chunk_frames 字段，要换流式启动脚本；tokenizer 布局校验失败，需运行 generate_tokenizer_files --streaming 重新生成。OOM 时按顺序下调 --gpu-memory-utilization、--mm-processor-cache-gb、--max-model-len。块大小和 lookahead 写在 checkpoint 的 preprocessor_config.json 里，运行时改小来压延迟这条路走不通。
不想配环境，官方在线 demo 在 aka.ms/vibeasr，浏览器里试麦克风。
生态定位：微软语音版图的流式拼图
VibeVoice 家族的 ASR 线现在有三条：离线 VibeVoice-ASR-7B（60 分钟长音频、50+ 语言，2026 年 1 月开源）、本文的流式版、VibeVoice-ASR-BitNet（CPU 实时推理，权重从 4.62 GB 压到 1.58 GB，3 线程以上 RTF<1）。加上更早开源的 TTS 线，微软在把“语音进—语音出”整条链路开源化，许可证全部为 MIT；Azure AI Foundry Labs 已于 2026 年 3 月接入 ASR，开源权重与云服务并行。
对谁有用：做会议转写、语音 Agent、实时字幕的团队，原来要拼 ASR 加 diarization 两个模型和一堆胶水代码，现在一个模型出“谁说了什么”；需要私有化部署、不能把音频送公有云 API 的，MIT 权重加 vLLM 服务是一条完整路径。与 Gemini 3.5 Transcribe Live、ElevenLabs Scribe v2 Realtime 这类商用流式 API 相比，它换来的是可控与可微调，付出的是自己的 GPU 和运维。
上线前的行动清单
五条，每条对应一个部署决策：
- 先用 aka.ms/vibeasr 在线 demo 验证你的音频类型（会议、远场、口音）值不值得部署，再下载权重。
- 显存紧张或只想试效果，从 1.5B 起步；正式上会议场景用 7B，两者平均 cpWER 相差 12.76 个点。
- 把人名、产品名、术语写进 --context_info 热词，这是模型卡点名的功能，垂直场景用自己的词表先测一轮增量。
- 多卡部署用 --tp 2，不要用 --dp；请求按会话路由，不要按块路由。
- 会话超过 8 分钟先自测准确率漂移并检查 --max-model-len 上限；不做实时的长录音需求，用 VibeVoice-ASR 离线版。
AI 速览
