导读实时语音识别ASR正在从云端走向终端。会议转录、直播字幕、语音助手等场景对延迟的要求越来越苛刻——用户期望话音未落文字已经出现在屏幕上。然而现有的高精度 ASR 模型大多是离线架构需要等待一段完整语音输入后才能处理无法满足实时交互的需求。而已有的流式方案往往在精度上做出较大让步。Mistral AI 发布的 Voxtral Mini 4B Realtime试图在这两者之间找到平衡一个原生流式设计的 4.4B 参数 ASR 模型在 480ms 延迟下实现了接近离线模型的转录精度覆盖 13 种语言权重以 Apache 2.0 协议开源。更值得关注的是社区项目 voxtral-mini-realtime-rs 已将其 Q4 量化至 2.5GB通过 WebGPU 在浏览器标签页中完成端侧实时转录。本文将从实时流式 ASR 的需求出发拆解 Voxtral Realtime 的架构设计、性能表现、部署方案并讨论其在端侧 ASR 领域的定位。项目信息模型Voxtral Mini 4B Realtime团队Mistral AI时间2026 年 2 月 4 日论文链接https://arxiv.org/abs/2602.11298模型权重https://huggingface.co/mistralai/Voxtral-Mini-4B-Realtime-2602协议Apache 2.0一、为什么需要原生流式 ASR传统高精度 ASR 模型如 Whisper采用双向注意力机制bidirectional attention编码器需要看到整段音频后才能生成特征表示。这意味着模型必须等待一个完整的音频片段Whisper 固定为 30 秒输入完毕后才开始处理。对于离线转录录音文件、播客后期处理这没有问题但对于实时场景——会议同声字幕、语音助手、直播弹幕——这种等待是不可接受的。一种常见的折中方案是分块处理chunking把音频切成短片段逐段送入离线模型。但这种做法引入了两个问题一是片段边界处容易产生识别错误因为模型看不到跨片段的上下文二是每个片段仍需等待一定长度的音频积累延迟依然受限于块大小。Voxtral Realtime 走了另一条路从训练阶段就按流式设计。它的编码器使用因果注意力causal attention只关注当前和过去的音频帧不依赖未来信息文本解码与音频输入之间有明确的时间对齐关系——每个文本 token 对应 80ms 的音频。这种原生流式设计避免了分块方案的边界割裂问题同时支持配置不同的延迟从 80ms 到 2400ms在精度和延迟之间灵活取舍。二、架构设计因果编码器 延迟流建模Voxtral Realtime 由三个核心组件构成图片来源于原论文因果音频编码器Causal Audio Encoder规模32 层1280 维约970M 参数输入处理将原始波形转为128 bin 的 log-Mel 频谱图hop size 160经过 2 倍时间降采样后每 20ms 输出一个嵌入向量50Hz 帧率关键设计使用因果自注意力每一帧只关注当前及过去的输入配合750 帧滑窗注意力约 15 秒窗口支持理论上无限长的流式输入与 Whisper 编码器的核心差异Whisper 用双向注意力 LayerNorm GELUVoxtral 用因果注意力 RMSNorm SwiGLU适配层Adapter单层 MLP将编码器输出做4 倍时间压缩最终帧率降至12.5Hz每帧 80ms约 25M 参数语言解码器Language Decoder规模26 层3072 维约3.4B 参数使用分组查询注意力8 个 KV 头初始化自Ministral 3B基座模型采用8192 token 滑窗注意力同样支持长时流式推理延迟流建模Delayed Streams Modeling模型的核心创新在于流同步设计在每个解码步骤中解码器接收的输入是当前时刻音频嵌入与最近生成的文本 token 嵌入的逐元素求和。音频流和文本流之间保持固定的时间偏移即延迟模型在训练时从 80ms 到 2400ms 均匀采样不同延迟值。为了让单一模型适配不同延迟Voxtral 提出了Ada RMS-Norm通过正弦嵌入将延迟值编码为 32 维向量经 MLP 投影后以加法形式注入前馈层的归一化空间。这样只增加约 5M 参数就实现了在不同延迟设置下灵活切换无需为每个延迟单独训练模型。总参数量约4.4B970M 25M 3.4B 5M。训练策略训练分两个阶段编码器预热前 5% 训练步冻结解码器仅训练编码器和适配层学习率 4×10⁻⁴让编码器先学习音频表示端到端联合训练后 95%全部参数一起优化学习率 6×10⁻⁵训练使用z-loss 惩罚项防止 logit 幅度发散保持 softmax 归一化器接近零。三、性能数据480ms 延迟下逼近离线模型多语言基准 FLEURSWER%以下为 Voxtral Realtime 在 480ms 延迟下与其他模型的对比数据来自论文 Table 7语言Whisper离线GPT-4o mini Transcribe实时 APIVoxtral Mini V2离线Voxtral Realtime480ms英语 (en)4.003.653.324.90西班牙语 (es)2.813.412.633.31法语 (fr)5.555.844.326.42德语 (de)5.464.073.546.19意大利语 (it)2.712.822.173.27葡萄牙语 (pt)3.905.043.565.03荷兰语 (nl)5.876.004.787.07俄语 (ru)5.135.304.756.02阿拉伯语 (ar)15.4413.9913.5422.53印地语 (hi)28.878.3910.3312.88日语 (ja)4.979.894.149.59韩语 (ko)14.3019.4612.2915.74中文 (zh)7.9415.437.3010.45宏平均8.237.955.908.72在 480ms 延迟下Voxtral Realtime 的 13 语言宏平均 WER 为 8.72%与离线 Whisper8.23%差距不到 0.5 个百分点。当延迟放宽至 960ms 时WER 降至 7.70%已经优于 Whisper。英语短音频基准WER%以下为 10 个英语短音频数据集的宏平均对比数据来自论文 Table 5模型延迟宏平均 WERWhisper离线—8.39GPT-4o mini Transcribe实时 API—7.93Voxtral Mini Transcribe V2离线—7.27Scribe v2 Realtime实时 API—7.33Nemotron Streaming560ms9.59Nemotron Streaming1120ms9.41Voxtral Realtime480ms8.47Voxtral Realtime960ms7.94Voxtral Realtime2400ms7.72Voxtral Realtime 在 480ms 延迟下英语短音频 WER 为 8.47%与离线 Whisper8.39%几乎持平。论文中 GPT-4o mini Transcribe 和 Scribe v2 Realtime 均被归类为实时 API模型非离线同类流式模型 Nemotron Streaming 在 560ms 延迟下 WER 为 9.59%差距明显。英语长音频基准WER%长音频场景下 Voxtral Realtime 表现更好数据来自论文 Table 6模型延迟宏平均 WERWhisper离线—7.97GPT-4o mini Transcribe实时 API—7.97Voxtral Mini Transcribe V2离线—7.11Scribe v2 Realtime实时 API—7.43Voxtral Realtime480ms7.73Voxtral Realtime960ms7.13在 480ms 延迟下Voxtral Realtime 的长音频 WER 7.73% 已经优于Whisper离线和 GPT-4o mini Transcribe实时 API的 7.97%。延迟-精度权衡模型支持从 80ms 到 2400ms 的延迟配置用户可根据场景灵活选择延迟英语短音频 WERFLEURS 宏平均 WER适用场景240ms9.9510.80极低延迟语音交互480ms8.478.72实时字幕 / 语音助手推荐960ms7.947.70会议转录2400ms7.726.73高精度字幕生成注适用场景列为编者建议非论文原文。图片来源于原论文四、部署方案从 GPU 服务器到浏览器标签页服务器端部署vLLM推荐Voxtral Realtime 已集成到vLLM推理框架支持生产级流式服务# 安装 uv pip install -U vllm uv pip install soxr librosa soundfile uv pip install --upgrade transformers # 启动服务 VLLM_DISABLE_COMPILE_CACHE1 vllm serve mistralai/Voxtral-Mini-4B-Realtime-2602 \ --compilation_config {cudagraph_mode: PIECEWISE}vLLM 为该模型做了专门优化定制的 paged-attention 后端处理编码器50Hz与解码器12.5Hz的异构 KV 缓存支持可恢复请求resumable requests每 80ms 增量音频更新时保留 KV 状态通过 WebSocket 双向端点实现边接收音频、边输出文本。GPU 显存要求BF16 推理需 16GB 以上 VRAM。Transformers 推理Transformers v5.2.0已原生支持from transformers import VoxtralRealtimeForConditionalGeneration, AutoProcessor from mistral_common.tokens.tokenizers.audio import Audio repo_id mistralai/Voxtral-Mini-4B-Realtime-2602 processor AutoProcessor.from_pretrained(repo_id) model VoxtralRealtimeForConditionalGeneration.from_pretrained( repo_id, device_mapauto ) audio Audio.from_file(audio_file.mp3, strictFalse) audio.resample(processor.feature_extractor.sampling_rate) inputs processor(audio.audio_array, return_tensorspt) inputs inputs.to(model.device, dtypemodel.dtype) outputs model.generate(**inputs) decoded_outputs processor.batch_decode(outputs, skip_special_tokensTrue) print(decoded_outputs[0])推荐配置temperature 设为 0.01 小时音频需设置--max-model-len 45000计算公式音频秒数 / 0.08。浏览器端部署WebGPU社区开发者基于 Burn ML 框架Rust实现了 Voxtral Realtime 的纯 Rust 推理引擎voxtral-mini-realtime-rs并通过 WASM WebGPU 将其部署在浏览器中模型体积Q4_0 量化后约2.5GB原始 F32 约 16GB量化方案4-bit 量化block size 32每 block 18 字节浏览器适配GGUF 文件切分为 512MB 分片绕过浏览器 ArrayBuffer 大小限制使用自定义 WGSL shader 实现融合反量化与矩阵乘法运行要求支持 WebGPU 的浏览器Chrome 113 或 Edge足够 RAM 容纳 2.5GB 模型在线 DemoHuggingFace Spaces 上可直接体验mistralai/Voxtral-Realtime-WebGPU其他社区实现实现语言说明voxtral.cCSalvatore Sanfilippoantirez开发纯 C 实现零外部依赖voxtral-mini-realtime-rsRust基于 Burn 框架支持本地 浏览器MLX (voxmlx / mlx-audio)PythonApple MLX 框架适配社区有两个独立实现ExecuTorch—端侧部署方案官方列出标注为未测试支持的 13 种语言英语、中文、西班牙语、法语、德语、阿拉伯语、印地语、日语、韩语、俄语、意大利语、荷兰语、葡萄牙语。五、总结与思考Voxtral Realtime 在端侧实时 ASR 领域提供了一个值得关注的选项其核心特点可以从三个维度理解与离线模型的关系Voxtral Realtime 不是要替代 Whisper 或 GPT-4o Transcribe 等离线模型而是填补需要实时输出的场景空白。在 480ms 延迟下它的精度与离线 Whisper 的差距控制在 1% WER 以内长音频场景甚至更优这是此前流式模型难以达到的水平。与 Moonshine 等轻量端侧模型的定位差异Moonshine27M-61M 参数面向极端资源受限的设备仅支持英语模型极小但精度有限。Voxtral Realtime4.4B 参数体量大得多覆盖 13 种语言适合有一定算力条件的端侧场景如带独立 GPU 的笔记本、WebGPU 浏览器环境。两者面向不同的硬件层级。实际部署考量BF16 全精度推理需要 16GB 以上显存适合服务器端Q4 量化后 2.5GB 可在浏览器中运行但需要 WebGPU 支持和足够内存移动端浏览器的 WebGPU 支持仍在普及中实际运行效果受设备 GPU 性能限制推荐延迟 480ms 是精度与响应速度的平衡点对精度要求更高的场景可选 960ms 或 2400msApache 2.0 协议允许商业使用数据不出本地适合隐私敏感场景适用场景私有会议转录、直播实时字幕、语音助手的前端识别模块、需要多语言支持的跨国协作工具。