Chrome vs Edge:哪个更适合运行 Fun-ASR WebUI
在语音识别技术快速落地的今天,越来越多企业开始部署本地化的大模型 ASR 系统。Fun-ASR 作为钉钉与通义实验室联合推出的高性能语音识别方案,凭借其高精度、多语种支持和低延迟推理能力,正被广泛应用于会议纪要生成、客服录音质检、教学内容转录等实际场景。而为了让非技术人员也能便捷使用,Fun-ASR 提供了基于 Gradio 构建的 WebUI 界面——用户只需打开浏览器,即可完成音频上传、实时录音、结果查看等操作。
但你有没有遇到过这样的情况:明明模型服务正常运行,前端页面也加载成功,可点击'开始录音'却毫无反应?或者长时间录制中途突然中断,刷新后历史记录全丢?这些问题往往不在于模型本身,而是浏览器的选择与配置不当所导致的功能异常或性能瓶颈。
尤其是在 Windows 环境下,Chrome 和 Edge 都是 Chromium 内核的主流浏览器,表面上看几乎一模一样,但在处理像 Fun-ASR 这类依赖音频采集、WebSocket 实时通信和 GPU 加速渲染的复杂 Web 应用时,两者的表现其实存在微妙却关键的差异。
从一次真实故障说起
某客户在会议室部署了一套 Fun-ASR 本地系统,用于自动记录每日例会内容。他们使用的是预装 Windows 的笔记本,默认浏览器为 Microsoft Edge。初期测试顺利,但连续运行超过 20 分钟后,系统频繁出现'麦克风断开'提示,且无法自动恢复。更换设备重试仍复现问题。
技术人员排查后发现,并非硬件或网络原因。最终通过切换至 Google Chrome 浏览器,问题彻底消失。进一步分析表明,Edge 在默认'效率模式'下对后台标签页的 CPU 调度进行了限制,导致 Web Audio API 缓冲区未能及时处理音频流,从而引发溢出崩溃。
这个案例揭示了一个常被忽视的事实:浏览器不仅是网页容器,更是决定 AI 应用能否稳定运行的关键环节。
Chrome:开发者首选,稳定性压倒一切
Google Chrome 自诞生以来就以性能领先著称,尤其在开发调试领域几乎成为标准工具链的一部分。对于 Fun-ASR WebUI 这样的工程级应用,它的优势体现在多个层面:
首先是 对 WebRTC 和 MediaDevices API 的极致支持。navigator.mediaDevices.getUserMedia() 是实现浏览器内录音的核心接口,Chrome 不仅最早完整实现该规范,而且在各种外设(如 USB 阵列麦克风、专业声卡)上的兼容性表现最为稳健。
async function startMicrophoneStream() {
try {
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: false });
const audioContext = new AudioContext();
const source = audioContext.createMediaStreamSource(stream);
console.log("麦克风已启用");
return source;
} catch (error) {
.(, error);
error;
}
}

