whisper.cpp 中文转写实测：五档模型怎么选

一句话结论：brew 装 whisper.cpp 1.9.5，直接上 1.5GB 的 large-v3-turbo，M4 上 182 秒音频 14.5 秒跑完，一小时录音约五分钟出 SRT 字幕，中文可以不作校对直接用。要更快就用 small，medium 这一档没有留的必要。

一条 brew 命令，但二进制全改名了

macOS 上装 whisper.cpp 现在只有一条命令，实测耗时 97 秒。Homebrew 从 bottle 装了五个包：whisper.cpp 1.9.5、ggml 0.29.0、llama.cpp 0.9.0、sdl3 3.4.20、sdl2-compat 2.32.74，合计约 46MB 磁盘，其中 whisper.cpp 本体只有 6.5MB。

brew install whisper-cpp

装完会多出七个命令。主程序叫 whisper-cli，另有 whisper-server 起 HTTP 接口、whisper-stream 接话筒做实时转写、whisper-bench 跑性能基准、whisper-quantize 做模型量化、whisper-vad-speech-segments 只切人声段，还有一个 ggml-metal-tuning 用来调 Metal 参数。2024 年以前的中文教程还在写 ./main 和 ./server，这两个名字现在已经不存在，照抄会直接 command not found。

brew 只装程序不带模型，这一步最容易卡住。默认模型路径是相对的 models/ggml-base.en.bin，在任意目录下不带 -m 直接跑，拿到的报错是：

error: model file not found 'models/ggml-base.en.bin'

退出码是 3。脚本里判 ne 0 能接住这个失败，但如果只 grep stdout 里有没有 error 字样，某些版本的帮助文本也会带这个词，容易误判。

五档模型：磁盘、内存、速度全测

模型在 HuggingFace 的 ggerganov/whisper.cpp 仓库里，走 hf-mirror 镜像下五个档位共 3.8GB，耗时 142 秒，单流速度在 21 到 29MB/s 之间波动。同一个镜像不同时段能差十倍，慢了先换时段再换工具，测法见hf-mirror 下载模型那篇。所有数字都是在 M4 16GB 统一内存上跑出来的，模型走 Metal 后端，参数为推荐配置也就是带简体 prompt 且保留时间戳。

峰值内存取 /usr/bin/time -l 里的 peak memory footprint 字段，单位是字节，除以 1073741824 才是 GB。关键片段命中是我从两段测试音频里挑出的十六个必现项，包括年份、百分比、采样率、时长与 mp4、srt 这类英文标识，逐段人工核对是否出现。

表里最反常的一行是 medium。它磁盘 1.4GB、内存 2180MB、182 秒音频要 22.68 秒，三项全输给参数更多的 large-v3-turbo。差别在结构，turbo 是 large-v3 的编码器配四层解码器，medium 是二十四层解码器。所以选型表里 medium 可以直接划掉，要么 small 要么 turbo。

tiny 和 base 的耗时接近，base 只慢一点，准确率也没强多少，两者都稳定把赫兹写成和资。想省资源的话从 base 换成 tiny 意义不大，省不下多少东西，错字一样多。

第一条命令就该带这三个参数

help 里 -l 的默认值是 en，中文音频不加语言标记会被当成英语硬解，输出一串音译。完整可用的写法是这样：

whisper-cli -m models/ggml-large-v3-turbo.bin \
  -f meeting.wav -l zh \
  --prompt "以下是普通话的句子，请使用简体中文转写。" \
  -osrt -otxt -np -of meeting

三个参数各管一件事。-l zh 指定语言，--prompt 决定输出字形是简体还是繁体，-osrt 和 -otxt 让它把结果落到 meeting.srt 与 meeting.txt，-np 压掉除结果外的所有打印，脚本里必加。

简繁这件事必须单独说。只给 -l zh 不加 prompt，tiny 和 base 输出全是繁体，第一句是今天講一個實際遇到的問題。加一句简体提示后同一条命令立刻变简体。这是 whisper 训练语料里中文字幕以繁体为主造成的，五档都会出繁体，跟模型的参数规模无关。

m4a 直接报错，采样率反而不用管

help 里写明支持的容器只有 flac、mp3、ogg、wav 四种。iPhone 语音备忘录的 m4a 喂进去是这样：

read_audio_data: failed to read audio data
error: failed to read audio file 'memo.m4a'

退出码是 11。这个数字要记住，很多批处理脚本只判退出码等于 1，11 会被当成成功继续往下跑，最后拿到一堆空文件还以为转写完成了。

反过来，采样率完全不用管。我把同一段话转成 44.1kHz 单声道 wav 直接喂进去，whisper-cli 内部会自动重采样，输出文本和 16kHz 版本逐字相同。老教程里那句必须先 -ar 16000 的说法在当前版本上不成立。立体声倒是真会出问题，16kHz 双声道下句子被切得更碎，pcm_s16le 被拆成 P、C、M、S、1、6、L 七段。所以只转声道就够：

ffmpeg -i memo.m4a -ac 1 -c:a pcm_s16le memo.wav

不加 -ar 16000 也能跑，加了省一点内存。素材本来是 mp3 就完全不用转，-f memo.mp3 直接支持。

踩坑一：加 -nt 会凭空多出一句

这是本轮最值钱的一条。-nt 的意思是关掉时间戳输出，很多人为了拿纯文本会顺手加上。同一段 30 秒音频、同一档 turbo、其他参数完全一致，加 -nt 连跑三次，三次结尾都多出这句：

请不吝点赞 订阅 转发 打赏支持明镜与点点栏目

去掉 -nt 保留时间戳，同样连跑三次，三次都是干净的五个分段，最后一段结束在 30.14 秒。换 medium 同样中招，编出来的是中文字幕志愿者 李宗盛。原始音频里没有这两句话的任何音素，它们是训练语料里视频字幕尾巴的残留。机制大概是关掉时间戳后模型失去了结束时间戳这个停止信号，会在静音段继续往下续写。

五种常规抑制手段我都试了，全部无效：-mc 0 清空上下文、-sns 抑制非语音 token、-nth 0.8 提高静音阈值、-nf 关掉温度回退、--vad 只解人声段。五项分别单独加上，那句点赞订阅照样在。网上那些调阈值的办法在当前版本上可以不用再试。

能用的判据只有一个，看 SRT 最后一条的结束时间有没有超过音频真实时长。tiny 档上我抓到一条 00:00:30.000 --> 00:00:32.000 的段落，而音频总长只有 30.47 秒。越界的那条一定是编的，批处理时按这个规则过滤就够：

import re, subprocess
dur = float(subprocess.check_output(['ffprobe', '-v', 'error', '-show_entries',
      'format=duration', '-of', 'csv=p=0', 'meeting.wav']))
cues = re.findall(r'(\d\d):(\d\d):(\d\d),(\d\d\d)', open('meeting.srt').read())
h, m, s, ms = map(int, cues[-1])
end = h * 3600 + m * 60 + s + ms / 1000
if end > dur + 0.5:
    print('last cue overruns audio, drop it')

再加一条兜底正则，把已知的语料尾巴按句清掉，关键词包括字幕、点赞、订阅、转发、打赏、明镜、栏目。这属于训练语料污染，跟你的录音质量没有关系，换个麦克风也治不好。

踩坑二：命令行参数串永远转不对

技术内容转写是 whisper 的死角。同一段话里的 ffmpeg 被识别成 ThemPad、thmpeg 或者 Fmpec，pcm_s16le 变成 R16000ACC RTC MS16L，wav 变 WARF。五档模型全错，turbo 也救不回来。

在 prompt 里塞术语能救一部分。我把 ffmpeg、pcm_s16le、mp4、srt 写进提示词后，turbo 输出里的 mp4、srt、62 分钟、11 秒全部正确，ffmpeg 仍然错，带下划线的参数仍然全错。结论是 prompt 对专有名词有效，对命令行参数无效。这个边界值得记住，否则会以为喂了词表就万事大吉。

数字会被自动归一化。中文说法二零二五年输成 2025 年，百分之三点八输成 3.8%。做字幕看不出问题，但拿转写稿去和原始脚本比字数时会发现两边数字写法完全不同，这不是错字，是模型的文本规范化行为。

需要精确的命令内容，办法是转写完按时间轴回听那一段人工补，或者提前把命令片段存成文本文件，转写稿只当定位索引用。指望 ASR 直接通过代码段落，现在任何模型都做不到，包括云端那些按分钟计费的。

长音频怎么跑，要不要起服务

182.8 秒的音频，turbo 用了 14.50 秒，实时率 12.6 倍。按这个倍数折算，一小时录音大约 4.8 分钟，十小时会议拆十段跑不到一小时。同一批文件换 medium 要 22.68 秒，慢了 56%，这也是 medium 不值得用的另一个证据。

要接到自己的程序里，用 whisper-server 起一个 HTTP 接口，模型只在启动时加载一次，之后每次请求省掉几十毫秒的加载开销：

whisper-server -m models/ggml-large-v3-turbo.bin --host 127.0.0.1 --port 18080 -l zh
curl -F [email protected] -F response_format=srt http://127.0.0.1:18080/inference

根路径 / 返回 200 和一个 HTML 页，可以当健康检查用。推理端点是 /inference，表单字段支持 file、response_format、language、prompt，实测传 prompt 能生效，输出立刻变简体。日志里会打印样本数、线程数与语言，排查问题时先看这一行。

默认线程是 4。M4 上加到 8 收益有限，瓶颈在 Metal 后端不在 CPU。真要提速，并行跑多个文件比加线程有效，但每个进程各占一份峰值内存，16GB 机器上最多同时跑三路 turbo，再加上别的常驻服务就会开始换页。

选型结论

要中文准确率就 large-v3-turbo，1.5GB 磁盘、1926MB 内存、12.6 倍实时率，是五档里唯一在关键片段上全命中八项的。要极致速度与低占用就 small，465MB 磁盘、851MB 内存、18 倍实时率，错字集中在专有名词，人扫一遍就能改。tiny 和 base 只适合做语言检测或草稿预览，正式出字幕不要用，它们的错字分布是整句级别的。

跑之前的资源账要提前算，峰值内存大致等于模型体积的一点三倍，跟音频长度基本无关，因为模型按 30 秒窗口切段处理。这套估法和本地大模型算显存是同一个思路，可以对照本地大模型显存计算那篇的公式一起看。转写稿要进知识库做语义检索，嵌入模型的配置方式与Cherry Studio 知识库配嵌入那篇是同一套。模型占盘的问题同理，长期跑建议直接把模型目录挪到大盘，思路与Ollama 模型搬目录那篇一致。

常见问题

brew 装完提示 model file not found 怎么办：brew 只装程序不带模型，必须单独下 ggml 开头的 bin 文件并用绝对路径喂给 -m。默认值 models/ggml-base.en.bin 是相对当前目录的，换个目录就失效。下载走 hf-mirror 最稳，链接在第二节。

一小时以上的会议录音能直接跑吗：能。turbo 折算约 4.8 分钟，内存占用与音频长度基本无关，因为按 30 秒窗口切段。超过两小时建议先用 ffmpeg 抽音轨再跑，避免解码器在 mp4 容器上多花时间。

为什么输出是繁体或者干脆是英文：繁体是训练语料造成的，加 --prompt 写一句要求简体中文即可。输出英文说明 -l 没传，默认值是 en。这两项都不是模型档位问题，换更大的模型没用。