在离线场景下用 CPU 跑 Whisper 模型，推理速度过慢时，通常有三个可调方向：模型量化、线程数设置、解码参数（beam size 与 batch size）。这三者都不需要重新训练，但各自有副作用和适用边界。建议先确定瓶颈是否真的在矩阵计算，再按“量化 → 线程数 → beam size”的顺序逐个调整，并用同一段音频和固定计时来对比。
CPU 跑 Whisper 速度慢，不一定是算力不够。优先用 int8 量化（如 faster-whisper 的 compute_type='int8'）或 whisper.cpp 的 q5_0/q8_0 量化模型；线程数建议从物理核数的一半起调，不要盲目开满。beam_size 调成 1 效果往往比线程数更明显。这些改动都能用日志或计时验证，但需要自行评估量化后的准确率影响。
先判断瓶颈：是单线程慢还是多线程跑不满
调参之前先看 CPU 是否被充分利用。运行推理时，在另一个终端执行 top 或 htop，观察 CPU 占用情况和每个核的负载。如果只有一两个核心满载，说明模型执行阶段没有并行起来，可能是算子未支持多线程，也可能是音频数据被分割导致解码循环串行；这时候加线程数无效，需要换推理引擎或量化方式。如果所有核心都接近满载但耗时依然很长，说明计算已经并行化，但瓶颈可能落在内存带宽上。此时继续增加线程数会加剧竞争，反而可能拖慢速度。另外，如果内存使用接近上限并出现 swap，那么提速第一步是增加内存或减小模型体积，而不是调线程数。
量化：优先选 int8 量化的推理库
Whisper 原版 PyTorch 模型在 CPU 上默认使用 fp32，速度慢是常态。常见的提速方案是换用支持量化的推理后端，比如 faster-whisper（基于 CTranslate2）或 whisper.cpp。
faster-whisper 是 Python 库，直接通过参数加载 int8 模型。示例代码如下：
from faster_whisper import WhisperModel
model = WhisperModel('small', device='cpu', compute_type='int8', cpu_threads=4)
segments, info = model.transcribe('audio.wav', beam_size=1)
for segment in segments:
print(segment.text)其中 compute_type='int8' 会把权重和部分计算改成 8 位精度；cpu_threads 控制线程数。需要说明的是，int8 在 CPU 上是否一定比 fp32 快，和 CPU 支持的指令集有关，有些旧 CPU 可能收益有限，甚至因反量化开销变慢。所以第一次切换后一定要用同一段音频实测。
whisper.cpp 这类 C++ 实现则提供 ggml 格式的量化模型，常见有 q5_0、q8_0 等。启动命令类似：
./main -m models/ggml-base-q5_0.bin -f audio.wav -t 4-t 是线程数。量化模型需要手动转换或下载，具体转换流程以 whisper.cpp 仓库 README 为准。这种方式更适合命令行环境，也更容易嵌入服务。
线程数：不是越大越好，要从物理核心数往下试
线程数影响的是并行解码、特征提取等环节，但 Transformer 的解码过程本身有很强的序列依赖，单条音频能并行的地方有限。盲目设置成几百线程只会增加开销。建议先用 lscpu 查看物理核心数（Core(s) per socket × Socket(s)），然后从物理核心数的一半开始测试，例如 4 核 CPU 先设 2，再尝试 4，对比耗时。如果使用 faster-whisper，也可以在代码里设置环境变量：
import os
os.environ['OMP_NUM_THREADS'] = '4'在 whisper.cpp 中，-t 参数同理。如果模拟多线程测试时发现线程数增加但耗时几乎不变，说明瓶颈已经不在 CPU 计算，而是内存带宽或音频解码，此时继续调线程数没有意义。
另外，beam_size（束搜索大小）对速度影响很大。faster-whisper 默认 beam_size 是 5，改为 1 相当于贪心解码，能显著缩短延迟，但可能损失少量准确率。这也是一个可调参数，优先于线程数去试。
组合调优：步骤与验证清单
建议按固定流程做对比，避免每次调整只凭感觉。准备一段 3-5 分钟的音频，分别记录总耗时和转录内容。在代码中用 time.time() 计时：
import time
from faster_whisper import WhisperModel
model = WhisperModel('small', device='cpu', compute_type='int8', cpu_threads=4)
start = time.time()
segments, info = model.transcribe('test.wav', beam_size=1)
for segment in segments:
pass
print('elapsed:', time.time() - start)至少对比以下四组：
- fp32 + 默认线程数 + beam_size=5（作为基准）
- int8 + 相同线程数 + 相同 beam_size（看量化影响）
- int8 + 不同线程数（从 1、2、4 到物理核数）
- int8 + beam_size=1（看解码参数影响）
每组跑两次取较短时间，同时用 top 记录 CPU 使用率。如果量化后转录出现明显错字或漏字，需要权衡是否接受；如果只求关键词提取，通常可以接受。线程数最终选取耗时最短且 CPU 占用稳定的配置，而不是最大线程数。
最后提醒一点：如果模型本身很大（large），量化后仍然需要较多内存。在内存受限的机器上，优先选小尺寸模型（base 或 small），而不是单一依赖量化和线程数。