互動／背景模型拆分

資料來源#

• A frontend-backend architecture for tool calls in full-duplex speech models
• Build more natural voice experiences with GPT‑Live‑1 in the API
• How we built a realtime system for responsive voice AI in six months
• Inkling: Our Open-Weights Model
• Interaction Models: A Scalable Approach to Human-AI Collaboration
• Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking
• NemotronLabs VoiceChat: An Open Full-duplex Speech-to-Speech Model with Tool Calling Capabilities

摘要#

Interaction Models 的架構由兩個協作模型構成：

• 具時間感知能力的互動模型，維持即時在線狀態，在持續循環中感知並回應（參見 Time-Aligned Micro-Turns）；
• 非同步背景模型，處理持續推理、工具使用及較長期的工作。

帶來的好處是：使用者同時獲得即時回應與深入處理——「以非思考模型的回應延遲，取得推理模型的規劃、工具使用與代理式工作流程。」

委派如何運作#

• 當任務需要無法立即完成的深入推理時，互動模型會委派給非同步執行的背景模型。
• 交接內容是豐富的情境套件——不是單獨的查詢，而是完整對話。
• 互動模型在整個過程中持續在線——回答後續問題、接收新輸入、延續對話脈絡。
• 背景模型產生結果時，結果會串流傳回；互動模型會在適合使用者當下活動的時機，將更新穿插到對話中，而不是突然切換情境。

兩端都具備智慧#

這不是「前端遲鈍、後端聰明」的設計。互動模型本身在「互動與智慧基準測試上都有競爭力」——參見 Interactivity Benchmarks（例如，即使沒有背景代理，TML-Interaction-Small 在 Audio MultiChallenge APR 上也勝過所有非思考基準模型；標記 * 的基準測試會在推理／工具任務中使用背景代理）。

與其他多模型模式的關係#

這是多模型編排中延遲與深度的取捨軸，與以下模式不同：

• Client-Side Agent Optimization 中的依角色選擇模型（在代理程式圖中，依角色分配便宜或昂貴的模型）——該模式的拆分由成本驅動且固定；此處則由延遲驅動，並隨每一輪動態變化；
• 三代理程式／在全新情境中審查模式（Deep Modules for Agents、Agent Harness Engineering）——該模式為了情境隔離而拆分；此處拆分則是為了時間考量（保持回應能力或深入思考）。

背景端有了名字：Inkling（2026 年 7 月）#

拆分初次提出時，背景模型還只是未具名的能力。Inkling 填補了這個位置：TML 表示，「Inkling 設計的一個主要目標，是在互動模型系統中擔任背景推理模型」——因此這個 975B 開放權重基礎模型採原生多模態方式訓練（無編碼器 dMel 音訊與 hMLP 視覺，輸入堆疊與互動模型相同），而非加上轉接器的文字推理模型。兩者的對稱性更進一步：Inkling-Small 是 276B／12B 的 MoE，與 TML-Interaction-Small 的確切規模相同，暗示拆分兩端有共同的系譜。現在，架構的兩端都成了公開成果，不再是一個模型加上一個承諾。

拆分正式投入生產：GPT-Live（2026 年 7 月）#

OpenAI 的 GPT-Live 是獨立發展出相同雙模型架構，並部署到 ChatGPT 規模的成果——全雙工語音模型維持對話，較深入的推理與工具使用則非同步委派給 GPT-5.5 等前沿模型。OpenAI 對此效益的說法呼應了 TML：「實際上將『交談』與更深入的『思考』分開。」TML 的研究預覽推出兩個月後，第二家實驗室也已讓拆分的兩端都成為正式環境系統。

正式環境的說明補上了研究論述未提及的工程細節——將委派迴圈當作延遲預算處理（case-study，第一方資料）：

• 豐富情境套件成為預先填入內容的常駐工作階段。 語音工作階段開始時，應用程式伺服器會先建立前沿模型的推論工作階段，並以初始對話情境預填，讓提示在首次要求委派前就完成處理——也就是提前支付 TML「委派完整對話」交接中的預填成本。
• 工作階段黏著性與提示快取讓對話期間的後續委派成本保持低廉，即使工作者故障也能以低成本復原。
• 所有能縮短取得實用結果時間的環節都經過調校：推理力度、輸出限制、工具結構描述，以及模型與工具之間的往返次數。
• 互動端可能停頓，但不會隱身。 語音模型「可以在前沿模型推理或使用工具時，短暫維持對話進行，但無法掩蓋任意長的延遲」——這說明拆分前端能吸收多少延遲有實證上限。

服務端細節見 Live-Path Minimalism。

第三種推導，也是首次公開的委派訊號（NVIDIA，2026 年 9 月）#

Hu et al.（NVIDIA，arXiv 2609.19334，2026-09-16，empirical）從第三種起點第三度建立相同拆分——其源自串流 ASR 系譜，而非規模擴張策略或服務架構改寫——他們之所以這麼做，是因為前兩者都沒說明交接如何運作。他們在調查中寫下的這句話，正是本文引用這項來源的原因：

「然而，[28、29、30] 中的委派訊號如何設計，以及背景模型如何與雙工前端互動，仍不清楚。」

三個括號中的參考文獻分別是 Thinking Machines 的互動模型、Qwen-audio-agent，以及 GPT-Live。直到現在，本文的機制說明都是從兩份描述委派效果卻不透露其格式的資料拼湊而成。NVIDIA 公開了格式。

系統。 互動端是雙工語音轉文字模型：一個 600M 參數的 Parakeet 串流語音編碼器，輸入 NVIDIA Nemotron-Nano-9B-v2-Base 主幹；串流 ASR 頭與代理文字頭共用該主幹，並在單次解碼中輸出。代理文字會傳給獨立的串流 TTS（VoiceChat-TTS）轉成音訊。背景端是現成的LangGraph ReAct 代理——代理節點內有一個遵循指令的 LLM、工具節點，以及在該輪沒有更多呼叫時才結束的條件邊。

完整的委派訊號。 代理文字通道中的四個特殊 token，除此之外別無其他：

• 當前端判斷查詢需要工具時，<tc bos> 會取代一般的 <agent bos>，時間大約在使用者回合結束後 320 ms。
• 接著是一句簡短的口語填充語（約 1 秒，例如 「請稍等。」），然後是 <tc eos>。
• <tc eos> 觸發派送：串流 ASR 逐字稿以 <user eos> 標示結尾，並作為訊息傳給後端圖。
• 後端的自然語言答案會以 <pf bos>／<pf eos> 包住，預填至代理文字通道，並訓練前端從 <agent bos> 開始原樣重現。預填片段會從損失計算中遮罩掉，但重現部分不會。呼叫期間，代理輸出會以 pad token 抑制。

訓練讓 token 可供學習，而不是依靠規則：SFT 混合資料包含約 8.5k 小時、由文字對話合成的多輪工具呼叫對話（由 Nemotron 3 Nano、Gemma-4-31B-IT 與 Qwen3.5-397B-A17B 生成，經 LLM 評審篩選、TTS 轉換，並以 WER／CER 篩選），也包含 When2Call 風格的變體，涵蓋何時不該呼叫以及何時應該追問。

與上述規格的三項差異——值得並列檢視，因為本文的機制描述來自已推出系統的實驗室，而這次是公開了系統細節的實驗室：

	上述的 TML／GPT-Live 描述	NVIDIA 的實作與測量
跨越界線的內容	豐富的情境套件——完整對話	僅當前回合的 ASR 逐字稿；多輪狀態由後端以執行緒索引的 LangGraph 檢查點保存
呼叫期間的前端	「全程持續在線——回答後續問題、接收新輸入、延續對話脈絡」	沉默：「工具呼叫期間前端保持沉默」，約 1 秒的等待提示語後，以 pad token 抑制代理輸出
結果整合方式	串流傳回，並在適合使用者當下活動的時機穿插	預填後逐字重複；沒有穿插更新的政策

中間那一列是實質上的矛盾。GPT-Live 早已承認此限制——語音模型「可以在前沿模型推理或使用工具時，短暫維持對話進行，但無法掩蓋任意長的延遲」。NVIDIA 系統將這個限制推到極限：一句等待提示語，然後便一片安靜。不過，前端確實全程保持聆聽（仍會接收使用者音訊並產生 ASR；在 FDB3 中，呼叫觸發前也會在不流暢處的停頓中發出應答），因此一邊說話一邊聽依然成立，一邊說話一邊思考則不成立。證據權重方面：TML 的持續在線說法屬於 vendor-claim，OpenAI 的說法屬於第一方 case-study，兩者都未公布測量結果；NVIDIA 的說法屬於 empirical，但只是作者以盡量減少前端改動為目標的一種實作。審慎的解讀是：委派期間持續在線的主張被宣稱兩次，實際展示零次，而非證明此事不可能。

拆分的第三種理由，而且不是延遲。 TML 主張以低延遲達成深度處理；OpenAI 主張即時路徑不能停頓。NVIDIA 主張的是容量經濟：

「音訊原生建模帶來根本的容量取捨：音訊 token 會占用參數與情境預算，而純文字 LLM 可以把這些資源用於事實知識、指令遵循與工具呼叫能力。相較之下，採委派式的後端代理更具模組化，且幾乎不消耗前端語音模型的建模容量。」

這是在討論參數該放在哪裡；即使委派不造成任何延遲，這個論點依然成立。動機來自其他地方測得的能力落差：τ-Voice 發現，在乾淨條件下，領先的商用雙工語音模型只能完成 31–51% 的有根據客戶服務任務；相同任務的文字版本中，GPT-5 則達到 85%。

拆分呈現為能力介面，而不只是收斂出的架構。 同一組前端權重搭配三種不同後端，在互動端完全沒有重新訓練的情況下，代理能力數值便隨之改變：

• BFCL-audio AST 平均分數：71.7（Qwen2.5-7B）→ 73.0（Qwen3-30B-A3B）→ 74.6（Qwen3-30B-A3B 搭配外部而非內部 ASR 逐字稿；增益集中在 Parallel-Multiple，55.1 → 61.1）。
• FDB3 回應品質：54.0（30B）→ 67.0（Qwen3-235B-A22B）；Pass@1 為 44.0 → 48.0。
• EVA-Bench EVA-A：32.4（30B）→ 46.6（235B），任務完成率 40.4 → 57.3——從低於 Qwen3-Omni-30B-A3B-Instruct，提升至與 Gemini 3.1 Flash Lite 相當。

這是本文資料集中的首項證據，顯示拆分可以成為無須重新訓練互動模型即可調整的槓桿——這既支持它是架構設計而非過渡支架，也恰好說明精心設計的過渡支架會是什麼樣子。論文本身將根本問題視為未解：「雙工語音模型應直接內化工具呼叫能力，還是將這些能力委派給後端文字代理」，並以 DuplexSLA（arXiv 2605.20755）為內化方案的例子；它將工具呼叫放在 Moshi 風格雙工模型的專用通道中。

委派 token 讓原本應維持不變的前端付出什麼代價。 此處的「最小修改」精確來說，就是在預測目標中新增一個控制 token，不改動架構；NVIDIA 也進行了其他人都未做過的消融測試，將此模型與訓練方式相同、但沒有工具呼叫資料的前端相比。即時路徑成本接近零，對話品質成本則不然；數據與注意事項見 Live-Path Minimalism。

開源狀態。 沒有宣布釋出前端權重或訓練程式碼，只有 Hugging Face Spaces 示範。其他所有元件都已公開：Parakeet、Nemotron-Nano-9B-v2-Base、VoiceChat-TTS、LangGraph、Triton、Chatterbox，以及三個開放權重 Qwen 檢查點。因此，任何人都能重現此拆分的架構形式，但無法重現經訓練而得的委派行為。

拆分兩端各自定價：API 中的 GPT-Live-1（2026 年 9 月）#

以上內容都將拆分視為架構。OpenAI 的 API 發表（2026-09-10，vendor-claim）則將它變成商業界線，提供了不同類型的證據，說明這種架構形式有多持久：內部接縫可以透過重構消除，但有價目表、兩家供應商都在其上的接縫，就比較難抹去。

兩端分開計費，且計價單位不同。 GPT-Live-1 的「前端語音層」定價為每分鐘 0.05 美元。價格不含後端：「搭配適合你產品的後端模型與代理 harness」，再由提供者按 token 計費。互動端按分鐘、背景端按 token 計價，正是本文論點的定價形式——一端購買的是在線時間，另一端購買的是完成的工作。成本影響見 Cost-per-Task Over Cost-per-Token 與 Live-Path Minimalism。

後端明確可替換，也可使用外部供應商。 OpenAI 列出三個自家選項——適用於複雜推理的 GPT-6 Astra、適用於排程與訂單更新等大量任務的 Luna，以及工具呼叫基準測試中使用的 Terra——接著直言：「後端文字模型可以是 GPT-6 Astra，也可以是第三方模型。」理由是依任務搭配：「這種彈性讓開發者可以依每項任務，調整推理深度、速度與成本。」這是上文 NVIDIA 章節所述介面主張的再度宣稱：第二家實驗室在正式產品上提出此說法，而非在測試台上展示；互動端的設計本就不依賴特定後端，OpenAI 甚至願意放棄後端營收來表明這點。

而 OpenAI 自家的基準測試註腳也以實證支持這種介面，對自己有利。 七張比較卡中，四張註明 GPT-Live 組態使用的後端，三張沒有——Tau3（Pass@1 86.2%）與 Tau Banking（32.0%）使用中等力度的 Astra；工具呼叫（Pass@1 87.0%）與回應品質（90.0%）使用低力度的 Terra；Conversational Dynamics、Full Duplex Bench v1.5 Interactivity 與輪替延遲則未註明後端。因此，OpenAI 公開了 NVIDIA 測量過的相同拆解方式：互動分數屬於前端，智慧與工具分數屬於兩端搭配——供應商還為兩類任務選了不同後端與不同力度，這正是在行銷表格中運用能力介面槓桿。數據與所有卡片見 GPT-Live；基準測試目錄見 Interactivity Benchmarks。

委派呼叫有了面向應用程式的公開形式。 NVIDIA 公開了模型內訊號（<tc bos>／<tc eos>／<pf bos>／<pf eos>）；OpenAI 現在則公開了同一交接的另一端——開發者端代理會用 live.send({ type: "session.commentary.append", delegation_id, content }) 傳回答案，這是對工作階段發出的委派 ID 進行非同步附加；「連線設定與委派處理……從略。」兩項揭露彼此互補，不能直接比較：一項說明雙工模型如何決定交接，另一項說明應用程式如何交還結果。API 文章沒有說明委派期間前端會輸出什麼，因此 NVIDIA 章節提出的 token 層級問題仍未解答。

持續在線的說法第三度出現，測量次數仍是零。 文章主張：GPT-Live-1「能在受到打斷及收到確認時即時回應，同時將更深入的推理委派給後端。這讓工作在背景執行時，對話仍能繼續。」這是 TML 持續在線主張的重述，也是 OpenAI 在 7 月的說法，如今則套用在正式推出的 API 上——一樣沒有測量、沒有填充語頻率數據，也沒有與等待提示語政策比較。不過文章確實提供了一項政策資料，與 NVIDIA 的設計相左：OpenAI 將「靜默情境管理」宣傳為處理背景噪音與靜默的方式，能「不打斷對話，也不會把每一步都大聲說出來」——也就是明確販售不使用等待提示語的做法；NVIDIA 前端則依設計使用等待提示語，填充語比例為 83–85%。因此，上方差異表的中間一列現在兩側都有供應商把相反政策當成產品特點，卻仍無人以相同後端延遲分布測試兩者。計數：宣稱三次，展示零次。

第四家供應商：沒有後端、沒有價格，兩種政策兼具（Google，2026 年 9 月）#

Google 的 Gemini 3.8 Live 發表（2026-09-15，vendor-claim）是本文資料集中的首個前沿即時語音產品公告，既未具名任何背景模型，也未公開委派機制，亦未替任何項目定價——然而這是迄今對上方差異表中間一列最有資訊量的來源，因為 Google 在同一段落裡同時販售兩邊的做法。

持續在線的主張，第四度出現。 「它會在背景執行工具與 API 呼叫，同時延續對話，因此模型在背景任務完成期間仍能回應要求並持續交談。」而談到 Extended Thinking，Google 表示它「能同時推理與說話……並維持不中斷的對話流程。」一則示範說明文字聲稱，多步驟預訂與非同步函式呼叫「完全不會打斷自然的即時對話」。沒有填充語比例、沒有延遲數據、沒有對照組，也沒有通訊協定。計數：宣稱四次，展示零次。

然而兩句之後，又把等待提示語當成特色販售。 同一段落宣傳「像『讓我查一下……』這類提早給出的口語提示，可自然地確認收到要求；也提供即時進度旁白，在多步驟背景任務進行時引導使用者。」將其與本文已記錄的兩種做法相比：NVIDIA 前端會依設計給出約 1 秒的等待提示語，然後保持沉默；FDB3 的填充語比例為 83–85%；OpenAI 則把刻意不使用這種做法——「不打斷對話，也不會把每一步都大聲說出來」——當成「靜默情境管理」來行銷。現在 Google 同時站在兩邊：一面聲稱對話會繼續，一面提供確認收到訊息的填充語，還提供步驟旁白，並將三者都當作賣點。如果供應商真能消除持續在線的落差，就不需要提早給出口語提示；若模型會安靜下來，也不會宣稱能維持不中斷的流程。最合理的解讀是，商業語境中的「持續在線」指的是會發出某種聲音，而非持續進行有實質內容的對話——本文應追蹤這種語意漂移，因為它讓下方的未解問題更難被證偽，而非更容易：三家供應商可能都說得沒錯，只是使用了不同的動詞。

有價的界線尚無第二個案例。 2026-09-10 設下的檢驗標準，是第二家實驗室是否會將即時層與後端分開定價。Google 的文章完全沒有任何形式的定價——不論按分鐘、按 token 或按音訊小時。本文唯一涉及金額的，是第三方測得的每小時輸入音訊成本（3.8 Live 為 0.84 美元、Extended Thinking 為 3.50 美元、GPT-Live-1 + Astra 為 5.83 美元）；這是基準測試結果，不是價目表，而且明確未拆分為前端與後端費用。因此，上文的商業持久性論點仍只建立在一家供應商、一個價格點、一篇文章上；「有價的互動界線」頁面候選在壓力 3 下仍遭否決——如今又多了一項有日期的反面證據：本月第二個前沿語音產品發表選擇完全不揭露這條接縫。

值得記錄的語法線索，畢竟沒有其他揭露可記錄。 OpenAI 的基準測試卡註明後端模型與其推理力度（中等力度的 Astra、低力度的 Terra）；Google 的圖表長條則標示即時模型本身的推理力度（Extended Thinking 為 High、3.8 Live 未標示、Gemini 3.1 Flash Live 為 High 與 Minimal）。兩家供應商呈現產品時，把力度調整鈕放在接縫的相反兩側。這是關於各家希望使用者如何理解產品的證據——OpenAI 將產品呈現為可自行組合的搭配，Google 則呈現為可選擇的模型——但不是任一架構的證據。Google 的代理任務註明是在「Gemini Enterprise Agent Platform 的 Live API 上」執行，這是 harness，也是文章最接近承認有其他元件參與運作之處。論點與注意事項見 Interaction Models；產品簡介見 Gemini 3.8 Live。

開放中／已確認#

TML 稱背景代理是「不可或缺的能力」，而他們「才剛開始探索皮毛」——既會持續推進背景代理式智慧的前沿，也會探索背景代理如何與互動模型協作。

同一實驗室的另一條路線，兩天後發表（NVIDIA，2026 年 9 月）#

Hu 等人提出了選擇，卻沒有作出決定：「雙工語音模型應直接內化工具呼叫能力，還是將這些能力委派給後端文字代理。」他們將 DuplexSLA 列為內化方案，之後便未再展開。四十八小時後，同一實驗室公開了內化系統——NemotronLabs VoiceChat（arXiv 2609.21967，2026-09-18，empirical）——採用重疊的硬體、重疊的主幹，以及相同的基準測試。本文資料集通常沒有反事實案例；這次有，但仍須留意：兩篇論文沒有互相引用，兩次測試也不是設計成同一實驗的對照組。

機制：平行函式通道，而非序列化通道。 工具呼叫位於與代理文字通道並行運作的專用自回歸通道，而非代理文字通道內。每個 80 ms 影格中，模態融合層會將三項輸入——編碼後的使用者音訊、前一個代理文字 token 的嵌入，以及前一個函式 token 的嵌入——以融合權重 1、1、2加權求和，再由獨立函式頭預測下一個函式通道 token。不需要動作時，該通道會輸出填充內容；論文明確指出這種負向監督「對避免虛假呼叫很重要」（即使 CPT 完全沒有工具範例，函式頭仍會以填充內容接受監督）。呼叫以 <SOTC> 開始、以 <EOTC> 結束，接著是工具回應片段，並以 <EOTR> 結尾；內部對應的保留詞彙欄位為 <SPECIAL_20/21/22>。<TOOLCALL> 內容是一份 JSON 清單，項目由 {name, arguments} 物件構成，因此單一或多個平行呼叫都使用相同表示法。工具回應 token 會作為情境輸入，並從損失計算中遮罩掉。函式通道的損失權重設定差距很大——<TOOLCALL> 內容為 64.0、<SOTC>／<EOTC> 各為 6.0、<EOTR> 為 3.0、填充內容為 0.3——代理文字通道的回合開始、回合結束、內容與填充權重則分別為 12.5／7.5／5.0／1.0。

這是此軸線上的第三種立場，論文刻意強調這一點：「不同於將異質動作相關 token 序列化在同一自回歸通道中的 DuplexSLA，NemotronLabs VoiceChat 維持平行且各自專用的串流，以保留全雙工互動所需的低延遲行為。」因此，選擇從來不只二選一。將工作委派給文字代理（Hu 等人、GPT-Live、TML）；將動作序列化到對話通道（DuplexSLA）；或是在相同時間軸上以獨立通道處理動作。第三種方案增加一個頭與一項融合項，並讓對話通道保持乾淨。

執行階段說明了交接的兩端，與 Hu 等人公開 <tc bos>／<pf bos> 訊號相對應：「fast-decode」是在通道輸出 <SOTC> 後，非同步解碼完整呼叫；「fast-inject」則是執行階段將工具結果序列化，並強制插入函式通道與解碼器情境中。在這兩者之間，TTS 會說出一段直接定義於工具結構描述中的逐工具確認語（"ack_message": "Sure, let me calculate that for you"）；論文也明確指出，應選擇提示語的長度來「掩蓋延遲」——快速工具可略過，慢速工具則使用較長的提示語。

正面比較：相同基準測試、相同實驗室，間隔兩週。 FDB 3.0，百分比：

	工具選擇	參數準確度	Pass@1	回應品質
內化式——VoiceChat，平行函式通道	82.5（F1）	42.2	33.0	未報告
委派式——前端 + Qwen3-30B-A3B 後端	74.6（準確率）	52.8	44.0	54.0
委派式——前端 + Qwen3-235B-A22B 後端	71.7（準確率）	55.2	48.0	67.0

請仔細解讀，因為兩篇論文對路由欄使用了不同名稱——內化系統報告 F1，委派系統報告準確率——而兩者都沒有說明這是相同指標。因此，第一欄只能作為參考，真正的比較應看其餘兩項。結果呈現出明確的分工：雙工模型決定應呼叫哪個工具時至少不輸，但填寫工具參數與完成任務的能力明顯較弱。 內化系統的第 5 節也從內部得出相同結論——「工具路由能力明顯強於參數擷取與端到端執行」；FDB 3.0 的 Pass@1 只有在模型選對所有工具，且每次呼叫都提供完美參數時才計分，因此路由分數 82.5、Pass@1 卻只有 33.0，問題在於參數落地，而非路由。

這是本文用來說明拆分緣由的最有力證據。委派帶來的不是工具選擇能力，而是後端的參數擷取與多步驟組合能力——正是 Hu 等人所追求、成熟的指令遵循與長期推理能力。這也代表容量經濟論點指錯了欄位：音訊 token 似乎沒有妨礙前端知道需要工具，以及需要哪一個工具。

內化分支也無法避開拆分自身的失敗。 Interaction Models 提出的反證條件是「在不陷入沉默的前提下，單一雙工模型的工具呼叫準確度達到委派系統水準」。VoiceChat 是單一雙工模型，但它也會安靜下來——使用預先設定的確認語、以填充內容佔據代理文字通道，而且承認得比 Hu 等人更明確：輸入音訊仍持續經過感知與 RNN-T，但「工具執行期間不會用來調節回應生成。因此，此階段無法插話打斷。」Hu 等人的前端至少持續聆聽，且這些資訊會一路傳到後續呼叫。因此，在即時路徑問題上，兩個分支的行為趨於一致，而內化式稍差。論文在未來工作中提出「具中斷感知能力的工具執行」，正是作者親口承認此限制。

實際上限也已公開，而且不高：論文建議每個工作階段最多使用五項工具；同時呼叫多個工具「尚不可靠」；呼叫可能遭到「略過、選錯，或被填入虛構參數」；模型「可能在應該呼叫工具時依內部知識作答」；漫長的工具回應則會延遲後續語音。背後搭配 235B 指令微調模型的委派式後端，依設計便不受這些限制。

開源，與其同系列模型不同。 Hu 等人沒有釋出前端權重。此檢查點已上架 Hugging Face，名稱為 NVIDIA-NemotronLabs-VoiceChat-11B——因此 Peng 等人能在技術報告發布前一天進行獨立測量。內化分支因此可重現；委派分支則有較高的 Pass@1，卻沒有公開權重。

延伸閱讀#

• Native Multimodal Modeling: Fusion Depth and I/O Duality——該調查的運算子定義將上方內化式雙工系統分類為採用中層融合的 M2T，並搭配接枝式語音渲染器，而非 M2M；這正是拆分的架構形式：代理文字是原生能力，語音則是外加元件
• Interaction Models——上位概念
• Time-Aligned Micro-Turns——背景模型思考期間，如何讓互動模型保持在線
• Interactivity Benchmarks——標記 * 的結果使用背景代理；也收錄 NVIDIA 執行的工具呼叫評估（BFCL-audio、FDB3、EVA-Bench、τ-Voice）
• Client-Side Agent Optimization——多模型設計的另一軸線（成本／角色，而非延遲／深度）
• Deep Modules for Agents / Agent Harness Engineering——為情境隔離而採用的多代理程式拆分，而非為了延遲
• Harness Shrinkage as Models Improve——此拆分是永久架構，還是等到單一模型兼具速度與深度前的過渡產物，仍待釐清
• Encoder-Free Early Fusion——架構的另一端（感知／生成部分）
• Full-Duplex Interaction——互動模型保持在線時，並行深度工作如何進行
• TML-Interaction-Small——實作此拆分的模型；即使沒有背景代理，在智慧基準測試上仍具競爭力
• GPT-Live——OpenAI 在正式環境中實作此拆分的產品：全雙工語音模型委派工作給 GPT-5.5
• Live-Path Minimalism——讓委派避開即時媒體路徑的服務架構
• Cost-per-Task Over Cost-per-Token——產品化的拆分以不同單位計費：前端按分鐘計算在線時間，後端按 token 計算工作量
• NVIDIA——第三家推導出此拆分的實驗室，也是公開委派訊號的一方
• Gemini 3.8 Live——第四個即時語音產品：未具名後端、兩端都未定價，並在宣稱持續在線的同時提供與此矛盾的等待提示語

待解決的問題#

• 委派期間持續說話的互動模型，在使用者感受到的品質上，是否真的勝過發出等待提示語後便保持沉默的模型？Thinking Machines 與 OpenAI 都宣稱模型會持續在線；NVIDIA 測量的是沉默版本，並指出其輪替率為 100%，依設計填充語比例為 83–85%。沒有人以相同後端延遲分布測試兩種政策並詢問使用者。(2026-09-21：仍然無人測試。Build more natural voice experiences with GPT‑Live‑1 in the API 第三度宣稱模型持續在線，並將不使用等待提示語——「不必逐步說出每個步驟」——當成產品特色販售，因此兩種政策已成為明確對立的供應商立場，而非未受注意的差異。雙方都沒有測量數據；問題仍未解決，但動機更充分。) (2026-09-21，第二則觀察紀錄：Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking 第四度宣稱模型持續在線——「在背景任務完成期間回應要求並持續交談」——又在同一段落中販售提早給出的口語提示（「讓我查一下……」）以及多步驟背景任務的即時進度旁白。現在有一家供應商同時採用兩種政策，這代表「兩種設計流派彼此競爭」的解讀已不成立，取而代之的是更棘手的問題：三方宣稱的「持續在線」並非同一行為。實驗開始前必須先定義依變項——持續進行有實質內容的對話，或只要發出任何聲音都算。測量次數仍是零。)
• 新增委派 token 對雙工品質造成的損失，究竟是 token 本身不可避免的代價，還是合成訓練資料造成的結果？NVIDIA 的消融測試顯示，加入 token 後 ASR WER 從 10.80 升至 11.47，FDB-v1 停頓 TOR 從 53.2 升至 68.2；並將兩者歸因於合成 SFT 音訊及缺少自然停頓資料。以自然停頓及真實語音工具呼叫資料訓練第二個前端，即可定論。部分解答（2026-09-23）——合成音訊的解釋變弱了，token 本身的解釋則未變。 NemotronLabs VoiceChat: An Open Full-duplex Speech-to-Speech Model with Tool Calling Capabilities（empirical）訓練了一個同系列雙工模型，其語音也幾乎全由 TTS 生成——CPT 與 SFT「使用的語料均來自純文字 Nemotron 主幹，而非原生錄製的對話語音」——但其 FDB 1.0 停頓 TOR 仍達 15.3%／25.5%，是表中五種開放權重系統最低的數值，遠低於消融測試中 53.2 升至 68.2 的區間。它使用平行函式通道而非委派 token 來處理工具呼叫，並加入消融前端未報告的三項對話增強措施：以 p = 0.1 機率提早中斷（代理回合截斷，持續 8 個影格／640 ms 後才輸出 EOS）、每個樣本以 p = 0.05 機率注入回應音，以及延遲兩個影格（160 ms）輸出代理文字，但刻意不延遲函式通道。因此，合成音訊不會為停頓行為設下硬性上限，增強策略更值得懷疑。這不是消融測試——模型、資料與通道設計都不同——所以 token 的影響仍未解答，原本的反證條件依然成立。

資料來源#

• Interaction Models: A Scalable Approach to Human-AI Collaboration
• Inkling: Our Open-Weights Model——Inkling 被設計為背景推理模型（vendor-claim）
• How we built a realtime system for responsive voice AI in six months——OpenAI，2026-07-29（case-study，第一方資料）：GPT-Live 的委派路徑如何作為延遲預算處理（預先建立並填入內容的工作階段、黏著性與快取、調校推理力度／結構描述／往返次數）
• A frontend-backend architecture for tool calls in full-duplex speech models——Hu 等人（NVIDIA），arXiv 2609.19334，2026-09-16（empirical，5 頁）：§3.1 前端及 <tc bos>／<tc eos>／<pf bos>／<pf eos> token 設計；§3.2 LangGraph 後端及其執行緒索引檢查點；§4 訓練方法與完整示範序列；§5.1–5.2 BFCL-audio／FDB3／EVA-Bench 結果；§5.3 無工具呼叫消融測試。由作者針對自家系統回報，單次測試，沒有誤差線；其他模型的基準數值由作者重新執行。**解析註記：**表 4、5、7 的 3 個儲存格出現 table-shift 警示——這是多層跨欄標題造成的問題（docling 將展平後的標題文字重複套用到跨欄儲存格），每個儲存格都已從 pdftotext -f 4 -l 5 -layout 重新讀取；表 1–3 也同樣以 pdftotext -f 2 -l 3 -layout 重新讀取，並與 docling 正文逐字逐數字相符。wiki 頁面上的數值都不是來自未核對的列。
• Build more natural voice experiences with GPT‑Live‑1 in the API——OpenAI，2026-09-10（vendor-claim，約 1,670 字，未署名）：拆分成為有價產品界線——前端層每分鐘 0.05 美元；後端由開發者選擇、另行計費，且可採用第三方模型；具名的 Astra／Luna／Terra 後端；session.commentary.append 委派呼叫；以及用來區分僅前端分數與搭配分數的逐卡後端註腳。全文皆為第一方資料，只與 OpenAI 先前模型測量比較。
• NemotronLabs VoiceChat: An Open Full-duplex Speech-to-Speech Model with Tool Calling Capabilities——Balam、Bartley、Casanova 等人（NVIDIA，48 位貢獻者），NemotronLabs VoiceChat: An Open Full-duplex Speech-to-Speech Model with Tool Calling Capabilities，arXiv 2609.21967，2026-09-18（empirical，19 頁）：§2.2 平行函式通道、<SOTC>／<EOTC>／<EOTR> 狀態機與 1／1／2 模態融合權重；§3.2 函式通道的 64.0／6.0／3.0／0.3 損失權重；§4 填充訊息與端點設定備援增強；表 4 的 FDB 3.0 正面比較；附錄 B 的 fast-decode／fast-inject 執行階段及無法插話打斷的承認；§7 五項工具上限。7 張表均已逐格與 pdftotext -layout 核對；NVIDIA 評分 NVIDIA，單次測試，沒有誤差線；FDB 3.0 的基準組合與同系列論文不同（此處為 Gemini Live 2.5／3.1，另一篇則為 Gemini-3.5 Flash 與 GPT-realtime）——參見 Interactivity Benchmarks
• Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking——Ouyang 與 Jaganathan（Google，Gemini Audio Team），2026-09-15（vendor-claim，約 1,764 字）：第四度宣稱持續在線、與此矛盾的提早口語提示和進度旁白功能、未提供定價，以及推理力度標示方式。文章全文未提及後端模型、委派機制或延遲數據；文中引用但未納入資料的 DeepMind 模型卡亦未整理。