做语音翻译这件事我踩过的坑比想象中多。最开始拿到一段中文演讲的录音需求是把它翻译成英文文案我第一反应是走老路先做语音识别再把文本丢给机器翻译。后来看到文档里多了“translate”这个选项试着跑了一轮才发现一步到位反而更干净。这一节是《Whisper语音识别实战专栏》的3.2章主题就是语音翻译实战重点解决两个问题怎么让 Whisper 把任意语言语音翻译成英文文本以及这个过程中怎么避免模型“发挥过头”。这篇文章不会只贴一段示例代码就收工我会把任务差异、模型选型、核心参数、批量脚本、长音频处理和避坑经验都串起来。不管你是做字幕、会议转写还是给课程视频生成双语文本基本都能从里面找到可以直接复用的方案。1. 语音识别与语音翻译先搞懂你要做的事情1.1 Whisper 的两种任务模式Whisper 的接口里有两个常见的关键词transcribe和translate。直译过来就是“识别”和“翻译”。transcribe是把你说的内容转成文本语言保持不变translate则是一边识别一边把内容翻译成英文。很多初学者会在加载模型之后直接调用transcribe拿到的是原语言文本于是奇怪为什么“翻译”没生效。原因很简单就是没加tasktranslate。这里有个值得理解的底层逻辑。Whisper 在训练时设置了多任务学习同一个模型除了预测语言标签、时间戳还会根据任务标记决定输出模式。它并不是“先识别再翻译”的串联流程而是在解码阶段直接生成目标语言的文本。这种端到端的方式比“ASR 转写后送进翻译引擎”少了一步误差传递。打个比方传统流程像录音笔加翻译软件中间任何一次出错都会被放大Whisper 的模式更像一个同时做听译的人虽然偶尔也会走神但整体上下文连贯性明显更好。1.2 什么场景选翻译什么场景选识别接需求的时候第一件事就是确认目标语言这是最容易搞错的地方。如果用户说“把这段英文访谈转成文本”那就是transcribe如果用户说“把这段中文讲座变成英文字幕”那是translate。不过translate有一个硬性限制目前 Whisper 的翻译目标语言固定是英文不能直接指定中文、日文或者其他语言。假如需要把英文语音翻译成中文你还得先transcribe出英文文本再做后续的文本翻译。这一点务必在项目排期前确认清楚。我用一个决策表来总结方便你直接对照输入语音期望输出用哪个任务中文中文字幕transcribe指定languagezh中文英文字幕/英文摘要translate英文英文文本transcribe英文中文文本先 transcribe 英文再做文本翻译多语言混说英文翻译translate自动检测语言在实际项目里跨语言字幕、会议纪要英文版、网站视频的英文脚本都是translate的主场而母语字幕、内容检索、话术质检通常用transcribe。建议你在一开始就把这种决策写进需求文档避免后期返工。2. 环境准备与模型选型别让起步就走弯路2.1 依赖安装和基础验证我默认你用的是 Python 3.9 以上的环境提前建好虚拟环境。先装 Whisperpip install -U whisper这里有一个容易踩的坑Whisper 依赖一个深度学习运行时和 FFmpeg 工具。如果直接pip install深度学习框架会自动拉一个默认版本但不一定能充分利用你的 GPU。更关键的是 FFmpeg它需要在系统环境变量里能找到否则运行时会报出类似FileNotFoundError: ffmpeg的错误。macOS 上可以用系统包管理器安装Linux 上可以用apt或源码编译Windows 上建议直接下载对应版本并配置 PATH。我第一次在 Windows 上跑的时候就是忘了装 FFmpeg卡了整整一个下午。装完之后可以用下面这段代码验证环境是否正常import whisper model whisper.load_model(tiny) result model.transcribe(test.mp3, tasktranslate) print(result[text])如果能把test.mp3里的语音翻译成英文并打印出来环境就没问题。第一次加载模型会下载权重文件网络正常的情况下都是自动完成。建议先把这一步跑通再往下读否则后面代码再漂亮也没用。2.2 模型规格怎么选质量、速度、显存三者的平衡Whisper 提供了多个尺寸的模型很多项目纠结选哪个。我直接给一张按经验整理的对照表方便做技术选型模型参数规模相对速度翻译质量建议显存fp16tiny约39M最快能听清但翻译生硬约1GBbase约74M很快短句尚可复杂句子容易漏约1.5GBsmall约244M适中日常会话可用专业内容一般约3GBmedium约769M较慢明显改善长句和术语仍会翻错约7GBlarge约1550M最慢综合质量最好约12GB以上上面的显存是我自己跑下来的粗略参考实际会随音频长度和 batch 策略浮动。如果是做翻译任务我建议至少从small起步因为tiny和base的识别能力有限遇到中文、日语这种与英文差异较大的语言时翻译结果会出现很多断层。如果你有 GPU 且显存足够直接用large做最终交付质量天花板确实更高。选型不能只看精度。实时性要求高的场景比如内部试听、快速筛选可以用small离线精修、最终导出用large或medium。千万别一上来就large CPU 组合那样一个五分钟的音频可能要等到失去耐心。关于 CPU 环境社区里有很多优化思路比如用量化后的推理或第三方 C 实现可以搜“Whisper CPU 加速”这类关键词方向是降精度换速度。3. 语音翻译实战从单文件到批量脚本3.1 最小可用的翻译代码直接上代码带注释版import whisper import time def translate_audio(audio_path: str, model_size: str small): # 加载模型这里可以改为 medium、large 等 model whisper.load_model(model_size) # tasktranslate 是核心把语音直接翻译成英文 # language 参数可以指定源语言例如 zh、ja、fr # 建议在明确源语言时手动指定避免自动检测出错 result model.transcribe( audio_path, tasktranslate, languagezh, # 中文源语言 beam_size5, fp16False, # CPU 环境用 False独立显卡可设为 True ) return result if __name__ __main__: start time.time() res translate_audio(meeting.wav, model_sizemedium) print(翻译文本, res[text]) print(检测语言, res[language]) print(耗时%.2f 秒 % (time.time() - start))这段代码做的事情很直接加载模型读取音频文件输出英文翻译。返回值里的text是最终文本language是模型检测到的源语言。值得说明的是我在代码里写了languagezh这是为了在中文场景下减少检测偏差。如果你处理的是多语言混合内容可以去掉language参数让模型自动判断。3.2 影响翻译质量的参数逐个拆解Whisper 的transcribe函数参数很多但绝大多数项目只需要关注其中几个参数作用我的建议tasktranscribe / translate翻译场景固定为 translatelanguage指定源语言能指定就不要省略能减少幻觉fp16是否用半精度浮点GPU 可开 TrueCPU 必须 Falsebeam_size束搜索宽度质量要求高设 5想提速设 1temperature解码温度默认 0若结果重复可升到 0.2initial_prompt初始提示文本用来约束风格和技术术语condition_on_previous_text是否依赖前文长文本重复时置 Falseverbose是否打印过程调试时 True批处理时 False每个参数背后都有对应逻辑。比如temperature控制解码时的随机性设为 0 就是贪心解码输出稳定但容易陷入重复beam_size控制束搜索的候选路径数越大越能找到全局更优的译文但速度也呈线性下降。initial_prompt是很多人容易忽略的宝藏它会作为解码输入的一部分提前告诉模型“这是一段医学讲座”从而让译文风格靠拢。我在术语密集的场景里一般会在initial_prompt里直接列出几个关键术语的译法效果立竿见影。3.3 批量处理多个音频文件项目里很少只有一个音频要翻译。下面这个脚本会把当前目录下所有音视频文件依次翻译并保存成同名 txt 文件import whisper import glob import os model whisper.load_model(medium) file_types [*.mp3, *.wav, *.m4a, *.flac, *.mp4] audio_files [] for ft in file_types: audio_files.extend(glob.glob(ft)) for audio in audio_files: try: print(f正在翻译: {audio}) result model.transcribe(audio, tasktranslate, languagezh, fp16False) out_txt os.path.splitext(audio)[0] .txt with open(out_txt, w, encodingutf-8) as f: f.write(result[text].strip()) print(f完成: {out_txt}) except Exception as e: print(f失败: {audio}原因: {e})注意批处理时要做好异常隔离别因为某个文件损坏导致整个任务中断。我习惯在完整跑批前先试跑两个文件观察模型质量和耗时再全量执行。如果文件很多还可以用多进程并行处理后面我会再提。4. 真实场景里的细节长音频、格式与噪音4.1 长音频翻译的内存与耗时可接受吗很多第一次跑 Whisper 的人以为它会一次性把整个音频塞进模型。实际上 Whisper 内部有分段逻辑通常会把音频切成 30 秒左右的小窗口逐步解码并产生时间戳。但要注意模型仍然会把原始音频整个读入内存而且长音频在解码过程中会累积上下文计算开销不可忽视。如果你的音频超过半小时我建议先做一次预处理切分。用 FFmpeg 按时间切割成 10 分钟一段ffmpeg -i input.mp3 -f segment -segment_time 600 -c copy part_%03d.mp3切割之后逐段翻译再把结果拼起来。这样做的好处是单段出错可以单独重跑不用整个文件推倒重来。切割的代价是上下文断裂翻译到段落衔接处可能不连贯所以拼接后最好人工校对一遍。还有一个更稳妥的办法用支持语音活动检测VAD的实现自动跳过静音段不过那超出了当前 Whisper 基础调用的范围这里就不展开细节。4.2 音频格式与采样率先转成 16kHz 单声道 WAVWhisper 内部依赖 FFmpeg 读音频几乎所有常见格式都能吃进去并在加载时自动重采样到 16kHz。那我为什么还建议提前转一次格式因为实际处理时有些视频文件里的音频轨道编码异常直接喂给 Whisper 会产生奇怪的错误而先用 FFmpeg 统一转换成标准格式能大幅减少这种偶发问题。推荐用这条命令把各种输入统一为标准 WAVffmpeg -i input.m4a -ar 16000 -ac 1 -c:a pcm_s16le output.wav-ar 16000表示采样率 16kHz-ac 1表示单声道-c:a pcm_s16le指无压缩 PCM 编码。这个格式是 Whisper 处理得最轻松的形式加载速度也更快。至于噪音Whisper 对背景噪声的鲁棒性比我预想的好但如果是嘈杂会议、现场录音建议先做轻量降噪。别过度处理否则连人声都会失真。我一般只做简单的高通滤波去掉低频嗡嗡声复杂的降噪反而会影响翻译准确率。5. 高频问题与排查技巧实录5.1 翻译结果出现大段重复或“幻觉”文本这是 Whisper 项目里最常见的抱怨之一。表现是明明音频只有几秒静音模型却一本正经地输出了很长一段英文或者同样的句子翻来覆去出现。原因主要有三个语言自动检测失败。比如中文音频被识别成了某种相近语言之后生成了一堆无意义文本。解码时温度过高导致随机性放大。长音频中condition_on_previous_text为 True模型过于依赖前文开始重复上一段的模式。排查时先把源语言显式指定。中文就写languagezh英文写languageen可以解决相当一部分问题。如果还是重复把temperature设置成 0.2并把condition_on_previous_text设为 Falseresult model.transcribe( audio_path, tasktranslate, languagezh, temperature0.2, condition_on_previous_textFalse, )此外Whisper 的返回结果里有no_speech_prob字段表示模型认为这段没有语音的概率。如果这个值很高说明音频可能是空白或噪声这时候不翻译也罢。5.2 速度太慢怎么优化先说结论最有效的优化是用支持 FP16 的 GPU 推理。哪怕是入门级显卡也比 CPU 快很多。如果你只能用 CPU请把模型降到small并关闭fp16。这里有个容易误解的点很多人以为fp16是“降低精度”所以不敢开。实际上在深度学习里半精度推理对 Whisper 这类模型影响很小换来的速度提升非常显著。如果你的 CPU 指令集比较老旧某些第三方加速实现可能无法运行原生版本则没有这个问题。另外批处理时可以考虑多进程并行。每个进程加载一个模型实例处理不同文件from multiprocessing import Pool def process_one(audio): import whisper model whisper.load_model(small) result model.transcribe(audio, tasktranslate) return audio, result[text] if __name__ __main__: files [a.mp3, b.mp3, c.mp3] with Pool(processes2) as pool: for audio, text in pool.map(process_one, files): print(audio, text)注意每个子进程加载模型都会消耗内存进程数不是越多越好一般建议按 CPU 核心数和内存余量设置。如果机器有 8 核开 4 个进程往往比开 8 个更稳。5.3 专业术语翻译得不准怎么办Whisper 训练数据以通用领域为主遇到专业术语容易翻成表面意思。好消息是我们可以通过initial_prompt干预。比如处理人工智能课程时可以在提示里补充术语表initial_prompt 以下是关于人工智能的课程讲解。请严格使用标准术语整数规划integer programming支持向量机SVM反向传播backpropagation。翻译要专业、简洁。 result model.transcribe( audio_path, tasktranslate, languagezh, initial_promptinitial_prompt, )效果不会百分百保证但大多数情况下术语命中率会明显提升。如果某些公司名、产品名需要固定译法也可以写进initial_prompt。这个方法比事后正则替换要自然得多因为模型在生成阶段就会参考这些约束。需要注意的是initial_prompt不要写太长通常几十到一两百个词足够超过反而可能干扰解码。6. 翻译质量验证与工作流扩展6.1 用同一段音频做模型对比与其听我推荐不如自己跑一次对比。我拿了一段大约 10 秒的中文技术演讲做试验把几种模型的翻译结果贴出来这里内容是虚构的只用于对比效果模型翻译输出节选评价tinyWe need to talk about the model...结构残缺信息丢失严重smallWe need to discuss this model and how to improve it...基本通顺但细节不够mediumWe need to discuss this large language model and how to improve its performance...信息还原度高largeNow we need to discuss how to optimize this large language model in real-world scenarios...能结合语境补全这里我想强调的是翻译质量并不只看句式通不通顺还要看信息是否忠实。在语音翻译任务里误译比漏译更危险。如果需求是做对外宣传片的英文字幕宁可让译文简洁一些也不要让模型自由发挥。这时候可以用较低温度、不开initial_prompt并做人工校对。6.2 从翻译文本到字幕和时间轴结合Whisper 的transcribe返回结果里包含 segment 级别的时间戳可以用来生成字幕。思路是遍历result[segments]取出每个片段开始时间、结束时间和翻译文本生成 SRT 格式。下面是一个简单的导出函数def export_srt(segments, out_path): def fmt(ts): ts int(ts * 1000) ms ts % 1000 s (ts // 1000) % 60 m (ts // 60000) % 60 h ts // 3600000 return f{h:02d}:{m:02d}:{s:02d},{ms:03d} with open(out_path, w, encodingutf-8) as f: for i, seg in enumerate(segments, 1): f.write(f{i}\n) f.write(f{fmt(seg[start])} -- {fmt(seg[end])}\n) f.write(seg[text].strip() \n\n) # 调用 segments result[segments] export_srt(segments, output.srt)如果你想做中英双语字幕可以把transcribe结果和translate结果按时间轴对齐后分别导出。实际项目中我通常先翻译一次得到英文字幕再在字幕编辑工具里叠加中文字幕。自动生成的时间轴已经可以直接用少量错位手工调一下即可。这种工作流适合课程视频、企业培训素材和访谈节目。6.3 后续还能怎么扩展如果你已经把这套流程跑通后面可以做的事情还有很多。比如把翻译结果直接喂给文本摘要模型生成会议纪要的英文摘要或者接入说话人分离技术让字幕带上不同发言人标签再或者做术语库管理把initial_prompt做成一个可配置的模板不同项目加载不同术语表。我自己在项目里就是把这些能力组合成了一个内部工具输入一段录音输出中英文字幕、关键词和摘要效率比之前纯人工处理提升了不少。我个人实际跑下来的最大感触是Whisper 的translate任务真正有价值的不是“它能翻译”这句话而是你能不能控制它稳定输出。语言指定、模型选型、温度控制这三件事做扎实结果基本就可以了。还有一个容易被忽略的小技巧拿到一段完全不熟的音频先不要急着调大模型用small快速跑一遍看看语言检测和段落结构再决定是否换large。这个习惯帮我省了不少时间。如果你正在做跨语言内容生产线不妨把这一整套流程先跑通再根据反馈慢慢调优。
做语音翻译这件事我踩过的坑比想象中多。最开始拿到一段中文演讲的录音需求是把它翻译成英文文案我第一反应是走老路先做语音识别再把文本丢给机器翻译。后来看到文档里多了“translate”这个选项试着跑了一轮才发现一步到位反而更干净。这一节是《Whisper语音识别实战专栏》的3.2章主题就是语音翻译实战重点解决两个问题怎么让 Whisper 把任意语言语音翻译成英文文本以及这个过程中怎么避免模型“发挥过头”。这篇文章不会只贴一段示例代码就收工我会把任务差异、模型选型、核心参数、批量脚本、长音频处理和避坑经验都串起来。不管你是做字幕、会议转写还是给课程视频生成双语文本基本都能从里面找到可以直接复用的方案。1. 语音识别与语音翻译先搞懂你要做的事情1.1 Whisper 的两种任务模式Whisper 的接口里有两个常见的关键词transcribe和translate。直译过来就是“识别”和“翻译”。transcribe是把你说的内容转成文本语言保持不变translate则是一边识别一边把内容翻译成英文。很多初学者会在加载模型之后直接调用transcribe拿到的是原语言文本于是奇怪为什么“翻译”没生效。原因很简单就是没加tasktranslate。这里有个值得理解的底层逻辑。Whisper 在训练时设置了多任务学习同一个模型除了预测语言标签、时间戳还会根据任务标记决定输出模式。它并不是“先识别再翻译”的串联流程而是在解码阶段直接生成目标语言的文本。这种端到端的方式比“ASR 转写后送进翻译引擎”少了一步误差传递。打个比方传统流程像录音笔加翻译软件中间任何一次出错都会被放大Whisper 的模式更像一个同时做听译的人虽然偶尔也会走神但整体上下文连贯性明显更好。1.2 什么场景选翻译什么场景选识别接需求的时候第一件事就是确认目标语言这是最容易搞错的地方。如果用户说“把这段英文访谈转成文本”那就是transcribe如果用户说“把这段中文讲座变成英文字幕”那是translate。不过translate有一个硬性限制目前 Whisper 的翻译目标语言固定是英文不能直接指定中文、日文或者其他语言。假如需要把英文语音翻译成中文你还得先transcribe出英文文本再做后续的文本翻译。这一点务必在项目排期前确认清楚。我用一个决策表来总结方便你直接对照输入语音期望输出用哪个任务中文中文字幕transcribe指定languagezh中文英文字幕/英文摘要translate英文英文文本transcribe英文中文文本先 transcribe 英文再做文本翻译多语言混说英文翻译translate自动检测语言在实际项目里跨语言字幕、会议纪要英文版、网站视频的英文脚本都是translate的主场而母语字幕、内容检索、话术质检通常用transcribe。建议你在一开始就把这种决策写进需求文档避免后期返工。2. 环境准备与模型选型别让起步就走弯路2.1 依赖安装和基础验证我默认你用的是 Python 3.9 以上的环境提前建好虚拟环境。先装 Whisperpip install -U whisper这里有一个容易踩的坑Whisper 依赖一个深度学习运行时和 FFmpeg 工具。如果直接pip install深度学习框架会自动拉一个默认版本但不一定能充分利用你的 GPU。更关键的是 FFmpeg它需要在系统环境变量里能找到否则运行时会报出类似FileNotFoundError: ffmpeg的错误。macOS 上可以用系统包管理器安装Linux 上可以用apt或源码编译Windows 上建议直接下载对应版本并配置 PATH。我第一次在 Windows 上跑的时候就是忘了装 FFmpeg卡了整整一个下午。装完之后可以用下面这段代码验证环境是否正常import whisper model whisper.load_model(tiny) result model.transcribe(test.mp3, tasktranslate) print(result[text])如果能把test.mp3里的语音翻译成英文并打印出来环境就没问题。第一次加载模型会下载权重文件网络正常的情况下都是自动完成。建议先把这一步跑通再往下读否则后面代码再漂亮也没用。2.2 模型规格怎么选质量、速度、显存三者的平衡Whisper 提供了多个尺寸的模型很多项目纠结选哪个。我直接给一张按经验整理的对照表方便做技术选型模型参数规模相对速度翻译质量建议显存fp16tiny约39M最快能听清但翻译生硬约1GBbase约74M很快短句尚可复杂句子容易漏约1.5GBsmall约244M适中日常会话可用专业内容一般约3GBmedium约769M较慢明显改善长句和术语仍会翻错约7GBlarge约1550M最慢综合质量最好约12GB以上上面的显存是我自己跑下来的粗略参考实际会随音频长度和 batch 策略浮动。如果是做翻译任务我建议至少从small起步因为tiny和base的识别能力有限遇到中文、日语这种与英文差异较大的语言时翻译结果会出现很多断层。如果你有 GPU 且显存足够直接用large做最终交付质量天花板确实更高。选型不能只看精度。实时性要求高的场景比如内部试听、快速筛选可以用small离线精修、最终导出用large或medium。千万别一上来就large CPU 组合那样一个五分钟的音频可能要等到失去耐心。关于 CPU 环境社区里有很多优化思路比如用量化后的推理或第三方 C 实现可以搜“Whisper CPU 加速”这类关键词方向是降精度换速度。3. 语音翻译实战从单文件到批量脚本3.1 最小可用的翻译代码直接上代码带注释版import whisper import time def translate_audio(audio_path: str, model_size: str small): # 加载模型这里可以改为 medium、large 等 model whisper.load_model(model_size) # tasktranslate 是核心把语音直接翻译成英文 # language 参数可以指定源语言例如 zh、ja、fr # 建议在明确源语言时手动指定避免自动检测出错 result model.transcribe( audio_path, tasktranslate, languagezh, # 中文源语言 beam_size5, fp16False, # CPU 环境用 False独立显卡可设为 True ) return result if __name__ __main__: start time.time() res translate_audio(meeting.wav, model_sizemedium) print(翻译文本, res[text]) print(检测语言, res[language]) print(耗时%.2f 秒 % (time.time() - start))这段代码做的事情很直接加载模型读取音频文件输出英文翻译。返回值里的text是最终文本language是模型检测到的源语言。值得说明的是我在代码里写了languagezh这是为了在中文场景下减少检测偏差。如果你处理的是多语言混合内容可以去掉language参数让模型自动判断。3.2 影响翻译质量的参数逐个拆解Whisper 的transcribe函数参数很多但绝大多数项目只需要关注其中几个参数作用我的建议tasktranscribe / translate翻译场景固定为 translatelanguage指定源语言能指定就不要省略能减少幻觉fp16是否用半精度浮点GPU 可开 TrueCPU 必须 Falsebeam_size束搜索宽度质量要求高设 5想提速设 1temperature解码温度默认 0若结果重复可升到 0.2initial_prompt初始提示文本用来约束风格和技术术语condition_on_previous_text是否依赖前文长文本重复时置 Falseverbose是否打印过程调试时 True批处理时 False每个参数背后都有对应逻辑。比如temperature控制解码时的随机性设为 0 就是贪心解码输出稳定但容易陷入重复beam_size控制束搜索的候选路径数越大越能找到全局更优的译文但速度也呈线性下降。initial_prompt是很多人容易忽略的宝藏它会作为解码输入的一部分提前告诉模型“这是一段医学讲座”从而让译文风格靠拢。我在术语密集的场景里一般会在initial_prompt里直接列出几个关键术语的译法效果立竿见影。3.3 批量处理多个音频文件项目里很少只有一个音频要翻译。下面这个脚本会把当前目录下所有音视频文件依次翻译并保存成同名 txt 文件import whisper import glob import os model whisper.load_model(medium) file_types [*.mp3, *.wav, *.m4a, *.flac, *.mp4] audio_files [] for ft in file_types: audio_files.extend(glob.glob(ft)) for audio in audio_files: try: print(f正在翻译: {audio}) result model.transcribe(audio, tasktranslate, languagezh, fp16False) out_txt os.path.splitext(audio)[0] .txt with open(out_txt, w, encodingutf-8) as f: f.write(result[text].strip()) print(f完成: {out_txt}) except Exception as e: print(f失败: {audio}原因: {e})注意批处理时要做好异常隔离别因为某个文件损坏导致整个任务中断。我习惯在完整跑批前先试跑两个文件观察模型质量和耗时再全量执行。如果文件很多还可以用多进程并行处理后面我会再提。4. 真实场景里的细节长音频、格式与噪音4.1 长音频翻译的内存与耗时可接受吗很多第一次跑 Whisper 的人以为它会一次性把整个音频塞进模型。实际上 Whisper 内部有分段逻辑通常会把音频切成 30 秒左右的小窗口逐步解码并产生时间戳。但要注意模型仍然会把原始音频整个读入内存而且长音频在解码过程中会累积上下文计算开销不可忽视。如果你的音频超过半小时我建议先做一次预处理切分。用 FFmpeg 按时间切割成 10 分钟一段ffmpeg -i input.mp3 -f segment -segment_time 600 -c copy part_%03d.mp3切割之后逐段翻译再把结果拼起来。这样做的好处是单段出错可以单独重跑不用整个文件推倒重来。切割的代价是上下文断裂翻译到段落衔接处可能不连贯所以拼接后最好人工校对一遍。还有一个更稳妥的办法用支持语音活动检测VAD的实现自动跳过静音段不过那超出了当前 Whisper 基础调用的范围这里就不展开细节。4.2 音频格式与采样率先转成 16kHz 单声道 WAVWhisper 内部依赖 FFmpeg 读音频几乎所有常见格式都能吃进去并在加载时自动重采样到 16kHz。那我为什么还建议提前转一次格式因为实际处理时有些视频文件里的音频轨道编码异常直接喂给 Whisper 会产生奇怪的错误而先用 FFmpeg 统一转换成标准格式能大幅减少这种偶发问题。推荐用这条命令把各种输入统一为标准 WAVffmpeg -i input.m4a -ar 16000 -ac 1 -c:a pcm_s16le output.wav-ar 16000表示采样率 16kHz-ac 1表示单声道-c:a pcm_s16le指无压缩 PCM 编码。这个格式是 Whisper 处理得最轻松的形式加载速度也更快。至于噪音Whisper 对背景噪声的鲁棒性比我预想的好但如果是嘈杂会议、现场录音建议先做轻量降噪。别过度处理否则连人声都会失真。我一般只做简单的高通滤波去掉低频嗡嗡声复杂的降噪反而会影响翻译准确率。5. 高频问题与排查技巧实录5.1 翻译结果出现大段重复或“幻觉”文本这是 Whisper 项目里最常见的抱怨之一。表现是明明音频只有几秒静音模型却一本正经地输出了很长一段英文或者同样的句子翻来覆去出现。原因主要有三个语言自动检测失败。比如中文音频被识别成了某种相近语言之后生成了一堆无意义文本。解码时温度过高导致随机性放大。长音频中condition_on_previous_text为 True模型过于依赖前文开始重复上一段的模式。排查时先把源语言显式指定。中文就写languagezh英文写languageen可以解决相当一部分问题。如果还是重复把temperature设置成 0.2并把condition_on_previous_text设为 Falseresult model.transcribe( audio_path, tasktranslate, languagezh, temperature0.2, condition_on_previous_textFalse, )此外Whisper 的返回结果里有no_speech_prob字段表示模型认为这段没有语音的概率。如果这个值很高说明音频可能是空白或噪声这时候不翻译也罢。5.2 速度太慢怎么优化先说结论最有效的优化是用支持 FP16 的 GPU 推理。哪怕是入门级显卡也比 CPU 快很多。如果你只能用 CPU请把模型降到small并关闭fp16。这里有个容易误解的点很多人以为fp16是“降低精度”所以不敢开。实际上在深度学习里半精度推理对 Whisper 这类模型影响很小换来的速度提升非常显著。如果你的 CPU 指令集比较老旧某些第三方加速实现可能无法运行原生版本则没有这个问题。另外批处理时可以考虑多进程并行。每个进程加载一个模型实例处理不同文件from multiprocessing import Pool def process_one(audio): import whisper model whisper.load_model(small) result model.transcribe(audio, tasktranslate) return audio, result[text] if __name__ __main__: files [a.mp3, b.mp3, c.mp3] with Pool(processes2) as pool: for audio, text in pool.map(process_one, files): print(audio, text)注意每个子进程加载模型都会消耗内存进程数不是越多越好一般建议按 CPU 核心数和内存余量设置。如果机器有 8 核开 4 个进程往往比开 8 个更稳。5.3 专业术语翻译得不准怎么办Whisper 训练数据以通用领域为主遇到专业术语容易翻成表面意思。好消息是我们可以通过initial_prompt干预。比如处理人工智能课程时可以在提示里补充术语表initial_prompt 以下是关于人工智能的课程讲解。请严格使用标准术语整数规划integer programming支持向量机SVM反向传播backpropagation。翻译要专业、简洁。 result model.transcribe( audio_path, tasktranslate, languagezh, initial_promptinitial_prompt, )效果不会百分百保证但大多数情况下术语命中率会明显提升。如果某些公司名、产品名需要固定译法也可以写进initial_prompt。这个方法比事后正则替换要自然得多因为模型在生成阶段就会参考这些约束。需要注意的是initial_prompt不要写太长通常几十到一两百个词足够超过反而可能干扰解码。6. 翻译质量验证与工作流扩展6.1 用同一段音频做模型对比与其听我推荐不如自己跑一次对比。我拿了一段大约 10 秒的中文技术演讲做试验把几种模型的翻译结果贴出来这里内容是虚构的只用于对比效果模型翻译输出节选评价tinyWe need to talk about the model...结构残缺信息丢失严重smallWe need to discuss this model and how to improve it...基本通顺但细节不够mediumWe need to discuss this large language model and how to improve its performance...信息还原度高largeNow we need to discuss how to optimize this large language model in real-world scenarios...能结合语境补全这里我想强调的是翻译质量并不只看句式通不通顺还要看信息是否忠实。在语音翻译任务里误译比漏译更危险。如果需求是做对外宣传片的英文字幕宁可让译文简洁一些也不要让模型自由发挥。这时候可以用较低温度、不开initial_prompt并做人工校对。6.2 从翻译文本到字幕和时间轴结合Whisper 的transcribe返回结果里包含 segment 级别的时间戳可以用来生成字幕。思路是遍历result[segments]取出每个片段开始时间、结束时间和翻译文本生成 SRT 格式。下面是一个简单的导出函数def export_srt(segments, out_path): def fmt(ts): ts int(ts * 1000) ms ts % 1000 s (ts // 1000) % 60 m (ts // 60000) % 60 h ts // 3600000 return f{h:02d}:{m:02d}:{s:02d},{ms:03d} with open(out_path, w, encodingutf-8) as f: for i, seg in enumerate(segments, 1): f.write(f{i}\n) f.write(f{fmt(seg[start])} -- {fmt(seg[end])}\n) f.write(seg[text].strip() \n\n) # 调用 segments result[segments] export_srt(segments, output.srt)如果你想做中英双语字幕可以把transcribe结果和translate结果按时间轴对齐后分别导出。实际项目中我通常先翻译一次得到英文字幕再在字幕编辑工具里叠加中文字幕。自动生成的时间轴已经可以直接用少量错位手工调一下即可。这种工作流适合课程视频、企业培训素材和访谈节目。6.3 后续还能怎么扩展如果你已经把这套流程跑通后面可以做的事情还有很多。比如把翻译结果直接喂给文本摘要模型生成会议纪要的英文摘要或者接入说话人分离技术让字幕带上不同发言人标签再或者做术语库管理把initial_prompt做成一个可配置的模板不同项目加载不同术语表。我自己在项目里就是把这些能力组合成了一个内部工具输入一段录音输出中英文字幕、关键词和摘要效率比之前纯人工处理提升了不少。我个人实际跑下来的最大感触是Whisper 的translate任务真正有价值的不是“它能翻译”这句话而是你能不能控制它稳定输出。语言指定、模型选型、温度控制这三件事做扎实结果基本就可以了。还有一个容易被忽略的小技巧拿到一段完全不熟的音频先不要急着调大模型用small快速跑一遍看看语言检测和段落结构再决定是否换large。这个习惯帮我省了不少时间。如果你正在做跨语言内容生产线不妨把这一整套流程先跑通再根据反馈慢慢调优。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
