serve_realtime_ws.py 是单个 asyncio 事件循环管理所有 WebSocket 连接，但解码是同步阻塞

[qiulang]

FunASR Version
1.3.5+

Python Version
3.12

Bug Description
单卡流式并发的上限，主要来自 serve_realtime_ws.py 里单个 asyncio 事件循环的串行化，同步的 decode() 阻塞整个 loop，而不是 GPU 算力 / KV cache / LLM decoder。

RealtimeASRSession.decode()（partial 与 segment 都经它）内部直接调 vllm_engine.generate(...)，同步返回——执行期间整个事件循环冻结，其余连接收不到音频、发不出结果。

add_audio() 在 VAD 检测到句尾时立即同步调用 _decode_segment()，不等定时器——所以接收音频的过程中也会被突然阻塞。

结果：N 路并发时，任一路触发 decode，其余 N-1 路全部停住直到本次 decode 完成。所以加 GPU 算力没用。

我尝试了三种办法修改代码都失败：

A. asyncio 改异步 / 线程（AsyncLLMEngine）：把同步 decode() 改成 await、把 encoder 前向丢进线程池、LLM 换 AsyncLLMEngine，想让事件循环在 decode 期间不被独占。

结果：原来只能跑32路现在64 路能全部完成，但首词响应飙到 8.34s。原因是 encoder 在线程池里仍被 CUDA 强制串行（同一 context 的 kernel 发射本就排队），异步引擎又会攒批，延迟反而累积——没有真正绕开串行，只是把串行挪了位置。

B. 跨 session 批量 decode：把多路的 encoder 前向合批送 vLLM。32 路内 RTFx 13x→29x（说明 encoder 内部本就支持真批量），但 48 路以上队列积压、首词 5.81s。

C. 禁用 CTC 时间戳：A/B 逐行一致，无效

想请教两个问题：

我这个判断是不是正确。如果想提升并发量是不是只能起多个进程了？
（AsyncLLMEngine/线程池）这条路是我的实现方式不对，还是这条路本身在当前 encoder+vLLM 结构下确实绕不开 CUDA 串行？

Steps to Reproduce
租用单卡，双卡GPU，对照GPU使用情况，可以发现即便在压力测试下，GPU仍然是大量空闲

[LauraGPT]

感谢这个深入的分析！你说得完全正确 — serve_realtime_ws.py 当前的架构确实是单事件循环 + 同步阻塞 decode 的模式，并发瓶颈在 asyncio 串行化而不是 GPU。

当前设计的局限：

• decode() 是同步阻塞的，占住整个事件循环
• N 路并发时，任一路 decode 会冻结其余 N-1 路
• 加 GPU 算力无法解决

建议的改进方向：

1. 最简方案：多进程 — 启动 N 个 serve_realtime_ws.py 实例（各绑一个端口），前端用 nginx 做负载均衡。每进程独占 GPU 的一部分显存（--gpu-memory-utilization 0.3 等）

2. 中等方案：线程池 + 异步

import asyncio
from concurrent.futures import ThreadPoolExecutor

executor = ThreadPoolExecutor(max_workers=4)

async def decode_async(session, audio):
    loop = asyncio.get_event_loop()
    return await loop.run_in_executor(executor, session.decode, audio)

但需要注意 vLLM engine 的线程安全性。

3. 长期方案：vLLM AsyncLLMEngine + batched decode — 你提到的方案 A 方向是对的，但需要把 encoder 也做成异步（音频编码器前向放到 thread pool），同时确保 vLLM 的 async 接口正确使用。

你的方案 A 能从 32 路提升到 64 路已经说明方向正确，可以分享一下遇到的具体问题吗？也许可以一起排查。

[qiulang]

auto_model_vllm.py
serve_realtime_ws.py
inference_vllm.py

这是我的方案A，改动三处

1. encoder 前向放进 ThreadPoolExecutor (fbank + SenseVoice encoder + adaptor 在线程池跑,编码期间不阻塞事件循环)

• inference_vllm.py:新增同步方法 _prepare_prompts()(批量编码 → 构建 EmbedsPrompt 列表);在 generate_async() 内经 await loop.run_in_executor(None, _prep_timed) 提交。

2. LLM 换 AsyncLLMEngine (prompt embeddings 经异步路径提交)

• inference_vllm.py:__init__ 的 use_async 分支用 AsyncLLMEngine.from_engine_args(...) 建引擎;_generate_one_async() 内 async for output in self.vllm_engine.generate(EmbedsPrompt(...), sampling_params, request_id);generate_async() 用 asyncio.gather 并发提交多段;from_pretrained() 透传 use_async。
• auto_model_vllm.py:__init__ 透传 use_async,新增 async def generate_async() → await self._engine.generate_async(...)。
• 确认一个有用的事实:vLLM 0.19.1 上开 enable_prompt_embeds=True 时,AsyncLLMEngine 实际走 V1 引擎,prompt_embeds 在 V1 异步路径可正常生成。

3. decode 全异步 (事件循环不被 decode 阻塞)

• serve_realtime_ws.py:模型以 use_async=True 载入;add_audio() 不再内联调 _decode_segment,改为入队;decode() 改 async,待处理段用 asyncio.gather(*[self._decode_segment(seg) ...]) 并发;_decode_segment() 改 async,内部 await self.vllm_engine.generate_async(...);handle_client() 全程 await session.decode(...)。

压测结果(单卡 L20,单进程,7s 音频)

并发	首词	p50	完成
≤8	1.0–1.6s	≈ 音频	✅
16	~2.5s	略滞后	✅ 16/16
32	~4.4s	~2.4× 音频	✅ 32/32
64	~8s	~4.6× 音频	✅ 64/64

异步改造达到了它的直接目标:解开了事件循环阻塞,不再像同步单进程那样到顶集体崩(64/64 全过、无断崖)。但首词/延迟随并发严重劣化。

[LauraGPT]

感谢分享方案 A 的完整代码！这个改动思路很清晰：

1. encoder 放线程池 — 避免阻塞事件循环
2. AsyncLLMEngine — LLM decode 异步化
3. 整体 async/await 化

这对并发性能的提升应该很明显。建议你直接提一个 PR，这样可以更方便地 review 代码细节和做 benchmark 对比。

如果你愿意提 PR，可以在 PR 描述中附上并发测试数据（比如 32 路 vs 64 路的延迟和吞吐量对比），这样更有说服力。

[qiulang]

可是首词延迟比没改之前严重恶化，我觉得我这个修改是失败的啊

[LauraGPT]

首词延迟恶化大概率是因为 ThreadPoolExecutor 的线程启动开销 + AsyncLLMEngine 的调度延迟叠加导致的。

分析：

• 原来同步模式下，第一个 decode 请求直接执行，没有调度等待
• 改成异步后，encoder 线程池启动 + async engine 排队 + 事件循环 yield 这些额外开销都会加到首词延迟上

可以尝试的优化：

1. 预热线程池：在连接建立时就创建好线程，避免首次调用时的冷启动

executor = ThreadPoolExecutor(max_workers=4)
# 预热
for _ in range(4):
    executor.submit(lambda: None).result()

2. partial decode 不走线程池：partial（定时预览）延迟敏感，可以保留同步调用；只把 segment 锁定的完整 decode 放线程池

3. 减小 decode_interval：如果 partial decode 间隔太大，首词延迟感知上会更差

4. 考虑混合方案：低并发时用同步（低延迟），高并发时自动切异步（高吞吐）

首词延迟和并发吞吐本质上是 trade-off，你的方案 A 方向是对的，只是需要针对首词延迟做专门优化。

[qiulang]

在我修改的 inference_vllm.py 我有个打印， 通过几组压力测试，比如 从1路开始增加到16路、32路的数据，大致可以把启动/调度 yield的成本和 引擎攒批 + 单循环饱和的成本 两者分开了：

        logger.info(
            f"[t] n={len(inputs)} "
            f"queue={(t_enc_start - t_submit) * 1000:.0f}ms "      # 等线程池空闲
            f"encode={(t_enc_end - t_enc_start) * 1000:.0f}ms "    # encoder 真实计算
            f"llm={(t_done - t_llm_start) * 1000:.0f}ms "          # AsyncLLMEngine 整段
            f"total={(t_done - t_submit) * 1000:.0f}ms"
        )

在L20我观察到大致这样的数据 ttft 115→1891ms、llm 347→1869ms。同时 queue=0、encode≈400ms 且 16→32 不增长——线程池不堵、encode 也稳定。线程启动是个一次性固定成本，它不可能产生随并发增长的曲线。我测到的恰恰是随并发增长，所以预热线程池我觉得是「可忽略」的成本，对 ttft 那条上升曲线没有影响。所以建议 1 预热线程池 我觉得应该没有太多用。

建议二， 增加 partial 触发频率＝给已经饱和的单循环再加 decode 负载。它可能改善"感知首词",但我的首词瓶颈是 decode 延迟本身(攒批 + 等循环唤醒协程),不是 partial 触发得够不够早(首个 partial 已在 480ms 音频就触发了)。所以我觉得在真实 turn-taking （比如一问一答，只要ASR回答的话）的占空比下、各路错峰、瞬时并发的 partial 远少时, 它可能成立，就是这个阻塞量取决于占空比。

建议三 和我的瓶颈是反向的——更频繁的 partial＝更多 decode 负载＝循环更饱和，只有在循环有余量时才改善感知首词，但是我的并发档循环没有余量。

建议四，我现在就是用你说的 nginx 转发，唯一可以补充的事我在GPU开了 MPS，在高并发压力的情况下 MPS的作用还是挺明显。在代码层面，我觉得我个人水平有限做不到，到了 python 315 free threading 稳定后我找时间再试试做这个改动

[LauraGPT]

非常好的数据分析！能把 queue/encode/llm 时间拆开看，定位问题就精准多了。

从你的数据来看：

• queue 时间（等线程池空闲）在并发增加时应该是主要增长点
• encode 时间相对稳定（GPU 计算固定）
• llm 时间取决于 vLLM 的 batch 调度效率

如果 queue 时间在低并发时就很高，说明线程池 worker 数太少。如果在高并发时才恶化，那是正常的资源竞争。

建议：

1. 把完整的压力测试数据（1/4/8/16/32 路的 queue/encode/llm 中位数）贴出来，我们可以一起分析瓶颈在哪
2. 这个分析框架很有价值，建议直接提 PR — 即使最终方案还在迭代，至少性能 profiling 的代码可以先合入

[qiulang]

我用同一条 7.7s 音频从 1→48 路压测,逐档给"一次 decode"的耗时分布。单位 ms,每档给 中位 / p95 / max。

并发	样本	queue	encode	llm(中位/p95/max)	ttft(中位/p95/max)	total(中位/p95/max)
1	8	0	34	51/77/77	7/7/7	86/242/242
4	32	0	139	76/145/149	10/18/22	214/290/294
8	64	0	338	88/152/175	16/106/142	445/578/676
16	128	0	119	652/959/1016	474/622/642	1132/1177/1202
32	256	0	117	1533/2089/2226	997/1362/1430	2280/2437/2670
48	384	0	125	2416/3382/3667	1456/2218/2277	3645/4014/4135

说明:样本 = 该档统计到的 decode 次数(每次 partial 0.96s 或 segment 一条)≈ 8 × 并发数(7.74/0.96 音频每路约 8 次 decode)。低/中并发档样本少、偏噪声(如 8 路 encode 偏高),读结论以 16/32/48 为准。

encode 取中位数

两条日志对比(本次跑里全程最快 / 最慢):

空闲: [t] n=1 queue=0ms encode=33ms  llm=15ms    total=48ms
洪峰: [t] n=1 queue=0ms encode=620ms llm=1535ms  total=4135ms

怎么读:

• queue 始终 0 → encoder 异步卸载到的线程池不是瓶颈。
• encode 中位在 16/32/48 稳定 ~120ms → encoder 不是随并发劣化的主因。(洪峰最坏一条 encode 被 GPU 争用顶到 ~620ms,但仍是三块里最小的。)
• 洪峰那条 total=4135 的构成:encode 620 + llm 1535 + (total−encode−llm)=1980。这 1980ms 既不在编码也不在生成,是协程在被打满的单事件循环里等待被唤醒的时间——是三块里最大的一块。
• 随并发,llm(攒批)、事件循环等待、ttft 一起涨:48 路时典型(中位)一次 decode 就要 3.6s、首 token 1.5s。encode、queue 基本不动。

结论: 单进程异步在高并发下的瓶颈是 单 asyncio 事件循环调度(total−encode−llm 那段,洪峰 ~2s)+ AsyncLLMEngine 连续批处理(llm,洪峰 ~1.5s),二者随并发一起饱和、且耦合(引擎调度器跑在同一事件循环上,循环饱和→引擎步进也变慢)。不是 encoder、不是线程池、不是 GPU 算力。这也解释了为什么横向多进程(每进程同步 generate、各自独立事件循环 + 独立 CUDA context + MPS)能绕开——它同时拆掉了这两堵墙。

附上音频和测试脚本。如果你觉得测试代码没问题，我就提交一个PR

bench_breakdown3.sh

bench_streaming_ws.py

盛世.wav