报错是这么冒出来的。在 8GB 显存的 3070 上用 openai-whisper 调 large-v3 转写 95 分钟双人访谈，脚本没做切分直接喂整个 wav，跑到 40 分钟左右抛出 CUDA out of memory，torch 提示已分配 7.6GB。
中间走过弯路，把「decode 时 beam_size 默认 5，中间张量成倍增长」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。整段音频一次性转成 mel 特征，峰值显存超过 8GB。另一种情况是large-v3 的 fp16 权重本身就要 3GB 以上。
不容易想到的是，同一进程里还留着上一段音频的缓存没释放。
先按静音点切成 5 分钟以内的片段
ffmpeg -i talk.wav -af silencedetect=noise=-35dB:d=0.6 -f null - 2>&1 | Select-String silence_end随后用 whisper 命令行逐片转写并输出 srt
whisper part_%03d.wav --model large-v3 --language zh --output_format srt --fp16 True显存不够时换 int8 或改用 faster-whisper
pip install faster-whisper==1.0.3 && python -c "from faster_whisper import WhisperModel;m=WhisperModel('large-v3',device='cuda',compute_type='int8_float16');print('ok')"等前面都确认过，再把头尾时间戳按片段偏移量回填成一条时间轴
python shift_srt.py --dir srt_parts/ --offset part_map.json --out talk.srt恢复的判定其实很直接。所有片段都转写完成且无 OOM，拼接后的 srt 首尾时间与原始音频对齐，抽查 10 处语句起始误差在半秒内。
提醒一点。Whisper 的显存占用和音频时长近似线性，短音频也可能因为 beam 搜索吃满显存，切分比降精度更稳，代价只是多几次模型加载。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。