应该用哪一版vllm跑fun-asr-nano?

[ZhangQi-HUST]

FunASR使用vllm加速时，应该使用哪个版本的vllm比较好。

Before asking

1. Search existing issues: https://github.com/modelscope/FunASR/issues
2. Search the docs: https://modelscope.github.io/FunASR/
3. Check the README quick start and deployment section.

Question

1、我用funasr-server --model fun-asr-nano --port 8000运行了服务器
2、在localhost:8000/docs中，用/v1/audio/transcriptions的try向服务器发送wav格式的语音文件
3、启动funasr-server后，发送第一个wav文件是可以正常识别的，通常（不一定）在发送第二个wav文件时服务器报错。
4、使用paraformer和sensevoice两种模型都没有出过问题。不安装vllm时使用fun-asr-nano模型也没出问题（除了每次发wav文件好像都要重加载模型有点慢）。

上面第3条里服务器报错如下：

ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "funasr/lib/python3.12/site-packages/uvicorn/protocols/http/httptools_impl.py", line 421, in run_asgi
    result = await app(  # type: ignore[func-returns-value]
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/uvicorn/middleware/proxy_headers.py", line 63, in __call__
    return await self.app(scope, receive, send)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/fastapi/applications.py", line 1159, in __call__
    await super().__call__(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/applications.py", line 90, in __call__
    await self.middleware_stack(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/middleware/errors.py", line 186, in __call__
    raise exc
  File "funasr/lib/python3.12/site-packages/starlette/middleware/errors.py", line 164, in __call__
    await self.app(scope, receive, _send)
  File "funasr/lib/python3.12/site-packages/starlette/middleware/exceptions.py", line 63, in __call__
    await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    raise exc
  File "funasr/lib/python3.12/site-packages/starlette/_exception_handler.py", line 42, in wrapped_app
    await app(scope, receive, sender)
  File "funasr/lib/python3.12/site-packages/fastapi/middleware/asyncexitstack.py", line 18, in __call__
    await self.app(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/routing.py", line 660, in __call__
    await self.middleware_stack(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/routing.py", line 680, in app
    await route.handle(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/routing.py", line 276, in handle
    await self.app(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/fastapi/routing.py", line 134, in app
    await wrap_app_handling_exceptions(app, request)(scope, receive, send)
  File "funasr/lib/python3.12/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    raise exc
  File "funasr/lib/python3.12/site-packages/starlette/_exception_handler.py", line 42, in wrapped_app
    await app(scope, receive, sender)
  File "funasr/lib/python3.12/site-packages/fastapi/routing.py", line 120, in app
    response = await f(request)
               ^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/fastapi/routing.py", line 674, in app
    raw_response = await run_endpoint_function(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/fastapi/routing.py", line 328, in run_endpoint_function
    return await dependant.call(**values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/funasr/bin/_server_app.py", line 204, in transcribe
    result = _process_vllm(audio_data, sr, language=language, use_spk=spk)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/funasr/bin/_server_app.py", line 142, in _process_vllm
    results = app.state.engine.generate(inputs=seg_audios, **gen_kwargs)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/funasr/models/fun_asr_nano/inference_vllm.py", line 609, in generate
    outputs = self.vllm_engine.generate(prompts, sampling_params, use_tqdm=len(inputs) > 1)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/vllm/entrypoints/llm.py", line 500, in generate
    return self._run_completion(
           ^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/vllm/entrypoints/llm.py", line 1651, in _run_completion
    return self._run_engine(use_tqdm=use_tqdm, output_type=output_type)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/vllm/entrypoints/llm.py", line 1861, in _run_engine
    step_outputs = self.llm_engine.step()
                   ^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/vllm/v1/engine/llm_engine.py", line 295, in step
    outputs = self.engine_core.get_output()
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "funasr/lib/python3.12/site-packages/vllm/v1/engine/core_client.py", line 793, in get_output
    raise self._format_exception(outputs) from None
vllm.v1.engine.exceptions.EngineDeadError: EngineCore encountered an issue. See stack trace (above) for the root cause.
[rank0]:[W610 12:53:34.768469318 ProcessGroupNCCL.cpp:1575] Warning: WARNING: destroy_process_group() was not called before program exit, which can leak resources. For more info, please see https://pytorch.org/docs/stable/distributed.html#shutdown (function operator())

Code or command

What have you tried?

Environment

• OS: Ubuntu 26.04
• Python version: 3.12.13
• FunASR version: 1.3.9
• ModelScope version: 1.37.1
• PyTorch / torchaudio version: 2.11.0+cu130
• Install method (pip, source, Docker): pip+uv(for vllm)
• Device (cuda, cpu, mps): cuda
• GPU model: RTX 5070ti 16G
• CUDA/cuDNN version: 13.3
• Docker image tag, if used:

[LauraGPT]

这个问题是 vLLM v1 engine 在多次请求间复用引擎时的已知 bug，出现在 vllm >= 0.8 的 V1 引擎架构中（你的 traceback 里可以看到 vllm/v1/engine/）。

推荐解决方案：

1. 使用 vLLM 0.8.5.post1（目前验证最稳定）：

pip install vllm==0.8.5.post1

2. 如果想用较新版本，可以尝试设置环境变量强制用 V0 引擎：

export VLLM_USE_V1=0
funasr-server --model fun-asr-nano --port 8000

3. PyTorch 版本：你用的 torch 2.11 + CUDA 13.3 太新了，vLLM 0.8.x 官方支持到 torch 2.6 + CUDA 12.6。建议用 torch==2.6.0+cu126 配合 vllm==0.8.5.post1。

根因分析： V1 engine 在第二次请求时 EngineCore 状态未正确重置（EngineDeadError），这是 vLLM 上游正在修复的问题。RTX 5070 Ti 是新架构（Blackwell），目前 vLLM 对其支持还不完善。

如果上面方法仍有问题，请提供 pip list | grep vllm 和 nvidia-smi 的输出，我帮你进一步排查。

[ZhangQi-HUST]

@LauraGPT
我是看https://modelscope.github.io/FunASR/vllm.html和https://github.com/modelscope/FunASR/blob/main/docs/vllm_guide.md等文件中的

pip install funasr>=1.3.0
pip install vllm>=0.12.0

才安装的较高版本。
另外，“vLLM v1 engine 在多次请求间复用引擎时的已知 bug” 这个issue方便告知在哪吗？

[qiulang]

@LauraGPT 基于我最近一周的经验，我有一点不同意见:

安装哪个版本vllm 还需要看cuda 版本，vllm 0.20 开始缺省用cuda 13 https://github.com/vllm-project/vllm/releases/tag/v0.20.0

CUDA 13.0 default: ...

如果是cuda 12 就用 0.19， 这两个组合我都在用，没碰到问题。

他出错这里 vllm_engine.generate( ) 也是我们最近反复讨论的

File "funasr/lib/python3.12/site-packages/funasr/models/fun_asr_nano/inference_vllm.py", line 609, in generate
outputs = self.vllm_engine.generate(prompts, sampling_params, use_tqdm=len(inputs) > 1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

@ZhangQi-HUST 你要把 EngineCore 子进程那段 traceback 打出来才能准确定位问题，你现在打的是 client的日志，没法准确定位。

但我猜是你的GPU RTX 5070 Ti 太新，基于 Blackwell , vllm 可能哪里没适配好。 或许可能就是 之前我给 @LauraGPT 提的 prompt_embeds 错 #2950

你可以先把 EngineCore 子进程那段 traceback 打出来，或者尝试cuda 12+ vllm 0.19 试试

[LauraGPT]

@qiulang 你说得对，我前面把 vLLM 版本建议说窄了。这里不应该简单写成固定某个 vLLM 版本，而应该按 NVIDIA driver / CUDA runtime / PyTorch / vLLM wheel 的组合来判断。

我已经把文档补了一层说明：不要无约束使用最新 wheel；如果 wheel 依赖的 CUDA runtime 高于当前驱动支持范围，会在 PyTorch CUDA 初始化阶段直接报 driver too old。对应 commit：modelscope/FunASR@ef46055

@ZhangQi-HUST 对你这个问题，下一步最有用的是补 EngineCore 子进程 traceback。现在贴出来的是 client 侧栈，只能看到死在 vllm_engine.generate() 外层，不能精确判断是 Blackwell 适配、prompt_embeds，还是 wheel/driver 组合问题。

[LauraGPT]

补充更新：文档里原来的 pip install vllm>=0.12.0 确实容易误导用户直接安装到与当前 NVIDIA driver / CUDA runtime / PyTorch wheel 不匹配的版本。

我已经把相关 vLLM 文档和 realtime demo 里的无上限安装命令改掉了：modelscope/FunASR@5a37a31

后续建议按环境固定一个验证过的组合，而不是用 vllm>=... 让 pip 拉最新版。这样可以避免在 FunASR 启动前就因为 PyTorch/vLLM wheel 的 CUDA runtime 与驱动不匹配而报错。