和 whisper.cpp 比一次：一台机器，一条音频，一个诚实的数字

同一台 macos/aarch64 主机，同一个 whisper-large-v3-turbo q8_0 模型，best-of-N 取最优——OpenASR 跑出 2370 ms 对 whisper.cpp 的 2573 ms，领先约 7.9%。这个数字不是宣传语，而是一道回归门禁。

基准测试的数字好发，经得起推敲的数字不好发。随便挑一台调过参的机器跑一轮，总能写出”提速 XX%“——但换一台机器、换一个版本、过半年再跑，那个数字还在不在？OpenASR 选择把性能基准直接提交进仓库：一份 suite 定义、一份 baseline JSON、一份文档。和 whisper.cpp 的对比只是其中一条被门禁保护的条目。这篇文章讲的是这条条目到底测了什么，以及它刻意没测什么。

这条条目叫 whisper-turbo-q8-vs-cpp。它让 OpenASR 和 whisper.cpp 跑同一个模型——whisper-large-v3-turbo，q8_0 量化——然后以 best-of-N wall clock 取成绩，避免后台负载偶然左右胜负。

同底层，不只是同模型

这里有必要说清楚：这是一次同底层的对比。OpenASR 的推理后端是一层薄的 Rust 封装，构建在 ggml 的 fork（third_party/openasr-ggml）之上。ggml 是 MIT 协议的 C 库，源自 llama.cpp / whisper.cpp 项目。也就是说，对比的两边跑的是同一个计算内核，跑得更快只说明调优和集成层面的差异，不代表引擎不同。我们感谢 Georgi Gerganov 以及 ggml / llama.cpp / whisper.cpp 社区的工作——没有他们，这个项目不会存在。

提交进仓库的那个数字

在一台 macos/aarch64 主机上，committed baseline 记录的成绩是：OpenASR 2370 ms，whisper.cpp 2573 ms，同一份 turbo q8_0 模型包。算下来 (2573 − 2370) / 2573 ≈ 7.9%。权威来源是仓库里的 baseline JSON，不是这段话，也不是任何一次重跑。7.9% 是我们对外引用的数字。

# 跑 whisper 系列的 suite 条目
# best-of-3 wall clock；每条条目在独立子进程中运行
openasr bench-suite --family whisper

看分布，不看标题

一次跑分不构成结论。我们报告的优势区间是 ~8–11%——在同一台主机上三组不同配置分别跑出 7.9% / 9.5% / 10.9%，committed baseline 取的是最低端的 7.9%。举例来说，线程数对齐（-t 4）的那组测出 2790 ms 对 3083 ms，约 9.5%。用最低端做标题是有意为之：如果将来这个数字要动，它应该往仓库里已有的那个方向动。

把它当作一次同模型、受控条件下的实测对比外加一道回归护栏——而不是”我们终于全面超过了开源”的宣言。

——引自 perf/PERFORMANCE.md

这句话是上面所有数字的承重声明。这次对比是单模型、单音频、单机器。它不代表 OpenASR 对 whisper.cpp 的一般性结论，更不代表对开源推理运行时的一般性结论。

回归护栏，不是奖杯

把这条条目提交进仓库，目的不是炫耀，而是让 OpenASR 一旦退步就立刻报警。门禁配置（gate_vs_cpp = true）设定了 cpp_slack = 0.05：只有当 OpenASR 比 whisper.cpp 慢超过 5% 时才会触发失败。目前 OpenASR 领先，这意味着留有很大余量——门禁的作用是拦住未来的回归，不是宣告当下的胜利。

为什么 slack 是单边的

vs-cpp 门禁是一条地板线，不是一个目标分。OpenASR 领先时它什么都不做；只有某次改动把同模型 wall clock 推到落后 whisper.cpp 超过 slack 阈值时，它才让 suite 失败。护栏，不是记分牌。

可比性从何而来

可比性来自把其他变量全部按住。suite 里每个 family 都跑同一条固定输入：一段 6.13 秒的 LibriSpeech test-clean 音频（237-134500-0000.wav），对应一条 17 词的参考转录。第二个数字比看上去重要——17 个参考词意味着错一个词就是大约 5.88% 的 WER，所以这条音频上的 WER 是粗粒度跳变的，不要过度解读微小的 WER 差异。这条音频是一个可比性夹具，不是质量基准，OpenASR 不以它做任何公开的 WER 承诺。同一条音频也出现在我们讨论量化对口音质量影响的文章里。

为什么方法可信

基准测试的诚实程度取决于它跑的到底是不是真实代码路径。我们的 harness 驱动的是真正的生产调用路径——transcribe_with_backend → NativeBackend，和 transcribe --benchmark 走的同一条路——而不是一个为了跑分好看而精简过的重新实现。每条条目通过 --run-single-entry 在独立子进程中运行，这样进程级的 peak-RSS 高水位不会被上一条条目的分配污染。Wall clock 和 WER 在这个边界上是确定性的；隔离是为了让内存数据干净。

这些都不会把 7.9% 变成一句营销口号——这正是我们想要的。它是一台机器、一条音频上的一个实测数字，接在一道失败即关闭的门禁后面，一旦运行时把这个优势还回去就会立刻亮红灯。“比 whisper.cpp 快”说起来更顺口，但”在受控条件下，同模型 wall clock 领先 7.9%，提交为回归护栏”要站得住得多。