FunASR ONNX Runtime CPU 推理性能基准Paraformer 的 RTF、加速比与 int8 量化复现指南【免费下载链接】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 仓库中的 ONNX CPU 基准文档系统讲解如何复现 Paraformer 系列模型在 ONNX Runtime 上的 CPU 推理性能测试包括 Aishell1 测试集的使用、test_rtf.sh/test_cer.sh两套脚本的完整流程与参数含义、RTF 与加速比Speedup Rate的计算方式以及 int8 动态量化在不同 Xeon 处理器上的实测收益并深入 ONNX 推理封装源码 说明模型加载与量化的底层机制帮助你在纯 CPU 环境下快速评估与部署 Paraformer 离线识别服务。一、基准测试的测试条件基准测试的测试条件与仓库文档保持一致复现前需要明确三个前提数据集Aishell1 test 集音频总时长36108.919 秒约 10 小时。该总时长是计算 RTF 的分母基准。推理后端ONNX Runtimebackendonnx精度分别为 fp32model.onnx与 int8 动态量化model_quant.onnx。被测模型Paraformer-large220M 参数模型文件 880MBint8 量化后 237MBAishell1 CER 1.95%量化后仍为 1.95%Paraformer68M 参数模型文件 275MBint8 量化后 81MBCER 3.73%量化后 3.78%几乎无损有 0.05% 的极小波动。测试在三种 Xeon 平台上进行平台差异主要体现在avx512_vnni 指令集是否可用——这正是 int8 量化加速的核心依赖后文结果分析部分会专门展开。二、环境准备依赖安装与模型导出2.1 安装 funasr 与 modelscope首先需要安装模型下载与训练推理框架pip install -U modelscope funasr # 国内用户可改用镜像源 # pip install -U funasr -i https://mirror.sjtu.edu.cn/pypi/web/simple2.2 安装基准脚本依赖仓库将 ONNX 基准脚本所需的依赖集中放在 runtime/python/utils/requirements.txt 中onnx onnxruntime torch-quant 0.4.0 funasr_torch funasr_onnx其中onnx与onnxruntime负责模型导出与推理torch-quant是 int8 动态量化工具funasr_torch与funasr_onnx则是从源码安装的 libtorch / ONNX 推理封装对应 runtime/python/libtorch 与 runtime/python/onnxruntime 两个子包。在 FunASR 仓库源码目录下执行cd runtime/python/utils pip install -r requirements.txt注意根据 ONNX Runtime 子目录说明funasr-onnx是独立于funasr的发行包升级funasr不会更新 ONNX 封装建议用python -m pip show funasr-onnx funasr分别确认版本必要时按 README 中的pip install -e ./方式从源码安装。2.3 导出 ONNX 模型基准脚本在 stage 0 会自动完成导出核心命令为python -m funasr.export.export_model \ --model-name damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-pytorch \ --export-dir ${export_root} \ --type onnx \ --quantize true \ --audio_in ${scp}即 test_rtf.sh 中 stage 0 分支的执行逻辑--type onnx指定后端--quantize true表示同时生成 int8 量化模型产物为model_quant.onnx--audio_in传入 wav.scp 用于导出时确定输入 shape。model_dir参数既支持 ModelScope 模型名也支持本地目录本地目录需包含model.onnx、config.yaml、am.mvn等文件见 ONNX 推理封装源码 中的加载逻辑。三、基准脚本详解test_rtf 与 test_cer3.1 test_rtf并发 RTF 测量仓库文档给出的运行方式为nohup bash test_rtf.sh log.txt 运行前需要修改 test_rtf.sh 中的三个关键变量脚本中以注释块形式给出model_namedamo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-pytorch backendonnx # 可选 torch quantizetrue # False 表示 fp32以及数据路径scpAishell1 test 的wav.scp与输出根目录export_root。脚本的完整执行链是stage 0执行上述funasr.export.export_model导出 onnx含量化模型stage 1 切分用 split_scp.pl 把wav.scp平均切成nj默认 32份wav.$JOB.scpstage 1 并发推理为每个 JOB 用taskset -c ${core_id}绑定到独立 CPU 核上并行执行 test_rtf.py——这正是基准表中“concurrent-tasks nj”的来源32 个进程各占 1 核模拟 32 路并发请求stage 1 汇总从各任务日志中 grep 出total_time_comput、total_time_wav后汇总计算rtf max(各任务耗时) / sum(各任务音频时长) speed 1 / rtf # 即 Speedup Rate注意 RTF 的分子取的是最慢任务的耗时墙钟时间口径而非平均耗时——这与并发部署的真实用户体感一致。3.2 test_cer精度验证test_cer.sh用于测量量化前后模型的识别准确率运行方式同为nohup bash test_cer.sh log.txt 。其分三个阶段test_cer.shstage 0 导出与 RTF 脚本相同但额外带--fallback-num 20参数允许最多 20 个算子回退到 libtorch 计算funasr_torch后端兜底保证 ONNX 导出对特殊算子的兼容性stage 1 推理同样切分 scp、taskset绑核并发运行 test_cer.py每个任务将text/token结果写入各自输出目录最后按 wav 名排序合并到1best_recog/stage 2 计算 CER依次调用 proce_text.py 归一化识别文本与参考文本去标点、转小写等再由 compute_wer.py 计算错误率tail -n 3输出总 CER。test_rtf.py与test_cer.py的公共推理逻辑test_rtf.pyparser.add_argument(--backend, typestr, defaultonnx) # [onnx, torch] parser.add_argument(--quantize, typestr2bool, defaultFalse) # True 加载 model_quant.onnx parser.add_argument(--intra_op_num_threads, typeint, default1) # onnx 核内并行线程数 if args.backend onnx: from funasr.runtime.python.onnxruntime.funasr_onnx import Paraformer model Paraformer(args.model_dir, batch_size1, quantizeargs.quantize, intra_op_num_threadsargs.intra_op_num_threads)值得注意的两个测量细节test_rtf.py在正式计时前先用首条音频做30 次 warm-up以稳定缓存与线程池intra_op_num_threads默认设为 1配合taskset单核绑定使“每任务单核”的口径与并发度严格对应——每个进程的 RTF 即为单核 RTF汇总后得到多路并发的整体加速比。四、基准结果Paraformer-large220M 参数模型规模 220M 参数存储 880MBfp32/ 237MBint8Aishell1 test CER 1.95%int8 量化后仍为1.95%——量化在该模型上完全无损。Intel(R) Xeon(R) Platinum 8369B 2.90GHz16 核 32 线程支持 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)28060.077712.91 (onnx int8)16110.044622.48 (onnx fp32)5380.014967.18 (onnx int8)2100.0058172.416 (onnx fp32)2880.0080125.216 (onnx int8)1170.0032309.932 (onnx fp32)1670.0046216.532 (onnx int8)860.0024420.064 (onnx fp32)1580.0044228.164 (onnx int8)820.0023442.896 (onnx fp32)1510.0042238.096 (onnx int8)800.0022452.0Intel(R) Xeon(R) Platinum 8269CY 2.50GHz16 核 32 线程支持 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)26130.072413.81 (onnx int8)13210.036622.432 (onnx fp32)1700.0047212.732 (onnx int8)890.0025407.064 (onnx fp32)1660.0046217.164 (onnx int8)870.0024414.7Intel(R) Xeon(R) Platinum 8163 2.50GHz32 核 64 线程无 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)29590.082012.21 (onnx int8)28140.077812.816 (onnx fp32)3730.010396.916 (onnx int8)3310.0091109.032 (onnx fp32)2110.0058171.432 (onnx int8)1810.0050200.064 (onnx fp32)1530.0042235.964 (onnx int8)1030.0029349.996 (onnx fp32)1460.0041247.096 (onnx int8)1080.0030334.1五、基准结果Paraformer68M 参数模型规模 68M 参数存储 275MBfp32/ 81MBint8Aishell1 test CER 3.73%int8 量化后 3.78%——同样接近无损。Intel(R) Xeon(R) Platinum 8369B 2.90GHz16 核 32 线程支持 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)11730.032530.81 (onnx int8)9760.027037.016 (onnx fp32)910.0025395.216 (onnx int8)780.0022463.032 (onnx fp32)600.0017598.832 (onnx int8)400.0011892.964 (onnx fp32)550.0015653.664 (onnx int8)310.00091162.896 (onnx fp32)570.0016632.996 (onnx int8)330.00091098.9六、结果分析量化收益、指令集与并发扩展性结合三张表可以归纳出几个对部署选型有直接指导意义的结论int8 量化的收益强烈依赖 avx512_vnni。在支持 avx512_vnni 的 8369B / 8269CY 上Paraformer-large 单任务 int8 相比 fp32 处理时间缩短约 42%2806s → 1611sSpeedup 从 12.9 提升到 22.4接近 1.7 倍而在不支持 avx512_vnni 的 8163 上单任务 int8 与 fp32 几乎持平2814s vs 2959s加速比反而略高仅源于微小误差。这说明 onnxruntime 的 int8 GEMM kernel 在缺少 VNNI 指令时没有明显优势。并发扩展性接近线性。8369B 上 Paraformer-large int8 的 Speedup 从 1 任务的 22.4 提升到 32 任务的 420.0约 18.7 倍于并发度说明taskset绑核 每任务单核推理的口径下任务间几乎无争抢。超过物理核数后收益饱和。8369B 只有 16 核 32 线程但 32/64/96 任务的处理时间差异很小fp32 从 167s 到 151s说明超核并发主要靠超线程填充吞吐趋于上限选型时以物理核数 × 2 附近设置并发即可。小模型并发效率更高。68M 的 Paraformer 单任务 Speedup30.8/37.0约为 220M Paraformer-large12.9/22.4的 2.4 倍96 并发 int8 下达 1098.9接近 Paraformer-large 的 2.4 倍——模型越小单核算力利用率与吞吐上限越高适合对时延敏感的中小规模部署。量化精度基本无损。两个模型的量化后 CER 与 fp32 差异均在 0.05% 以内且量化将模型文件缩小到约 1/4880MB → 237MB对 CPU 服务的内存占用与加载速度都有实际好处。七、底层机制ONNX 推理封装如何加载与量化上述结果最终都通过funasr_onnx.Paraformer这一封装类产生paraformer_bin.py几个实现细节解释了基准脚本各参数的作用量化开关只切换模型文件。构造函数中model_file默认指向model.onnx当quantizeTrue时切换为model_quant.onnx源码 L65-L68——即 fp32/int8 两条基准数据来自同一导出目录下的两个模型文件推理代码路径完全一致排除了实现差异对对比结果的干扰。缺 onnx 文件时自动导出。若model_dir下不存在model.onnx封装会提示并尝试通过funasr.AutoModel(...).export(typeonnx, quantizequantize)在线导出源码 L68-L78这解释了为什么test_rtf.sh的 stage 0 导出失败后后续阶段仍可能自行补齐模型。会话级线程控制。intra_op_num_threads透传给 OrtInferSession控制 onnxruntime 会话的核内并行度基准脚本将其设为 1 并配合taskset绑核保证“1 任务 1 核”的测量口径。推理主链路。__call__中依次执行波形加载 →WavFrontend特征提取含am.mvnCMVN 归一化→infer输出am_scores/valid_token_lens再经时间戳对齐time_stamp_lfr6_onnx与文本后处理sentence_postprocess生成结果支持 BiCifParaformer 的四路输出额外返回us_alphas、us_peaks。这套与训练框架funasr一致的封装结构使得基准测量的是真实部署时的完整推理链路而非裸算子性能。八、在自己的机器上复现完整复现步骤汇总如下相对本仓库根目录安装依赖pip install -U modelscope funasr再cd runtime/python/utils pip install -r requirements.txt准备 Aishell1 test 的wav.scp与参考文本text文件修改 test_rtf.sh 中的scp、export_root、model_name、backend、quantize按并发需求调整nj注意nj即“concurrent-tasks”然后nohup bash test_rtf.sh log.txt 需要验证精度时同样修改 test_cer.sh 的scp、label_text、export_root等变量后运行最终 CER 由1best_recog/text.cer末尾三行给出对比口径total_rtf取最慢任务耗时与总音频时长36108.919s 附近取决于切分之比Speedup Rate 1/RTF。如果你已有导出的 ONNX 模型也可以跳过脚本直接用 Python 封装单条推理验证加载是否正常参见 ONNX Runtime README 的 Paraformer 示例Paraformer(model_dir, batch_size1, quantizeTrue)若需要 C 侧的更优单核性能仓库另有 ONNX-C 基准文档 可对照阅读其结论int8 单核加速约 17 → 35与本文 Python 侧数据互相印证。九、小结Paraformer 系列在纯 CPU ONNX Runtime 下即可做到RTF 0.1 的单核实时性能多核并发下 Speedup 最高超过 1000 倍int8 动态量化在支持 avx512_vnni 的机器上可提升约 1.7 倍单核速度且精度无损模型体积缩至 1/4在老平台上收益有限选型前建议先用test_rtf.sh小样本实测复现入口集中在 runtime/python/utils/ 的test_rtf.sh/test_cer.sh测量口径warm-up、taskset 绑核、最慢任务聚合都已在脚本中固化结果可交叉核对。【免费下载链接】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 ONNX Runtime CPU 推理性能基准：Paraformer 的 RTF、加速比与 int8 量化复现指南
FunASR ONNX Runtime CPU 推理性能基准Paraformer 的 RTF、加速比与 int8 量化复现指南【免费下载链接】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 仓库中的 ONNX CPU 基准文档系统讲解如何复现 Paraformer 系列模型在 ONNX Runtime 上的 CPU 推理性能测试包括 Aishell1 测试集的使用、test_rtf.sh/test_cer.sh两套脚本的完整流程与参数含义、RTF 与加速比Speedup Rate的计算方式以及 int8 动态量化在不同 Xeon 处理器上的实测收益并深入 ONNX 推理封装源码 说明模型加载与量化的底层机制帮助你在纯 CPU 环境下快速评估与部署 Paraformer 离线识别服务。一、基准测试的测试条件基准测试的测试条件与仓库文档保持一致复现前需要明确三个前提数据集Aishell1 test 集音频总时长36108.919 秒约 10 小时。该总时长是计算 RTF 的分母基准。推理后端ONNX Runtimebackendonnx精度分别为 fp32model.onnx与 int8 动态量化model_quant.onnx。被测模型Paraformer-large220M 参数模型文件 880MBint8 量化后 237MBAishell1 CER 1.95%量化后仍为 1.95%Paraformer68M 参数模型文件 275MBint8 量化后 81MBCER 3.73%量化后 3.78%几乎无损有 0.05% 的极小波动。测试在三种 Xeon 平台上进行平台差异主要体现在avx512_vnni 指令集是否可用——这正是 int8 量化加速的核心依赖后文结果分析部分会专门展开。二、环境准备依赖安装与模型导出2.1 安装 funasr 与 modelscope首先需要安装模型下载与训练推理框架pip install -U modelscope funasr # 国内用户可改用镜像源 # pip install -U funasr -i https://mirror.sjtu.edu.cn/pypi/web/simple2.2 安装基准脚本依赖仓库将 ONNX 基准脚本所需的依赖集中放在 runtime/python/utils/requirements.txt 中onnx onnxruntime torch-quant 0.4.0 funasr_torch funasr_onnx其中onnx与onnxruntime负责模型导出与推理torch-quant是 int8 动态量化工具funasr_torch与funasr_onnx则是从源码安装的 libtorch / ONNX 推理封装对应 runtime/python/libtorch 与 runtime/python/onnxruntime 两个子包。在 FunASR 仓库源码目录下执行cd runtime/python/utils pip install -r requirements.txt注意根据 ONNX Runtime 子目录说明funasr-onnx是独立于funasr的发行包升级funasr不会更新 ONNX 封装建议用python -m pip show funasr-onnx funasr分别确认版本必要时按 README 中的pip install -e ./方式从源码安装。2.3 导出 ONNX 模型基准脚本在 stage 0 会自动完成导出核心命令为python -m funasr.export.export_model \ --model-name damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-pytorch \ --export-dir ${export_root} \ --type onnx \ --quantize true \ --audio_in ${scp}即 test_rtf.sh 中 stage 0 分支的执行逻辑--type onnx指定后端--quantize true表示同时生成 int8 量化模型产物为model_quant.onnx--audio_in传入 wav.scp 用于导出时确定输入 shape。model_dir参数既支持 ModelScope 模型名也支持本地目录本地目录需包含model.onnx、config.yaml、am.mvn等文件见 ONNX 推理封装源码 中的加载逻辑。三、基准脚本详解test_rtf 与 test_cer3.1 test_rtf并发 RTF 测量仓库文档给出的运行方式为nohup bash test_rtf.sh log.txt 运行前需要修改 test_rtf.sh 中的三个关键变量脚本中以注释块形式给出model_namedamo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-pytorch backendonnx # 可选 torch quantizetrue # False 表示 fp32以及数据路径scpAishell1 test 的wav.scp与输出根目录export_root。脚本的完整执行链是stage 0执行上述funasr.export.export_model导出 onnx含量化模型stage 1 切分用 split_scp.pl 把wav.scp平均切成nj默认 32份wav.$JOB.scpstage 1 并发推理为每个 JOB 用taskset -c ${core_id}绑定到独立 CPU 核上并行执行 test_rtf.py——这正是基准表中“concurrent-tasks nj”的来源32 个进程各占 1 核模拟 32 路并发请求stage 1 汇总从各任务日志中 grep 出total_time_comput、total_time_wav后汇总计算rtf max(各任务耗时) / sum(各任务音频时长) speed 1 / rtf # 即 Speedup Rate注意 RTF 的分子取的是最慢任务的耗时墙钟时间口径而非平均耗时——这与并发部署的真实用户体感一致。3.2 test_cer精度验证test_cer.sh用于测量量化前后模型的识别准确率运行方式同为nohup bash test_cer.sh log.txt 。其分三个阶段test_cer.shstage 0 导出与 RTF 脚本相同但额外带--fallback-num 20参数允许最多 20 个算子回退到 libtorch 计算funasr_torch后端兜底保证 ONNX 导出对特殊算子的兼容性stage 1 推理同样切分 scp、taskset绑核并发运行 test_cer.py每个任务将text/token结果写入各自输出目录最后按 wav 名排序合并到1best_recog/stage 2 计算 CER依次调用 proce_text.py 归一化识别文本与参考文本去标点、转小写等再由 compute_wer.py 计算错误率tail -n 3输出总 CER。test_rtf.py与test_cer.py的公共推理逻辑test_rtf.pyparser.add_argument(--backend, typestr, defaultonnx) # [onnx, torch] parser.add_argument(--quantize, typestr2bool, defaultFalse) # True 加载 model_quant.onnx parser.add_argument(--intra_op_num_threads, typeint, default1) # onnx 核内并行线程数 if args.backend onnx: from funasr.runtime.python.onnxruntime.funasr_onnx import Paraformer model Paraformer(args.model_dir, batch_size1, quantizeargs.quantize, intra_op_num_threadsargs.intra_op_num_threads)值得注意的两个测量细节test_rtf.py在正式计时前先用首条音频做30 次 warm-up以稳定缓存与线程池intra_op_num_threads默认设为 1配合taskset单核绑定使“每任务单核”的口径与并发度严格对应——每个进程的 RTF 即为单核 RTF汇总后得到多路并发的整体加速比。四、基准结果Paraformer-large220M 参数模型规模 220M 参数存储 880MBfp32/ 237MBint8Aishell1 test CER 1.95%int8 量化后仍为1.95%——量化在该模型上完全无损。Intel(R) Xeon(R) Platinum 8369B 2.90GHz16 核 32 线程支持 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)28060.077712.91 (onnx int8)16110.044622.48 (onnx fp32)5380.014967.18 (onnx int8)2100.0058172.416 (onnx fp32)2880.0080125.216 (onnx int8)1170.0032309.932 (onnx fp32)1670.0046216.532 (onnx int8)860.0024420.064 (onnx fp32)1580.0044228.164 (onnx int8)820.0023442.896 (onnx fp32)1510.0042238.096 (onnx int8)800.0022452.0Intel(R) Xeon(R) Platinum 8269CY 2.50GHz16 核 32 线程支持 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)26130.072413.81 (onnx int8)13210.036622.432 (onnx fp32)1700.0047212.732 (onnx int8)890.0025407.064 (onnx fp32)1660.0046217.164 (onnx int8)870.0024414.7Intel(R) Xeon(R) Platinum 8163 2.50GHz32 核 64 线程无 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)29590.082012.21 (onnx int8)28140.077812.816 (onnx fp32)3730.010396.916 (onnx int8)3310.0091109.032 (onnx fp32)2110.0058171.432 (onnx int8)1810.0050200.064 (onnx fp32)1530.0042235.964 (onnx int8)1030.0029349.996 (onnx fp32)1460.0041247.096 (onnx int8)1080.0030334.1五、基准结果Paraformer68M 参数模型规模 68M 参数存储 275MBfp32/ 81MBint8Aishell1 test CER 3.73%int8 量化后 3.78%——同样接近无损。Intel(R) Xeon(R) Platinum 8369B 2.90GHz16 核 32 线程支持 avx512_vnniconcurrent-tasksprocessing time(s)RTFSpeedup Rate1 (onnx fp32)11730.032530.81 (onnx int8)9760.027037.016 (onnx fp32)910.0025395.216 (onnx int8)780.0022463.032 (onnx fp32)600.0017598.832 (onnx int8)400.0011892.964 (onnx fp32)550.0015653.664 (onnx int8)310.00091162.896 (onnx fp32)570.0016632.996 (onnx int8)330.00091098.9六、结果分析量化收益、指令集与并发扩展性结合三张表可以归纳出几个对部署选型有直接指导意义的结论int8 量化的收益强烈依赖 avx512_vnni。在支持 avx512_vnni 的 8369B / 8269CY 上Paraformer-large 单任务 int8 相比 fp32 处理时间缩短约 42%2806s → 1611sSpeedup 从 12.9 提升到 22.4接近 1.7 倍而在不支持 avx512_vnni 的 8163 上单任务 int8 与 fp32 几乎持平2814s vs 2959s加速比反而略高仅源于微小误差。这说明 onnxruntime 的 int8 GEMM kernel 在缺少 VNNI 指令时没有明显优势。并发扩展性接近线性。8369B 上 Paraformer-large int8 的 Speedup 从 1 任务的 22.4 提升到 32 任务的 420.0约 18.7 倍于并发度说明taskset绑核 每任务单核推理的口径下任务间几乎无争抢。超过物理核数后收益饱和。8369B 只有 16 核 32 线程但 32/64/96 任务的处理时间差异很小fp32 从 167s 到 151s说明超核并发主要靠超线程填充吞吐趋于上限选型时以物理核数 × 2 附近设置并发即可。小模型并发效率更高。68M 的 Paraformer 单任务 Speedup30.8/37.0约为 220M Paraformer-large12.9/22.4的 2.4 倍96 并发 int8 下达 1098.9接近 Paraformer-large 的 2.4 倍——模型越小单核算力利用率与吞吐上限越高适合对时延敏感的中小规模部署。量化精度基本无损。两个模型的量化后 CER 与 fp32 差异均在 0.05% 以内且量化将模型文件缩小到约 1/4880MB → 237MB对 CPU 服务的内存占用与加载速度都有实际好处。七、底层机制ONNX 推理封装如何加载与量化上述结果最终都通过funasr_onnx.Paraformer这一封装类产生paraformer_bin.py几个实现细节解释了基准脚本各参数的作用量化开关只切换模型文件。构造函数中model_file默认指向model.onnx当quantizeTrue时切换为model_quant.onnx源码 L65-L68——即 fp32/int8 两条基准数据来自同一导出目录下的两个模型文件推理代码路径完全一致排除了实现差异对对比结果的干扰。缺 onnx 文件时自动导出。若model_dir下不存在model.onnx封装会提示并尝试通过funasr.AutoModel(...).export(typeonnx, quantizequantize)在线导出源码 L68-L78这解释了为什么test_rtf.sh的 stage 0 导出失败后后续阶段仍可能自行补齐模型。会话级线程控制。intra_op_num_threads透传给 OrtInferSession控制 onnxruntime 会话的核内并行度基准脚本将其设为 1 并配合taskset绑核保证“1 任务 1 核”的测量口径。推理主链路。__call__中依次执行波形加载 →WavFrontend特征提取含am.mvnCMVN 归一化→infer输出am_scores/valid_token_lens再经时间戳对齐time_stamp_lfr6_onnx与文本后处理sentence_postprocess生成结果支持 BiCifParaformer 的四路输出额外返回us_alphas、us_peaks。这套与训练框架funasr一致的封装结构使得基准测量的是真实部署时的完整推理链路而非裸算子性能。八、在自己的机器上复现完整复现步骤汇总如下相对本仓库根目录安装依赖pip install -U modelscope funasr再cd runtime/python/utils pip install -r requirements.txt准备 Aishell1 test 的wav.scp与参考文本text文件修改 test_rtf.sh 中的scp、export_root、model_name、backend、quantize按并发需求调整nj注意nj即“concurrent-tasks”然后nohup bash test_rtf.sh log.txt 需要验证精度时同样修改 test_cer.sh 的scp、label_text、export_root等变量后运行最终 CER 由1best_recog/text.cer末尾三行给出对比口径total_rtf取最慢任务耗时与总音频时长36108.919s 附近取决于切分之比Speedup Rate 1/RTF。如果你已有导出的 ONNX 模型也可以跳过脚本直接用 Python 封装单条推理验证加载是否正常参见 ONNX Runtime README 的 Paraformer 示例Paraformer(model_dir, batch_size1, quantizeTrue)若需要 C 侧的更优单核性能仓库另有 ONNX-C 基准文档 可对照阅读其结论int8 单核加速约 17 → 35与本文 Python 侧数据互相印证。九、小结Paraformer 系列在纯 CPU ONNX Runtime 下即可做到RTF 0.1 的单核实时性能多核并发下 Speedup 最高超过 1000 倍int8 动态量化在支持 avx512_vnni 的机器上可提升约 1.7 倍单核速度且精度无损模型体积缩至 1/4在老平台上收益有限选型前建议先用test_rtf.sh小样本实测复现入口集中在 runtime/python/utils/ 的test_rtf.sh/test_cer.sh测量口径warm-up、taskset 绑核、最慢任务聚合都已在脚本中固化结果可交叉核对。【免费下载链接】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），仅供参考