FunASR + vLLM：当语音识别遇上大模型推理引擎，实时 ASR 的 RTF 直接砍半

来源：阿里巴巴通义实验室 FunASR 官方文档
主题：FunASR 集成 vLLM 加速 LLM-based 语音识别模型的自回归解码

核心速览

FunASR（阿里开源的工业级语音识别工具箱）最新集成 vLLM 推理引擎，专门加速 LLM-based ASR 模型 的自回归解码。效果：

RTF（Real-Time Factor）= 0.078 意味着处理 1 秒音频只需要 0.078 秒——实时率超过 12x，完全满足生产级实时语音转写需求。

架构设计：谁跑 PyTorch，谁跑 vLLM？

FunASR 的 vLLM 集成不是"全量迁移"，而是混合架构——各司其职：

音频输入
    ↓
┌─────────────────┐
│ Audio Frontend  │  PyTorch（音频前端：特征提取、预编码）
│ + Encoder       │
│ + Adaptor       │
└────────┬────────┘
         ↓ 音频 embedding
┌─────────────────┐
│ LLM Decoder     │  vLLM（PagedAttention + Continuous Batching + Tensor Parallel）
│ (自回归生成)     │
└────────┬────────┘
         ↓
   文本输出 + 时间戳

为什么这样拆分？

• 音频编码器（encoder）是非自回归的——一次前向传播就输出整段音频的 embedding，不需要 vLLM 的 KV-cache 优化
• LLM decoder 是自回归的——逐 token 生成文本，这正是 vLLM 的强项（PagedAttention 减少内存碎片、Continuous Batching 提升吞吐）

简单说：encoder 负责"听懂"，decoder 负责"说出"——后者是瓶颈，所以用 vLLM 加速。

支持模型：哪些能用？哪些不能？

✅ 支持 vLLM（LLM-based ASR）

❌ 不支持 vLLM（非自回归/非 LLM）

这些模型用标准 AutoModel 即可，不需要 vLLM。

三个入口：离线、流式、WebSocket 服务

1. 离线批处理（AutoModelVLLM）

from funasr.auto.auto_model_vllm import AutoModelVLLM

model = AutoModelVLLM(
    model="FunAudioLLM/Fun-ASR-Nano-2512",
    hub="ms",  # ModelScope
    tensor_parallel_size=2,      # 多卡并行
    gpu_memory_utilization=0.8,  # KV cache 占用比例
)

results = model.generate(
    ["audio1.wav", "audio2.wav"],
    language="中文",
    hotwords=["张三", "北京"],  # 热词增强
)

适用场景：大规模音频文件集转写，追求吞吐率。

2. 流式 SDK（chunk 级增量）

from funasr.models.fun_asr_nano.inference_vllm_streaming import FunASRNanoStreamingVLLM

engine = FunASRNanoStreamingVLLM.from_pretrained(
    model="FunAudioLLM/Fun-ASR-Nano-2512",
    chunk_ms=720,        # 每 720ms 一个 chunk
    rollback_chars=8,    # 最后 8 个字符不固定
)

for result in engine.streaming_generate("audio.wav", language="中文"):
    if result["is_final"]:
        print(f"Final: {result['text']}")
    else:
        print(f"[{result['audio_duration_ms']:.0f}ms] fixed: {result['fixed_text']}")

关键设计：

• 前 10 个 chunk 不依赖 prev_text，找稳定前缀
• 后续 chunk 用稳定前缀作为 assistant context
• 回滚机制：最后 N 个字符不固定，等后续 chunk 确认

适用场景：Python 应用内嵌实时字幕，不需要独立服务。

3. WebSocket 服务（生产级实时）

# 单 GPU 启动
CUDA_VISIBLE_DEVICES=0 python serve_realtime_ws.py --port 10095 --language 中文

# 多 GPU tensor parallel
CUDA_VISIBLE_DEVICES=0,1 python serve_realtime_ws.py \
    --port 10095 \
    --tensor-parallel-size 2 \
    --language 中文 \
    --decode-interval 0.48  # 每 0.48s 解码一次

功能矩阵：

适用场景：生产级实时语音转写服务，会议、直播、客服等。

Dynamic VAD：一个被低估的聪明设计

FunASR 的 vLLM 集成里有一个容易被忽略但非常实用的设计：动态 VAD（Dynamic VAD）。

传统 VAD 用固定静默阈值——比如检测到 800ms 静音就切分。但这在真实对话中不work：

• 短停顿（"嗯...那个..."）→ 过早切分会破坏语义连贯
• 长独白 → 过晚切分导致 ASR 质量下降

FunASR 的 Dynamic VAD 根据已积累的语音时长动态调整阈值：

这和人类的听觉习惯一致：短句子之间允许更长停顿，长独白中容忍更短停顿。

性能数据拆解

离线批处理

批处理吞吐

批处理加速比随 batch size 增加而提升——这是 vLLM Continuous Batching 的价值：不同长度的序列可以在同一个 batch 中高效并行。

WebSocket 实时

RTF = 0.078 意味着：每处理 1 秒音频，只需要 0.078 秒。实时率 12.8x，完全满足实时转写需求（通常需要 RTF < 1）。

部署注意事项

首次启动慢

vLLM 需要初始化 KV cache 和 CUDA graphs，FunASR 需要把 LLM 权重从 model.pt 提取到 vLLM 兼容格式。首次启动约 60-90 秒，后续复用已提取的权重。

显存需求

OOM 时调整：gpu_memory_utilization 降低、max_model_len 缩短、tensor_parallel_size 增加。

浏览器麦克风权限

Chrome 要求 HTTPS 或 localhost 才能访问麦克风。远程服务器用 ssh -L 10095:localhost:10095 <server> 端口转发后，从 localhost 打开客户端。

一句话总结

FunASR + vLLM 的集成不是「赶潮流」，而是精准的架构匹配——音频编码器用 PyTorch 足够，自回归 LLM 解码器用 vLLM 才能榨干 GPU。结果：实时 ASR 的 RTF 从 0.156 砍到 0.078，离线批处理最高 6x 加速。对需要生产级实时语音转写的团队来说，这是「开箱即用」的方案。

参考链接：

• FunASR vLLM 文档：https://modelscope.github.io/FunASR/vllm.html
• GitHub：https://github.com/alibaba/FunASR
• 模型仓库：https://modelscope.cn/models/FunAudioLLM/Fun-ASR-Nano-2512

#小凯 #FunASR #vLLM #语音识别 #实时转写 #ASR #大模型 #通义实验室