关于实时模式的vllm解码并发问题
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- backend, performance
Hướng nghiên cứu
Start in the realtime_ws flow around RealtimeBatchingEngine, handle_client, and run_session_work; trace the asyncio.to_thread call into synchronous LLM.generate. Run the existing concurrency benchmark, which currently covers up to 8 clients, and compare it with higher session counts. Done means a benchmark-backed decision and, if pursued, verified per-session partial ordering and latency under the target concurrency.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
【realtime_ws】并发 streaming session 的vllm解码
测试中并发 streaming session 增多时，首条结果延迟明显上升，超过一定并发后结果趋于停滞。
在约 15+ 个并发 session 下，首字延迟 p50 从 10 个 session 时的 ~1.5s 涨到 ~2.2s（p95
到 ~66s），并随并发继续恶化。以上数值仅供参考，不代表精确基准。
似乎RealtimeBatchingEngine把并发 session 的请求统一汇到单个 worker 线程，底层调用同步 `LLM.generate。实时流式里每个 session 的 handle_client循环要等自己的 partial 返回之后才发下一帧（run_session_work → asyncio.to_thread →阻塞 generate），语音请求在vad处理后请求天然稀疏，batch_wait_ms=10ms的攒批窗口几乎凑不齐。于是请求稀疏 → 批凑不满 → 单条串行 → 客户端等更久 → 更稀疏，形成自锁，吞吐受限。这是我的推测解释，未必准确，供参考。
目前benchmark 文档只到 8 clients，若未来有意支持更高并发，是否可以考虑把解码器切到 AsyncLLMEngine（vLLM v1 的vllm.v1.engine.async_llm.AsyncLLM，同样 enable_prompt_embeds=True），每个 session 的partial / 锁句作独立 request_id提交：引擎按 step 在卡上合批、同时把每条结果返回给各自调用方，天然保住每个 session 的顺序与 partial 中间态，吞吐也随之恢复。是否值得，请各位大佬按定位评估；我这边物理条件有限，测试结果未必准确，也很难支持更高并发下的吞吐测试，若感兴趣可在高并发下尝试验证。
- Ngôn ngữ chính
- Python
- Star
- 20.5k
- Fork
- 2.1k
- Merge trung bình
- 13 giờ 33 phút
- Pull request đã merge (30 ngày)
- 139
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelscope/FunASR
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
modelscope/FunASR#3730 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
modelscope/FunASR#3704 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
没有vllm时使用fun-asr-nano每次都重新加载模型Đang mởbug needs feedback
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
modelscope/FunASR#3401 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
【暴露的问题比断句严重】实时语音，切分不够彻底，怎么解决Đang mởbug needs triage
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
modelscope/FunASR#3727 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
funasr-nano在电话录音识别场景表现不是很好Đang mởneeds triage question
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
modelscope/FunASR#3718 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của modelscope/FunASR
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
PedestrianDynamics/pyFDS-Evac#343 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
theskumar/python-dotenv#708 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Docs Timedelta
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
pandas-dev/pandas#69919 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
API documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
zephyrproject-rtos/west#1009 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày