FunASR 历史 ASR 评测解读RTF/RTFx 数字的出处、局限与可复现路径【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR本文以 FunASR 仓库中的历史 ASR 评测记录docs/benchmark/historical_asr.md为主体完整保留原报告中 184 条中文长音频、H100 GPU 与 CPU 双平台的 RTF、RTFx、CER 对比数据并结合仓库内的评测方法论文档、迁移计时工具与 vLLM 基准脚本解释这份历史记录“能引用什么、不能当什么”以及如何在自己的音频上开展可复现的新评测。一、这份记录是什么历史存档不是排行榜docs/benchmark/historical_asr.md开篇就明确了自己的性质这是一份来源不完整incomplete provenance的历史记录仅用于帮助读者理解早期 FunASR 对比结果。它不是一次新的测量不是通用排行榜也不能作为当前 checkpoint、当前机器或当前部署的性能保证。这条定位有三个具体含义表中的“best / 最佳”等标签仅指该份历史报告本身不能推广到所有可选模型或硬件表中的能力说明例如某模型输出情感/事件标签、某 HTTP 接口返回哪些字段是历史表述不构成当前 API 能力保证——模型原始输出带标签不代表 HTTP 端点会返回这些标签旧报告中关于时间戳的限制性描述不能替代当前的 模型选型指南。因此阅读这份记录的正确姿势是把它当作“早期数字的原始出处存档”用它来对照旧文而新评测一律以 性能评测方法论 为起点。二、历史概览原报告的核心数字下表完整保留原报告的措辞与数字指标结果数据集184 条中文长音频总时长 11,539 秒约 192.3 分钟GPUNVIDIA H100 80GB HBM3最佳 GPU 速度SenseVoice-Small完整基准 169.6x realtime初次运行 211.8x最佳 CPU 速度SenseVoice-Small17.2x realtimeParaformer-Large15.6x realtime基线OpenAI Whisper-large-v3GPU 上 13.4x realtime原记录同时强调了两点常被误读的细节169.6x完整运行与 211.8x初次运行是两个相互独立的报告结果不是一次测量的两次采样不能混用原页面没有披露测量日期记录中的 2026-09-07 是来源快照核对audit日期不是测量日期。三、历史结果明细九行数据与四条阅读警告原报告的完整结果表如下全部数值与注释均为原报告的历史表述原样保留、未重新计算模型设备RTF速度CER说明SenseVoice-SmallGPU0.005896169.6x7.81%ASR 语种/情感/事件标签CER 为去除标签后计算Paraformer-LargeGPU0.008359119.6x10.18%高速非自回归中文 ASR配 VAD/标点流水线Fun-ASR-NanoGPU0.05880317.0x8.06%LLM-based 中/英/日 ASR覆盖 7 类中文方言与 26 种地域口音支持热词checkpoint 不提供可靠的原生时间戳对应上游 issue #106GLM-ASR-NanoGPU0.02697437.1x31.07%LLM-based 多语种 ASRWhisper-large-v3-turbo (OpenAI)GPU0.02170846.1x21.71%OpenAI Whisper 实现Whisper-large-v3 (OpenAI)GPU0.07469413.4x20.02%large Whisper 质量基线SenseVoice-SmallCPU0.05798817.2x7.81%CPU 结果来自 remaining benchmark 脚本Paraformer-LargeCPU0.06405615.6x10.18%CPU 可用于批量任务Fun-ASR-NanoCPU0.2743183.6x8.06%LLM-based 模型更重但仍高于实时原记录在该表之后给出了四条“阅读警告”引用这些数据时必须一并带出CPU/GPU 行重复出现相同 CER如 SenseVoice-Small 两行均为 7.81%这不能证明评测方曾对两种设备分别独立评分审计材料中没有原始预测、参考文本和评分程序因此“去除标签后计算 CER”只能作为历史说法保留不是新近验证过的评分输出原始精度以及经过舍入的速度/RTF 数值对均原样保留未做重新计算由于缺少复现材料见下一节“CPU 对比 GPU”的结论不能视为面向所有生产环境的保证。从这张表还能看到一个结构性事实非自回归模型SenseVoice-Small、Paraformer-Large在该历史报告中 GPU 速度领先一个数量级LLM-based 的 Fun-ASR-Nano 速度较低17.0x但 CER 与 SenseVoice-Small 接近8.06% vs 7.81%。这一“速度换质量/能力”的对比形态与仓库中当前 vLLM 基准脚本的设计意图一致——见第六节。四、RTF 与 RTFx 的定义以及那“两秒差异”原报告对 RTF 的定义是总推理时间除以总音频时长速度throughput为其倒数后者也称 RTFxRTF total inference time / total audio duration RTFx total audio duration / total inference time 1 / RTF这与仓库当前方法论文档 docs/benchmark/rtf_reproducibility.md 中的定义一致RTF processing_time_seconds / input_audio_seconds RTFx input_audio_seconds / processing_time_seconds 1 / RTF方法论文档还给了一个可直接换算的例子某 vLLM 公开表中 184 个文件共 11,541 秒音频RTFx 340意味着整组音频的实测处理时间约为11541 / 340 33.94 秒在该表的计时范围内。这里有一个原文特别要求读者注意的数据边界本历史记录的总时长是11,539 秒vLLM 方法论中引用的公开表是11,541 秒两者都提到 184 个文件但“文件数相同”不能证明数据集成员完全一致因此不要合并两份表格的行也不要自行抹平这 2 秒差异。引用任何一侧数字时必须连同其总时长一起引用。方法论文档同样警告离线批处理的 RTFx 结果不能与流式首 token 延迟或端到端产品延迟直接比较——它们测的是不同的东西。实时并发服务的评估应转用 WebSocket 压测说明。五、来源与可复现性限制审计结论逐条拆解5.1 来源的固定方式原记录说明原始英文/中文 HTML 页面被固定到历史 GitHub Pages 提交且在来源审计时与旧公网快照逐字节一致。这句话的确切含义是它只能确认“本表数字的出处”不能证明底层测量本身正确或可复现。5.2 三条“不能直接运行”的历史命令原记录中的以下命令仅为历史文本在本次审计的 FunASR 源码版本386f6f9106684ba5a114e796147db4396a09eab5中三个被引用文件均不存在本仓库也不提供替代脚本或复现数据python benchmark/run_full_benchmark.py python benchmark/run_remaining.py python benchmark/fix_sensevoice_cer.py这提醒读者在当前仓库里看到旧博客/旧文档提到的 benchmark 脚本时先确认文件是否真实存在不要假设历史命令可以直接执行。5.3 原报告缺失的审计字段审计结论逐条列出原报告未披露的材料CPU 型号与线程数、数据集成员与参考文本清单、精确的 checkpoint revision、软件/驱动版本、逐文件预测与计时日志以及覆盖预热、I/O、预处理的完整计时范围。缺少这些材料旧表无法直接复现。作为对照当前方法论要求任何新的 FunASR 基准数字必须附带八类字段类别应记录的内容数据文件数、总时长、语言/领域、采样率、单声道/立体声处理、测试文件是否公开模型模型 ID、checkpoint 来源、revision/commit、语言设置、热词、文本归一化运行时Python SDK、ONNX、C、vLLM、llama.cpp/GGUF、API 服务或其他方式硬件CPU 型号与线程数、GPU/NPU 型号、数量、显存、驱动、CUDA/CANN/运行时版本软件funasr、PyTorch、torchaudio、vLLM、ONNX Runtime、CUDA、Python、操作系统版本流水线VAD、标点、说话人分离、ITN、时间戳、后处理各项的开/关批处理batch size、batch_size_s、并发请求数、tensor parallel 大小、chunk 大小、VAD 分段策略计时范围计时是否包含模型下载、冷启动、预热、文件 I/O、音频解码/重采样、VAD、后处理与结果序列化质量CER/WER 方法、参考文本归一化、忽略 token、失败文件处理方式建议的计时协议为先算好总时长 → 稳态数字先预热一次 → 只测一个范围纯模型 / 纯流水线 / 端到端服务→ 同一范围至少跑 3 次并报中位数加 min/max → 保留转写输出、失败文件列表与计时 JSON/CSV。六、从历史数字走向当前路径仓库里真正可用的评测入口原文档的最后一节“Choosing a Current Path”将旧推荐表降级为历史上下文并指出现有评测入口。下面结合仓库源码逐一说明。6.1 原推荐表仅作历史上下文保留需求原报告推荐模型最快生产转写SenseVoice-Small 或 Paraformer-LargeCPU 批量转写优先 SenseVoice-Small中文生产流水线可选 Paraformer-Large中/英/日及方言口音的 LLM-style 识别Fun-ASR-Nano需要 31 语种时使用独立的 Fun-ASR-MLT-Nano checkpoint并用 vLLM 提升 LLM 解码吞吐OpenAI 兼容本地服务使用 funasr-server模型别名sensevoice、paraformer或fun-asr-nano原记录同时强调独立 MLT checkpoint 的语种覆盖不能归到 Fun-ASR-Nano名下当前决策应参考 模型与能力指南、Agent 集成契约 与 vLLM 部署指南并在选型前用自己的音频、运行时和端到端延迟要求做评估。6.2 迁移计时工具examples/migration/benchmark_funasr.py历史文档指出的当前入口是 迁移计时工具。从源码看它的职责边界非常明确——只测 FunASR 一侧它不计算 CER/WER、不运行 Whisper、也不复现缺失的历史脚本转写文本通过rich_transcription_postprocess做后处理源码逐文件计时后写入results.jsonl与summary.mdsummary 包含运行配置模型、设备、VAD、说话人模型、语言、batch size、模型加载耗时、聚合结果成功/失败数、已知音频秒数、推理秒数、聚合实时倍数和逐文件 RTF 表。主要参数来自源码的 argparse 定义参数默认值说明--input/-i必填单个音频文件或目录--output-dir/-ooutputs/migration_benchmark结果输出目录--model/-miic/SenseVoiceSmallFunASR 模型名或 ModelScope/Hugging Face id--device/-dcpu推理设备cpu、cuda或mps--vad-modelfsmn-vadVAD 模型none可关闭--spk-model空可选说话人模型如cam--languageauto传给model.generate的语言提示--batch-size1传给model.generate的 batch_size--recursive/-r关递归扫描输入目录--metadata无自由keyvalue元数据会抄进 summary如--metadata baselinewhisper-large-v3运行示例python examples/migration/benchmark_funasr.py \ --input ./my_audio/ \ --model iic/SenseVoiceSmall \ --device cuda \ --output-dir ./out \ --metadata baselinewhisper-large-v3脚本对单个文件失败是容错的异常记入error字段并继续音频时长优先用soundfile读取.wav回退到标准库wave。这与方法论“把失败文件列表和计时范围分别、显式记录”的要求一一对应。6.3 vLLM 速度 CER 一体化基准benchmark_vllm.py仓库根目录的 benchmark_vllm.py 是覆盖“速度 CER”的当前脚本支持 Fun-ASR-Nano、GLM-ASR-Nano 及任意AutoModelVLLM模型。从源码看它实现了方法论要求的关键纪律先用fsmn-vad对音频做 VAD 预分段丢弃小于 0.5 秒的片段把分段写回/tmp/benchmark_vllm_segsPyTorch 与 vLLM 两条路径都先 warmup 一次再开始计时model.generate(inputseg_files[0])vLLM 路径按模型分派Fun-ASR-Nano 走funasr.models.fun_asr_nano.inference_vllm.FunASRNanoVLLMdtypebf16、max_model_len4096、gpu_memory_utilization0.5GLM-ASR 走GLMASRVLLMEngine其余走AutoModelVLLMCER 用kaldialign做字符级对齐归一化只保留中文/字数字母后转大写逐路径输出Time / RTFx / CER可用--skip-pytorch只测 vLLM、--max-files做小规模抽查。CUDA_VISIBLE_DEVICES0 python benchmark_vllm.py \ --model FunAudioLLM/Fun-ASR-Nano-2512 \ --audio-dir /path/to/benchmark_audio \ --label-json /path/to/benchmark_testset.json6.4 实时并发场景WebSocket 压测历史记录中“GPU 13.4x 基线”这类离线数字不能当作实时服务的容量结论。针对并发实时服务仓库提供独立的 Realtime WebSocket 基准以 16 kHz 单声道 PCM16 WAV 为唯一输入从测量中剔除重采样与文件解码客户端按 100 ms 帧实时 pace 发送音频报告first_update_ms_p50/p95、final_after_stop_ms_p50/p95、client_response_lag_ms_p95_max、partial_messages/final_messages等客户端可观测指标并明确要求“不要把离线 RTFx 数字当作并发声明”。七、引用这份历史数据的操作清单综合原文档与其引用的方法论引用或复用该记录时建议遵守数字必须与出处一起引用11,539 秒 / 184 文件 / H100 80GB且不并入 vLLM 表的 11,541 秒数据169.6x 与 211.8x 分开引用注明一个是完整基准、一个是初次运行“最佳”“CPU 可用于批量”等表述加上“原报告”限定词避免被读成当前保证不复述缺失的脚本命令为可运行步骤新的测量一律按 性能评测方法论 记录八类字段用 迁移计时工具 或 benchmark_vllm.py 在自己的音频上出数实时并发容量用 WebSocket 压测 单独评估不与离线 RTFx 混用。这份历史存档的价值在于保留了早期对比报告的原始措辞与审计边界而仓库当前的方法论与脚本则给出了把“听来的数字”变成“可复现数字”的完整工具链。【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考