2026/9/7 23:35:12
FEATURED · 精选文章 
用户一多识别就卡3步打通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/FunASR做过语音识别服务的同学大概都遇到过这个场景一个人用着挺流畅用户一多起来识别结果就开始挤牙膏甚至整个服务像死机了一样没反应。其实瓶颈往往不在模型本身而在服务的并发处理能力上。开源语音识别工具包 FunASR 的 WebSocket 服务端runtime/python/websocket/内置了一套多线程并发机制通过异步事件循环 线程池 按模块限流的组合让单机服务能同时扛住多个用户而且不用改一行模型代码就能上手。原理讲明白一个前台一排灶台不贴代码用开饭店的方式理解这套机制 前台asyncio 事件循环负责接待所有客人WebSocket 连接接单、传菜、上菜都是它干。它自己不下厨所以哪怕同时挂着几百个连接也不会被某个慢活儿拖住。灶台线程池 ThreadPoolExecutor真正费算力的炒菜VAD 端点检测、ASR 推理丢给后台一群灶台并行做。开几个灶台由--worker_threads决定默认取4 和 CPU 核数中的较大值保证事件循环不被阻塞计算卡死。每道菜的限流口信号量灶台再多也不能一锅乱炖。服务端给 VAD、流式 ASR、离线 ASR、标点、说话人识别各设了独立的并发上限默认分别是 4、4、2、1、1相当于每个窗口前只排固定长度队重活儿离线 ASR自然被控制住轻活儿VAD先跑起来谁也不会饿死。独立餐位连接级状态字典每个 WebSocket 连接都有自己独立的缓存和状态A 用户的音频片段绝不会混进 B 用户的识别结果里多用户并行天然隔离。一句话总结前台管接待、灶台管算力、限流口管公平——这就是 FunASR 并发吞吐量的来源。三步开启并发识别服务拿到代码并装好依赖若已装过 funasr 可跳过前两步git clone https://gitcode.com/GitHub_Trending/fun/FunASR cd FunASR pip install -U funasr cd runtime/python/websocket pip install -r requirements_server.txt启动服务端按需带上并发参数python funasr_wss_server.py --port 10095 --ncpu 4 --worker_threads 8关键参数速查--ncpu单次推理占用的 CPU 核数别超过物理核数--worker_threads线程池大小决定灶台数默认max(4, CPU核数)--concurrent_asr_offline离线/2pass 识别并发上限默认 2GPU 富余可调大--ngpu/--device指定计算设备GPU 推理时把并发压力从 CPU 转移到显卡拉起客户端压测用麦克风试或直接喂 wav.scp 文件python funasr_wss_client.py --host 127.0.0.1 --port 10095 --mode 2pass --audio_in ./data/wav.scp--mode可选online纯流式、offline离线、2pass流式先出结果、离线再修正兼顾延迟和准确率。线程数怎么配不踩坑4个常见问题问题1并发一上来所有用户的结果都变慢原因推理是阻塞型重计算如果全挤在事件循环上一个长音频就能卡住所有连接。 解法确认服务端用了线程池卸载run_blocking机制并把--worker_threads设为与物理核数相当的值让推理真正并行起来。问题2线程加多了CPU 100% 反而吞吐下降原因线程过多引发上下文切换和内存争抢--ncpu过大时每次推理还在互相抢核。 解法--ncpu控制在物理核数的 1~2 倍以内用top看稳态 CPU 占用利用率超过 90% 就停止加线程——此时瓶颈是硬件不是线程数。问题32pass 模式下离线修正迟迟不回来原因离线 ASR 模型比流式模型重得多而默认并发上限只有 2多人同时说完话就会排队。 解法GPU 有余量就调大--concurrent_asr_offline没有余量就上多实例前面挂一层 Nginx 做负载均衡横向扩容。问题4结果整体不慢唯独带标点的那一步拖后腿原因标点模型CT-Transformer默认并发是 1属于刻意保守。 解法确认它确实是链路最慢环节后适度调大--concurrent_punc观察延迟变化即可 ⚙️三句话收尾FunASR 的并发 异步事件循环接连接 线程池跑推理 各模块信号量限流三者缺一不可调优顺序先定--ncpu和--worker_threads再按最慢环节调--concurrent_*最后才考虑多实例扩容动手前先看官方示例和服务端源码runtime/python/websocket/进阶问题可查 docs/reference/FQA.md【免费下载链接】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），仅供参考
用户一多识别就卡？3步打通FunASR多线程并发，吞吐量拉满
用户一多识别就卡3步打通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/FunASR做过语音识别服务的同学大概都遇到过这个场景一个人用着挺流畅用户一多起来识别结果就开始挤牙膏甚至整个服务像死机了一样没反应。其实瓶颈往往不在模型本身而在服务的并发处理能力上。开源语音识别工具包 FunASR 的 WebSocket 服务端runtime/python/websocket/内置了一套多线程并发机制通过异步事件循环 线程池 按模块限流的组合让单机服务能同时扛住多个用户而且不用改一行模型代码就能上手。原理讲明白一个前台一排灶台不贴代码用开饭店的方式理解这套机制 前台asyncio 事件循环负责接待所有客人WebSocket 连接接单、传菜、上菜都是它干。它自己不下厨所以哪怕同时挂着几百个连接也不会被某个慢活儿拖住。灶台线程池 ThreadPoolExecutor真正费算力的炒菜VAD 端点检测、ASR 推理丢给后台一群灶台并行做。开几个灶台由--worker_threads决定默认取4 和 CPU 核数中的较大值保证事件循环不被阻塞计算卡死。每道菜的限流口信号量灶台再多也不能一锅乱炖。服务端给 VAD、流式 ASR、离线 ASR、标点、说话人识别各设了独立的并发上限默认分别是 4、4、2、1、1相当于每个窗口前只排固定长度队重活儿离线 ASR自然被控制住轻活儿VAD先跑起来谁也不会饿死。独立餐位连接级状态字典每个 WebSocket 连接都有自己独立的缓存和状态A 用户的音频片段绝不会混进 B 用户的识别结果里多用户并行天然隔离。一句话总结前台管接待、灶台管算力、限流口管公平——这就是 FunASR 并发吞吐量的来源。三步开启并发识别服务拿到代码并装好依赖若已装过 funasr 可跳过前两步git clone https://gitcode.com/GitHub_Trending/fun/FunASR cd FunASR pip install -U funasr cd runtime/python/websocket pip install -r requirements_server.txt启动服务端按需带上并发参数python funasr_wss_server.py --port 10095 --ncpu 4 --worker_threads 8关键参数速查--ncpu单次推理占用的 CPU 核数别超过物理核数--worker_threads线程池大小决定灶台数默认max(4, CPU核数)--concurrent_asr_offline离线/2pass 识别并发上限默认 2GPU 富余可调大--ngpu/--device指定计算设备GPU 推理时把并发压力从 CPU 转移到显卡拉起客户端压测用麦克风试或直接喂 wav.scp 文件python funasr_wss_client.py --host 127.0.0.1 --port 10095 --mode 2pass --audio_in ./data/wav.scp--mode可选online纯流式、offline离线、2pass流式先出结果、离线再修正兼顾延迟和准确率。线程数怎么配不踩坑4个常见问题问题1并发一上来所有用户的结果都变慢原因推理是阻塞型重计算如果全挤在事件循环上一个长音频就能卡住所有连接。 解法确认服务端用了线程池卸载run_blocking机制并把--worker_threads设为与物理核数相当的值让推理真正并行起来。问题2线程加多了CPU 100% 反而吞吐下降原因线程过多引发上下文切换和内存争抢--ncpu过大时每次推理还在互相抢核。 解法--ncpu控制在物理核数的 1~2 倍以内用top看稳态 CPU 占用利用率超过 90% 就停止加线程——此时瓶颈是硬件不是线程数。问题32pass 模式下离线修正迟迟不回来原因离线 ASR 模型比流式模型重得多而默认并发上限只有 2多人同时说完话就会排队。 解法GPU 有余量就调大--concurrent_asr_offline没有余量就上多实例前面挂一层 Nginx 做负载均衡横向扩容。问题4结果整体不慢唯独带标点的那一步拖后腿原因标点模型CT-Transformer默认并发是 1属于刻意保守。 解法确认它确实是链路最慢环节后适度调大--concurrent_punc观察延迟变化即可 ⚙️三句话收尾FunASR 的并发 异步事件循环接连接 线程池跑推理 各模块信号量限流三者缺一不可调优顺序先定--ncpu和--worker_threads再按最慢环节调--concurrent_*最后才考虑多实例扩容动手前先看官方示例和服务端源码runtime/python/websocket/进阶问题可查 docs/reference/FQA.md【免费下载链接】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），仅供参考 
