whisper.cpp 模型怎么选：从 75MiB 到 1.5GiB 的完整决策路径

whisper.cpp 模型怎么选：从 75MiB 到 1.5GiB 的完整决策路径

【免费下载链接】whisper.cppPort of OpenAI's Whisper model in C/C++项目地址: https://gitcode.com/GitHub_Trending/wh/whisper.cpp

凌晨一点赶路演 demo，我让车机语音助手把一段录音转成字幕。OpenAI 的 Whisper 模型精度是够，但 Python 环境、GPU 依赖、外发音频——一条路全堵。换成 whisper.cpp 这个 C/C++ 本地部署版本，没有第三方依赖，一条 cmake 命令就起来。问题是：tiny 到 large-v3-turbo 五档模型，75MiB 到 1.5GiB，你的设备到底装得下哪一档？

干了三年推理部署，我按"设备能装多少"重新梳理了一遍选型逻辑。先给结论，再拆细节。

30 秒决策表

一句话版本：内存装不下就是最大的选型约束，其次才是精度。

轻量档：tiny 系列——先让方案跑起来

定位：嵌入式设备和实时链路的安全垫，磁盘 75MiB，运行时内存约 273MB。

在树莓派上跑，实测 256MB 的板子连 base（约 388MB）都装不下，tiny 是 256-512MB 区间里唯一不爆内存的选项。指令识别、车载控制这类场景，用户对"识别错一个词"的容忍度远高于对"等 5 秒出结果"的容忍度，tiny.en 够用。

# 下载 tiny.en（75MiB） sh ./models/download-ggml-model.sh tiny.en # 4 线程跑 16kHz WAV 转录 ./build/bin/whisper-cli -m models/ggml-tiny.en.bin -t 4 -f samples/jfk.wav

什么时候该升到下一档？当测试集上的识别错误率开始影响业务（比如专名、数字读错），或者你需要同时识别第二种语言，就升到 small 档。

中量档：base 与 small——桌面端的主力区间

定位：精度和体积的折中点。base 磁盘 142MiB / 内存约 388MB；small 磁盘 466MiB / 内存约 852MB。

. en 后缀是英语专用模型，训练目标单一，同档体积下识别质量更高；代价是喂进去非英语音频基本等于白跑。别纠结了：只处理英语就选 .en，混语种就选不带后缀的版本。

bench 工具在 ARM 平台上跑 small.en 的一次 encoder 全量耗时约 1062ms（4 线程，NEON + BLAS），对照 30 秒的输入音频，这是接近实时的水平。small.en 是我做桌面离线字幕时的默认选择：852MB 内存对任何现代工作站都不算事。

# 拉取 small.en（466MiB） sh ./models/download-ggml-model.sh small.en # 在目标硬件上实测 encoder 耗时，别信别人的 benchmark ./build/bin/whisper-bench -m models/ggml-small.en.bin -t 4

什么时候该再往上走？批量任务里 small 的错误率仍不达标，或需要德语、日语这类低频语种，上 medium / large-v3。代价是内存直接到 2.1GB 起步。

重量档：medium 与 large-v3-turbo——GPU 服务器的游戏

定位：精度天花板。medium 磁盘 1.5GiB / 内存约 2.1GB；large-v3-turbo 磁盘 1.5GiB，是 large-v3 的提速版。

这一档没有 GPU 就不要碰：CPU 上 medium 的 encoder 耗时轻松超过音频时长本身，"离线批处理"会变成"离线等一周"。large-v3-turbo 是这批模型里唯一值得为体积妥协的选项——它把 large-v3 的解码器砍到 1 层，磁盘直接从 2.9GiB 压到 1.5GiB，精度损失在多数业务测试集里换不到统计显著的错误率上涨。

这一档的标准动作是量化：whisper.cpp 支持整数量化，medium 和 large-v3-turbo 都有现成的 q5_0 版本可直接下载，体积再省 30-40%，推理还能更快。

# 直接下量化版，省去本地转换 sh ./models/download-ggml-model.sh large-v3-turbo-q5_0 # 或本地量化 medium（q5_0 档） ./build/bin/quantize models/ggml-medium.bin models/ggml-medium-q5_0.bin q5_0

平台配方：构建→启动→验证，各三步

x86 服务器：CUDA 编译与 HTTP 服务

NVIDIA GPU 走 CUDA（cuBLAS + 自定义 kernel），跨厂商显卡走 Vulkan。server 示例自带 HTTP 接口，默认监听 127.0.0.1:8080。

# 开启 CUDA 构建（需先装好 cuda 工具链） cmake -B build -DGGML_CUDA=1 cmake --build build -j --config Release # 启动 HTTP 转录服务，8 线程 ./build/bin/server -m models/ggml-large-v3-turbo-q5_0.bin -t 8 --port 8080 # 验证：POST 一段音频 curl 127.0.0.1:8080/inference -F file=@samples/jfk.wav

ARM 设备：NEON 加速与树莓派部署

examples/stream/ 这类工具在 ARM 上自动走 NEON 指令集，构建时不需要额外开关——看启动日志里NEON = 1确认即可。树莓派上选 tiny 或 tiny.en，4 线程起步。

# 默认构建即可，NEON 自动启用 cmake -B build && cmake --build build -j --config Release # 实时流式：每 3 秒一个 step，窗口 10 秒 ./build/bin/stream -m models/ggml-tiny.en.bin -t 4 --step 3000 --length 10000 # 验证：日志出现 NEON = 1，且每秒都有增量输出

Apple Silicon：Metal 与 Core ML

Apple 系是 whisper.cpp 的一等公民：默认走 Metal，Encoder 还能交给 ANE（通过 Core ML），官方数据比纯 CPU 快 3 倍以上。Core ML 模型要先离线生成，首次运行会慢（ANE 在编译模型缓存），第二次起才快。

# 生成 base.en 的 Core ML encoder 模型 ./models/generate-coreml-model.sh base.en # 带 Core ML 构建 cmake -B build -DWHISPER_COREML=1 cmake --build build -j --config Release # 验证：日志出现 Core ML model loaded ./build/bin/whisper-cli -m models/ggml-base.en.bin -f samples/jfk.wav

移动端：Android 与 iOS 集成

仓库里 examples/whisper.android/（Kotlin）和 examples/whisper.objc/（iOS 原生）是现成工程，README 里演示了 iPhone 13 全离线转写的完整效果。移动端原则不变：包里能塞下多少模型就选哪档，small.en（466MiB）是多数中端手机的上限，再大就得考虑量化或云端分流。

# Android 工程用 Gradle 构建（Kotlin 示例工程） cd examples/whisper.android && ./gradlew assembleDebug # iOS 工程直接打开 Xcode 项目 open examples/whisper.objc/whisper.objc.xcodeproj # 验证：设备日志确认模型 size 与内存占用在预期内

高频坑与解法：我踩过的这几个

坑 1：报failed to load wav或识别全是乱码原因：whisper-cli 只吃 16-bit WAV，你喂了 mp3 或 44.1kHz 立体声。 修复：先用 ffmpeg 转格式——ffmpeg -i input.mp3 -ar 16000 -ac 1 -c:a pcm_s16le output.wav。

坑 2：设备直接 OOM 被系统杀掉原因：把"磁盘 1.5GiB"当成了内存需求。medium 磁盘 1.5GiB，实际运行内存约 2.1GB，large-v3-turbo 要 3.9GB 量级。 修复：可用内存 ≥ 模型运行内存 × 1.5，否则降一档或上量化版。

坑 3：stream 实时链路输出断断续续原因：--step和--length没配平。length 不是 step 的整数倍时，滑动窗口会错位。 修复：--step 3000 --length 10000这种整除组合，或干脆用默认值。

坑 4：量化后报错或加载失败原因：用原始模型的路径加载量化文件，或量化档位名写错（q5_0写成q5）。 修复：量化产物的文件名是原模型加-q5_0后缀，参数必须写全名。

坑 5：Core ML / OpenVINO 首次运行慢得离谱原因：不是模型慢，是 ANE / OpenVINO 在把模型编译成设备专属格式，结果会被缓存。 修复：跑一次预热，第二次开始才是真实速度；线上环境把预热放进启动脚本。

坑 6：CPU 多核但速度反而上不去原因：-t开满逻辑核数，超线程互相抢 cache。 修复：线程数给物理核数，看启动日志的n_threads = x / y，x 是实际线程，y 是硬件并发上限。

上线前 10 问

1. 目标设备可用内存是否 ≥ 模型运行内存 × 1.5（tiny 约 273MB，small 约 852MB，medium 约 2.1GB）？
2. 磁盘剩余空间是否 ≥ 模型体积 × 2（含量化产物和临时文件）？
3. 所有输入是否统一转成 16kHz / 16-bit / 单声道 WAV？
4. -t线程数是否对齐物理核心数，而不是逻辑核数？
5. 有 GPU 吗？有的话 CUDA / Vulkan / Metal 有没有在构建参数里打开？
6. 实时场景的 stream--step/--length是否整除，端到端延迟实测是否达标？
7. 只处理英语却选了非 .en 模型（或多语种混入却选了 .en）？
8. 用 whisper-bench 在你自己的目标硬件上测过 encoder 耗时，而不是抄别人的数据？
9. 量化版是否在业务测试集上复核过错误率，而不是只看体积省了多少？
10. 并发数 × 每请求线程数，是否已经超过总核数？

whisper.cpp 的选型说穿了就一句话：先按内存定档，再按语种定后缀，最后用量化和 GPU 补余量。把上面 10 个问题在目标硬件上各答一遍，剩下的就是调参。

【免费下载链接】whisper.cppPort of OpenAI's Whisper model in C/C++项目地址: https://gitcode.com/GitHub_Trending/wh/whisper.cpp