當用戶開啟豆包的視訊通話功能，將鏡頭對準孩子的作業本，AI能即時理解畫面並一步步講解題目——這種自然的多模態互動體驗，正推動豆包的使用者規模發生質變。火山引擎智慧影片技術負責人裴志偉在近期分享中披露，在視訊通話等多模態場景的帶動下，豆包的日活躍使用者（DAU）從千萬級躍升至億級，業務規模增長了10倍，且幾乎未依賴大規模投放。
這一增長背後，是火山引擎為支撐AI Agent時代即時互動而重構的多模態傳輸系統。裴志偉指出，多模態體驗並非僅由模型能力決定。當用戶開啟攝像頭和麥克風，真正影響體驗的是傳輸質量：連線是否夠快、弱網下是否穩定、音畫是否同步、使用者打斷能否被及時響應，以及模型能否在正確時間獲取正確資訊。
豆包的多模態傳輸探索經歷了多個技術階段。最初，團隊採用WebSocket協議實現語音互動，其全雙工和長連線特性足以驗證方向。但隨著場景複雜化，WebSocket在弱網下的高丟包和延遲不可控問題暴露，延遲抖動超過1秒就會導致模型接收資訊變形，造成回答失真。為此，豆包引入QUIC協議，利用其弱網恢復、多路複用和連線遷移能力，支撐起耳機、車載、機器人、智慧眼鏡等更多終端場景。
當視訊通話成為重點能力後，QUIC也無法滿足需求。火山引擎進一步採用WebRTC技術，實現超低時延——端到端延遲比QUIC最佳化10%——並內建音影片編解碼與回聲消除，使豆包的反應更接近真人交流。然而，WebRTC雖強，卻並非為AI互動原生設計。火山引擎判斷，面向AI的多模態傳輸系統體量可能是傳統RTC需求的100倍至500倍，億級使用者長時間線上和高頻呼叫會急劇放大成本與穩定性壓力。
更深層的差異在於傳輸目標的變化。人與人通話追求穩定傳送連續內容，而AI互動中模型可能瞬間生成大量資訊，使用者也可能隨時打斷、追問或切換畫面。傳輸鏈路需做到即時中的非同步，提前快取以減少載入時間。更關鍵的是，當用戶詢問螢幕上的一行小字，繼續傳輸低位元速率影片並非最優解，系統應觸發高畫質截圖或區域性增強，讓模型先看清問題。
為此，火山引擎基於C/S架構重構了多模態傳輸系統。客戶端保留成熟的採集、編碼、回聲消除等音影片能力，同時將底層網路庫替換為QUIC庫，增強弱網恢復與連線遷移。傳輸層基於MoQ協議實現精細會話控制，判斷不同模態的優先順序——哪路音訊優先、哪幀影片更值得送給模型、哪些內容需可靠傳輸、哪些可為低延遲取捨。服務側閘道器則承擔關鍵角色，可決定是否直接將使用者語音送往模型，或根據需要對影片進行抽幀、高畫質增強等處理，並引入MediaKit同源演算法服務於即時傳輸。
這套系統已在豆包中落地，相當一部分更新使用者已開始使用新的多模態傳輸鏈路，意味著其已進入真實的C端高併發場景驗證。火山引擎計劃將這套能力模組化輸出：提供一站式多模態互動Agent、Agent前後處理能力，以及面向強定製需求客戶的即時傳輸網路、傳輸SDK、傳輸閘道器和處理閘道器等元件。
這一佈局與海外趨勢同頻。OpenAI於7月8日推出的GPT-Live，同樣將連續對話與深度推理任務解耦，構建低延遲、可打斷、可持續的多模態資訊互動層。儘管初期尚未完全融合語音、視覺與螢幕共享，但其方向明確指向將語音、視覺和工具呼叫納入同一即時會話系統。
行業正形成共識：模型決定智慧上限，傳輸決定體驗下限。沒有穩定、低延遲、低成本的多模態傳輸能力，再強的模型也難以進入高頻、長時、移動化的真實場景。火山引擎在豆包超大規模流量中沉澱並驗證的多模態傳輸系統，不僅為豆包補齊了技術鏈路，更在為Agent時代搭建底層基礎設施。當AI開始即時進入真實世界，誰能長期、穩定、低成本地支撐這種互動，誰就更接近下一代AI應用的核心位置。