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/FunASRFunASR 仓库的 历史 ASR 评测记录 收录了一份来源不完整但信息量很大的早期基准数据184 条中文长音频上SenseVoice-Small、Paraformer-Large、Fun-ASR-Nano 等模型在 H100 GPU 与 CPU 上的 RTF/CER 对比结果。本文以该记录为主体完整继承其数据表、RTF/RTFx 定义与来源限制并结合仓库中的 评测方法说明 与 迁移计时工具帮你既看懂这份历史记录又知道如何对它开展一次可复现的新测量。这份记录的定位历史快照不是当前保证在引用任何数字之前必须先明确这份文档的性质。原文明确声明它是一份来源不完整的历史记录用于帮助读者理解早期 FunASR 对比结果不是新测量、通用排行榜也不是对当前 checkpoint、机器或部署的保证。三个关键时间点与限定条件需要牢记表格数值与措辞均保留原报告原貌最佳等标签仅指该份报告不能推广到所有模型或硬件原页面没有披露测量日期文档中出现的2026-09-07 是本次来源快照核对日期不是测量日期开展新的评测前应先阅读仓库内的 性能评测方法说明而不是把这份历史表当作选型依据。历史概览数据集、硬件与基线原报告的核心测试条件如下表所示全部数字原样保留自历史记录指标结果数据集184 条中文长音频总时长 11,539 秒约 192.3 分钟GPUNVIDIA H100 80GB HBM3最佳 GPU 速度SenseVoice-Small完整基准 169.6x初次运行 211.8x最佳 CPU 速度SenseVoice-Small 17.2xParaformer-Large 15.6x基线OpenAI Whisper-large-v3GPU 上 13.4 倍实时这里有一个容易被误读的细节完整运行的 169.6x 与初次运行的 211.8x 是两个独立报告的结果它们之间不存在性能回退或性能波动的结论依据只是原报告中两次口径不同的记录。引用时必须注明是哪一个数字。历史结果表完整数据与引用边界下表是历史记录的核心全部数值和说明都是原报告的历史表述不是当前 API 能力保证模型设备RTF速度CER说明SenseVoice-SmallGPU0.005896169.6x7.81%ASR 语种 / 情感 / 事件标签CER 已去除标签后计算Paraformer-LargeGPU0.008356119.6x10.18%高速非自回归中文 ASR适合 VAD/标点生产流水线Fun-ASR-NanoGPU0.05880317.0x8.06%LLM-based 中/英/日 ASR另覆盖 7 类中文方言和 26 种地域口音支持热词不提供可靠的 checkpoint 原生时间戳见 Fun-ASR 上游 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 模型更重但仍高于实时原始精度以及经过舍入的速度/RTF 数值均原样保留不做重新计算。同时必须保留原文档给出的两条引用边界模型原始输出包含富文本标签不代表 HTTP 接口一定返回这些标签旧记录中的时间戳限制也不能代替当前的 模型选型说明CPU/GPU 行重复出现相同 CER不能证明曾分别独立评分审计材料中没有原始预测、参考文本或评分程序去除标签后计算仅保留为历史说法不是本次验证过的评分输出。RTF 与 RTFx 的定义原报告将 RTF 定义为总推理时间除以总音频时长速度为其倒数后者也称 RTFxRTF 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-Small 或 Paraformer-LargeCPU 批量转写优先 SenseVoice-Small中文生产流水线可选 Paraformer-Large中/英/日及中文方言、口音的 LLM-style 识别Fun-ASR-Nano需要 31 语种时使用独立的 Fun-ASR-MLT-Nano checkpoint并使用 vLLM 提升 LLM 解码吞吐见 vLLM 部署说明OpenAI 兼容本地服务使用 funasr-server模型别名为sensevoice、paraformer或fun-asr-nano见 Agent 接口契约从当前仓库文档交叉印证模型与能力说明 中确实将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 基准时必须随数字一起给出的字段覆盖数据、模型、运行时、硬件、软件版本、流水线开关、批处理参数、计时范围与质量评估九大类例如类别需要记录的内容数据文件数、总音频时长、语言/领域、采样率、单声道处理、测试文件是否公开模型模型 ID、checkpoint 来源与 revision、语种设置、热词、文本规范化运行时Python SDK、ONNX、C、vLLM、llama.cpp/GGUF 还是 API 服务硬件CPU 型号与线程数、GPU 型号与数量、显存、驱动、CUDA 版本计时范围是否包含模型下载、冷启动、预热、文件 I/O、音频解码/重采样、VAD、后处理与序列化质量CER/WER 方法、参考文本规范化、忽略 token、失败文件处理文档同时给出五条计时协议先算好总时长再跑 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 baselinewhisper-large-v3结合源码可以看到几个关键设计音频时长优先用soundfile读取.wav回退到标准库wave时长探测逻辑每个文件的实时倍率定义为音频秒数 / 推理秒数与 RTFx 同口径逐文件计时单文件失败不会中断整个批次错误会记入error字段并继续跑其余文件转写文本经过rich_transcription_postprocess清洗后再写入结果避免富文本标签污染摘要支持--recursive递归扫描、--extensions过滤格式、--metadata keyvalue把基线信息如baselinewhisper-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FunASR 历史 ASR 基准记录详解：读懂早期 RTF/CER 数据并开展可复现的新评测
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/FunASRFunASR 仓库的 历史 ASR 评测记录 收录了一份来源不完整但信息量很大的早期基准数据184 条中文长音频上SenseVoice-Small、Paraformer-Large、Fun-ASR-Nano 等模型在 H100 GPU 与 CPU 上的 RTF/CER 对比结果。本文以该记录为主体完整继承其数据表、RTF/RTFx 定义与来源限制并结合仓库中的 评测方法说明 与 迁移计时工具帮你既看懂这份历史记录又知道如何对它开展一次可复现的新测量。这份记录的定位历史快照不是当前保证在引用任何数字之前必须先明确这份文档的性质。原文明确声明它是一份来源不完整的历史记录用于帮助读者理解早期 FunASR 对比结果不是新测量、通用排行榜也不是对当前 checkpoint、机器或部署的保证。三个关键时间点与限定条件需要牢记表格数值与措辞均保留原报告原貌最佳等标签仅指该份报告不能推广到所有模型或硬件原页面没有披露测量日期文档中出现的2026-09-07 是本次来源快照核对日期不是测量日期开展新的评测前应先阅读仓库内的 性能评测方法说明而不是把这份历史表当作选型依据。历史概览数据集、硬件与基线原报告的核心测试条件如下表所示全部数字原样保留自历史记录指标结果数据集184 条中文长音频总时长 11,539 秒约 192.3 分钟GPUNVIDIA H100 80GB HBM3最佳 GPU 速度SenseVoice-Small完整基准 169.6x初次运行 211.8x最佳 CPU 速度SenseVoice-Small 17.2xParaformer-Large 15.6x基线OpenAI Whisper-large-v3GPU 上 13.4 倍实时这里有一个容易被误读的细节完整运行的 169.6x 与初次运行的 211.8x 是两个独立报告的结果它们之间不存在性能回退或性能波动的结论依据只是原报告中两次口径不同的记录。引用时必须注明是哪一个数字。历史结果表完整数据与引用边界下表是历史记录的核心全部数值和说明都是原报告的历史表述不是当前 API 能力保证模型设备RTF速度CER说明SenseVoice-SmallGPU0.005896169.6x7.81%ASR 语种 / 情感 / 事件标签CER 已去除标签后计算Paraformer-LargeGPU0.008356119.6x10.18%高速非自回归中文 ASR适合 VAD/标点生产流水线Fun-ASR-NanoGPU0.05880317.0x8.06%LLM-based 中/英/日 ASR另覆盖 7 类中文方言和 26 种地域口音支持热词不提供可靠的 checkpoint 原生时间戳见 Fun-ASR 上游 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 模型更重但仍高于实时原始精度以及经过舍入的速度/RTF 数值均原样保留不做重新计算。同时必须保留原文档给出的两条引用边界模型原始输出包含富文本标签不代表 HTTP 接口一定返回这些标签旧记录中的时间戳限制也不能代替当前的 模型选型说明CPU/GPU 行重复出现相同 CER不能证明曾分别独立评分审计材料中没有原始预测、参考文本或评分程序去除标签后计算仅保留为历史说法不是本次验证过的评分输出。RTF 与 RTFx 的定义原报告将 RTF 定义为总推理时间除以总音频时长速度为其倒数后者也称 RTFxRTF 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-Small 或 Paraformer-LargeCPU 批量转写优先 SenseVoice-Small中文生产流水线可选 Paraformer-Large中/英/日及中文方言、口音的 LLM-style 识别Fun-ASR-Nano需要 31 语种时使用独立的 Fun-ASR-MLT-Nano checkpoint并使用 vLLM 提升 LLM 解码吞吐见 vLLM 部署说明OpenAI 兼容本地服务使用 funasr-server模型别名为sensevoice、paraformer或fun-asr-nano见 Agent 接口契约从当前仓库文档交叉印证模型与能力说明 中确实将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 基准时必须随数字一起给出的字段覆盖数据、模型、运行时、硬件、软件版本、流水线开关、批处理参数、计时范围与质量评估九大类例如类别需要记录的内容数据文件数、总音频时长、语言/领域、采样率、单声道处理、测试文件是否公开模型模型 ID、checkpoint 来源与 revision、语种设置、热词、文本规范化运行时Python SDK、ONNX、C、vLLM、llama.cpp/GGUF 还是 API 服务硬件CPU 型号与线程数、GPU 型号与数量、显存、驱动、CUDA 版本计时范围是否包含模型下载、冷启动、预热、文件 I/O、音频解码/重采样、VAD、后处理与序列化质量CER/WER 方法、参考文本规范化、忽略 token、失败文件处理文档同时给出五条计时协议先算好总时长再跑 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 baselinewhisper-large-v3结合源码可以看到几个关键设计音频时长优先用soundfile读取.wav回退到标准库wave时长探测逻辑每个文件的实时倍率定义为音频秒数 / 推理秒数与 RTFx 同口径逐文件计时单文件失败不会中断整个批次错误会记入error字段并继续跑其余文件转写文本经过rich_transcription_postprocess清洗后再写入结果避免富文本标签污染摘要支持--recursive递归扫描、--extensions过滤格式、--metadata keyvalue把基线信息如baselinewhisper-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考