Fun-ASR-Nano使用StreamingVLLM推理结果异常

[gotorion]

🐛 Bug

使用bf16类型推理结果异常。

To Reproduce

运行下面的 Python 脚本即可。
其中asr_example_zh.wav为Readme中的示例音频。

Code sample

from funasr.models.fun_asr_nano.inference_vllm_streaming import FunASRNanoStreamingVLLM


def main():
    engine = FunASRNanoStreamingVLLM.from_pretrained(
        model="FunAudioLLM/Fun-ASR-Nano-2512",
        chunk_ms=50,
        dtype='bf16',
        rollback_chars=8,
    )
    for result in engine.streaming_generate("./asr_example_zh.wav", language="中文"):
        if result["is_final"]:
            print(f"Final: {result['text']}")
        else:
            print(f"[{result['audio_duration_ms']:.0f}ms] Confirmed: {result['fixed_text']}")

if __name__ == "__main__":
    main()

Expected behavior

推理结果正常。

Error logs

推理的结果如下：

[5350ms] Confirmed: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!聪聪!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[5400ms] Confirmed: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!聪聪!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[5450ms] Confirmed: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!聪聪!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Environment

• OS: Ubuntu 22.04
• Python version: 3.12.13
• FunASR version: 1.4.2
• ModelScope version: 1.39.1
• PyTorch / torchaudio version: 2.13.0
• Install method (pip, source, Docker): pip
• Device (cuda, cpu, mps): cuda
• GPU model: H100
• CUDA/cuDNN version: 13.0
• Docker image tag, if used:

[LauraGPT]

感谢提供最小复现。我在同型号 H100 80GB 上用当前 main@2b6294d69e6588a63c0ce06300f1b55ded71ae58、同一份 README 示例音频、dtype="bf16"、chunk_ms=50 完成了 111 个累计 chunk 的复测，final 输出正常：

欢迎您来体验达摩院推出的语音识别模型。

本次可复现实验使用 vLLM 0.10.2、Torch 2.8.0+cu128；完整日志 SHA-256 为 e560de650e7dd7258af4065d7914ca1148b3a37def41a00dc78f99788ab51b4b。因此目前不能把异常归因于 bf16 本身，也不会提前关闭 issue。

你使用的是 FunASR 1.4.2，而当前 PyPI 版本为 1.4.11。请先升级后用同一脚本复测，并补充 python -c "import vllm; print(vllm.__version__)" 的输出。你给出的 Torch 2.13.0 环境很可能对应不同的 vLLM 执行路径；拿到 exact vLLM 版本后我们会继续做同版本对照。

[gotorion]

@LauraGPT 这里有一个笔误，应该是使用fp16类型推理结果异常。
以下为更新后的复现代码，funasr版本为1.4.11，vllm版本为0.27.1，其余环境保持不变。

from funasr.models.fun_asr_nano.inference_vllm_streaming import FunASRNanoStreamingVLLM


def main():
    engine = FunASRNanoStreamingVLLM.from_pretrained(
        model="FunAudioLLM/Fun-ASR-Nano-2512",
        chunk_ms=50,
        dtype='fp16',
        rollback_chars=8,
    )
    for result in engine.streaming_generate("./asr_example_zh.wav", language="中文"):
        if result["is_final"]:
            print(f"Final: {result['text']}")
        else:
            print(f"[{result['audio_duration_ms']:.0f}ms] Confirmed: {result['fixed_text']}")

if __name__ == "__main__":
    main()

[LauraGPT]

I reproduced the corrected dtype="fp16" report on an H100: the public 5.55 s sample returned a long string of !. Split-dtype runs isolated the instability to the Qwen3 vLLM decoder rather than the audio encoder/adaptor.

I opened #3597 with a bounded fix: audio compute remains torch.float16, while the Qwen3 vLLM decoder uses torch.bfloat16 (the same two-byte weight footprint). On exact signed head 881c396a2632c0b4336b5041de7197f9526e0951, the same H100 sample returned:

欢迎您来体验达摩院推出的语音识别模型。

The focused and related regression suite is 53/53 green. The available H100 host supports CUDA 12.8, so the reporter's exact vLLM 0.27.1 / PyTorch 2.13.0 CUDA 13 binary could not initialize here; I validated the original symptom and fix with vLLM 0.10.2 / PyTorch 2.8.0+cu128 and added constructor coverage for both offline and streaming paths.

I will keep this issue open through review/merge and until you can retest the merged or released build in your vLLM 0.27.1 environment.

[gotorion]

@LauraGPT 看起来这是一个比较trick的修复，本质上依然不是使用fp16计算的。
我注意到之前已经有issue提到过这个问题：#2976 ，是否考虑在adaptor添加归一化避免在只支持fp16的设备上计算的溢出问题呢？

[LauraGPT]

1.4.12 已发布到 PyPI：

python -m pip install -U "funasr==1.4.12"

我重新核对了实现与此前 V100/FP16 证据。这里确实需要区分两层：当请求 dtype="fp16" 时，音频 adaptor 与 embedding 仍使用 FP16；但 Qwen3 解码器本身在 vLLM FP16 下会出现重复/退化输出，因此 1.4.12 将解码器固定到 BF16。对不支持 BF16 的 GPU，当前可验证的路径是 dtype="fp32"，而不是宣称已经支持端到端 FP16。

你提到的 adaptor 归一化值得继续实验，但它不能单独证明能消除 Qwen3 decoder 的 FP16 数值不稳定；我会把它作为独立假设做最小化测试。请先在原 H100 / CUDA 13 / vLLM 0.27.1 环境用 1.4.12 复测并贴出完整首段输出；如果目标设备仅支持 FP16，也请一并提供 GPU 型号、显存和 dtype="fp32" 的启动结果。此 issue 保持打开，等待这些复测证据。

[LauraGPT]

我已按你提出的 adaptor 归一化假设做了一个受控的组件级实验。它不覆盖 vLLM 的 Qwen3 decoder，因此不能证明端到端 FP16 已解决；但可以先判断 adaptor 本身是否已经出现明显溢出。

环境和输入：

• H100 80GB，PyTorch 2.11.0 + CUDA 12.8；同一份本地 Fun-ASR-Nano-2512 权重和仓库 sample WAV
• audio encoder 固定 FP32；分别让完整 audio adaptor 以 FP16、BF16 执行
• 该测试没有改动模型权重或源码

结果：

• encoder 输出绝对值最大值：FP16 路径 5.0475，BF16 路径 5.0495
• adaptor 输出：FP16/BF16 均全部 finite；绝对值最大值分别为 1099 / 1104，远低于 FP16 的有限范围上限
• FP16 与 BF16 adaptor 输出的余弦相似度为 0.999861，平均绝对差 0.334，最大绝对差 10.0

因此，当前这一个真实样本没有显示 adaptor FP16 溢出或灾难性偏移；仅在 adaptor 增加归一化还缺乏证据，且不能替代对 vLLM decoder 的端到端验证。问题仍然更可能位于完整 prompt-embedding / decoder 数值链路，或特定长音频、流式状态和 vLLM 版本的交互。

这个 issue 继续保持 open。我下一步会在能运行 CUDA 12.8/12.9 匹配 vLLM 的环境上补端到端 FP16/BF16 对照；在此之前不会把 adaptor 归一化作为“已验证修复”合入。

[LauraGPT]

状态更新：FP16/BF16 的实际运行边界现在已写入中英文 vLLM 指南，并已在 main 发布。

• 中文：https://github.com/modelscope/FunASR/blob/main/docs/vllm_guide_zh.md#9-faq
• English: https://github.com/modelscope/FunASR/blob/main/docs/vllm_guide.md#9-faq

对 FunASRNanoStreamingVLLM(..., dtype="fp16")，音频 frontend/adaptor 仍是 FP16；为避免 Qwen3 vLLM decoder 的重复退化输出，decoder 会自动用 BF16。若目标 GPU 不支持 BF16，当前可验证路径是 dtype="fp32"；这里不宣称端到端 FP16 decoder 已被解决。

请使用当前 funasr==1.4.13 在原 H100 / CUDA 13 / vLLM 0.27.1 环境复测，并贴出首段与最终文本、GPU 型号和 dtype="fp32" 对照结果。issue 保持 open，等待你的环境证据。