funasr流式推理并发数为2个正常吗？

[ingale726]

使用docker部署的funasr，只部署了一个容器，流式推理，正常说话语速，websocket长链接，大概说1-3分钟，这样的场景测并发，结果是两个并发可以，3个4个就不行了，这个结果正常吗？

[lukeewin]

使用docker部署的funasr，只部署了一个容器，流式推理，正常说话语速，websocket长链接，大概说1-3分钟，这样的场景测并发，结果是两个并发可以，3个4个就不行了，这个结果正常吗？

有可能资源不够吧

[LauraGPT]

先更正我上一条回复：官方 FunASR C++ Docker 实时服务没有通用的 --workers 参数；那条建议不适用于这个 runtime。

“只能 2 路”本身不能直接判断是否正常。 如果你使用的是官方 funasr-wss-server / funasr-wss-server-2pass，服务端并发相关参数是：

• --decoder-thread-num：解码线程池大小，官方文档将其定义为支持的最大并发路数；
• --model-thread-num：每路识别内部的 ONNX 并行线程数；
• --io-thread-num：WebSocket I/O 线程数。

官方文档建议 decoder-thread-num * model-thread-num 与容器可用线程数匹配；部署脚本还可能根据机器线程数自动配置这些值。源码中的服务端默认 decoder-thread-num 是 8，因此“2 路可以、3/4 路不行”不能简单归因于默认 worker 数。

先在宿主机检查容器实际启动参数和日志：

docker exec <container> sh -lc 'ps -ef | grep "[f]unasr-wss-server"'
docker logs <container> 2>&1 | grep -E 'decoder-thread-num|io-thread-num|model-thread-num|RTF|timeout|error|OOM'
docker inspect <container> --format '{{json .HostConfig}}'

文档中的修改方式是：

sudo bash funasr-runtime-deploy-online-cpu-zh.sh update --decode_thread_num <N>

但不要直接照抄示例里的 32。应先按容器实际可用 CPU 线程数分配 decoder-thread-num 和 model-thread-num，再逐级压测。客户端脚本的 --thread-num 只控制客户端同时发送的路数，不会扩大服务端解码线程池。

并发是否达标要同时看：目标并发下每路处理速度能否持续跟上实时音频（RTF/处理耗时不持续超过 1）、排队延迟是否增长、WebSocket 是否超时/断开，以及进程是否 OOM。3/4 路“不行”可能分别对应线程池配置、CPU 饱和、内存限制、客户端发送逻辑或超时设置，需要日志才能区分。

请补充下面信息，我可以据此给出具体参数：

1. Docker 镜像完整名称和 tag、完整启动命令；
2. 宿主机及容器可用 CPU、内存、GPU/显存限制；
3. online 还是 2pass、使用的模型及客户端 chunk 配置；
4. 第 3 路开始的准确现象：连接被拒绝、断连、无结果、延迟不断增长，还是容器退出/OOM；
5. 对应时间段的服务端日志。

官方依据：

• 在线服务参数说明
• 在线部署脚本修改线程数
• funasr-wss-server 默认解码线程数