深挖 · WhisperLiveKit × sokuji 横评：开源实时语音转写两路线，先学哪个

WhisperLiveKit（下称 WLK）是 ~11k stars 的 Python 流式语音转写翻译工具包，Apache-2.0，月更节奏。这是上一篇 sokuji 深挖的续篇：sokuji 是「能直接用的同传应用」，WLK 是「能拆开学习的同传引擎」——它恰好把 sokuji 没有解决的增量翻译问题做成了可复用模块。本文深挖 WLK 本体，然后与 sokuji 横评，最后给出「先 study 哪一个」的结论。

是什么

WLK 的形态是库 + CLI + 自托管服务 + 客户端的全家桶，PyPI 包名 whisperlivekit（v0.2.26），官方 tagline「Ultra-low-latency, self-hosted speech-to-text pipeline」（README）：

• 库：集成契约极小——AudioProcessor.process_audio() 收音频字节、create_tasks() 异步生成器出结果、断连 cleanup()；TranscriptionEngine 全局单例跨连接共享模型。官方明说自带 FastAPI server「只是一个示例」，任意 async 框架可嵌（technical_integration.md）
• CLI/服务：wlk --model base --language en 一条命令起 :8000 端口，自带 Web UI；wlk transcribe 出 SRT 字幕、wlk pull 预下载模型、wlk bench 跑基准
• 接口三协议：OpenAI 兼容 REST（/v1/audio/transcriptions，OpenAI Python SDK 改个 base_url 直连）、Deepgram 兼容 WebSocket、原生 WebSocket（/asr，带增量 diff 模式）（docs/API.md）
• 边界要认清：无 TTS（输出到文本为止）、无 WebRTC、无双向会议模式、说话人分离上限 4 人且不处理重叠语音——这三项全历史 commit 查询均为空（01-技术原料）

一句话：WLK 管线层（耳朵到文字），sokuji 应用层（文字回到声音和会议软件）。

核心机制

流式 ASR 双策略（--backend-policy 切换）：

• AlignAtt/SimulStreaming（默认）：用 Whisper 解码器 cross-attention 的对齐帧给 token 打时间戳（softmax + z-normalize + median filter + 多头平均）；注意力回跳判定幻觉并 rewind；音频耗尽（距末尾 ≤25 帧≈0.5s）时暂停等新音频；CIF 词边界门控发射（词没结束就扣住）；DRY 惩罚防逐字复读 + runaway guard 防解码失控（simul_whisper.py）
• LocalAgreement-2：对不断增长的音频反复解码，只有连续两次假设的最长公共前缀才提交；置信度>0.95 可跳过协议提前提交；1-5 gram 去重防边界复读。实现约百行，极易复刻（online_asr.py）

增量翻译三路线（这是它相对 sokuji 最大的差异点）：

1. NLLB 蒸馏 + LocalAgreement（默认，--target-language 激活）：600M/1.3B 蒸馏 NLLB，源 token 增量喂入重跑翻译、两次一致的前缀才提交，未定尾部每轮重评估
2. AlignAtt4LLM（--translation-backend alignatt，vLLM sidecar，默认 Gemma-4-E4B 约 40GB VRAM）：decoder-only LLM 对 ASR 未提交的不稳定尾部「可起草、不可提交」；注意力门控决定 commit 时机；append-only 永不撤回；ASR 后续提交源词时 sidecar 从缓存草稿零成本放行目标 token——效果是翻译延迟跟踪（track）ASR 提交延迟，而不是叠加在其上。三档延迟模式中 low 档端到端约 2.5s（translation-alignatt.md）
3. Whisper 直译英文（--direct-english-translation）：不走翻译模块，STT 模型直接出英文

一个容易搞错的事实：README 把 SimulStreaming 当核心卖点，但 SimulStreaming 是查理大学 UFAL 的方法与论文（arXiv 2506.17077，作者 Macháček & Polák），Fuxa 是集成者不是发明者；他本人的一作论文是 AlignAtt4LLM（IWSLT 2026，与 Macháček 合著，arXiv 2606.03967，其中 En→Zh 结果混合）（arXiv）。WLK 对 ufal 两个上游是 vendor + 深度改写（非 fork），配套件 NLLW/Alignatt4LLM/Qwen3-ASR-causal 都是 Fuxa 自研——这是一个「产业界工程师 × 学术界策略内核」的组合体。

工程质量：20 个测试文件、CodeQL、多平台发布矩阵、文档与代码同步更新，42 个 PyPI 版本持续发布。代价是复杂度膨胀：16 个互斥 extras、功能按后端裁剪、部分组合需分 venv——自建时按需抽模块，别照单全收。

怎么跑起来（3090 视角）

• 安装：pip install whisperlivekit 单包即用（torch/faster-whisper 是默认依赖），Python 3.11-3.13；进阶组合用 uv extras：uv sync --extra cu129 --extra diarization-sortformer --extra translation（pyproject.toml）
• 3090 完全适配且宽裕：faster-whisper 官方基准机就是同为 Ampere 的 3070 Ti；large-v3 fp16 约 4.5-6GB + NLLB 600M 约 3GB + Sortformer 说话人分离，三件套在 24GB 内共存还有余量，必要时 ASR 降 int8（faster-whisper README）
• 模型全从 HuggingFace 自动下载，首拉合计约 6GB；成本全本地零 API 费用，无外部 key
• 许可陷阱：WLK 本体 Apache-2.0 可商用，但默认翻译模型 NLLB 权重是 CC-BY-NC-4.0 非商用——商用同传需换翻译模型（entai2965/nllb-ct2）
• 中文：官方路线是 FunASR 后端（SenseVoiceSmall，支持 zh/yue/en/ja 等，2026 年由中文社区 PR #385 推动合入）。两处已知摩擦：Whisper 用 zh 而 NLLB 用 zho_Hans，语言代码体系不同（issue #361）；中文标点恢复需自己挂 FunASR 的 ct-punc（issue #135）
• 部署：Docker/compose/Nginx/gunicorn 官方配置齐全，--api-token 鉴权，生产可直上

数据说话

• README 正文没有任何数字，量化结果在散点图和原始 JSON 里（作者自测，H100，每语言仅 6 分钟 LibriVox，无延迟指标入档）：AlignAtt 比 LocalAgreement 快 2-4 倍（RTF 0.10-0.14 vs 0.30-0.48），但 large-v3-turbo 档 SimulStreaming 的 WER 是 18.1，LocalAgreement 是 5.3，差 3.4 倍——这个精度代价正文没提；base/small 档则是 SS 全面占优（base：9.5 vs 24.6）（bench_scatter_en_aware.json）
• 归档基准（H100、英文）给出 first-word 延迟 0.09-0.47s、RTF 0.065-0.2；无翻译链路端到端延迟、无中文数据、无 3090 数据——3090 上要自己 wlk bench（archive/results.json）
• 口碑与坑：维护活跃度无可挑剔（作者亲自在 issue #283 做根因分析：SimulStreaming 后端长会话 VRAM 泄漏 + 词无限重复，0.2.18 修复，但后续仍有残留报告）；HN 全库检索 0 条讨论、无具名公司生产采用，11k stars 构成不可考（无刷星实锤，但 fork 比例正常而讨论量偏低）
• 与最直接竞品 WhisperLive 没有任何直接对比基准；引用其数字时注意全部是作者自测

横评：sokuji vs WhisperLiveKit

两者的能力矩阵严格互补（证据来自两仓库 README/docs 交叉比对，04-横评原料）：sokuji 覆盖应用层闭环（声音进声音出、会议软件接入、AEC 回声处理），但把自己封闭成产品、没有编程接口；WLK 覆盖管线层引擎（流式算法、增量翻译、开放协议），但输出到文字为止、不出声。要自研一个同传，两者恰好各覆盖一半链路。

先 study 哪一个

**结论：先 WhisperLiveKit，sokuji 作第二对象。**理由：

1. 自研同传最难的部分 WLK 已模块化。流式 ASR 策略与增量翻译是算法门槛所在，WLK 把它们做成了 35 行 Python 可嵌入的库，OpenAI SDK 直连使自研前端对接成本接近零；sokuji 的分段/降级状态机优秀但没有增量翻译，算法上限低一档
2. 3090 + 中文路径明确。faster-whisper + FunASR 后端组合有官方支持，注意语言代码体系与标点两处摩擦即可
3. 许可更友好。Apache-2.0 可商用（换掉 NLLB 权重后整条链路无障碍）；AGPL 的 sokuji 只能学不能抄

sokuji 的价值在 WLK 空缺的另一半：TTS 选型经验（137 个模型的实践）、虚拟麦克风路由、双向回声的 AEC 组合拳、VRAM ledger——这些在做「出声」阶段时回来按需取用。

建议的阅读顺序：local_agreement/online_asr.py（LA-2，百行入门）→ simul_whisper/（AlignAtt 注意力机制）→ docs/translation-alignatt.md + Alignatt4LLM 仓库（增量翻译协议，配 arXiv 2606.03967 论文）→ 再回 sokuji 的 asr_engine.py 与 audio-flow 文档（分段降级与 AEC 工程）。

参考阅读

• WhisperLiveKit README — 定位/quickstart/后端矩阵/extras
• docs/technical_integration.md — 库嵌入契约（三个调用）
• docs/translation-alignatt.md — AlignAtt4LLM 增量翻译协议，级联 LLM 同传的核心参考
• local_agreement/online_asr.py — LA-2 实现本体，最先读的源码
• arXiv 2506.17077 — SimulStreaming/AlignAtt 上游论文（UFAL）
• arXiv 2606.03967 — AlignAtt4LLM（作者一作，IWSLT 2026）
• kizuna-ai-lab/sokuji — 横评对象，应用层互补参考
• 深挖 · sokuji — 本站前篇