刊 DailyNews 科技 / AI 每日文摘2026 年 10 月 30 日

每日文摘

深挖 · sokuji：开源实时语音同传，工程答案比算法更值得抄

sokuji（日语「即時」）是一个开源的实时双向语音同传应用：两个人各说一种语言，它边听边译边合成对方的语言，还能伪装成虚拟麦克风直接接入 Zoom/Meet/Teams。它最近连日发版、热度攀升，但真正值得深挖的原因是：它没有用什么惊人的同传算法，却把延迟、分段、回声、显存这几类工程问题解得非常系统——对想自己做一个同传功能的人来说，这恰好是最值得抄的部分。

是什么

先回答最直接的问题：是的，sokuji 的重点就是同声传译。官方定位是「Real-time two-way speech translation for bilingual meetings」——双语会议实时双向语音翻译。它不是转写工具，也不是翻译 API 库，而是一个完整的端到端同传产品：

核心机制：它做同传的要点在哪

朴素做法是「录一段 → 整句 Whisper → 整句翻译 → 整段 TTS」，延迟以句为单位，而且句首经常被吃掉。sokuji 的源码（sidecar/sokuji_sidecar/）展示了一套很有参考价值的解法，六个要点：

① VAD 分段权在客户端，与 ASR 解耦。 silero VAD 跑在客户端 worker 里，由它决定语音从哪开始、到哪结束，向 ASR 引擎只发 start/end/cancel 三种边缘事件；ASR 引擎本身不做服务端 VAD（asr_engine.py）。切分逻辑单点 owned，上下游职责干净。

② 0.7 秒预滚，补 VAD 迟确认。 silero 在真实语音起始后 300-600ms 才会确认「有人开始说话了」——如果直接从 VAD 触发那一刻开始喂音频，句首就没了。sokuji 的流式 ASR 在门控模式下每次开始说话都先重放 0.7s 预滚音频，源码注释里明说了这个原因（asr_engine.py）。这是自己动手做同传几乎必踩的第一个坑。

③ 流式 ASR 双模式 + 运行时降级自愈。 always_stream 模式维持一条长流持续喂音频（端点归客户端管，靠「Pause-cut」结束流来 flush 滞留尾部再重开）；per_utterance 门控模式只在检测到说话时才喂音。更有意思的是自适应：队列滞后超过 3 秒就自动从长流降到门控模式，说完一段后如果实时率小于 1（处理比说话快）再升回去（asr_engine.py）。机器扛不住时优雅变慢，而不是崩掉。

④ 全链路 partial 流水线——但翻译本身是整句全量调用。 ASR 持续吐 partial 增量 → 翻译引擎发 translate_partial → TTS 按 chunk 流式合成播放；采集端 20ms 一片，播放端累积到 100ms 才开播防抖（audio-flow-analysis.md）。但注意：翻译阶段没有任何增量重译算法——每次翻译都是独立的全量整句调用，靠模型常驻显存换吞吐（translate_engine.py）。它的取舍是「用分段粒度控制延迟」，而不是上复杂的增量翻译算法。

⑤ 双向同传特有的回声组合拳。 译出来的声音会被自己的麦克风再次采到（「自己听到自己的翻译」），这是双向场景的硬问题。sokuji 的解法是一套组合：Chrome 系统级 AEC（echoCancellationType: 'system'）+ suppressLocalAudioPlayback + 一个 gain=0 的 dummyGain 把回环静音 + passthrough 通道刻意加延迟辅助消除（audio-flow-analysis.md）。

⑥ 跨三引擎的显存预算（VRAM ledger）。 ASR、翻译、TTS 三个模型同时驻留一张卡，翻译引擎初始化前会通过 ledger 把 ASR/TTS 模型的尺寸计入预算、必要时释放旧模型，配合 catalog（模型目录卡）/planner（纯排序）/loader（有副作用）三层分离做模型选择与硬件回退（translate_engine.py、CONTEXT.md）。

架构层面还有一个值得注意的决策：本地推理有两条对等且刻意不合并的路线——浏览器路线用 sherpa-onnx WASM + Transformers.js/WebGPU（15 个 worker）；桌面路线用 Python sidecar 加载在同一份 ggml 0.22 之上构建的三个 C++ 引擎（transcribe.cpp/llama.cpp/audio.cpp），统一 sk_* C ABI，Linux/Windows 走 Vulkan、mac 走 Metal，无 CUDA 依赖（CLAUDE.md、CONTEXT.md）。文档明令「不要在两者之间引入统一层」——浏览器和原生的约束差异太大，强行抽象只会两头受限。

一句话总结它的特别之处：核心竞争力不在任何单点算法（翻译阶段反而是最朴素的做法），而在分段、延迟、回声、显存四类工程问题的系统性解法。

怎么跑起来

数据说话

值不值得跟：想自己实现同传，从这里学什么

结合「自己做一个同传功能」这个目标，sokuji 的价值可以分三层：

但要清楚它的边界：sokuji 没有解决「真增量翻译」的问题（整句全量调用，延迟下限受句长制约）。如果目标是更低延迟的同传，GitHub 上有更对口的参考：

参考阅读