FunASR 多线程并发完整指南：几个关键参数让实时识别吞吐量翻倍

FunASR 多线程并发完整指南几个关键参数让实时识别吞吐量翻倍【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASRFunASR 是一个开源语音识别工具包覆盖训练、推理、流式识别、VAD、标点与说话人分离并能以 WebSocket 形式对外提供识别服务。当你同时有多路语音流打进一台 FunASR 服务时FunASR 多线程并发就是提升吞吐量的关键把收音频和跑模型拆开让事件循环不被推理阻塞单个实例就能扛住十几路实时连接。️ 真实场景直播字幕与客服高峰为什么先崩先说结论并发场景下最常见的故障不是算得慢而是排队堵死。想象一场带货直播要上实时字幕或语音客服系统午高峰 50 人同时来电。几十个 WebSocket 长连接同时在线每路客户端按 100ms 一帧持续推 PCM。如果识别逻辑是同步执行的一次离线推理要几秒期间整条连接循环被占住——这一路用户的音频没人接其他用户的新帧也在队列里干等字幕延迟越滚越大最后超时断开。仓库里这份服务脚本 funasr_wss_server.py 打印的 now supports multi-client with non-blocking inference 说的正是这次改造支持多客户端、推理不阻塞事件循环。 原理拆解异步接收 线程池处理为什么有效用一家餐厅来类比。服务员asyncio 事件循环负责收订单、上菜、招呼客人动作轻快可以来回跑真正炒菜的是后厨的 N 个厨师ThreadPoolExecutor 线程池。订单一旦交给厨师服务员立刻回大厅服务下一桌而不是站在灶台前干等。FunASR 的 WebSocket 服务就是这个分工async for message in websocket收到的每一帧音频只做攒帧、计数这类轻活真正耗时的model.generate()是阻塞调用被包进线程池异步执行。收包吞吐和算力吞吐从此解耦——连接再多事件循环也只管调度推理重叠着跑吞吐量自然上去了。 源码走读状态隔离与任务调度怎么落地并发服务最怕串味A 用户的缓存混进 B 用户的识别。看 funasr_wss_server.py 第 353-356 行每个连接建立时各建一套状态字典分别存流式 ASR、VAD、标点的上下文互不干扰websocket.status_dict_asr {} # hotword 等 websocket.status_dict_asr_online {cache: {}, is_final: False} websocket.status_dict_vad {cache: {}, is_final: False} websocket.status_dict_punc {cache: {}}任务调度端第 296-316 行用线程池 信号量两道闸线程池控制同时开几个厨师信号量控制每种模型同时放几个任务进灶台防止 GPU 被打爆rec_out await run_blocking( _generate_sync, model_asr_streaming, audio_in, websocket.status_dict_asr_online, semSEM_ASR_ONLINE, )⚙️ 调优实战ncpu / ngpu / device 与三种模式怎么选如何设置 ncpu 让 8 核机器跑满ncpu传给每个AutoModel控制模型内部特征提取、VAD 等 CPU 侧计算的线程数。GPU 推理场景下 CPU 只干杂活配 1-2 即可纯 CPU 部署--device cpu --ngpu 0才需要给到物理核心数。另外两个容易忽略的旋钮--worker_threads是线程池大小默认取 CPU 核数--concurrent_asr_online/--concurrent_asr_offline/--concurrent_vad是各模型的同时推理上限。记住厨师别超过灶台线程开再多超过物理核只会互相抢调度吞吐反而下降。启动示例python runtime/python/websocket/funasr_wss_server.py \ --device cuda --ngpu 1 --ncpu 2 \ --worker_threads 8 --port 10095online / offline / 2pass 怎么选客户端连上后发一条 JSON 指定mode。online只跑流式模型延迟最低适合实时字幕、语音助手offline攒整句再跑离线大模型精度最高适合录音转写、质检这类批量场景2pass是默认模式两条线并行VAD 检测到句尾后离线 Paraformer 的结果修正并替换掉在线初稿——用户先秒级看到文字稍后收到更准的版本延迟和精度兼得。 效果验证12-16 路并发下的实测数字看仓库自带的基准 realtime_ws_benchmark.md单张 H100 80GB、47 秒中文录音按 100ms 帧循环回放、多客户端同时压测。旧版串行服务v1.4.3在 12 路并发下端到端只做到约 8.4 倍实时句末出最终结果的 p50 要 19.5 秒换成推理卸载线程池 并发批处理后的新版12 路并发跑到约 11.6 倍实时11566 秒音频 ÷ 48.8 秒墙钟最终结果 p50 降到 0.41 秒首次出字延迟几乎没变485ms vs 462ms。16 路并发时差距更大8.56x 对 13.17x最终结果从 40.5 秒缩到 9.8 秒。这组数字说明并发能力不是玄学异步接收 线程池 限流每一步都有可测量的回报。✅ 行动清单照着做就能上线部署语音识别服务克隆仓库git clone https://gitcode.com/GitHub_Trending/fun/FunASR按 runtime/python/websocket/README.md 装依赖并启动服务。起步配置1 张 GPU 8 核 CPU 的机器--ncpu 2 --worker_threads 8多客户端场景一律选2pass。盯两个指标CPU/GPU 利用率与 p95 最终结果延迟。CPU 长期打满说明ncpu或worker_threads开大了往下调GPU 打满且 p95 飙升说明该加实例了别再加线程。水平扩容别只调线程用 Nginx 把多台识别服务挂成 upstream 轮询配合健康检查摘除故障节点——单实例参数调优有天花板横向扩才是并发峰值大促直播、客服高峰的解法。【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考