企业官网建设流程全解析

FunASR 历史 ASR 基准记录详解：读懂早期 RTF/CER 数据并开展可复现的新评测

【免费下载链接】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 评测记录 收录了一份来源不完整但信息量很大的早期基准数据：184 条中文长音频上，SenseVoice-Small、Paraformer-Large、Fun-ASR-Nano 等模型在 H100 GPU 与 CPU 上的 RTF/CER 对比结果。本文以该记录为主体，完整继承其数据表、RTF/RTFx 定义与来源限制，并结合仓库中的 评测方法说明 与 迁移计时工具，帮你既看懂这份历史记录，又知道如何对它开展一次可复现的新测量。

这份记录的定位：历史快照，不是当前保证

在引用任何数字之前，必须先明确这份文档的性质。原文明确声明它是一份来源不完整的历史记录，用于帮助读者理解早期 FunASR 对比结果，不是新测量、通用排行榜，也不是对当前 checkpoint、机器或部署的保证。

三个关键时间点与限定条件需要牢记：

• 表格数值与措辞均保留原报告原貌，"最佳"等标签仅指该份报告，不能推广到所有模型或硬件；
• 原页面没有披露测量日期，文档中出现的2026-09-07 是本次来源快照核对日期，不是测量日期；
• 开展新的评测前，应先阅读仓库内的 性能评测方法说明，而不是把这份历史表当作选型依据。

历史概览：数据集、硬件与基线

原报告的核心测试条件如下表所示，全部数字原样保留自历史记录：

这里有一个容易被误读的细节：完整运行的 169.6x 与初次运行的 211.8x 是两个独立报告的结果，它们之间不存在"性能回退"或"性能波动"的结论依据，只是原报告中两次口径不同的记录。引用时必须注明是哪一个数字。

历史结果表：完整数据与引用边界

下表是历史记录的核心，全部数值和说明都是原报告的历史表述，不是当前 API 能力保证：

原始精度以及经过舍入的速度/RTF 数值均原样保留，不做重新计算。同时必须保留原文档给出的两条引用边界：

1. 模型原始输出包含富文本标签，不代表 HTTP 接口一定返回这些标签；旧记录中的时间戳限制也不能代替当前的 模型选型说明；
2. CPU/GPU 行重复出现相同 CER，不能证明曾分别独立评分；审计材料中没有原始预测、参考文本或评分程序，"去除标签后计算"仅保留为历史说法，不是本次验证过的评分输出。

RTF 与 RTFx 的定义

原报告将 RTF 定义为总推理时间除以总音频时长，速度为其倒数，后者也称 RTFx：

RTF = total inference time / total audio duration RTFx = total audio duration / total inference time = 1 / RTF

以表中的 SenseVoice-Small GPU 行为例：11,539 秒音频对应 RTF 0.005896，即约 68 秒的推理时间处理完全部音频，RTFx 约为 169.6x。仓库中的 评测方法说明 还特别提醒：不要拿离线批处理的 RTFx 去对比流式首字延迟或端到端产品延迟，它们测量的是不同的东西；实时 WebSocket 服务的容量规划应参考 WebSocket 压测说明，该文档针对 实时服务端 测量首更延迟、STOP 后最终延迟、响应滞后与多客户端行为。

来源与限制：哪些东西缺失了

这份记录的可信度边界值得单独一节讲清楚。

来源固定方式：原报告固定到一个历史 GitHub Pages 提交（commit67d63b80a246dc33749e43904c294e0409cd9183下的zh/benchmark.html）；本次核对时，该文件与旧公网快照逐字节一致。这能确认表格出处，但不能证明原始测量正确或可复现。

缺失的材料清单：审计的原报告未披露 CPU 型号/线程数、数据成员与参考文本清单、精确 checkpoint revision、软件/驱动版本、逐文件预测和计时日志，以及是否包含预热、I/O、预处理在内的完整计时范围。缺少这些材料，旧表无法直接复现，"CPU 对比 GPU"的标题也不能视作面向所有生产环境的保证。

三条历史脚本不可执行：原报告引用的三个文件在本次审计的 FunASR 源码版本中都不存在，它们只是历史文本：

python benchmark/run_full_benchmark.py python benchmark/run_remaining.py python benchmark/fix_sensevoice_cer.py

文档明确说明没有提供替代脚本或复现数据，因此这三行命令不能直接执行，仓库中也不存在对应的替代实现。

两份数据必须分开引用：这份历史记录的总时长是11,539 秒，而 vLLM 评测方法 中公开 vLLM 表的总时长是11,541 秒。两者都提到 184 个文件，但这并不能证明数据成员完全一致。引用时不要合并两份表格的结果，也不要自行消除这两秒差异。

历史推荐选型表及其当前去向

原报告附带的选型建议表仅保留为历史上下文，不是新验证的推荐或性能排名：

从当前仓库文档交叉印证：模型与能力说明 中确实将sensevoice映射到iic/SenseVoiceSmall、fun-asr-nano映射到FunAudioLLM/Fun-ASR-Nano-2512，并给出了与上表方向一致的选型建议（例如"从 Whisper/云端 ASR 迁移：先用 SenseVoice-Small，再 benchmark 其他模型"）。历史表中的"选型"与当前文档只是方向性呼应，具体决策请以当前 模型选型、Agent 接口契约 和 vLLM 部署说明 为准。另外注意：独立 MLT checkpoint 的语种覆盖不能归到 Fun-ASR-Nano 头上，选型前请使用自己的音频、运行时与端到端延迟要求做评估。

新的测量怎么做：仓库给出的可执行路径

历史记录无法复现，但仓库为"新测量"提供了完整的规范与工具，按下面的顺序操作即可。

1. 先按可复现字段规范记录结果

评测方法说明 列出了发布 FunASR 基准时必须随数字一起给出的字段，覆盖数据、模型、运行时、硬件、软件版本、流水线开关、批处理参数、计时范围与质量评估九大类，例如：

文档同时给出五条计时协议：先算好总时长再跑 ASR；如需稳态吞吐先预热一次并声明；只计时一个口径（仅模型、仅流水线或端到端服务）；同一口径至少跑三次并给出中位数与最小/最大值；保留转写输出、失败文件列表与计时 JSON/CSV。

2. 用迁移计时工具在自己的音频上跑基线

仓库自带的 迁移基准脚本 就是这份指引落地的实现。它通过AutoModel加载模型，逐文件计时并写出两份产物：results.jsonl（逐文件明细）和summary.md（运行配置 + 汇总 + 每文件 RTF 表）。典型用法：

python examples/migration/benchmark_funasr.py \ --input /path/to/audio \ --model iic/SenseVoiceSmall \ --device cuda \ --vad-model fsmn-vad \ --language auto \ --batch-size 1 \ --metadata baseline=whisper-large-v3

结合源码可以看到几个关键设计：

• 音频时长优先用soundfile读取，.wav回退到标准库wave（时长探测逻辑）；
• 每个文件的实时倍率定义为音频秒数 / 推理秒数，与 RTFx 同口径（逐文件计时）；
• 单文件失败不会中断整个批次，错误会记入error字段并继续跑其余文件；
• 转写文本经过rich_transcription_postprocess清洗后再写入结果，避免富文本标签污染摘要；
• 支持--recursive递归扫描、--extensions过滤格式、--metadata key=value把基线信息（如baseline=whisper-large-v3）原样写进 summary，方便归档对比。

该脚本有一个明确的能力边界，与历史文档的表述一致：它只测量 FunASR 在你自有音频上的表现，不计算 CER/WER、不运行 Whisper，也不复现缺失的历史脚本。Whisper 或云端基线需要单独跑，然后用你正常的 WER/CER 或人工评审流程对比转写结果；计时范围、失败文件与质量评估要分别记录。

3. 场景化对照：离线吞吐、实时服务与 vLLM 是三个不同的表

引用 FunASR 数字时最容易犯的错，是把三张表混在一起：

• 历史总 ASR 表（本文主体）：184 文件、11,539 秒、H100 80GB，记录在 历史 ASR 评测；
• vLLM 吞吐表：184 文件、11,541 秒，记录 Fun-ASR-Nano 与 GLM-ASR-Nano 的 vLLM 吞吐，见 vLLM 部署说明。该表给出过 Fun-ASR-Nano vLLM 批量结果 RTFx 340、CER 8.20%，PyTorch 基线 RTFx 21、CER 8.06%——注意 RTFx 340 是实时倍率，不是"比 PyTorch 快 340 倍"，且这些历史测量不保证其他硬件与话务下的性能；
• 实时 WebSocket 压测：针对客户端可观察行为（首更延迟、STOP 后延迟、并发行为），见 WebSocket 压测说明。

新测量按 性能评测方法 记录；跨引擎（如 Rust 自定义运行时）对比时，要求同一份音频、同一重采样/降混策略、VAD/标点/说话人/时间戳全开或全关、速度和质量一起报告，并给出 RTFx 与原始处理秒数，而不是只给一个相对加速比。

小结：如何正确地引用这份历史记录

把原文档的核心纪律浓缩为四条：历史表格的数字、RTF 定义与"最佳"标签只能原样引用并注明出处；11,539 秒与 11,541 秒两份数据分开引用，不合并、不抹平；三条历史脚本命令不可执行，仓库也没有替代脚本；当前选型与性能判断一律以 模型选型、Agent 接口契约、vLLM 部署说明 和按 评测方法 自行跑出的新测量为准。做到这几点，这份来源不完整的早期记录就能安全地作为历史上下文被搜索引擎、Agent 和开发者检索引用，而不会演变成误导性的性能承诺。

【免费下载链接】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