火山引擎重构多模态传输底座，支撑豆包视频通话

背景

过去一年，多模态交互正成为通用 Agent 提升用户体验的关键基础技术。用户不再满足于传统的“输入文字、上传图片、等待回答”模式，而是期望 AI 能像真人一样“在场”——例如家长把摄像头对准孩子正在做的题目，让 AI 一步步讲解；穿搭建议、视障人群视频导航等场景中，用户希望 AI 能在整个任务过程中持续倾听、对话。这种变化不仅提高了功能丰富度，更显著提升了用户与 AI 建立连接的频率和深度。

火山引擎智能视频技术负责人裴志伟指出，视频通话等多模态场景“极大地拓宽了技术方案的普适性，带来了更多的想象力”，同时帮助豆包在几乎没做太多投放的情况下，业务规模从千万级 DAU 增长为亿级 DAU。然而，这种多模态体验并非仅由模型能力决定。用户打开摄像头和麦克风后，真正影响体验的还有传输质量——连接速度、弱网稳定性、音画同步、用户打断的响应及时性，以及模型能否在正确时间拿到正确的信息。因此，国内的豆包和海外的 ChatGPT 都在构建让 AI 与人自然沟通的更成熟技术底座。

核心内容

火山引擎与 OpenAI 在构建多模态交互技术时，都意识到传统音视频传输技术已无法满足 Agent 时代的需求。豆包并非一开始就攻关复杂的视频通话，而是从语音交互起步，最初选择了 WebSocket。WebSocket 简单、标准、支持全双工和长连接，穿透性好，能快速连接用户和模型，验证方向有效性。但很快 WebSocket 的弱网体验弊端显现——视频丢包、延迟不可控，直接导致模型反应失真或不回答。裴志伟介绍，延迟抖动超过 1 秒，模型接收到的信息就会变形。

为解决弱网问题，豆包引入了 QUIC 方案。相比 WebSocket，QUIC 在弱网恢复、多路复用和连接迁移上更适合移动端场景，使豆包在耳机、车载、机器人、智能眼镜等多路、复杂场景中实现稳定高效传输。但当豆包将视频通话作为重点能力建设时，QUIC 也不再满足需求，转而采用 WebRTC。WebRTC 实现超低时延，端到端延迟比 QUIC 优化 10%，并具备完整视频链路能力（内置音视频编解码、回声消除、浏览器原生支持），使豆包反应更快、能被自然打断、声音画面更接近真人交流。

然而，WebRTC 也非面向 AI 交互的多模态传输最优解。火山引擎判断这类多模态传输系统可能是目前最复杂或规模最大的 RTC 系统，服务体量可能是此前 RTC 需求的 100～500 倍。亿级用户、长时间在线、高频调用的 AI 场景持续放大成本与稳定性压力。此外，人与人通话时音视频内容按时间连续产生，系统只需稳定传输；而 AI 交互中，模型可能在短时间内集中生成大量内容，用户可能随时打断、追问、切换画面，传输链路需做到“实时中的异步”，提前缓存以减少加载时间。更核心的差异在于目标：人与 Agent 交互追求的是模型在正确时间拿到最有价值的信息——例如用户问屏幕上的一行小字时，继续传输低码率视频未必最优，更合理的方式是触发高清图、抽帧或局部增强。

因此，豆包需要一套面向 AI 交互的全新多模态传输链路，要求建联从秒级压到数百毫秒，端到端延迟对齐 RTC，弱网体验更稳定，并支撑亿级并发、控制长期成本。火山引擎选择基于 C/S 架构搭建系统，保留客户端成熟的采集、编码、回声消除能力，将底层网络库替换为 QUIC 库以增强弱网恢复、多路复用和连接迁移能力。传输层基于 MoQ 协议实现更好的会话控制，通过信令的分层逻辑单元支持精细的模态判断（如哪路音频优先、哪帧视频更关键、是否需可靠传输等）。服务侧的网关承担关键角色：用户传来一句话，网关决定是否直接送往模型；打开摄像头后，网关判断是否需要抽帧、高清图或结合模型反馈改变策略。火山引擎引入了 MediaKit 同源的处理算法服务于实时传输。

目前，这套多模态传输系统（MMT）已在豆包中落地。近期更新豆包的用户中已有相当一部分使用新链路，意味着系统已进入真实 C 端高并发场景，而非内部测试。火山引擎计划将这套系统输出给客户：需要一站式服务的客户可直接获得多模态交互 Agent；希望保留 Agent 定制空间的客户可获得前后处理能力；有较强音视频处理能力的客户则可直接采购多模态传输和基础处理能力。火山引擎并非简单外溢豆包的视频通话能力，而是将经过验证的多模态传输能力拆分为（实时传输网络、传输 SDK、传输网关、处理网关等）不同模块，让不同开发深度的 AI 应用都能按需接入。

与此同时，OpenAI 于 7 月 8 日推出 GPT-Live，将连续对话与更深入的搜索、推理和智能体任务解耦，打造了一个相对独立、低延迟、可打断、可持续的多模态信息交互层。GPT-Live 可以将任务交给另一个模型，自身继续维持对话，本质上是将“自然交互”和“深度智能”拆成两个协作层。尽管发布初期尚未将语音与视频或屏幕共享完全结合，但其下一步显然是将语音、视觉、屏幕和工具调用纳入同一实时会话系统。

关键要点

• 传统音视频传输技术（WebSocket、QUIC、WebRTC）在 Agent 时代的多模态交互中存在根本性落差：弱网体验差、延迟不可控、无法应对模型集中生成与用户随时打断的异步需求，且服务体量激增 100～500 倍。
• 火山引擎构建的 MMT 系统基于 C/S 架构，保留客户端成熟音视频能力，底层网络库替换为 QUIC 库，传输层采用 MoQ 协议实现精细会话控制，服务侧引入 MediaKit 同源算法，网关负责判断何时抽帧、高清图或改变处理策略。
• 新链路显著提升体验：建联从秒级降至数百毫秒，端到端延迟对齐 RTC，弱网更稳定，支持亿级并发，并通过模块化拆分成实时传输网络、传输 SDK、传输网关、处理网关等，对外部客户按需输出。
• OpenAl 的 GPT-Live 采用类似的“自然交互层+深度智能层”架构，将连续对话与复杂推理解耦，未来将整合语音、视觉、屏幕和工具调用。
• 豆包凭借 MMT 系统，在几乎无额外投放的情况下，DAU 从千万级翻倍至亿级，证明了多模态传输对用户连接频率和深度的关键作用。

意义与影响

豆包的视频通话之所以深受用户喜爱，不是因为简单地“增加了摄像头”，而是因为多模态传输让 AI 从工具变成了更接近“在场者”的角色。火山引擎在豆包超大规模 C 端流量中快速沉淀并验证了 MMT 系统，使其能够支撑真实流量、复杂网络和高频交互。长远来看，多模态传输正从通信管道演变为 Agent 时代的人机交互技术底座。

过去两年，大模型竞争围绕参数、推理、上下文、多模态理解能力展开，行业评价 AI 能力的重要标尺往往是“谁能回答更准确”“谁能推理更复杂”。但当 AI 从聊天框走向真实场景，保证体验下限变得同样重要：没有稳定、低延迟、低成本的多模态传输，再强的模型也难以进入高频、长时、移动化、硬件化的场景。用户不关心底层协议，但能感知到模型是否“跟上了自己”。模型决定智能上限，传输决定体验下限——这是对 AI 产品化的硬约束。

火山引擎与 OpenAI 的投入表明，Agent 竞争正从模型能力延伸到工程能力。行业需要一套完善的 AI 原生基础设施。火山引擎在多模态传输上的布局，不只是为豆包补齐技术链路，更是为 Agent 时代进行底层基建。当 AI 开始实时进入真实世界，谁能长期、稳定、低成本地支撑这种交互，谁就更接近下一代 AI 应用的基础设施位置。