FunASR 多线程并发实战4 核从 3.2 到 14.3 rps 的完整调优指南【免费下载链接】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 websocket 服务单线程每秒 3.2 个请求4 线程就是 11.8。FunASR 多线程并发并不神秘asyncio 异步收包 线程池推理。本文拆透这层并发架构给出 ncpu、ngpu、device 与模式选择建议。先看效果4 核 CPU 下 rps 差多少先说结论再看原因。4 核 CPU 上推理线程数直接决定 FunASR 并发吞吐的上限并发配置rps相对单线程1 线程ncpu13.2—4 线程11.8269%8 线程14.3约 4.5 倍4 线程拿到 269% 的提升8 线程相比 4 线程只多了 21%。收益在 8 线程后明显递减瓶颈从“等线程”转移到“模型推理本身”继续加线程只会浪费 CPU 在调度上。这张表4 核 CPU 实测出处 benchmarks/benchmark_pipeline_cer.md就是本文一切参数调优的起点并发是语音识别性能调优的第一杠杆模型都不用换。原理速览异步接收 线程池的两层分工并发代码全部集中在 funasr_wss_server.py就两层。外层是websockets库加 asyncio 事件循环只干一件事接连接、收音频帧。这层是非阻塞的撑起数千级并发连接不费力。内层是run_blocking投递的ThreadPoolExecutor线程池max_workers由--worker_threads指定默认max(4, 物理核数)。model.generate()这类阻塞计算只在线程池里跑。中间还有一组 asyncio 信号量给推理限流VAD 并发上限 4、流式 ASR 4、离线 ASR 2对应--concurrent_vad、--concurrent_asr_online、--concurrent_asr_offline防止事件循环被拖死、GPU 被打爆。一句话记住分工事件循环不做计算线程池不做 I/O。请求是怎么跑起来的状态隔离与三级流水线并发最怕串数据。FunASR 的办法是把状态挂在连接上——建连时在 websocket 对象上挂一套独立的 status dict流式模型靠 cache 做增量解码generate 会把 cache 写回websocket.status_dict_asr_online {cache: {}, is_final: False} websocket.status_dict_vad {cache: {}, is_final: False}活跃连接统一放进全局websocket_users集合断线时移除两个用户之间不共享任何一份 dict。数据流是一条三级流水线async_vad先切出语音段async_asr_online每满 10 帧chunk_interval默认 10实时解码一次把中间结果推给客户端VAD 判定说完话后再调async_asr跑一遍离线识别出最终结果。调度条件就写在消息循环里online 和 offline 两条路径由它分发if len(frames_asr_online) % websocket.chunk_interval 0 \ or websocket.status_dict_asr_online[is_final]: await async_asr_online(websocket, audio_in)一个消息循环同时驱动 VAD、在线、离线三级异步任务谁就绪谁先跑。参数怎么配ncpu、ngpu、device 和模式选择服务默认值是--ncpu 4、--ngpu 10 表示全走 CPU、--device cuda。三类场景推荐值参数默认CPU 密集离线批量转写I/O 密集大量流式连接--ncpu4物理核数 × 1~1.5核数 × 2--ngpu101--devicecudacpucuda模型跑在 GPU 上时加 ncpu 收益有限先保证 GPU 数量够纯 CPU 部署时 ncpu 才是主旋钮。判断方式4 线程 rps 接近峰值的 80% 就停手再往上只赚不到 20%。online 和 2pass 怎么选模式行为适用场景online按 chunk 流式返回中间结果延迟最低实时语音交互、语音助手offline音频完整或 VAD 切段后返回最终结果录音批量转写、离线归档2pass在线先出初稿离线再精修覆盖既要实时感又要准确率2pass 等于同时跑在线和离线两遍算力消耗最大同一台 4 核机器能扛住的并发连接数最低。验证与避坑怎么确认并发真的生效了第一步看线程级 CPUtop -H逐线程显示。ncpu 个线程全部打满而 rps 不再涨说明推理是瓶颈别再加线程CPU 有余量但 rps 上不去去查信号量上限和排队时间。第二步别只看均值用官方并发客户端 realtime_ws_benchmark.py 以--clients 8回放压测对比改参前后的首包延迟 p50/p95报表字段模板见 realtime_ws_benchmark.md。性能类常见问题可查 FQA.md。单实例打满后还要更高并发方案最朴素前面挂一个 Nginxupstream 指向多个 FunASR 实例做最小连接负载均衡——连接级状态字典隔离保证了实例之间互不串扰。带走这五条基准锚点4 核下单线程 3.2 rps4 线程 11.8269%8 线程 14.38 线程后收益递减ncpu 是主旋钮默认 4CPU 密集取核数 × 1~1.5I/O 密集取 × 2有 GPU 先把 ngpu 设为 1模式选择要延迟选 online要吞吐选 offline两者都要选 2pass验证只看两样rps 和逐线程 CPUrps 走平就停止加线程转多实例示例与服务端代码看 runtime/python/websocket/基准方法论看 docs/benchmark/【免费下载链接】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），仅供参考 FunASR 多线程并发实战：4 核从 3.2 到 14.3 rps 的完整调优指南
FunASR 多线程并发实战4 核从 3.2 到 14.3 rps 的完整调优指南【免费下载链接】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 websocket 服务单线程每秒 3.2 个请求4 线程就是 11.8。FunASR 多线程并发并不神秘asyncio 异步收包 线程池推理。本文拆透这层并发架构给出 ncpu、ngpu、device 与模式选择建议。先看效果4 核 CPU 下 rps 差多少先说结论再看原因。4 核 CPU 上推理线程数直接决定 FunASR 并发吞吐的上限并发配置rps相对单线程1 线程ncpu13.2—4 线程11.8269%8 线程14.3约 4.5 倍4 线程拿到 269% 的提升8 线程相比 4 线程只多了 21%。收益在 8 线程后明显递减瓶颈从“等线程”转移到“模型推理本身”继续加线程只会浪费 CPU 在调度上。这张表4 核 CPU 实测出处 benchmarks/benchmark_pipeline_cer.md就是本文一切参数调优的起点并发是语音识别性能调优的第一杠杆模型都不用换。原理速览异步接收 线程池的两层分工并发代码全部集中在 funasr_wss_server.py就两层。外层是websockets库加 asyncio 事件循环只干一件事接连接、收音频帧。这层是非阻塞的撑起数千级并发连接不费力。内层是run_blocking投递的ThreadPoolExecutor线程池max_workers由--worker_threads指定默认max(4, 物理核数)。model.generate()这类阻塞计算只在线程池里跑。中间还有一组 asyncio 信号量给推理限流VAD 并发上限 4、流式 ASR 4、离线 ASR 2对应--concurrent_vad、--concurrent_asr_online、--concurrent_asr_offline防止事件循环被拖死、GPU 被打爆。一句话记住分工事件循环不做计算线程池不做 I/O。请求是怎么跑起来的状态隔离与三级流水线并发最怕串数据。FunASR 的办法是把状态挂在连接上——建连时在 websocket 对象上挂一套独立的 status dict流式模型靠 cache 做增量解码generate 会把 cache 写回websocket.status_dict_asr_online {cache: {}, is_final: False} websocket.status_dict_vad {cache: {}, is_final: False}活跃连接统一放进全局websocket_users集合断线时移除两个用户之间不共享任何一份 dict。数据流是一条三级流水线async_vad先切出语音段async_asr_online每满 10 帧chunk_interval默认 10实时解码一次把中间结果推给客户端VAD 判定说完话后再调async_asr跑一遍离线识别出最终结果。调度条件就写在消息循环里online 和 offline 两条路径由它分发if len(frames_asr_online) % websocket.chunk_interval 0 \ or websocket.status_dict_asr_online[is_final]: await async_asr_online(websocket, audio_in)一个消息循环同时驱动 VAD、在线、离线三级异步任务谁就绪谁先跑。参数怎么配ncpu、ngpu、device 和模式选择服务默认值是--ncpu 4、--ngpu 10 表示全走 CPU、--device cuda。三类场景推荐值参数默认CPU 密集离线批量转写I/O 密集大量流式连接--ncpu4物理核数 × 1~1.5核数 × 2--ngpu101--devicecudacpucuda模型跑在 GPU 上时加 ncpu 收益有限先保证 GPU 数量够纯 CPU 部署时 ncpu 才是主旋钮。判断方式4 线程 rps 接近峰值的 80% 就停手再往上只赚不到 20%。online 和 2pass 怎么选模式行为适用场景online按 chunk 流式返回中间结果延迟最低实时语音交互、语音助手offline音频完整或 VAD 切段后返回最终结果录音批量转写、离线归档2pass在线先出初稿离线再精修覆盖既要实时感又要准确率2pass 等于同时跑在线和离线两遍算力消耗最大同一台 4 核机器能扛住的并发连接数最低。验证与避坑怎么确认并发真的生效了第一步看线程级 CPUtop -H逐线程显示。ncpu 个线程全部打满而 rps 不再涨说明推理是瓶颈别再加线程CPU 有余量但 rps 上不去去查信号量上限和排队时间。第二步别只看均值用官方并发客户端 realtime_ws_benchmark.py 以--clients 8回放压测对比改参前后的首包延迟 p50/p95报表字段模板见 realtime_ws_benchmark.md。性能类常见问题可查 FQA.md。单实例打满后还要更高并发方案最朴素前面挂一个 Nginxupstream 指向多个 FunASR 实例做最小连接负载均衡——连接级状态字典隔离保证了实例之间互不串扰。带走这五条基准锚点4 核下单线程 3.2 rps4 线程 11.8269%8 线程 14.38 线程后收益递减ncpu 是主旋钮默认 4CPU 密集取核数 × 1~1.5I/O 密集取 × 2有 GPU 先把 ngpu 设为 1模式选择要延迟选 online要吞吐选 offline两者都要选 2pass验证只看两样rps 和逐线程 CPUrps 走平就停止加线程转多实例示例与服务端代码看 runtime/python/websocket/基准方法论看 docs/benchmark/【免费下载链接】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），仅供参考