从 19.6 秒到 414 毫秒FunASR 的 WebSocket 并发服务如何用线程池拉高语音识别吞吐量【免费下载链接】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/FunASR200 路麦克风流同时打到同一个服务上第一个用户的首条结果却卡在第二个用户的解码后面——瓶颈卡在哪一行开源语音识别工具包 FunASR 用非阻塞推理这套设计回答了 WebSocket 高并发问题本文跟着一条音频请求走完全程并告诉你该拧哪几个参数。请求进来之后发生了什么FunASR 的并发服务实现在 runtime/python/websocket/funasr_wss_server.py 中一条请求依次经过四个节点。连接建立与状态隔离。WebSocket 连接一建立服务端先给这个用户发一张独立的状态卡websocket.status_dict_asr_online {cache: {}, is_final: False} websocket.status_dict_vad {cache: {}, is_final: False}cache 是流式识别模型的记忆存着上一段音频处理到哪了。它保证了两个用户的流式识别互不污染对方的缓存断线重连也不会串台。分片调度。服务端不是收到音频就立刻送模型而是攒够 10 帧chunk_interval 默认值才跑一轮流式识别客户端大约每 600 毫秒就能看到一次草稿结果。同时 VAD 在后台判断用户何时说完了话一旦检测到语音尾点就把这一整段语音交给离线模型精识。这就是上图的 2pass在线出草稿离线做修正两者并行而不是串行排队。非阻塞推理。这是并发上最关键的一步。model.generate 是阻塞调用如果直接跑在事件循环上一次识别期间所有其他连接都收不到新音频。服务端的办法是把所有推理丢进线程池再按任务类型限流async def run_blocking(fn, *a, semNone, **kw): loop asyncio.get_running_loop() call functools.partial(fn, *a, **kw) if sem is None: return await loop.run_in_executor(EXECUTOR, call) async with sem: return await loop.run_in_executor(EXECUTOR, call)线程池就是同时能接多少路识别的座席数信号量则限制每类任务VAD、在线、离线、标点同时占用几个座席。它保证了客户端再多也只是排队不会把整个事件循环打爆。结果回流。流式结果只回草稿2pass 模式下不标 is_final离线结果附带说话人、标点和时间戳经 JSON 序列化后返回这一段结束前连接里的状态缓存才会清空。ncpu 调优ncpu、worker_threads 与并发上限设多少三个参数各管一层别混着调。ncpu默认 4推荐设为物理核心数。它传给每个模型的 CPU 推理控制特征提取等阶段的线程数。调高的代价同一进程里 VAD、流式、离线、标点、声纹共 5 个模型各自都要 ncpu 个线程设 16 实际开出 80 个线程槽内存和上下文切换开销同步上涨而 CPU 密集计算还受 GIL 限制吞吐量不会按同比例提升。worker_threads默认 max(4, cpu_count)。线程池的座席总数。调高的代价座席越多同时被叫号的音频段越多CPU 并行不过来时每段任务的排队时间变长首字延迟first_update_ms反而更差。concurrent_asr_online / concurrent_asr_offline默认 4 / 2。按任务类型限流离线识别更重所以默认上限更低。建议先保持默认观察 GPU 利用率低于 70% 时再每次加 1 重跑基准。调高的代价是显存压力一旦吃紧所有连接的解码同时变慢比排队更糟。启动方式如下python runtime/python/websocket/funasr_wss_server.py --ncpu 8 --worker_threads 8 --ngpu 1 --device cuda对 8 核机器这是一个均衡的起点座席够数线程不浪费。用数据说话12 到 16 并发吞吐量实际涨多少docs/benchmark/realtime_ws_benchmark.md 里的实测1 张 H100 80GB、vLLM 0.19.1、47 秒中文录音循环、按 100ms 帧实时发送并发客户端吞吐音频秒/挂钟时间最终结果等待 p5012优化前8.43x19,550 ms12启用并发解码与限流11.57x414 ms16优化前8.56x40,463 ms16优化后13.17x9,758 ms最终结果等待 19.6 秒 vs 414 毫秒是最直观的差距优化前一次离线解码会阻塞事件循环12 个客户端的最终结果互相排队优化后它们在各自线程池里并行执行。吞吐 8.43x → 11.57x 不是模型变快了而是模型不再阻塞接线台。离线侧另有一组数据同一 Fun-ASR-NanovLLM 批量 RTX 340 对 PyTorch 基线 21差距与并发架构处于同一量级。部署前检查清单先确认物理核心数不是逻辑核心数据此设好--ncpu与--worker_threads再启动 funasr_wss_server.py。上线前用 realtime_ws_benchmark.py 加--clients 8 --loops 3跑一遍基线记下first_update_ms_p50与final_after_stop_ms_p50两个数。⚠️ 对比版本时核对partial_messages数量若阻塞导致草稿结果变少更快是假象。按 realtime_ws_benchmark.md 的报告模板记录硬件、参数与音频保证数字可复现。参数调了仍不符合预期时先查 FQA.md 里的性能调优条目。并发的本质就三句话事件循环接电话、线程池干活、限流防打爆。想动手跑起来从 examples/ 和 docs/tutorial/ 目录开始即可。【免费下载链接】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），仅供参考 从 19.6 秒到 414 毫秒：FunASR 的 WebSocket 并发服务如何用线程池拉高语音识别吞吐量
从 19.6 秒到 414 毫秒FunASR 的 WebSocket 并发服务如何用线程池拉高语音识别吞吐量【免费下载链接】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/FunASR200 路麦克风流同时打到同一个服务上第一个用户的首条结果却卡在第二个用户的解码后面——瓶颈卡在哪一行开源语音识别工具包 FunASR 用非阻塞推理这套设计回答了 WebSocket 高并发问题本文跟着一条音频请求走完全程并告诉你该拧哪几个参数。请求进来之后发生了什么FunASR 的并发服务实现在 runtime/python/websocket/funasr_wss_server.py 中一条请求依次经过四个节点。连接建立与状态隔离。WebSocket 连接一建立服务端先给这个用户发一张独立的状态卡websocket.status_dict_asr_online {cache: {}, is_final: False} websocket.status_dict_vad {cache: {}, is_final: False}cache 是流式识别模型的记忆存着上一段音频处理到哪了。它保证了两个用户的流式识别互不污染对方的缓存断线重连也不会串台。分片调度。服务端不是收到音频就立刻送模型而是攒够 10 帧chunk_interval 默认值才跑一轮流式识别客户端大约每 600 毫秒就能看到一次草稿结果。同时 VAD 在后台判断用户何时说完了话一旦检测到语音尾点就把这一整段语音交给离线模型精识。这就是上图的 2pass在线出草稿离线做修正两者并行而不是串行排队。非阻塞推理。这是并发上最关键的一步。model.generate 是阻塞调用如果直接跑在事件循环上一次识别期间所有其他连接都收不到新音频。服务端的办法是把所有推理丢进线程池再按任务类型限流async def run_blocking(fn, *a, semNone, **kw): loop asyncio.get_running_loop() call functools.partial(fn, *a, **kw) if sem is None: return await loop.run_in_executor(EXECUTOR, call) async with sem: return await loop.run_in_executor(EXECUTOR, call)线程池就是同时能接多少路识别的座席数信号量则限制每类任务VAD、在线、离线、标点同时占用几个座席。它保证了客户端再多也只是排队不会把整个事件循环打爆。结果回流。流式结果只回草稿2pass 模式下不标 is_final离线结果附带说话人、标点和时间戳经 JSON 序列化后返回这一段结束前连接里的状态缓存才会清空。ncpu 调优ncpu、worker_threads 与并发上限设多少三个参数各管一层别混着调。ncpu默认 4推荐设为物理核心数。它传给每个模型的 CPU 推理控制特征提取等阶段的线程数。调高的代价同一进程里 VAD、流式、离线、标点、声纹共 5 个模型各自都要 ncpu 个线程设 16 实际开出 80 个线程槽内存和上下文切换开销同步上涨而 CPU 密集计算还受 GIL 限制吞吐量不会按同比例提升。worker_threads默认 max(4, cpu_count)。线程池的座席总数。调高的代价座席越多同时被叫号的音频段越多CPU 并行不过来时每段任务的排队时间变长首字延迟first_update_ms反而更差。concurrent_asr_online / concurrent_asr_offline默认 4 / 2。按任务类型限流离线识别更重所以默认上限更低。建议先保持默认观察 GPU 利用率低于 70% 时再每次加 1 重跑基准。调高的代价是显存压力一旦吃紧所有连接的解码同时变慢比排队更糟。启动方式如下python runtime/python/websocket/funasr_wss_server.py --ncpu 8 --worker_threads 8 --ngpu 1 --device cuda对 8 核机器这是一个均衡的起点座席够数线程不浪费。用数据说话12 到 16 并发吞吐量实际涨多少docs/benchmark/realtime_ws_benchmark.md 里的实测1 张 H100 80GB、vLLM 0.19.1、47 秒中文录音循环、按 100ms 帧实时发送并发客户端吞吐音频秒/挂钟时间最终结果等待 p5012优化前8.43x19,550 ms12启用并发解码与限流11.57x414 ms16优化前8.56x40,463 ms16优化后13.17x9,758 ms最终结果等待 19.6 秒 vs 414 毫秒是最直观的差距优化前一次离线解码会阻塞事件循环12 个客户端的最终结果互相排队优化后它们在各自线程池里并行执行。吞吐 8.43x → 11.57x 不是模型变快了而是模型不再阻塞接线台。离线侧另有一组数据同一 Fun-ASR-NanovLLM 批量 RTX 340 对 PyTorch 基线 21差距与并发架构处于同一量级。部署前检查清单先确认物理核心数不是逻辑核心数据此设好--ncpu与--worker_threads再启动 funasr_wss_server.py。上线前用 realtime_ws_benchmark.py 加--clients 8 --loops 3跑一遍基线记下first_update_ms_p50与final_after_stop_ms_p50两个数。⚠️ 对比版本时核对partial_messages数量若阻塞导致草稿结果变少更快是假象。按 realtime_ws_benchmark.md 的报告模板记录硬件、参数与音频保证数字可复现。参数调了仍不符合预期时先查 FQA.md 里的性能调优条目。并发的本质就三句话事件循环接电话、线程池干活、限流防打爆。想动手跑起来从 examples/ 和 docs/tutorial/ 目录开始即可。【免费下载链接】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），仅供参考