Speechlib：用 AI 把「谁说了什么」还给音频

场景切入：想象你是一场长达两小时会议录音的唯一记录者。打开音频，满耳是七八个声音此起彼伏——有人语速飞快，有人偶尔打断，还有人说着说着笑了出来。手动把这段对话转成文字，并标注"这是张总说的""那是李工提的疑问"——光是想想就令人头皮发麻。Speechlib 正是为解决这个痛点而生的。

图1：Speechlib 生成的对话转录结果，每段对话标注了说话人、时间戳和识别语言

背景：语音 AI 流水线为何长期割裂

过去，开发者想让一段多人音频"听得懂"——不仅知道说了什么，还知道谁在何时发言——需要自行拼接三套系统：

• 说话人分割（Spatial Diarization）：把连续音频切分成「A 说话片段」「B 说话片段」……
• 语音识别（ASR）：把每个片段转成文字
• 说话人识别（Speaker Recognition）：把「A 说话片段」中的 A，映射到具体的说话人身份

这三套系统往往来自不同团队、不同框架、不同依赖，串联它们的工程量不亚于重新开发一个产品。而 Whisper、PyAnnote、SpeechBrain 等上游模型迭代频繁，每次升级都可能让胶水代码失效。

Speechlib 的解决思路：一个 Pipeline，三套模型，一个接口

作者 Navod Peiris（斯里兰卡开发者）将上述三阶段封装为统一 Pipeline，通过依赖注入（Dependency Injection）让用户自由组合底层实现，同时保证输入输出格式一致。

图2：speechlib 核心架构，Diarizer + ASR + Recognizer 三组件可自由替换

说话人分割（Diarization）

目前支持 PyAnnote（基于 pyannote/speaker-diarization@2.1），这是目前开源社区最成熟的说话人分割模型。使用前需要在 HuggingFace 申请访问权限（模型对非商业用途免费）。

核心参数：

• min_speakers / max_speakers：设置说话人数量范围
• access_token：HuggingFace Token（需申请 pyannote 模型权限）

自动语音识别（ASR）

Speechlib 支持 5 种 ASR 后端，用户可以根据精度/速度/成本需求自由切换：

后端	特点	适用场景
FasterWhisperASR	CTranslate2 加速，比原版 Whisper 快 4-10 倍	生产环境首选，CPU/GPU 均支持
WhisperASR	OpenAI Whisper 原生版	精度优先、不在意速度
HuggingFaceASR	HuggingFace Transformers 生态	已有 HF 模型储备的用户
CustomWhisperASR	支持自定义 Whisper 模型路径	fine-tuned 模型
AssemblyAIASR	云端 API，无需本地 GPU	无 GPU 的快速原型

说话人身份识别（Speaker Recognition）

通过 SpeechBrain 实现可选的说话人身份识别。用户需要提前准备一个 voices/ 文件夹，按说话人名字组织参考音频：

voices/
  张总/
    张总_intro.wav
  李工/
    李工_提问.wav

Pipeline 运行时会自动将「说话人片段」与参考音频比对，输出真实人名而非匿名标签（如 SPEAKER_00）。

音频预处理

实际处理前，Pipeline 会自动完成三步标准化：

1. 格式转换：任意输入格式 → WAV
2. 单声道合并：多轨音频 → 单声道
3. 重编码：16-bit PCM（大多数模型要求）

这一步骤由 pydub + soundfile 完成，用户无需手动操作。

并行转录优化

当音频被切分为大量说话人片段后（可能是几十到上百段），串行转录会非常慢。Speechlib 使用 ThreadPoolExecutor 并行处理转录片段，释放 GIL 的 PyTorch/CTranslate2 推理让多线程真正并发。默认 workers = cpu_count - 1。

输出格式

支持三种输出格式：txt、json 或两者同时输出。可选生成 SRT 字幕文件，方便直接导入视频编辑工具。

部署体验：Python 3.10 + ffmpeg + GPU，生产级门槛

Speechlib 不是 Web 应用，没有 Docker，没有 UI，是一个纯粹的 Python 库，部署方式本质上与安装一个普通 pip 包无异：

# CPU 版本（一键安装）
pip install speechlib

# GPU 版本（需指定 CUDA 版本）
pip install speechlib --extra-index-url https://download.pytorch.org/whl/cu126

然而隐性依赖才是真正的门槛：

• ffmpeg 必须预装
• GPU 用户需要 NVIDIA CUDA 11 + cuBLAS + cuDNN 8
• 首次运行会从 HuggingFace 下载多个模型（总量数 GB）
• pyannote/speaker-diarization 和 pyannote/segmentation 需要 HF Token 授权

因此虽然技术上「pip install」就能用，但真正让它跑出可用结果，需要 30 分钟到数小时的环境配置时间。

局限与挑战

1. HuggingFace Token 的双重门槛：PyAnnote 模型虽然免费，但需要用户在 HuggingFace 网站手动申请权限，且 pyannote 团队审批可能需要数小时到数天。这是许多开发者在 GitHub Issues 中反馈的首要痛点。

2. GPU 显存要求不低：Faster-Whisper 的 large-v3 模型需要约 6GB VRAM，medium 模型也需要 4GB+。CPU 用户只能使用 tiny / base 等小模型，精度差距明显。

3. 多人长音频处理速度：PyAnnote Diarization 在 CPU 上处理 1 小时音频可能需要 20-30 分钟，GPU 加速的 Faster-Whisper 也救不了这一段。

4. 商业竞争压力：Recall.ai（项目赞助商）在 README 中大力推广，其云端 API 提供了"100% 准确率"的说话人分割（直接读取会议平台原始数据），这与 Speechlib 基于音频信号的分割在原理上有根本差异。

行业意义：开源语音流水线的工程化范式

Speechlib 在 GitHub 获得了 265 Stars，其核心价值不是某个算法的创新，而是工程化的封装思路：

• 插件化架构：用户可以替换任何一个组件（换 ASR 后端、换 Diarization 模型），而不必重写整个流水线
• 容错设计：单个片段转录失败不影响整体输出（该片段 text 为空）
• 文档完善：README + library.md 超过 14,000 字，覆盖所有组件参数说明

这类工具代表了一种趋势：当单个模型（Whisper、PyAnnote）已经足够好后，开源社区的下一个关注点转向把模型串联成可用产品的工程层。这与 langchain 在 LLM 领域的定位如出一辙。

快速上手

import os
from speechlib import Pipeline, PyAnnoteDiarizer, FasterWhisperASR

pipeline = Pipeline(
    diarization_model=PyAnnoteDiarizer(
        access_token=os.environ["HF_TOKEN"],  # 需提前申请
        min_speakers=1,
        max_speakers=4,
    ),
    asr_model=FasterWhisperASR("turbo"),     # 大小: turbo/base/large-v3
    language=None,                             # None = 自动检测语言
    log_folder="logs",
    output_format="both",                      # 同时输出 txt 和 json
)

segments = pipeline.run("meeting.wav")

只需约 30 行代码，就能完成从原始音频到带说话人标注的转录结果的完整流水线。