拓冰网站定制 
3 步跑通 WhisperLiveKit Sortformer 实时说话人区分【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit周二下午的产品评审会五个人围着桌子抢话会后你只拿到一份不分归属的文字稿想确认那句话是谁说的只能回去翻录音。WhisperLiveKit 的 Sortformer 说话人区分功能把这件事变成实时的转录流里每一行都带一个说话人编号边说边出标签。Sortformer 在解决什么问题Sortformer默认模型nvidia/diar_streaming_sortformer_4spk-v2本质上做的是逐帧说话人分类把音频流切成 1 秒的块对每一帧输出 4 个说话人的概率并在块与块之间维护一个说话人缓存让同一个人整场会议保持同一个编号。这和录完一整段再全局聚类的离线做法是两条路线。维度传统做法本方案做法处理方式整段音频离线批处理流式每 1 秒音频走一次推理标签延迟录音结束后数分钟边说边出标签说话人编号全局聚类长音频中 ID 可能漂移188 帧增量说话人缓存会话内编号稳定运行门槛常依赖 HF 账号下载模型NeMo 本地加载离线可用最多 4 人顺带一提它输出的是匿名编号speaker 1、speaker 2不关心这个人叫什么——名字映射需要你自己在外层做。一条音频块如何变成说话人标签按数据流拆成 4 个阶段对应 sortformer_backend.py 里的实际代码路径音频累积分块16 kHz PCM 经 WebSocket 进来缓冲满 1 秒chunk_len 10 帧 × 下采样 10才发出一个块静默期用insert_silence补偿全局时间偏移保证区分时间轴和转录时间轴始终对齐。Mel 特征提取AudioToMelSpectrogramPreprocessor25 ms 窗、128 维 Mel把音频块转成频谱图再拼接上一块末尾的 99 帧约 0.99 秒作为左上下文块与块之间不留信息断层。流式推理forward_streaming_step逐块前向流式状态里带着 188 帧的说话人缓存spkcache和最近语音的 FIFO 队列输出逐帧 4 分类概率缓存每 144 帧刷新一次。片段合并与 token 对齐逐帧取 argmax把相邻同说话人帧合并成SpeakerSegment(start, end)tokens_alignment再让每个转录 token 按最大时间重叠匹配到某个片段得到一个 1 起编号的说话人前端输出编号 文本的行。图中区分模块与 ASR、翻译流水线并行运行它的片段输出只被下游对齐模块消费不参与文本生成本身——这也解释了为什么关掉转录仍能单独拿到区分结果。本地跑通实时说话人区分 最短可运行路径分 3 步1️⃣克隆并装依赖git clone https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit进入目录后uv sync --extra cu129 --extra diarization-sortformer。完成后启动服务不会抛缺 NeMo 的 SystemExitGPU 环境加 cu129 extra纯 CPU 只装 diarization-sortformer。2️⃣启动服务uv run wlk --model small --diarization --language en。完成后 8000 端口出 Web UIDocker 用户直接docker compose up --build wlk-gpu-sortformer。3️⃣录音验证打开 localhost:8000让两个人交替说几句。你会看到每行文本带上 speaker 1 / speaker 2 标签交替时编号切换且标签跟着人走而不是跟着句子走。不同说话人的文本行用不同颜色区分行首编号与录音里实际的语音交接点一一对应。Sortformer 参数怎么调这些参数目前写死在_load_model里没有暴露成 CLI 参数想调就得改 sortformer_backend.py或者用--sortformer-model-path指向自己改过配置的.nemo文件。⚙️参数名默认值可调范围调大 / 调小的后果chunk_len10 帧约 1 秒/次推理5–15调大减少推理次数、省算力但标签出得慢调小实时性更好chunk_left_context10代码实际拼接约 99 帧 Mel5–15调大边界判断更稳单次推理计算量上升spkcache_len188150–250调大说话人记忆更长、长对话编号更稳调小易换号spkcache_update_period144100–200调小缓存更新更勤、更准但更耗算力调大长对话易串号如果只调一个追低延迟先动 chunk_len追长对话编号稳定先动 spkcache_len。说话人区分延迟和混淆怎么办现象启动即 SystemExit提示 Sortformer diarization requires NeMo。原因是只装了基础包没装区分依赖。处理uv sync --extra diarization-sortformer或pip install whisperlivekit[diarization-sortformer]。现象首次运行长时间无输出像卡死。原因是在从 Hugging Face 拉取diar_streaming_sortformer_4spk-v2模型。处理内网/离线环境提前下载.nemo文件用--sortformer-model-path指向本地路径。现象超过 4 个人时编号混乱、互相抢标签。原因是模型按最多 4 说话人训练4spk说话人缓存也只保留 188 帧的历史。处理场景控制在 4 人以内超长会议里偶发换号属于该架构的已知边界不是配置错误。这个功能适合什么场景适合2–4 人会议、访谈、播客录制这类需要实时谁说了什么的流式转文字带说话人标签场景且环境能本地跑 NeMoGPU 优先。不适合4 人以上的大场需要识别具体是谁的场景只能拿到匿名编号以及纯 CPU 且负载重的机器——每 1 秒一次的推理在低算力下容易追不上实时。编号和文本从同一条流水线出来这是 Sortformer 说话区分的核心价值先试试把 spkcache_len 提到 250 再录 30 分钟会议看编号还稳不稳。【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 3 步跑通 WhisperLiveKit Sortformer 实时说话人区分
3 步跑通 WhisperLiveKit Sortformer 实时说话人区分【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit周二下午的产品评审会五个人围着桌子抢话会后你只拿到一份不分归属的文字稿想确认那句话是谁说的只能回去翻录音。WhisperLiveKit 的 Sortformer 说话人区分功能把这件事变成实时的转录流里每一行都带一个说话人编号边说边出标签。Sortformer 在解决什么问题Sortformer默认模型nvidia/diar_streaming_sortformer_4spk-v2本质上做的是逐帧说话人分类把音频流切成 1 秒的块对每一帧输出 4 个说话人的概率并在块与块之间维护一个说话人缓存让同一个人整场会议保持同一个编号。这和录完一整段再全局聚类的离线做法是两条路线。维度传统做法本方案做法处理方式整段音频离线批处理流式每 1 秒音频走一次推理标签延迟录音结束后数分钟边说边出标签说话人编号全局聚类长音频中 ID 可能漂移188 帧增量说话人缓存会话内编号稳定运行门槛常依赖 HF 账号下载模型NeMo 本地加载离线可用最多 4 人顺带一提它输出的是匿名编号speaker 1、speaker 2不关心这个人叫什么——名字映射需要你自己在外层做。一条音频块如何变成说话人标签按数据流拆成 4 个阶段对应 sortformer_backend.py 里的实际代码路径音频累积分块16 kHz PCM 经 WebSocket 进来缓冲满 1 秒chunk_len 10 帧 × 下采样 10才发出一个块静默期用insert_silence补偿全局时间偏移保证区分时间轴和转录时间轴始终对齐。Mel 特征提取AudioToMelSpectrogramPreprocessor25 ms 窗、128 维 Mel把音频块转成频谱图再拼接上一块末尾的 99 帧约 0.99 秒作为左上下文块与块之间不留信息断层。流式推理forward_streaming_step逐块前向流式状态里带着 188 帧的说话人缓存spkcache和最近语音的 FIFO 队列输出逐帧 4 分类概率缓存每 144 帧刷新一次。片段合并与 token 对齐逐帧取 argmax把相邻同说话人帧合并成SpeakerSegment(start, end)tokens_alignment再让每个转录 token 按最大时间重叠匹配到某个片段得到一个 1 起编号的说话人前端输出编号 文本的行。图中区分模块与 ASR、翻译流水线并行运行它的片段输出只被下游对齐模块消费不参与文本生成本身——这也解释了为什么关掉转录仍能单独拿到区分结果。本地跑通实时说话人区分 最短可运行路径分 3 步1️⃣克隆并装依赖git clone https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit进入目录后uv sync --extra cu129 --extra diarization-sortformer。完成后启动服务不会抛缺 NeMo 的 SystemExitGPU 环境加 cu129 extra纯 CPU 只装 diarization-sortformer。2️⃣启动服务uv run wlk --model small --diarization --language en。完成后 8000 端口出 Web UIDocker 用户直接docker compose up --build wlk-gpu-sortformer。3️⃣录音验证打开 localhost:8000让两个人交替说几句。你会看到每行文本带上 speaker 1 / speaker 2 标签交替时编号切换且标签跟着人走而不是跟着句子走。不同说话人的文本行用不同颜色区分行首编号与录音里实际的语音交接点一一对应。Sortformer 参数怎么调这些参数目前写死在_load_model里没有暴露成 CLI 参数想调就得改 sortformer_backend.py或者用--sortformer-model-path指向自己改过配置的.nemo文件。⚙️参数名默认值可调范围调大 / 调小的后果chunk_len10 帧约 1 秒/次推理5–15调大减少推理次数、省算力但标签出得慢调小实时性更好chunk_left_context10代码实际拼接约 99 帧 Mel5–15调大边界判断更稳单次推理计算量上升spkcache_len188150–250调大说话人记忆更长、长对话编号更稳调小易换号spkcache_update_period144100–200调小缓存更新更勤、更准但更耗算力调大长对话易串号如果只调一个追低延迟先动 chunk_len追长对话编号稳定先动 spkcache_len。说话人区分延迟和混淆怎么办现象启动即 SystemExit提示 Sortformer diarization requires NeMo。原因是只装了基础包没装区分依赖。处理uv sync --extra diarization-sortformer或pip install whisperlivekit[diarization-sortformer]。现象首次运行长时间无输出像卡死。原因是在从 Hugging Face 拉取diar_streaming_sortformer_4spk-v2模型。处理内网/离线环境提前下载.nemo文件用--sortformer-model-path指向本地路径。现象超过 4 个人时编号混乱、互相抢标签。原因是模型按最多 4 说话人训练4spk说话人缓存也只保留 188 帧的历史。处理场景控制在 4 人以内超长会议里偶发换号属于该架构的已知边界不是配置错误。这个功能适合什么场景适合2–4 人会议、访谈、播客录制这类需要实时谁说了什么的流式转文字带说话人标签场景且环境能本地跑 NeMoGPU 优先。不适合4 人以上的大场需要识别具体是谁的场景只能拿到匿名编号以及纯 CPU 且负载重的机器——每 1 秒一次的推理在低算力下容易追不上实时。编号和文本从同一条流水线出来这是 Sortformer 说话区分的核心价值先试试把 spkcache_len 提到 250 再录 30 分钟会议看编号还稳不稳。【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考