Sokuji 評測：雙語會議的即時雙向語音翻譯，雲端與離線兩條路
Real-time two-way speech translation for bilingual meetings — auto-detects the spoken language and translates both directions, cloud or fully offline on-device. Desktop (Windows · macOS · Linux) + browser extension (Chrome · Edge) for Zoom, Meet, Teams & any app.
秒懂
- 它是什麼？
- Sokuji 是 Kizuna AI Lab 以 TypeScript 開發的跨平台即時語音翻譯工具，桌面版與瀏覽器擴充功能共用同一套功能。它的核心取捨很清楚：要嘛把音訊送到雲端供應商，要嘛用 WASM 與 WebGPU 在本機跑完整條 ASR 到 TTS 的管線。
- 適合誰用？
- 如果你面對的是固定兩個語言的會議，而且需要雙向同時進行，Sokuji 的雙向模式與桌面版「任何有麥克風輸入的應用」定位值得實測；如果你的場景是單向的講座或字幕，或需要企業級合規稽核與正式支援合約，這個專案不適合，因為 README 只提供 GitHub Issues 與 DeepWiki 這兩個求助管道。採用前先確認三件事：你的會議語言對是否落在 Soniox 宣稱的 3,600+ 語言對範圍內、Local Inference 在你機器上的實際延遲是否可接受、以及 AGPL-3.0 對你打算散布的修改版本意味著什麼。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Sokuji 想解的是雙向會議，不是單向字幕
多數即時翻譯工具的預設情境是單向的：一個人講，其他人讀字幕。Sokuji 把目標放在另一種場景，README 的說法是「兩個人、兩種語言、一段對話」。差別在於方向。單向工具只需要一條 ASR 到翻譯到 TTS 的管線；雙向會議需要同時處理麥克風與系統音訊兩路輸入，判斷每一段語音屬於哪個語言，再翻成另一個語言送回去。
README 明確列出這個模式的四個特徵：自動語言偵測、雙向同時進行、可分享螢幕讓對方跟著讀的即時字幕，以及在 Zoom、Google Meet、Teams、Discord 或任何應用中運作。文件把雙向能力歸因於 Soniox 的 two-way mode，並引用其 60+ 語言與 3,600+ 語言對的數字。這裡要留意：這是 README 對供應商能力的轉述，不是這個專案自己的量測結果。
適合的對象因此相當具體：經常與固定語言的對象開會、而且雙方都需要聽到對方語言的人。反過來說，如果你只是要把一場英文演講轉成中文字幕，雙向模式帶來的複雜度對你沒有價值。
一條管線，兩種執行位置
README 用一張 Mermaid 流程圖交代架構：使用者說話，進入 Sokuji，然後在雲端與本機之間二選一，最後輸出翻譯後的語音到 Zoom、Teams、Meet、Discord 或任何應用。這個分岔點是整個專案最重要的設計決定，因為它同時決定了隱私、成本和硬體需求。
雲端路徑列出九個供應商：OpenAI、Google Gemini、Palabra.ai、Kizuna AI、Doubao AST 2.0、Soniox、Zoom AI、OpenAI Compatible，以及 Local Inference。其中 OpenAI Compatible 這一項值得注意，它意味著任何相容 OpenAI 介面的端點都能接上，包含自架服務。
本機路徑則是由 WASM 與 WebGPU 驅動的 ASR、翻譯、TTS 三段管線。README 的說法是「no API key required, no expensive GPU needed, fully offline, and completely private」。這裡的關鍵字是 WASM 與 WebGPU：前者讓模型能在瀏覽器環境執行，後者讓推論能用到使用者的 GPU。README 強調用的是現有的 CPU 與內建顯示晶片，而不是獨立顯卡。
值得注意的是，兩條路徑的輸出是同一件事：翻譯後的語音。也就是說切換供應商不需要改變使用流程，這對評估來說是好事，因為你可以先用雲端驗證品質，再決定是否為了隱私換到本機。
Local Inference 的模型數量與快取機制
離線模式的具體內容，README 給了三個數字：44 個 ASR 模型、75 個翻譯模型、137 個 TTS 模型。拆開來看，ASR 的 44 個包含 23 個離線模型、10 個串流模型、11 個 WebGPU 模型，涵蓋 Whisper、Cohere Transcribe、Voxtral、Granite Speech，語言覆蓋 99+。翻譯的 75 個是 69 個 Opus-MT 語言對加上 6 個多語言 LLM，後者包含 Qwen 2.5、Qwen 3、Qwen 3.5、Hunyuan-MT 1.5、TranslateGemma，走 WebGPU。TTS 的 137 個橫跨 53 種語言，引擎有 Piper、Piper-Plus、Coqui、Mimic3、Matcha、MMS、VITS、Supertonic。
這些數字的意義在於組合方式。69 個 Opus-MT 語言對是離散配對，不是任意語言互翻；如果你需要的語言對不在其中，就得改用那 6 個多語言 LLM，而它們依賴 WebGPU。README 提到「One-click model download with IndexedDB caching」，也就是模型下載後存在 IndexedDB。這對桌面版與擴充功能都成立，但快取是瀏覽器儲存層，不是獨立的模型目錄，清理瀏覽器資料或擴充功能重裝時要預期需要重新下載。
串流與離線 ASR 的區分也值得注意。即時會議需要的是串流模型，離線模型適合先錄後轉。README 沒有說明兩者在延遲上的差異，這一項必須自己量。
安裝路徑：從 Releases 到 npm run electron:dev
桌面版從 Releases 頁面下載，README 列出的檔名格式很明確。Windows 是 Sokuji-x.y.z.Setup.exe；macOS 依架構分 Sokuji-x.y.z-arm64.pkg 與 Sokuji-x.y.z-x64.pkg；Linux 是 sokuji_x.y.z_amd64.deb 與 sokuji_x.y.z_arm64.deb，對應 Debian 與 Ubuntu。這裡沒有列出 AppImage 或 rpm，所以 Fedora、RHEL 這類發行版的使用者得自己處理 deb 轉換，或走原始碼建置。
瀏覽器擴充功能走商店安裝，README 提供 Chrome Web Store 與 Microsoft Edge Add-ons 兩個連結。若要在開發者模式下載入，步驟是從 Releases 下載 sokuji-extension.zip、解壓縮、開啟 chrome://extensions/、啟用 Developer mode、點 Load unpacked 並選擇解壓後的資料夾。
從原始碼建置的指令是：
git clone https://github.com/kizuna-ai-lab/sokuji.git cd sokuji && npm install npm run electron:dev npm run electron:build
前兩行取得原始碼與相依套件，electron:dev 是開發模式，electron:build 是正式建置。README 沒有說明 Node.js 版本需求，也沒有列出建置產物的輸出位置，這兩點在實際動工前要先確認。
桌面版與擴充功能的功能對照表中，README 聲明兩者「All features identical」。差異在使用範圍：桌面版適用任何有麥克風輸入的應用，包含遊戲與 OBS；擴充功能則限於網頁版會議平台，列出的有 Google Meet、Teams、Zoom、Yandex Telemost、Discord、Slack、Gather.town、Whereby、Jitsi Meet。如果你的會議工具是原生桌面程式，擴充功能幫不上忙。
離線模式不是萬靈丹：模型選擇與硬體現實
Local Inference 的行銷語言很吸引人，但限制寫在細節裡。翻譯模型那 75 個之中，69 個是固定的 Opus-MT 語言對。這代表離線翻譯的語言覆蓋是列舉式的，不是任意組合。README 說翻譯覆蓋 55+ 語言，但沒有說明這 55+ 是怎麼從 69 個語言對加上 6 個 LLM 推導出來的。如果你的語言對不在 Opus-MT 清單裡，就落到那 6 個多語言 LLM 上，而它們需要 WebGPU。
WebGPU 的可用性是第二個變數。README 說「runs efficiently on any modern browser」，但沒有列出支援的瀏覽器版本或作業系統組合。桌面版底層是 Electron，其 WebGPU 支援取決於內嵌的 Chromium 版本，這與你在 Chrome 或 Edge 裡跑擴充功能的狀況不一定相同。
第三個是「no expensive GPU needed」的邊界。內建顯示晶片能跑，但 README 沒有給出任何延遲或吞吐數字。即時會議對延遲的容忍度很低，而模型大小、量化方式、語言對都會影響結果。這不是專案的缺陷，而是文件沒有提供可判斷的依據，所以只能自己測。
最後是模型下載。44 加 75 加 137 個模型的目錄不代表你會全部下載，但如果你在受限網路環境或儲存空間有限的機器上工作，一鍵下載的便利性會變成磁碟佔用的問題，而 README 沒有給出各模型的檔案大小。
與其他做法的差異：Soniox 雙向模式對上通用語音 API
要理解 Sokuji 的位置，得看它把雙向能力交給誰。README 明確寫「Powered by Soniox two-way mode」，也就是說雲端路徑下的自動語言偵測與雙向翻譯，核心是 Soniox 的能力，Sokuji 負責的是擷取麥克風與系統音訊、管理供應商切換、把結果送到目標應用，以及提供桌面與瀏覽器兩種外殼。
另一種做法是直接用 OpenAI 的即時語音 API 或 Google Gemini 自行組裝。差異在方向處理：通用語音 API 通常要你指定來源語言，或至少要在每次切換語言時調整參數。Sokuji 的價值在於把「誰在說哪個語言」這件事自動化，並且同時處理兩路輸入。如果你只需要單一方向的轉錄加翻譯，自己接 API 可能更簡單，也少一層 Electron 或擴充功能的封裝。
第三種做法是自架 Whisper 加翻譯模型。這條路完全在你自己手上，語言對不受限，但你要自己處理串流、延遲補償、TTS 與音訊路由。Sokuji 的 Local Inference 某種程度上就是這個方向的封裝版本，只是把模型清單固定下來，換取不用自己調管線。
三條路的取捨因此是：Soniox 路線換取雙向自動化但依賴外部服務；通用 API 路線換取簡單但失去方向自動判斷；自架路線換取控制權但付出整合成本。
AGPL-3.0 與維護節奏的實際含意
授權是 AGPL-3.0。對內部使用的團隊來說，這通常不構成問題，因為你沒有散布軟體。但如果你打算把 Sokuji 包進自己的產品、或修改後提供給外部使用者，AGPL 的網路服務條款會要求你提供對應的原始碼。這是採用前必須和法務確認的事，本文不提供法律意見。
維護節奏可以從版本號觀察。README 列出的近期版本是 v0.40.3（2026-09-07）、v0.40.2（2026-09-05）、v0.40.1（2026-09-05），最後推送時間是 2026-09-10。三天內三個修補版本，說明專案處於活躍開發階段，但同時也意味著 API 或設定介面可能還在變動。README 沒有提供穩定性承諾或長期支援版本。
求助管道方面，README 只給了 GitHub Issues 與 DeepWiki 兩個入口，沒有商業支援、沒有 SLA、沒有社群論壇。對需要正式支援合約的組織來說，這是明確的缺口。
升級成本則取決於你走哪條路。用官方 Releases 的安裝檔，升級就是換一個檔案。從原始碼建置的話，每次升級都要重新 npm install 與 electron:build，而 Electron 專案的相依套件更新經常帶來建置環境的調整。離線模式還多一層：模型快取在 IndexedDB，升級後是否需要重新下載，README 沒有說明。
編輯結論
如果你面對的是固定兩個語言的會議，而且需要雙向同時進行，Sokuji 的雙向模式與桌面版「任何有麥克風輸入的應用」定位值得實測；如果你的場景是單向的講座或字幕，或需要企業級合規稽核與正式支援合約，這個專案不適合，因為 README 只提供 GitHub Issues 與 DeepWiki 這兩個求助管道。採用前先確認三件事：你的會議語言對是否落在 Soniox 宣稱的 3,600+ 語言對範圍內、Local Inference 在你機器上的實際延遲是否可接受、以及 AGPL-3.0 對你打算散布的修改版本意味著什麼。
社群筆記