社群供稿丨 GPT-4o 對實時互動與 RTC 的影響

以下文章來源於共識粉碎機 ，作者 AI 芋圓子

前面的話：

GPT-4o 釋出當週，我們的社群夥伴「共識粉碎機」就主辦了一場主題為「GPT-4o 對實時互動與 RTC 的影響」討論會。涉及的話題包括：

• GPT-4o 如何降低延遲（VAD 模組可能也應用了 LLM？）
• GPT-4o 怎麼影響實時互動場景（分析了醫療、法律、教育、陪伴和客服等場景）
• GPT-4o 應用到實時，也有不完善的地方
• GPT-4o 為什麼要用到 RTC（Input 場景 RTC 可以被視作解決方案。Output 場景 RTC 不一定是必須。）
• 怎麼選擇 RTC 供應商
• 實時場景對端側的影響

另外，此次討論會嘉賓史業民在我們的播客《編碼人聲》裡深度解析了 GPT-4o 的能力邊界，並基於實時多模態開發的一手經驗，給開發者提出了不少建議，也歡迎收聽。

這次討論會的資訊量極大，Enjoy！

本期討論會參與者：

杜金房老師： 煙臺小櫻桃網路科技有限公司創始人，FreeSWITCH 中文社群創始人，RTS 社群和 RTSCon 創始人，《FreeSWITCH 權威指南》、《Kamailio 實戰》、《深入理解 FFmpeg》作者，FreeSWITCH 開源專案核心 Committer。杜老師同時是 RTE 實時互動開發者社群聯合主理人。

劉連響老師： 資深 RTC 技術專家，推特@leeoxiang。

史業民老師： 實時互動 AI 創業者，前智源研究院研究員。

徐淨文老師： 負責百川的戰略、投融資、開源生態、海外等業務。

1、GPT4o 如何降低延遲

GPT4o 前呼叫 OpenAI API 延遲極限情況下可以壓縮到 2 秒

• 中美跨海光纜差不多 100-200ms，如果考慮丟包，那平均在 300-400ms。

• 語音場景需要經過 ASR（語音轉文字），在大模型無法流式輸入的情況下，一般需要說完一句話再餵給大模型，平均需要 400-500ms 延遲。

• 如果不考慮 Planning 和 RAG 等環節，只計算 First Token 的話過去平均需要 700-1000ms 延遲。

• 大模型可以流式輸出，但一般第一句話節後給 TTS（文字轉語音），TTS 環節也需要 400-500ms 延遲。

• 所以整體延遲最低可以低到 2 秒。

• 上述場景主要是考慮的網路良好的情況，如果在室外體驗，丟包機率會大幅增加，延遲還會再往上波動。

但在客服等場景中還經常需要做 Planning 和 RAG，延遲會進一步增加

• 上述主要是可以用 First Token 來判斷延遲的場景，對話內容比較簡單。

• 像在類似客服等場景，在 First Token 前還需要先做 Planning 和 RAG，就可能還需要經歷 1-2 次完整延遲，整體延遲就會遠遠超過 2 秒，可能到 4-5 秒或者更高。

GPT4o 最佳化延遲的機制

• VAD（Voice Activity Detection）提升：VAD 主要用於儘早發現使用者說完話，用於觸發大模型，過去用停頓時間判斷，現在可能有了語義理解能力。

• 端到端能力：端到端可以替換掉 ASR 和 TTS 的延遲，開發者未來可以用 GPT4o 的 ASR/TTS，也可以自己做。

• 其他延遲最佳化還包括流式處理、非同步處理，多個模組在向量畫的過程中如何統一，在 GPT4o 的設計上有很多巧思。

VAD 模組可能也應用了 LLM

• 之前有一些簡單的 VAD 判斷標準，比如停頓 1000 毫秒，就預設使用者說完話了。

• 但現在 GPT4o 為了節省時間，單純用停頓判斷肯定不可能，應該要走到語義層面。

• 最極端或者暴力的方案，可以拿 GPT4o 的模型去 Finetune 一個小的 VAD 模型， 模型可以控制在 0.5B-1B 的規模，類似於向下降維打擊的方式實現 VAD。

• 這樣對於 VAD 模型來說，Input 是 Audio，Output 就是說完與否的 “Yes or No”。

GPT4o 後，還可以透過工程併發的方式進一步降低延遲

• 在 GPT4o 前，工程角度已經可以在一些特殊場景，提前做好 RAG 等檢索工作，然後再將 TTS 與 Output 等場景做成並行，透過很多工程做法，在不考慮跨海傳輸的情況下，有機會將延遲控制在 1 秒以內。

• 現在在複雜一點的場景，甚至到 Planning 和 RAG 相關的場景，也可以嘗試做並行進一步壓縮延遲。

• 基於 DSL（Domain SPecific Language）結果做 RAG、對輸入的 Vision 和 Audio 做向量化預處理、剛剛提到的 VAD，這三個部分也可以做並行。

• 現在還不確定 OpenAI 會不會開放著三個介面，從模型工程角度來說，如果這幾個部分都做好，幾乎可以把 RAG 的延遲都覆蓋掉。

在做應用的時候還可以用一些雞賊的產品體驗進一步降低 “延遲感”

• 為了提高使用者體驗，可以在產品層面做一些改動。例如 OpenAI 的 Demo 中，在響應時間的過程裡，手機中的畫面會有波動的動畫，在這個過程中，哪怕沒有任何的實質性輸出，人看到動畫也會覺得親切一些，對延遲的敏感度也會降低。

• 在下面杜金房老師演示的影片中，也可以透過 “嘟” 的方式給使用者起到心理安慰，“AI 馬上就要說話了”。

• 但這種場景也會有明顯的侷限，只適合使用者已經知道對面是 AI 的情況，這種情況對延遲的容忍度也會相對較高。在不想讓使用者知道對面是 AI 的場景，這類產品功能也會容易暴露對面是 AI 不是真人。

2、GPT4o 怎麼影響實時互動場景

有哪些實時互動場景可以開始做了

• 類似 Hume.AI 等各種陪伴產品。

• VR 遊戲=Vision Pro/PICO 場景的互動產品。

• 互動機器人，互動機器人加入實時互動能力後，對使用者體驗提升幫助很大。

• AI 音響，可能會出現新的落地場景。

• 還包括現在也有在討論車載互動能力，讓開車的過程中沒那麼無聊，以及解放雙手做一些車內的控制任務。

還有一些典型的行業場景，也很適合實時互動需求

• 這些場景一般都非常個性化。

• 出現的時候會比較緊急，一點點延遲提高都能帶來使用者的體驗改善。

• 可以透過季節性、年齡等維度進行預處理，進一步減少延遲。

醫療進入實時互動可以大大減緩患者焦慮

• 遠端診斷諮詢，個性化建議，都可以做非常多的實時性提升。

• 疾病症狀季節性集中度非常高，所以在 Planning 和 RAG 上可以做非常多預處理，可以壓縮模型時間。

• 即時互動可以解決心理焦慮，從使用者端體驗會變得非常好。像美國有個機構 Hippocratic AI 正在做，延遲大概在 5 秒，那等 5 秒的過程患者會非常焦慮的。因為機構 Hippocratic AI 是用影片/語音方式來解決的，所以需要差不多 5 秒延遲。模型在延遲上小小提升，就可以解決患者焦慮的狀態。

• 醫療場景中每個人都認為自己的小病是大事，但不一定很嚴重。如果能夠更快的得到權威的回應，就在心理層面有很大的幫助， 甚至不一定要在物理層面上改善。只要是及時的回答，就可能能解決問題。

• 醫療也要分場景，疾病會有輕重之分。如果是重症，那呼叫 Planning 和 RAG 的成分就會非常多，但大部分的醫療場景中，高頻發生的還是小病疾病。比如小朋友發燒、老人摔跤、吃過敏藥後忘記醫囑喝了酒等場景，不需要呼叫非常厚的醫療詞典，也不需要讓很多專家模型介入，這些場景的延遲改善會更加明顯一點。在這些場景，5 秒到 1 秒的改善，對於使用者體驗的提高是非常大的。

• 目前還沒到 OTC 開藥和重症階段，現在短期還很難因為實時互動改變。但是比如心理輔助，比如患者就站在橋旁邊，那實時互動就能立刻見效。

法律引入實時互動後適合現場處理場景

• 過去的處理週期非常長：形成文件，然後透過人去解決。比如車險報警，過去是拍照上傳、交警介入。

• 現在有了 GPT4o 的實時機制後，非常多的裁決是可以現場發生的，當然最後處理部分還是需要人來介入。

• 除了車險和現場暴力事件，剩下的還是一定程度能接受延遲。

教育引入實時後適合線上解題和語言教學場景

• GPT4o 的 Demo 上就有線上解題。

• 解題是個高度個性化的過程，還包括題庫的應用，結合 RAG 和模型能力提高，再加上 RTC 的實時效果，線上教育領域的教學和輔助能力會有巨大提升，也可以做更多市場化的嘗試了。

• 過去需要上傳，需要等待。那現在變成了更像輔導和學習伴侶的過程，在語言教學等場景，會實質性的改變學生的學習曲線和接受度。

GPT4o 後最快會是哪些場景能跑出來

• 最直接的場景是陪伴，因為陪伴對 Planning 和 RAG 的要求低，只需要定義好角色背景和音色，而且非常適合應用到 GPT4o 的端到端場景。很容易就可以把延遲迅速降下來。

• 客服等場景稍微複雜點，需要用到 Planning 和 RAG，延遲沒有陪伴降的這麼厲害。在這類場景裡，延遲不是主要取決於端到端和 First Token，還要取決於整個 Pipeline 的系統級延遲。但如果做好並行機制和各種最佳化，也可以到 1-2 秒的延遲。

3、GPT4o 應用到實時也有不完善的地方

在觸發機制等問題上還無法做到完全實時

• 之前提到 VAD 的進步是延遲降低的一個關鍵是因素，需要儘早觸發多模態模型，那就需要符合 VAD 的觸發條件，在使用者無法說話，或者 使用者正在說話過程中的情況，大模型就無法觸發。

• 舉一個例子，在 OpenAI 的 Demo 裡有一個例子是兩個人 + 一個 AI 互動，但如果假設 A 停了幾秒，B 再去說，就會發現 AI 提前介入，B 的話就會被 AI 搶了。就必須要提前設計好 AB 角色以及 AI 對應角色的角色分析，新增更多的限定條件。

• 在實時互動場景中，也需要 AI 能夠在使用者溝通中回覆一些內容，可以更好激發使用者去表達，現那也做不到。

• 如果你要他說話之前就能回答，那還需要做很多工程工作，中間可能還會有誤觸發方案，但長期應該可以解決。這更多是場景決定的需求，例如實時翻譯和需要插話的場景，要設定提前觸發的請求規則。但在類似 Assistant 的場景，就不需要設定插話的提前觸發條件。

具體舉一些場景來看的話

• 例如開著攝像頭，要試試去看場景有什麼變化，有什麼危險，如果不設定定時觸發機制，那 GPT4o 無法實時提醒。

• 例如同聲傳譯和語法糾錯場景，需要在說話過程中就進行處理，或者實時糾錯。這裡也不能直接應用，因為 VAD 機制需要判斷說完話。

• 例如盲人眼睛場景，使用者希望的是戴上眼鏡就能實時感受路況。但現在的需要使用者不斷地問有沒有違憲，或者工程上設定一個 1-2 秒的自動請求機制，來幫助 GPT4o 高頻判斷。

• 總體來講，GPT4o 如果是從助手級別（接收完人類指令），已經幾乎完美了。但到了上述要更進一步的實時互動，還存在失望的地方，可能到下一代 GPT5 可以滿足。

4、GPT4o 為什麼要用到 RTC

GPT4o 為什麼需要 RTC？用 RTC 的 LLM 會產生時空穿越？？

• 在 GPT4o 的 RTC 場景中有兩個方向，Input 和 Output。

• Input 場景中，LLM 需要實時接收使用者的影片，人不能加速產生內容，為了降低 100-200 毫秒的延遲，RTC 可以被視作是必須的解決方案。

• Output 場景中，RTC 不一定是必須，也可以用 WebSocket 等方案，鏈路存在但是開發者還沒有大範圍整合。

• 與 Input 場景不同，在 Output 場景中， LLM 生成音影片未來可能做到兩倍速，甚至四倍速、八倍速。那 Output 的 Token 生成速度會比時間還快，但是播放時候必須是一倍速，這就造成了在倍速場景中會有時空穿越的感覺，延遲實際上是負數。 只要解決首幀、First Token 的延遲就可以了。內容會因為生成比播放還快，而先預存在本地，然後再播放，就類似現在聽網路小說、看影片一樣。

• 如果開發者有很強的最佳化能力，或者傳輸資料量沒那麼大的情況，提前做好 ASR/TTS 等，那可能可以不用 RTC。

LLM 可能還會影響新的 RTC 技術

• RTC 行業發展這麼多年了，已經很成熟了，看不到明顯的增長了，LLM 出來後大家很興奮，覺得應該能做點事情。

• 最直接的互動方式還是語音和影片，也是 RTC 的強項，有些人在探索結合，也有直接轉型 LLM 的。

• GPT4o 出來後，大家又看了新挑戰，比如做四倍速 RTC、八倍速 RTC，可能還會有新的 RTC 技術出來。

• 我們現在很多假設都是 RTC 一倍的情況，未來 RTC 可能是兩倍、四倍場景。那在正常情況下，比如 RTC 是 500 毫秒延遲，但是弱網可能就是 1 秒，稍微慢一點也能接受。但如果未來有了兩倍速 RTC，那可能網路條件差了點，延遲還是在 500 毫秒到 1 秒之間，那也會有很大幫助。

但目前的 LLM RTC 需求還不復雜

• 主要還是一進一出的場景。

• 以前 RTC 場景裡複雜的比如小班課，一堂課可能有幾十路 RTC，就比一進一出高很多。

• 難度可能還比不上直播連麥的難度，直播間裡玩法也非常多樣。

• 未來也要看 LLM 玩法的迭代，越複雜的玩法需求越大

• RTC 國內最大的是社交娛樂和教育，後面來來回回想了很多場景要起來，比如 IoT 等，但最後還是沒起來。現在還不確定 LLM 會不會也是這樣一個需求，謹慎樂觀。

除了直接延遲外，RTC 在網路不好的場景，以及對打斷有需求的場景有明顯優勢

• 網路好的時候延遲差別不大。但是網路不好的時候差別很大，比如丟了個包那來回 200 毫秒就沒了，如果再丟一個包那 20 毫秒又沒了。TCP 是最後元件，前面的延遲炸了，後面也會累積。

• RTC 做了很多抗弱網策略，加重傳策略，包括猜測下一個聲音做補全等。

• 沒辦法直接給出和 CDN 延遲差多少，還是 Case by Case，只能說不好的情況下差比較多。

• RTC 也適合互相打斷，流式傳輸必備。CDN 不適合打斷場景。

5、怎麼選擇 RTC 供應商

先講講 RTC 的發展歷史

• Google 在 2010 年收購了 WebRTC 技術公司，然後再 2011 年透過 Chrome 開放了 WebRTC 原始碼，相當於 Chrome 就具有了實時能力。因為要做一套 RTC 引擎成本還很高，涉及到演算法、編解碼、各種規範，Google 開放 WebRTC 之前 有能力把 RTC 做好的並不多。

• 2013-2014 就有第一波熱潮，那時候出現了很多 RTC 創業公司，然後很快都接著死了。迎來了第一波低谷。

• 2015 年出現了聲網，後面國內也有幾家。2016-20187，國內出現了上千直播平臺，開始有了連麥的需求。然後緊接著 2018 年線上教育跑起來了。

• 2020 年最大的一波來了，疫情期間，包括各種視訊會議、線上教育等居家辦公需求。

• 疫情熱度過後，RTC 需求就開始降溫了，進入第二次低谷。

OpenAI 目前選擇了 LiveKit，但未來 API 可能可以不與 LiveKit 繫結

• 看全球的 RTC 供應商，除了國內的聲網、騰訊 TRTC 等也多數不能打。

• OpenAI 在選擇方案的時候肯定非常謹慎，可能會更多考慮開放標準，也會考慮到中國公司的情況。如果是閉源方法，就會涉及到開發者怎麼選擇；不能繫結一家商業公司。在這個層面，LiveKit 是個非常好的生態位，你想用的話可以用 LiveKit 的 Cloud，也可以自己建。

• OpenAI 現在也開始自己招人，那和 LiveKit 可能就是合作關係，前期可能會給一些諮詢費一起共建，但後面可能還是會自建。

• 未來可能是 ChatGPT 產品用 LiveKit，API 端可能不繫結 RTC。

未來客戶可能也能使用商業 RTC 方案

• 現在給不出一個準確的答案，這個要取決於 OpenAI 的決策。

• 但推測 OpenAI 可以採用一個開放的標準，讓各家產品都可以接入，這是一個更加平臺風格的選擇。

• 比如客戶想做成商業產品或者在全球應用，那就採用商用方案，這是最省研發成本的。

使用 GPT4o 不一定必須用其自帶的 TTS

• TTS 都在一個大模型裡面，對開發者不是那麼友好。

• 比如 Hume.AI，已經帶有情感 TTS 的，那怎麼和新 4o 去閉環；客戶不一定能接受 OpenAI 現在給的幾種聲音模式，會有更多樣化的需求，比如更像某個人的聲音（定製化的），或者更卡通化等風格需求。

• 那可能 4o API 最好同時支援 Voice 出和 Text 出。

各方是怎麼看要不要用 RTC 的

• 模型公司角度很可能會優選 RTC，成熟，可擴充性也好，同時可以開放給開發者不同選擇。

• 開發者角度，延遲還是越少越好，越實時互動的場景越需要 RTC。

6、實時場景對端側的影響

Vocie Assistant 場景對於端側硬體的要求

• 如果全部使用 GPT4o，端側只接收影片，就幾乎不需要算力

• 如果要將 VAD 技術放在端側，那端側就需要一定算力。但總體會遠遠低於 LLM 的算力。

對 RTC/RTE 感興趣的朋友也歡迎訪問 RTE 開發者社群：

https://www.rtecommunity.dev/

最後我們放一張本次活動的聽眾 Agent 創業者 王軼老師 參與互動後畫的一張圖，也比較清晰的展現了 RTC 引入後 LLM 的流程變化