当用户打开豆包的视频通话功能，将镜头对准孩子的作业本，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应用的核心位置。