1. 为什么我要在 Linux 上折腾本地 AI 转录

先说说我做这个事的起因。我平时的工作流里有大量语音素材要处理——会议录音、采访片段、自己随手录的灵感备忘，甚至还有一些视频素材需要提取字幕。早些年我一直用在线转录服务，方便是方便，但用久了问题就冒出来了：一是长音频要排队，二是隐私内容上传到别人服务器总归不踏实，三是免费额度用完就得掏钱，四是网络一波动就断。后来我干脆下决心，在本地 Linux 机器上搭一套完全离线的 AI 转录工作台，也就是我称之为 TrueScribe 的这套东西。

TrueScribe 本质上是一个跑在 Linux 本地的 AI 转录工作室，核心能力就三件事：把音频转成文字、把文字按时间轴对齐、把结果导出成各种格式。它不依赖任何在线接口，所有推理都在你自己的机器上完成。适合谁用？我总结下来是三类人：一是手里有大量录音需要批量处理的从业者，比如记者、播客主、做会议纪要的行政；二是对隐私敏感、不愿意把音频传到云端的开发者或法务相关工作者；三是喜欢折腾、想在 Linux 上跑本地大模型的爱好者。哪怕你只是想让自己的语音笔记自动变成可搜索的文本，这套方案也能用。

我踩过的坑不少，从显卡驱动到模型量化，从音频采样率到时间戳对齐，前后折腾了小半个月才把流程跑顺。这篇文章就把我整套思路、选型理由、实操步骤和避坑经验完整摊开讲，你照着抄作业基本能少走八成弯路。

2. 整体方案设计与技术选型思路

2.1 为什么坚持本地推理而不是调 API

很多人第一反应是：直接调在线转录接口不就完了，何必自己搭？我一开始也这么想，但实际用下来，本地推理有三个绕不开的优势。第一是隐私，音频里经常有客户姓名、项目代号、未公开的商业信息，这些东西一旦上传就脱离了你的控制。第二是成本，在线服务按分钟计费，我一个月要处理十几个小时的音频，长期算下来比自己买张显卡贵得多。第三是可控性，本地跑意味着我可以自由换模型、调参数、改后处理逻辑，不受任何服务商的接口限制。

当然本地推理也有代价：需要一块像样的 GPU，初次配置有学习成本，模型文件动辄几个 GB。但这些都是前期一次性投入，跑顺之后就是纯收益。我的判断标准很简单：如果你每月转录时长超过 5 小时，或者音频内容涉及隐私，本地方案就值得投入。

2.2 核心组件拆解：从音频到文字要经过哪几道工序

TrueScribe 的流水线我拆成四个阶段，每个阶段都有明确的输入输出，方便单独调试和替换。

这个拆分的意义在于，任何一环出问题我都能快速定位。比如转录结果全是乱码，那大概率是预处理阶段采样率不对；如果文字对了但时间轴错乱，那就是识别阶段的时间戳对齐有问题。分阶段调试比一锅端要高效得多。

2.3 模型选型：Whisper 系还是别的方案

语音识别这块我最终选了 Whisper 系列模型，理由有几个。首先是多语言支持好，中英文混说的场景它处理得比很多专用模型都稳。其次是社区生态成熟，各种量化版本、加速方案、后处理工具都能找到。第三是精度够用，large 版本在安静环境下的准确率我个人实测能到 95% 以上。

模型大小怎么选？我整理了一张对照表，你可以根据自己的硬件和精度要求来定。

我的建议是：先用 small 跑一遍看效果，如果准确率不满意再往上换。没必要一上来就上 large，那玩意儿在普通显卡上跑一小时音频要等十几分钟，体验很差。另外现在有很多量化版本，比如 int8 量化能把 large 的显存占用压到 6GB 左右，精度损失很小，性价比很高。

2.4 硬件门槛到底有多高

这是被问得最多的问题。我的实测数据是这样的：一张 8GB 显存的显卡，跑 medium 模型处理一小时音频大约需要 8 到 12 分钟；如果只有 CPU，同样的任务可能要 40 分钟以上，而且风扇狂转。所以我的底线建议是：至少 8GB 显存的独立显卡，N 卡在 Linux 上的驱动和推理生态最成熟，优先考虑。

如果没有独显怎么办？也不是不能跑，用 CPU 加 int8 量化的小模型，处理短音频（几分钟以内）还能接受。但如果你要批量处理长录音，还是建议攒一台带显卡的机器，或者用云主机按需跑——注意这里说的是自己控制的云主机，不是转录服务。

3. 环境搭建与核心依赖安装实操

3.1 系统准备与显卡驱动确认

我用的系统是 Ubuntu 22.04 LTS，这个版本在 AI 工具链上的兼容性最好。如果你用的是其他发行版，思路一样，只是包管理命令要换。第一步是确认显卡和驱动状态，打开终端跑：

nvidia-smi

如果能看到显卡型号、驱动版本和显存占用，说明驱动没问题。如果提示命令找不到，那就得先装驱动。Ubuntu 下最省事的方式是用系统自带的附加驱动工具，或者：

sudo ubuntu-drivers autoinstall sudo reboot

重启后再跑一次nvidia-smi确认。这里有个坑我要提醒：驱动版本不要太老，否则后面装推理框架时会报 CUDA 版本不兼容。我建议驱动版本至少在 525 以上。

3.2 Python 环境隔离：别污染系统环境

Linux 系统自带的 Python 是给系统工具用的，直接往上装包很容易把系统搞崩。我强烈建议用虚拟环境隔离。我习惯用 conda，因为它在处理 CUDA 相关依赖时更省心：

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh

装完之后创建独立环境：

conda create -n truescribe python=3.10 conda activate truescribe

为什么选 Python 3.10？因为 3.11 和 3.12 在部分推理库上还有兼容问题，3.10 是目前最稳的版本。这个细节很多人不注意，结果装到一半各种报错，回头排查半天。

3.3 推理框架安装与 CUDA 匹配

核心推理我用的 faster-whisper，它比原版 Whisper 快好几倍，而且显存占用更低。安装命令：

pip install faster-whisper

但这里有个关键点：faster-whisper 底层依赖 CTranslate2，而 CTranslate2 对 CUDA 和 cuDNN 版本有要求。我踩过的坑是，pip 装完跑起来报libcudnn找不到。解决办法是手动装对应版本的 cuDNN，或者用 conda 装：

conda install -c conda-forge cudnn

装完验证一下：

python -c "import ctranslate2; print(ctranslate2.get_cuda_device_count())"

如果输出大于 0，说明 GPU 能被正确识别。这一步是整个环境搭建里最容易翻车的地方，务必确认通过再往下走。

3.4 音频处理工具链准备

转录之前要处理音频，我用的是 ffmpeg，它是音频处理领域的瑞士军刀：

sudo apt install ffmpeg

验证安装：

ffmpeg -version

另外我还装了 sox 用来做降噪和音量归一化，这两个工具配合基本能覆盖所有预处理需求。ffmpeg 负责格式转换和切分，sox 负责音质优化，分工明确。

4. 转录流水线的完整实现

4.1 音频预处理：把素材统一成模型爱吃的格式

Whisper 系列模型对输入音频有明确偏好：16kHz 采样率、单声道、PCM 编码的 WAV。原始素材五花八门，有 44.1kHz 的立体声 MP3，有 48kHz 的 AAC，直接喂给模型虽然也能跑，但准确率会打折扣。所以第一步统一格式：

ffmpeg -i input.mp3 -ar 16000 -ac 1 -c:a pcm_s16le output.wav

参数解释一下：-ar 16000指定采样率 16kHz，-ac 1指定单声道，-c:a pcm_s16le指定 16 位 PCM 编码。这三个参数是 Whisper 的标配，别改。

如果音频里有明显底噪，我会再过一道 sox 降噪：

sox output.wav cleaned.wav noisered noise.prof 0.21

其中noise.prof是噪声样本文件，需要先从音频的静音段提取。这一步对录音环境差的素材提升很明显，安静环境下可以跳过。

注意：降噪不要过度，参数调太狠会把语音本身的高频细节也削掉，反而降低识别率。我一般从 0.21 开始试，效果不好再微调。

4.2 长音频切分策略：别让模型吃撑

Whisper 单次处理的音频长度有限制，虽然 faster-whisper 内部有滑动窗口机制，但超长音频还是建议先切分。我的做法是按静音段切，而不是按固定时长硬切，因为硬切容易把一句话从中间截断，导致识别出错。

用 ffmpeg 的静音检测来切分：

ffmpeg -i cleaned.wav -af silencedetect=noise=-30dB:d=0.5 -f null - 2> silence.log

这条命令会输出所有静音段的时间点，然后我写了个小脚本根据这些时间点把音频切成 5 到 10 分钟一段。为什么是 5 到 10 分钟？太短了切分开销大，太长了单段处理慢且出错后要重跑的成本高。这个区间是我实测下来比较平衡的。

4.3 核心转录脚本编写

下面是转录的核心代码，我用 faster-whisper 的 Python 接口：

from faster_whisper import WhisperModel model = WhisperModel("large-v3", device="cuda", compute_type="int8") segments, info = model.transcribe( "cleaned.wav", language="zh", beam_size=5, vad_filter=True, vad_parameters=dict(min_silence_duration_ms=500) ) for segment in segments: print(f"[{segment.start:.2f} -> {segment.end:.2f}] {segment.text}")

几个关键参数我解释一下。compute_type="int8"是量化推理，显存占用减半，速度提升明显，精度损失我实测在 1% 以内，非常划算。beam_size=5是束搜索宽度，值越大越准但越慢，5 是精度和速度的平衡点。vad_filter=True开启语音活动检测，能自动跳过静音段，既提速又减少幻觉。

语言参数language="zh"如果你不确定音频语言，可以设成None让模型自动检测，但自动检测偶尔会出错，尤其是中英混说的场景。我的做法是明确指定主语言，混说的部分模型自己会处理。

4.4 时间戳对齐与后处理

转录出来的原始文本没有标点，断句也乱，直接看很痛苦。后处理我分两步走。第一步是标点恢复，我用了一个基于规则加模型的方法，简单说就是根据停顿时间和语气词来补标点。第二步是断句优化，把过长的句子按语义切开。

时间戳这块 faster-whisper 输出的 segment 级别时间戳已经够用，但如果你要做字幕，需要更细的 word 级别时间戳，可以加参数：

segments, info = model.transcribe( "cleaned.wav", word_timestamps=True )

开启后每个 segment 里会带 words 列表，每个词都有精确的起止时间。做 SRT 字幕时这个很有用，能让字幕跟着语音逐词高亮。

4.5 导出格式与自动化串联

最后一步是导出。我写了个脚本把结果转成多种格式：

def to_srt(segments): lines = [] for i, seg in enumerate(segments, 1): start = format_time(seg.start) end = format_time(seg.end) lines.append(f"{i}\n{start} --> {end}\n{seg.text}\n") return "\n".join(lines)

format_time把秒数转成HH:MM:SS,mmm格式。整个流水线我用一个 shell 脚本串起来，从原始音频到最终字幕一键完成：

#!/bin/bash for f in ./raw/*.mp3; do name=$(basename "$f" .mp3) ffmpeg -i "$f" -ar 16000 -ac 1 -c:a pcm_s16le "./tmp/$name.wav" python transcribe.py "./tmp/$name.wav" > "./out/$name.txt" python to_srt.py "./out/$name.txt" > "./out/$name.srt" done

这样我只要把音频丢进 raw 目录，跑一下脚本，出去喝杯咖啡回来就全处理好了。

5. 常见问题排查与性能调优实录

5.1 转录结果乱码或重复的排查思路

这是最典型的问题，表现是输出一堆重复的词或者完全无关的内容。原因通常有三个。第一是音频采样率不对，模型把 44.1kHz 的音频当 16kHz 处理，声音被拉慢了，识别自然乱。解决办法就是老老实实做预处理，别偷懒。第二是模型幻觉，在静音段或纯音乐段模型会自己编内容，开启vad_filter能大幅缓解。第三是语言设置错误，把中文音频设成英文识别，结果就是一堆拼音。

排查顺序我建议：先确认采样率，再确认语言设置，最后看是不是幻觉。我整理了一张速查表：

5.2 显存不足的几种应对方案

跑 large 模型时显存爆掉很常见。我的应对方案按优先级排：第一是换量化版本，int8 量化能把显存需求砍半；第二是换小一号的模型，medium 在很多场景下够用；第三是开启分块处理，把长音频切成更小的段逐段推理；第四是降低 beam_size，从 5 降到 1，速度提升明显但精度略降。

如果这些都不行，那就只能上 CPU 推理了，虽然慢但至少能跑。CPU 模式下建议用 int8 量化加 small 模型，这是能跑和跑得动之间的平衡点。

5.3 批量处理的性能优化技巧

批量处理时我总结了几个提速技巧。第一是模型常驻内存，别每处理一个文件就重新加载模型，加载一次要好几秒，批量处理时这个开销很可观。第二是并行预处理，音频转换是 CPU 密集型任务，可以和 GPU 推理重叠进行。第三是结果缓存，同一个音频文件处理过就记下来，避免重复劳动。

我实测下来，优化前后处理 20 个音频文件的总耗时能从 40 分钟压到 25 分钟左右，提升还是很明显的。

5.4 我踩过的那些坑

说几个文档里不会写但实际很坑的点。第一是文件名带空格或中文，shell 脚本里不加引号就会出错，我建议所有中间文件都用英文加下划线命名。第二是磁盘空间，一小时 16kHz 单声道 WAV 大约 110MB，批量处理时临时文件很快就把盘塞满了，记得定期清理 tmp 目录。第三是显卡温度，连续跑几小时推理，显卡温度能上 80 度，机箱风道不好的话会降频，反而变慢，该加风扇就加。

还有一个隐蔽的坑是音频里的直流偏移，某些录音设备录出来的音频有直流分量，会导致 VAD 检测失灵。用 sox 的highpass滤波能解决：

sox input.wav output.wav highpass 80

这个 80Hz 的高通滤波能滤掉直流和低频噪声，对识别率有正面帮助。

6. 进阶玩法与扩展方向

6.1 说话人分离：让转录结果区分谁在说

会议录音最头疼的是分不清谁在说话。我试过用 pyannote 做说话人分离，效果不错但配置略麻烦。基本思路是先做说话人聚类，得到每段语音属于哪个说话人，再和转录结果按时间轴合并。这样输出的文本就带上了说话人标签，做会议纪要时非常实用。

配置上需要下载预训练模型，对显存有一定要求。如果只是两三个人的对话，用简单的声纹聚类也能凑合，不一定非要上重型方案。

6.2 实时转录：把延迟压到可接受范围

本地实时转录是可行的，但需要取舍。我的做法是用 small 模型加流式推理，把音频按 2 秒一段送进去，延迟能控制在 3 秒左右。这个延迟做实时字幕勉强够用，做同传就不行了。如果追求更低延迟，就得换更小的模型或者用专门的流式架构，但精度会下降。

实时转录的另一个难点是断句，流式输入没有完整的上下文，标点恢复会不准。我的处理是先用简单规则断句，等整段结束后再用完整模型重新处理一遍，兼顾实时性和最终质量。

6.3 与笔记系统的联动

转录结果最终要落到笔记里才有价值。我用的是一个简单的方案：转录完成后自动生成 Markdown 文件，带上时间戳和音频文件名，然后同步到我的笔记目录。这样我在笔记里搜索关键词就能定位到对应的录音片段，回听也很方便。

如果你用 Obsidian 之类的工具，还可以写个插件把音频和转录文本关联起来，点击文本就能跳转到音频对应位置。这个体验一旦用上就回不去了。

6.4 模型微调：针对特定领域提升准确率

通用模型在专业领域表现会打折，比如医学、法律、工程术语。如果我的转录内容集中在某个垂直领域，我会考虑做微调。微调需要准备领域相关的音频和对应文本，几百条数据就能看到明显提升。不过微调有门槛，需要一定的机器学习基础，普通用户先用通用模型加自定义词表也能改善不少。

自定义词表这个技巧很实用，把领域专有名词提前告诉模型，能显著减少这些词的识别错误。faster-whisper 支持通过initial_prompt参数传入提示词，把专业术语塞进去就行。

7. 一些实际使用中的体会

这套 TrueScribe 工作流我跑了小半年，处理了上百小时的音频，整体稳定性让我满意。最大的感受是，本地 AI 转录这件事的门槛比想象中低，一张中端显卡加一个周末的折腾就能搭起来，但收益是长期的。我现在处理录音基本是丢进去就不管了，回头直接拿结果，这种确定性和掌控感是在线服务给不了的。

如果让我给刚上手的人一句建议，那就是：先把 small 模型跑通，别一上来就追求 large 的精度。流程跑顺了，再逐步升级模型和优化参数，这样每一步都有正反馈，不容易半途而废。另外记得做好文件命名规范和目录结构，批量处理时这点比技术本身还重要。