ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

whisper.cpp 模型怎么选:从 75MiB 到 1.5GiB 的完整决策路径 whisper.cpp 模型怎么选从 75MiB 到 1.5GiB 的完整决策路径【免费下载链接】whisper.cppPort of OpenAIs 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 秒决策表设备条件场景选哪个模型内存 ≤ 300MB树莓派 / MCU 网关实时指令、车载语音控制tiny.en磁盘 75MiB内存 1GB 左右、只识别英语会议记录、字幕生成small.en466MiB内存 1GB 左右、需要多语种客服质检、国际业务small466MiB8GB 服务器、无 GPU批量离线转录medium1.5GiBGPU 服务器、精度优先专业转录、多语言翻译large-v3 / large-v3-turbo1.5GiB一句话版本内存装不下就是最大的选型约束其次才是精度。轻量档tiny 系列——先让方案跑起来定位嵌入式设备和实时链路的安全垫磁盘 75MiB运行时内存约 273MB。参数tinytiny.en磁盘75 MiB75 MiB运行内存~273 MB~273 MB适用多语种兜底纯英语实时在树莓派上跑实测 256MB 的板子连 base约 388MB都装不下tiny 是 256-512MB 区间里唯一不爆内存的选项。指令识别、车载控制这类场景用户对识别错一个词的容忍度远高于对等 5 秒出结果的容忍度tiny.en 够用。# 下载 tiny.en75MiB 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 / 内存约 388MBsmall 磁盘 466MiB / 内存约 852MB。参数base / base.ensmall / small.en磁盘142 MiB466 MiB运行内存~388 MB~852 MB多语种base 支持base.en 不支持small 支持small.en 不支持. en 后缀是英语专用模型训练目标单一同档体积下识别质量更高代价是喂进去非英语音频基本等于白跑。别纠结了只处理英语就选 .en混语种就选不带后缀的版本。bench 工具在 ARM 平台上跑 small.en 的一次 encoder 全量耗时约 1062ms4 线程NEON BLAS对照 30 秒的输入音频这是接近实时的水平。small.en 是我做桌面离线字幕时的默认选择852MB 内存对任何现代工作站都不算事。# 拉取 small.en466MiB 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.1GBlarge-v3-turbo 磁盘 1.5GiB是 large-v3 的提速版。模型磁盘运行内存medium1.5 GiB~2.1 GBlarge2.9 GiB~3.9 GBlarge-v3-turbo1.5 GiB~3.9 GB 量级这一档没有 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 # 或本地量化 mediumq5_0 档 ./build/bin/quantize models/ggml-medium.bin models/ggml-medium-q5_0.bin q5_0平台配方构建→启动→验证各三步x86 服务器CUDA 编译与 HTTP 服务NVIDIA GPU 走 CUDAcuBLAS 自定义 kernel跨厂商显卡走 Vulkan。server 示例自带 HTTP 接口默认监听 127.0.0.1:8080。# 开启 CUDA 构建需先装好 cuda 工具链 cmake -B build -DGGML_CUDA1 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 filesamples/jfk.wavARM 设备NEON 加速与树莓派部署examples/stream/ 这类工具在 ARM 上自动走 NEON 指令集构建时不需要额外开关——看启动日志里NEON 1确认即可。树莓派上选 tiny 或 tiny.en4 线程起步。# 默认构建即可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 SiliconMetal 与 Core MLApple 系是 whisper.cpp 的一等公民默认走 MetalEncoder 还能交给 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_COREML1 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.en466MiB是多数中端手机的上限再大就得考虑量化或云端分流。# 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.1GBlarge-v3-turbo 要 3.9GB 量级。 修复可用内存 ≥ 模型运行内存 × 1.5否则降一档或上量化版。坑 3stream 实时链路输出断断续续原因--step和--length没配平。length 不是 step 的整数倍时滑动窗口会错位。 修复--step 3000 --length 10000这种整除组合或干脆用默认值。坑 4量化后报错或加载失败原因用原始模型的路径加载量化文件或量化档位名写错q5_0写成q5。 修复量化产物的文件名是原模型加-q5_0后缀参数必须写全名。坑 5Core ML / OpenVINO 首次运行慢得离谱原因不是模型慢是 ANE / OpenVINO 在把模型编译成设备专属格式结果会被缓存。 修复跑一次预热第二次开始才是真实速度线上环境把预热放进启动脚本。坑 6CPU 多核但速度反而上不去原因-t开满逻辑核数超线程互相抢 cache。 修复线程数给物理核数看启动日志的n_threads x / yx 是实际线程y 是硬件并发上限。上线前 10 问目标设备可用内存是否 ≥ 模型运行内存 × 1.5tiny 约 273MBsmall 约 852MBmedium 约 2.1GB磁盘剩余空间是否 ≥ 模型体积 × 2含量化产物和临时文件所有输入是否统一转成 16kHz / 16-bit / 单声道 WAV-t线程数是否对齐物理核心数而不是逻辑核数有 GPU 吗有的话 CUDA / Vulkan / Metal 有没有在构建参数里打开实时场景的 stream--step/--length是否整除端到端延迟实测是否达标只处理英语却选了非 .en 模型或多语种混入却选了 .en用 whisper-bench 在你自己的目标硬件上测过 encoder 耗时而不是抄别人的数据量化版是否在业务测试集上复核过错误率而不是只看体积省了多少并发数 × 每请求线程数是否已经超过总核数whisper.cpp 的选型说穿了就一句话先按内存定档再按语种定后缀最后用量化和 GPU 补余量。把上面 10 个问题在目标硬件上各答一遍剩下的就是调参。【免费下载链接】whisper.cppPort of OpenAIs Whisper model in C/C项目地址: https://gitcode.com/GitHub_Trending/wh/whisper.cpp创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表