尧图网页设计 
WhisperLiveKit 实时说话人区分指南一条命令分清会议里谁说了什么【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKitWhisperLiveKit 的实时说话人区分speaker diarization功能基于流式 Sortformer 模型只需在启动命令后加一个--diarization开关就能在直播字幕、会议记录场景下实时给前 4 位发言者打标签。这篇文章从一条命令讲起装好依赖、跑起服务再解释标签是怎么稳定产生、哪些参数值得调。为什么实时场景必须用流式区分先把概念说清楚转录回答说了什么说话人区分回答谁在说。很多人习惯的思路是把整段录音跑完再事后分析但这只适用于会后整理。直播字幕、在线会议这类场景里字幕出来的那一刻就必须带上人名等不到整段结束。流式方案的核心是边听边记。WhisperLiveKit 采用的 Sortformer 每收到约 1 秒的音频就做一次推理同时维护两份记忆一份是从会话开始累积的长期说话人特征一份是最近几个音频块的短期队列。正因为有长期记忆同一个人中途再次开口时标签不会从 Speaker 1 跳成 Speaker 2——这是流式模型比每帧独立判断稳定得多的原因。安装依赖并启动服务Sortformer 依赖 NVIDIA NeMo它被放在 WhisperLiveKit 的可选依赖组里和主包一起安装pip install whisperlivekit[diarization-sortformer]如果仓库里用 uv 管理环境GPU 场景对应的是uv sync --extra cu129 --extra diarization-sortformer不想配置本地环境也可以直接用仓库里的 Compose 服务它已经把模型和开关都配好了docker compose up wlk-gpu-sortformer本地启动则是一条命令的事以中文会议为例wlk --model medium --diarization --language zh模型会自动选设备有 CUDA 就用 GPU否则落到 CPU 上跑。看效果标签直接长在转录行上服务起来后打开终端提示的地址进入实时转录界面两人对话时每一行文本前都会带上发言者和起止时间类似Speaker 0 00:02.0 – 00:07.4 第一阶段的数据已经跑完了 Speaker 1 00:07.6 – 00:12.1 那我们下午三点同步一下三个观察体验时值得注意的选项只想看谁在什么时候说话、不关心文字内容加--no-transcription界面只显示说话人回合1 对 1 的访谈可以用--sortformer-max-speakers 2声明最多两个人标签只会落在前两个通道上避免多余通道参与归属该参数取值是 1–4它是你对会议的声明而不是模型的估计——如果实际人数超出声明多出来的话会归并到保留的标签上所以拿不准就别加。标签在背后是怎么算出来的把 Sortformer 后端源码 读一遍流程其实不复杂音频以 1 秒为一个块送入先转成梅尔频谱图forward_streaming_step做一次流式推理更新内部状态并输出当前块每一帧的说话人概率连续属于同一说话人的帧被合并成SpeakerSegmentspeaker / start / end 三个字段发给前端渲染。默认加载的权重是nvidia/diar_streaming_sortformer_4spk-v2有 4 条说话人通道按谁先开口的顺序固定命名 Speaker 0 到 3之后整场会话不变。状态里的两块缓存各司其职长期缓存spkcache存从会话开始到现在的特征短期队列fifo存最近的块缓存按固定周期刷新从而既记得住张三的音色又能跟上第四个人刚进门这种变化。另外源码里有一个insert_silence(silence_duration)接口检测到长时间静音时把它记进全局时间轴时间戳不会漂静音也不会污染说话人特征。自己写客户端接入时静音检测部分可以照这个思路对接。参数速查参数作用备注--diarization打开说话人区分总开关默认关闭--diarization-backend选择区分后端可选sortformer或diart默认sortformerDiart 依赖 pyannote 模型且需要额外授权官方标注不推荐--sortformer-model-path指向本地.nemo文件、只含一个.nemo的目录或模型 ID不填则用默认 4 说话人模型--sortformer-max-speakers声明会话最多 N 人1–4见上文是声明不是估计--no-transcription只显示区分结果不做转录适合只关心回合的场景--language转录语言auto自动检测与区分功能互相独立想改推理侧的参数缓存长度、更新周期等它们都写在SortformerDiarization的初始化里例如 spkcache 与 fifo 的长度、缓存刷新周期按部署环境调整即可。硬件与延迟预期没有 NVIDIA GPU 也能跑CPU 上能完成实时区分只是留给转录的余量变小。有 GPU 时 Sortformer 会自动切到 CUDA。仓库基准数据里有一张 Apple M5 与 NVIDIA H100 的对比图转录部分在 GPU 上的速度优势非常明显说话人区分这块模型本身不大多数消费级 GPU 都够瓶颈通常先出现在 ASR 一侧。部署细节可以对照 Docker 与部署文档里面覆盖了带区分功能的镜像构建参数和wlk-gpu-sortformer服务的启动方式。收尾提醒上手路径就三件事装diarization-sortformer依赖组、启动命令加--diarization、按实际人数决定要不要声明--sortformer-max-speakers。之后如果标签仍然偶尔串人优先检查拾音质量——两个人离同一支麦克风远近差异太大时再好的流式模型也只能给出它听到的结果。【免费下载链接】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），仅供参考 WhisperLiveKit 实时说话人区分指南：一条命令分清会议里谁说了什么
WhisperLiveKit 实时说话人区分指南一条命令分清会议里谁说了什么【免费下载链接】WhisperLiveKitReal-time, local speech-to-text with streaming ASR, speaker diarization, translation, and OpenAI/Deepgram-compatible APIs.项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKitWhisperLiveKit 的实时说话人区分speaker diarization功能基于流式 Sortformer 模型只需在启动命令后加一个--diarization开关就能在直播字幕、会议记录场景下实时给前 4 位发言者打标签。这篇文章从一条命令讲起装好依赖、跑起服务再解释标签是怎么稳定产生、哪些参数值得调。为什么实时场景必须用流式区分先把概念说清楚转录回答说了什么说话人区分回答谁在说。很多人习惯的思路是把整段录音跑完再事后分析但这只适用于会后整理。直播字幕、在线会议这类场景里字幕出来的那一刻就必须带上人名等不到整段结束。流式方案的核心是边听边记。WhisperLiveKit 采用的 Sortformer 每收到约 1 秒的音频就做一次推理同时维护两份记忆一份是从会话开始累积的长期说话人特征一份是最近几个音频块的短期队列。正因为有长期记忆同一个人中途再次开口时标签不会从 Speaker 1 跳成 Speaker 2——这是流式模型比每帧独立判断稳定得多的原因。安装依赖并启动服务Sortformer 依赖 NVIDIA NeMo它被放在 WhisperLiveKit 的可选依赖组里和主包一起安装pip install whisperlivekit[diarization-sortformer]如果仓库里用 uv 管理环境GPU 场景对应的是uv sync --extra cu129 --extra diarization-sortformer不想配置本地环境也可以直接用仓库里的 Compose 服务它已经把模型和开关都配好了docker compose up wlk-gpu-sortformer本地启动则是一条命令的事以中文会议为例wlk --model medium --diarization --language zh模型会自动选设备有 CUDA 就用 GPU否则落到 CPU 上跑。看效果标签直接长在转录行上服务起来后打开终端提示的地址进入实时转录界面两人对话时每一行文本前都会带上发言者和起止时间类似Speaker 0 00:02.0 – 00:07.4 第一阶段的数据已经跑完了 Speaker 1 00:07.6 – 00:12.1 那我们下午三点同步一下三个观察体验时值得注意的选项只想看谁在什么时候说话、不关心文字内容加--no-transcription界面只显示说话人回合1 对 1 的访谈可以用--sortformer-max-speakers 2声明最多两个人标签只会落在前两个通道上避免多余通道参与归属该参数取值是 1–4它是你对会议的声明而不是模型的估计——如果实际人数超出声明多出来的话会归并到保留的标签上所以拿不准就别加。标签在背后是怎么算出来的把 Sortformer 后端源码 读一遍流程其实不复杂音频以 1 秒为一个块送入先转成梅尔频谱图forward_streaming_step做一次流式推理更新内部状态并输出当前块每一帧的说话人概率连续属于同一说话人的帧被合并成SpeakerSegmentspeaker / start / end 三个字段发给前端渲染。默认加载的权重是nvidia/diar_streaming_sortformer_4spk-v2有 4 条说话人通道按谁先开口的顺序固定命名 Speaker 0 到 3之后整场会话不变。状态里的两块缓存各司其职长期缓存spkcache存从会话开始到现在的特征短期队列fifo存最近的块缓存按固定周期刷新从而既记得住张三的音色又能跟上第四个人刚进门这种变化。另外源码里有一个insert_silence(silence_duration)接口检测到长时间静音时把它记进全局时间轴时间戳不会漂静音也不会污染说话人特征。自己写客户端接入时静音检测部分可以照这个思路对接。参数速查参数作用备注--diarization打开说话人区分总开关默认关闭--diarization-backend选择区分后端可选sortformer或diart默认sortformerDiart 依赖 pyannote 模型且需要额外授权官方标注不推荐--sortformer-model-path指向本地.nemo文件、只含一个.nemo的目录或模型 ID不填则用默认 4 说话人模型--sortformer-max-speakers声明会话最多 N 人1–4见上文是声明不是估计--no-transcription只显示区分结果不做转录适合只关心回合的场景--language转录语言auto自动检测与区分功能互相独立想改推理侧的参数缓存长度、更新周期等它们都写在SortformerDiarization的初始化里例如 spkcache 与 fifo 的长度、缓存刷新周期按部署环境调整即可。硬件与延迟预期没有 NVIDIA GPU 也能跑CPU 上能完成实时区分只是留给转录的余量变小。有 GPU 时 Sortformer 会自动切到 CUDA。仓库基准数据里有一张 Apple M5 与 NVIDIA H100 的对比图转录部分在 GPU 上的速度优势非常明显说话人区分这块模型本身不大多数消费级 GPU 都够瓶颈通常先出现在 ASR 一侧。部署细节可以对照 Docker 与部署文档里面覆盖了带区分功能的镜像构建参数和wlk-gpu-sortformer服务的启动方式。收尾提醒上手路径就三件事装diarization-sortformer依赖组、启动命令加--diarization、按实际人数决定要不要声明--sortformer-max-speakers。之后如果标签仍然偶尔串人优先检查拾音质量——两个人离同一支麦克风远近差异太大时再好的流式模型也只能给出它听到的结果。【免费下载链接】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），仅供参考