路线图展望Voxtral-Mini-4B-Realtime-2602-NPU 的实时流式 WebSocket 部署何时到来【免费下载链接】Voxtral-Mini-4B-Realtime-2602-NPU项目地址: https://ai.gitcode.com/z_studio/Voxtral-Mini-4B-Realtime-2602-NPUVoxtral-Mini-4B-Realtime-2602-NPU 是一个将 Mistral AI 开源的原生流式实时语音转写模型完整部署到昇腾 NPUAscend 910B4上的开源项目。目前整段音频转写已经稳定可用而社区最关心的实时流式 WebSocket 部署vLLM 的/v1/realtime接口正处于「服务能启动、推理差一步」的关键阶段。本文结合项目路线图为你梳理当前进展、核心卡点与上线时间预判帮你判断何时能用上这套完整方案。为什么实时流式 WebSocket 部署这么重要Voxtral Mini 4B Realtime 2602 是 Mistral AI 首批原生流式实时语音转写模型因果音频编码器 滑窗注意力让它从设计上就支持近乎无限的流式输入单条转写 token 约对应 80ms 音频还可在 80–1200ms 及 2400ms 之间调节转写延迟实现延迟与精度的灵活取舍。正因为模型天生为「边说边转」而生落地到真实场景就需要一个持续双向的通道——这正是WebSocket与/v1/realtime接口的价值一次连接内持续推送音频、持续返回文本无需反复握手。典型应用包括实时字幕与同声传译 语音助手与智能客服 会议、访谈的实时转写 直播与视频会议的即时字幕模型支持13 种语言含中、英、日、韩、法、德等端到端延迟可控制在 500ms 以内这让 WebSocket 流式部署成为「最后一公里」的关键拼图。现状盘点整段音频转写已在昇腾 NPU 上跑通 ✅先说好消息整段音频的离线转写已经完整可用。项目通过transformers≥5.2.0对voxtral_realtime架构的原生支持配合 torch_npu 昇腾推理引擎在 Ascend 910B4 上完成了「音频 → 文本」全链路验证适配状态为 SUCCESS。模型规格一览属性数值总参数量约 4B文本 LLM ≈3.4B 音频编码器 ≈970M权重格式bf16约 8.8GB文本主干26 层滑动窗口 8192音频编码器32 层因果编码器实测转写表现约 15.9s 经典录音生成 239 tokens 耗时 12.49s约19.1 tok/s短输出场景64 token可达24.7 tok/s转写准确、完整。上手只需一行命令推理脚本见inference.py完整说明见README.md./venv/bin/python inference.py --audio sample_en.wavvLLM-Ascend 路径服务能启动WebSocket 推理差最后一步如果只需要离线转写上面已经足够。但要拿到/v1/realtimeWebSocket 流式接口就必须走 vLLM 部署路线。项目通过sitecustomize.py完成了 vLLM-Ascend 的框架侧兼容适配共打了 5 类关键补丁whisper 因果编码器的 Ascend 注意力后端白名单torch.hann_window、torch.stft、复数abs的 NPU 安全改写VoxtralRealtimeGeneration.forward兼容 vllm-ascend 的 profile 阶段当前成果模型可正常加载、服务可正常启动/v1/models返回 200/v1/realtime路由注册成功。也就是说WebSocket 服务的「壳」已经就位。卡点剖析为什么 whisper-causal 注意力会段错误差的一步在真正的推理环节当模型开始实际推理时whisper 因果编码器的block-pooling 注意力会在 ATBAscend TensorBoost算子初始化阶段触发原生段错误Segfault atb::OperationSetup根因很明确vllm-ascend 尚未适配 Voxtral-Realtime 特有的块池化 KV Cache 注意力布局属于框架侧能力缺失需要上游补齐而不是模型本身的问题。这也是项目默认推理路径采用 transformers torch_npu 方案已验证完整可用的原因。路线图展望实时流式 WebSocket 部署何时到来综合项目路线图与上游动态可以归纳为清晰的「三步走」阶段内容状态第一步transformers torch_npu 整段音频转写✅ 已完成第二步vllm-ascend 适配块池化注意力 依赖上游第三步/v1/realtimeWebSocket 全链路打通⏳ 可预期时间上第二步完全取决于 vllm-ascend 对 Voxtral-Realtime 注意力的支持进度——上游一旦合入第三步的 WebSocket 部署就能在现有基础上快速落地。对开发者而言这正是一个跟进上游进展、甚至提交贡献的绝佳窗口期。等待期间你现在就能上手的三件事与其干等不如先把能做的做起来1. 克隆仓库并搭建环境 ️git clone https://gitcode.com/z_studio/Voxtral-Mini-4B-Realtime-2602-NPU依赖清单见requirements.txttransformers5.15.0、mistral-common[audio]1.11.7建议用--system-site-packages创建 venv继承系统已装好的 torch / torch_npu 与 CANN避免版本冲突。2. 用内置音频跑通整段转写 仓库自带sample_en.wav可直接体验「音频 → 文本」全流程感受 4B 实时模型在昇腾 NPU 上的实际表现并尝试--max-new-tokens、--dtype等参数调优。3. 学会用 npu-smi 监控你的 NPU 实时流式部署对设备健康度要求更高建议从现在就养成监控习惯用npu-smi info查看芯片健康、功率与温度并通过ASCEND_RT_VISIBLE_DEVICES指定逻辑卡本仓库验证环境为 Ascend 910B4单卡 64GB HBM。结语东风已备只待上游合入Voxtral-Mini-4B-Realtime-2602-NPU 已经将「整段转写」和「WebSocket 服务框架」两块拼图都放上了桌面剩下的关键一步——vllm-ascend 对块池化注意力的适配——正在上游推进。对普通用户而言当前的离线路径已经足够好上手对流式场景密切关注 vllm-ascend 的更新即可。这条路已经看得到终点。【免费下载链接】Voxtral-Mini-4B-Realtime-2602-NPU项目地址: https://ai.gitcode.com/z_studio/Voxtral-Mini-4B-Realtime-2602-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 路线图展望：Voxtral-Mini-4B-Realtime-2602-NPU 的实时流式 WebSocket 部署何时到来？
路线图展望Voxtral-Mini-4B-Realtime-2602-NPU 的实时流式 WebSocket 部署何时到来【免费下载链接】Voxtral-Mini-4B-Realtime-2602-NPU项目地址: https://ai.gitcode.com/z_studio/Voxtral-Mini-4B-Realtime-2602-NPUVoxtral-Mini-4B-Realtime-2602-NPU 是一个将 Mistral AI 开源的原生流式实时语音转写模型完整部署到昇腾 NPUAscend 910B4上的开源项目。目前整段音频转写已经稳定可用而社区最关心的实时流式 WebSocket 部署vLLM 的/v1/realtime接口正处于「服务能启动、推理差一步」的关键阶段。本文结合项目路线图为你梳理当前进展、核心卡点与上线时间预判帮你判断何时能用上这套完整方案。为什么实时流式 WebSocket 部署这么重要Voxtral Mini 4B Realtime 2602 是 Mistral AI 首批原生流式实时语音转写模型因果音频编码器 滑窗注意力让它从设计上就支持近乎无限的流式输入单条转写 token 约对应 80ms 音频还可在 80–1200ms 及 2400ms 之间调节转写延迟实现延迟与精度的灵活取舍。正因为模型天生为「边说边转」而生落地到真实场景就需要一个持续双向的通道——这正是WebSocket与/v1/realtime接口的价值一次连接内持续推送音频、持续返回文本无需反复握手。典型应用包括实时字幕与同声传译 语音助手与智能客服 会议、访谈的实时转写 直播与视频会议的即时字幕模型支持13 种语言含中、英、日、韩、法、德等端到端延迟可控制在 500ms 以内这让 WebSocket 流式部署成为「最后一公里」的关键拼图。现状盘点整段音频转写已在昇腾 NPU 上跑通 ✅先说好消息整段音频的离线转写已经完整可用。项目通过transformers≥5.2.0对voxtral_realtime架构的原生支持配合 torch_npu 昇腾推理引擎在 Ascend 910B4 上完成了「音频 → 文本」全链路验证适配状态为 SUCCESS。模型规格一览属性数值总参数量约 4B文本 LLM ≈3.4B 音频编码器 ≈970M权重格式bf16约 8.8GB文本主干26 层滑动窗口 8192音频编码器32 层因果编码器实测转写表现约 15.9s 经典录音生成 239 tokens 耗时 12.49s约19.1 tok/s短输出场景64 token可达24.7 tok/s转写准确、完整。上手只需一行命令推理脚本见inference.py完整说明见README.md./venv/bin/python inference.py --audio sample_en.wavvLLM-Ascend 路径服务能启动WebSocket 推理差最后一步如果只需要离线转写上面已经足够。但要拿到/v1/realtimeWebSocket 流式接口就必须走 vLLM 部署路线。项目通过sitecustomize.py完成了 vLLM-Ascend 的框架侧兼容适配共打了 5 类关键补丁whisper 因果编码器的 Ascend 注意力后端白名单torch.hann_window、torch.stft、复数abs的 NPU 安全改写VoxtralRealtimeGeneration.forward兼容 vllm-ascend 的 profile 阶段当前成果模型可正常加载、服务可正常启动/v1/models返回 200/v1/realtime路由注册成功。也就是说WebSocket 服务的「壳」已经就位。卡点剖析为什么 whisper-causal 注意力会段错误差的一步在真正的推理环节当模型开始实际推理时whisper 因果编码器的block-pooling 注意力会在 ATBAscend TensorBoost算子初始化阶段触发原生段错误Segfault atb::OperationSetup根因很明确vllm-ascend 尚未适配 Voxtral-Realtime 特有的块池化 KV Cache 注意力布局属于框架侧能力缺失需要上游补齐而不是模型本身的问题。这也是项目默认推理路径采用 transformers torch_npu 方案已验证完整可用的原因。路线图展望实时流式 WebSocket 部署何时到来综合项目路线图与上游动态可以归纳为清晰的「三步走」阶段内容状态第一步transformers torch_npu 整段音频转写✅ 已完成第二步vllm-ascend 适配块池化注意力 依赖上游第三步/v1/realtimeWebSocket 全链路打通⏳ 可预期时间上第二步完全取决于 vllm-ascend 对 Voxtral-Realtime 注意力的支持进度——上游一旦合入第三步的 WebSocket 部署就能在现有基础上快速落地。对开发者而言这正是一个跟进上游进展、甚至提交贡献的绝佳窗口期。等待期间你现在就能上手的三件事与其干等不如先把能做的做起来1. 克隆仓库并搭建环境 ️git clone https://gitcode.com/z_studio/Voxtral-Mini-4B-Realtime-2602-NPU依赖清单见requirements.txttransformers5.15.0、mistral-common[audio]1.11.7建议用--system-site-packages创建 venv继承系统已装好的 torch / torch_npu 与 CANN避免版本冲突。2. 用内置音频跑通整段转写 仓库自带sample_en.wav可直接体验「音频 → 文本」全流程感受 4B 实时模型在昇腾 NPU 上的实际表现并尝试--max-new-tokens、--dtype等参数调优。3. 学会用 npu-smi 监控你的 NPU 实时流式部署对设备健康度要求更高建议从现在就养成监控习惯用npu-smi info查看芯片健康、功率与温度并通过ASCEND_RT_VISIBLE_DEVICES指定逻辑卡本仓库验证环境为 Ascend 910B4单卡 64GB HBM。结语东风已备只待上游合入Voxtral-Mini-4B-Realtime-2602-NPU 已经将「整段转写」和「WebSocket 服务框架」两块拼图都放上了桌面剩下的关键一步——vllm-ascend 对块池化注意力的适配——正在上游推进。对普通用户而言当前的离线路径已经足够好上手对流式场景密切关注 vllm-ascend 的更新即可。这条路已经看得到终点。【免费下载链接】Voxtral-Mini-4B-Realtime-2602-NPU项目地址: https://ai.gitcode.com/z_studio/Voxtral-Mini-4B-Realtime-2602-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考