Sophon-Realtime v1 開放語音模型：Tag、Flash 與一張 80GB GPU 的取捨怎麼看？

Sophon-Realtime 開放了一套能邊聽邊說的語音模型，目標是讓對話不用等人整段講完，再把文字交給另一個系統配音。

這種全雙工互動也要處理打斷。當使用者改口或插話，代理必須停下原本回答，並且記住對方實際聽到哪裡，後續回覆才不會接錯內容。

Adventists AI 的 v1 家族提供 Tag、Flash 與研究預覽 E2E 三種構成，前兩者共用同一個理解與回答核心，主要差在聲音如何產生。

官方把 Tag 定位為表情較豐富的選擇，Flash 則偏向速度與同時服務人數。這個取捨會影響語音角色、客服或車內應用的部署規畫。

不過，開放權重不代表一般筆電就能順暢執行。官方的一張顯示卡部署範例需要八十 GB 顯示記憶體，延遲與評測也有指定測試條件。

想把它接進既有語音代理，先看清三種構成的差別，再談協定與硬體。

Sophon-Realtime 如何做到邊聽邊說與中途打斷？

系統在使用者停頓時判斷是否輪到自己回答，必要時先準備草稿，若對方繼續說話就丟棄尚未播放的內容。這與先錄完整段聲音、轉成文字後才開始回答的流程不同。

官方模型家族說明 把持續聆聽、決定說話時機與產生回答交給同一個三百二十億參數核心。它不只處理說了什麼，也要判斷停頓是否真的代表交出話輪。

例如使用者說到一半停下思考，若代理立刻搶答，對話就容易中斷。因此，系統可能先在內部準備回覆，等確認對方已停下，才開始播放聲音。

文字逐字稿與音訊可能不是同一個進度

實際應用通常同時顯示字幕、播放語音，還可能保存對話紀錄。如果字幕一次出現完整答案，但聲音只播到一半就被打斷，後續系統便容易把未聽見的內容也當成共同背景。

官方 gateway 的輸出逐字稿會配合播放推進，這讓應用有機會記錄真正呈現的內容。不過，開發者仍需確認畫面、音訊與後端歷史如何同步，不能只收到事件便假設使用者已經聽完。

聲音標籤也會出現在文字紀錄，例如笑聲或咳嗽的標示。要顯示給使用者時，可以依產品設計決定如何呈現，但不應把它們誤認為模型準備逐字念出的回答。

打斷之後，還要記住真正播放過的內容

全雙工是雙方能在同一段時間傳送聲音，但讓體驗自然，還需要處理中途插話。使用者改口時，代理應停止舊回答，後續對話也不能假裝對方已經聽完尚未播出的句子。

官方設計會保留實際聽到的部分，再繼續後續回覆。這讓「先不要那個方案」之類的改口有機會接回正確位置，而不是在內部完整答案與使用者聽到的片段之間產生落差。

這類能力不能只靠一次示範確認。測試時應刻意安排停頓、短促回應與真正打斷，分別觀察代理是否搶話、是否停止，以及後續是否沿用正確內容。

若想先了解全雙工和一般輪流對話的差別，可搭配其他研究的介紹，但不同模型的語言與評測不能直接互換。

延伸閱讀：Shizuku-Duplex 是什麼？日語全雙工語音 AI 的官方評測怎麼看

同一套理解核心可以配不同發聲方式，這也是三種構成的差別。

Tag、Flash 與 E2E 該怎麼選？

Tag 強調笑聲與嘆氣等表情，Flash 使用較輕的發聲模型降低延遲，而 E2E 仍列為研究預覽。選擇時先看需要表演感，還是需要在同樣硬體上接待更多對話。

Tag 的回答文字可以帶有聲音標籤，再交給表情較豐富的語音模型演出。像笑聲不是把標籤字面念出來，而是轉成對應聲音，這讓文字與聲音之間有明確的控制方式。

Flash 共用相同的理解核心，主要更換發聲階段。因此，兩者不是從聽懂問題到推理都完全不同的兩套模型，不能把聲音速度差異直接解釋成所有理解能力都有同樣落差。

不要把不同構成的最佳數字合在一起

如果任務重視角色笑聲與表情，Tag 的取捨較符合官方定位。如果主要是大量短對話、希望等待更短，Flash 則值得先比較，但仍要用自己的語音確認品質。

E2E 把發聲元件放進同一個模型，並不因此自動最省硬體。官方目前列為研究預覽，所需 GPU 與建議同時人數也與前兩者不同，不能只憑端到端名稱選型。

因此，若文章或簡報同時提到最快首音與最好表情分數，應確認來自同一構成。Flash 的速度不能配上 Tag 的表情成績，變成不存在的一種最佳設定。

選好聲音與速度的取捨後，還要確認硬體是否能支撐預期人數。

一張 80GB GPU 能服務多少人，數字有哪些條件？

官方建議 Tag 與 Flash 都使用一張八十 GB GPU，但兩者的人數與首音延遲不同，不能把最佳數字任意拼在一起。尤其單人測量和多人同時使用，是不同的負載條件。

Flash 官方模型卡 的表格，使用一張 H100 80GB，理解核心採 FP8，並由使用者語音量到第一段輸出聲音。這不是所有裝置連上網路後的完整通話延遲。

同時在線變多，等待也會增加

官方單路串流的首音中位數為零點三一秒，四十路時為零點五八秒。六十四路時，中位數增加到零點八四秒，也出現排隊造成的停頓，因此卡片建議約四十路以內。

這些數字的請求是在指定時間內陸續抵達，不能改寫成四十人同一瞬間同時發話，都固定得到零點三一秒回覆。實際對話長短、插話與工具等待，也會改變服務負載。

部署時應同時記錄首音中位數、較慢請求與播放停頓。平均速度看起來不錯，但少數人反覆聽到斷句或長停頓，仍可能讓客服體驗失敗。

開放權重仍有運行環境成本

官方程式以 Linux、CUDA、Python 與 vLLM-Omni 等環境提供部署方式，並非下載一個檔案就能在任何筆電執行。權重檔大小、GPU 記憶體與運行時使用量也不是同一個數字。

例如權重下載約四十多 GB，不能推定只要同樣容量的顯示記憶體就夠。模型執行還需要額外空間，若搭配語音轉文字元件，也會增加運行資源。

模型卡還提醒首次啟動需編譯，等待時間比後續啟動長。這表示服務維運要安排準備與就緒檢查，不能在使用者第一次來電時才把初始化等待算成對話速度。

硬體有了估算起點後，評測成績還要拆開看測量的能力。

語音、語氣與工具評測能說明什麼？

聽懂內容、表達語氣與正確呼叫工具是不同能力，官方的單項高分無法代替完整應用驗收。例如說得自然但查錯資料，與資料正確卻無法及時停下，都可能造成不同問題。

官方列出 VoiceBench 八十二點八分，以及 Big Bench Audio 百分之八十一點八。前者包含由模型評分的語音回答項目，後者使用一千道口說推理題，不能當成對所有通話的人工滿意度。

表情分數衡量的是特定聲音表現

家族比較中的 NVV-SuperBench，以不同聲音類別評估表情表現，中文 Tag 為零點八六，Flash 為零點七七。這類分數有指定樣本與評判模型，並非一般人對整段對話自然度的總評。

同樣地，英文與中文成績不同，不能拿其中一種語言代表台灣所有口音、背景噪音或中英混說。應使用已取得使用權的自製錄音，另外檢查實際需求。

百分之百有回應，不等於工具全部成功

Full-Duplex-Bench v3 的工具工作，官方報告 Pass@1 為百分之四十八，並註明取多次測量中最好的一次。它另列百分之百回應率，這只表示有回應，不能替代任務是否完成。

因此，不宜把回應率寫成百分之百工具成功。比較對手時，也要保留評測條件與重複測量選取方式，本文並未獨立重現這些分數。

Live gateway 如何接既有語音代理？

官方 Live gateway 文件 提供 GPT-Live 與 OpenAI Realtime 相容入口，讓既有客戶端有機會改用自架模型。相容協定仍要依應用實際使用的事件與音訊格式驗收。

需要查詢或執行動作時，Sophon 可以把工作交給開發者的後端，再用自己的聲音說明結果。實際資料存取、工具權限與交易邏輯仍由後端負責，不會因為接入語音模型而自動完成。

目前文件列出測過的 LiveKit Agents 與 Pipecat 版本，因此舊客戶端或其他版本仍須重新驗收。像音訊編碼、工具事件與中途打斷後截斷紀錄，都可能影響能否順利接續，而不是只改網址就能保證完整體驗。

若系統需要輸入逐字稿，gateway 另外載入小型語音辨識模型，約再占兩 GB GPU 記憶體。這個額外元件負責顯示或傳遞文字，不應和語音核心的理解能力或整體記憶體需求混成同一項。

官方也提醒有時可能過度委派，或先說要查卻沒有真正發出委派。因此，測試不能只聽見一句「讓我查一下」就判定工具已執行，還要檢查後端事件與回傳結果。

有些語音代理在文字階段設置檢查點，適合與這種全雙工架構一起比較實際流程，但不應把兩者當成相同產品。

延伸閱讀：Rime Prism 語音模型發表：先檢查文字再說話，企業導入要看哪些條件？

使用者能否順利插話、工具回覆能否接上，比單看第一段聲音的速度更接近實際體驗。

Sophon-Realtime 常見問題

首次連線沒有回應，就表示模型不能用嗎？

官方列出的已知限制包括引擎剛啟動後，第一個 session 可能不回應，建議先暖機。測試時應把初始化問題與一般對話失敗分開記錄，也要確認正式服務不會把未準備好的實例交給使用者。

免費開放代表沒有使用條件嗎？

程式與權重標示 Apache 2.0，但仍需保留適用授權與第三方元件說明。這也不代表任意聲音、人物形象或輸入錄音的權利都自動取得。

Flash 比較快，是否代表每項能力都比 Tag 好？

不是。兩者共用理解核心，主要差在發聲階段，官方表情測試仍有 Tag 較高的項目，應依聲音品質與負載取捨。

可以把官方展示影片當成效能保證嗎？

不宜。展示能觀察互動方式，穩定速度與同時人數仍需在實際硬體、網路及工具條件下量測，不能只看一次順暢對話。

一定要使用外部雲端大型模型嗎？

語音核心可自架，但若應用選擇把部分工作委派到外部模型或工具，仍會產生相應資料流與費用，應依自己的架構分別記錄。

先驗收一段可打斷對話，再擴大服務人數

已有 GPU 與語音系統開發能力的團隊，較適合先做有限範圍測試，單純需要隨開即用服務的人則要另算維運成本。

先用自製錄音測試停頓、改口與工具回覆，記錄使用者實際聽到的內容，確認中途打斷後能接回正確話題。這一段通過後，再增加同時在線人數，觀察較慢請求與播放停頓。

測試工具時，可先使用只回傳固定資料的模擬後端，讓團隊容易核對是否真的發出請求。等這段通過，再接入有正式權限管理的服務，避免把模型選錯工具與外部系統故障混在一起。

同時保留沒有委派的題目，確認一般閒聊不會每次都多叫一個外部服務。這樣才能衡量語音核心在該回答與該等待之間，是否做出符合應用需求的選擇。

最後把硬體、後端與可能的外部服務一起算入成本，才有基礎決定選 Tag、Flash，或繼續保留原本語音系統。

資料來源

• Sophon-Realtime v1 官方模型家族與評測
• Sophon-Realtime-32B-Flash 官方模型卡
• 官方 Live gateway 說明
• ModelScope 官方發布與示範影片