Media over QUIC：AI 多模态聊天中的低延迟传输探索

如果无法正常显示，请先停止浏览器的去广告插件。

1. Media Over QUIC AI多模态聊天中的低延迟传输探索蚂蚁终端体验科技大会

2. 自我介绍彭堂(花名:巴格) 阿巴巴淘天集团终端平台级技术专家，2009年毕业于北京航空航天学信息与计算科学专业。2013年加阿巴巴今，拥有超过10年的移动端技术架构经验。曾深度参与虾乐、机天猫、机淘宝等核移动客户端的架构设计与性能优化作。在移动端性能保障、络传输优化、多媒体技术等领域有着丰富的实战经验和深的技术洞察。

3. /01 背景 AI多模态面临的技术挑战传统网络方案的局限性 /02 MOQ协议介绍 QUIC协议基础介绍 Media Over Quic协议设计 /03 淘宝MOQ实践技术架构设计服务端设计客户端设计数据对比未来展望

4. ★全球对话式AI市场预计从2025年的170.5亿美元增到2031年的498亿美元 ★语助市场预计以13.6%的CAGR增 2033年达到148亿美元 ★语 AI代理市场预计以34.8%的CAGR增 2034年达到475亿美元，到，到 ✓ 传统持电话更效的交互 ✓ 减少户学习成本的简单界 ✓ 多模态交互能，持语与其他输式结合 ★ 多模态数据传输需要更带宽，特别是清图像和视频 ★ 移动络环境下带宽不稳定，影响多模态数据传输 ★ 多模态数据压缩与优化成为关键挑战 ★ 需要智能带宽分配策略，优先保障关键模态数据 ✤ 实时多模态交互要求端到端延迟低于500ms ✤ 传统HTTP/TCP协议的队头阻塞问题导致延迟波动 ✤ 多模态数据同步处理增加了系统复杂性 ✤ 需要优化的传输协议以满低延迟要求 AI实时多模态应用

5. 多模态AI聊天的延迟要求语本交互 ✓ 理想延迟: <500ms ✓ 可接受延迟: <1000ms ✓ 打字指示器可缓解延迟感知交互视觉交互 ✓ 理想延迟: <200ms ✓ 可接受延迟: <500ms ✓ 超过1000ms严重影响对话流畅度传统协议对 HTTP 1~3秒 RTMP 1~3秒 0.5~1.0秒 WebSocket 延迟传统延迟多数传统协议缺乏内置加密机制，需要额外的安全层中延迟低延迟 0.2~0.5秒 WebRTC ✓ 理想延迟: <300ms ✓ 可接受延迟: <800ms 户容忍度 ✓ 加载指示器可提主要局限性延迟传统网络解决方案的局限性络协议延迟普遍偏，法满实时交互诉求安全性不连接体验差在移动设备中法动切换WIF和蜂窝, 重连耗时协议复杂度 Webrtc的P2P协议需要STUN/TURN服务器穿透，但是AI聊天C/S就可以

6. WebRTC介绍在AI多模态聊天场景中，传统媒体传输协议面临的挑战点对点连接: WebRTC主要设计于端点之间的直接通信，通过P2P 连接减少服务器负担，适合规模的实时通信场景。信令服务器: 需要外部信令服务器协助建连接，交换会话描述协议 (SDP)信息，但信令协议本身不是WebRTC标准的部分。 NAT穿透组件: 包含ICE、STUN和TURN等组件，于解决NAT穿透问题，确保在复杂对于AI多模态应用这种适合C/S架构的场景，有什么更好的解决方案呢? 络环境下也能建连接。

7. /02 MOQ协议介绍 QUIC协议基础介绍 Media Over Quic协议设计

8. QUIC协议发展历程从Google实验到互联网标准的演进之路 2012-2013: 起源 “QUIC最初是作为个实验性协议开发的，旨在解决TCP协议在现代互联环境中的局限性” — Jim Roskind, Google QUIC协议由Google的Jim Roskind设计，2012年次实施和部署，2013年公开宣布并开始在Chrome浏览器中进实验 2015年7 ，Google展示了QUIC为超过92%的连接提供服务的测量结果 2016年，Akamai部署了Google QUIC，成为除Google外最的QUIC部署 2015-2016: 扩展 QUIC开始在Google服务中始关注并测试QUIC协议 2018-2019: 标准化 27 ，IETF发布RFC 9000，QUIC传输协议的标准化版本 2022年9 ，发布RFC 9308，讨论QUIC传输协议的适性型公司开 2021-2022: 正式标准 QUIC成为正式的互联标准，RFC 9000发布，主流浏览器和服务器开始全持QUIC和HTTP/3 从实验到标准 9年 2012-2021 全球QUIC流量占 ~30% 截 2025年，其他 2018年11 ，IETF成员将HTTP over QUIC重命名为HTTP/3，标志着协议标准化的重要程碑 2019年，多家CDN和浏览器商开始实验性持QUIC和HTTP/3 IETF开始QUIC标准化进程，HTTP over QUIC被重命名为HTTP/3，标志着 QUIC从专有协议向互联标准的转变 2021年5 泛部署，流量占迅速增主要采企业 100+ 包括Google、Facebook、Alibaba等

9. QUIC (Quick UDP Internet Connections) 是一种基于UDP的多路复用安全传输协议，旨在提供更低的连接延迟和更高的传输效率。 QUIC协议核心特性基于UDP的传输协议 QUIC建在UDP之上，避开了TCP的限制，同时增加了可靠性机制内置TLS 1.3加密协议层集成加密，提供更件扰 QUIC协议基础介绍安全性，减少中间 0RTT连接建 ★ 次连接仅需1-RTT，重连可实现0-RTT ★通过会话恢复机制存储连接参数 ★显著减少连接建延迟 ★适于频繁连接的场景多路复与队头阻塞 ★单连接上持多个独数据流 ★流之间相互独，避免队头阻塞 ★单个流的丢包不影响其他流 ★提并发传输效率连接迁移 ★ 持IP地址和络切换 IP:端 ★连接ID标识连接流量控制与拥塞控制 ★流级别和连接级别的流量控制 ★基于窗的拥塞控制机制 ★ 持多种拥塞控制算法 ★更精细的丢包检测与恢复 ★可选的前向纠错(FEC) 持 ★移动设备络切换时保持连接 ★提移动场景下的连接稳定性

10. Media Over Quic协议架构 MoQ是一种基于QUIC协议的新一代媒体传输协议，专为低延迟、高可扩展性和安全的实时媒体传输而设计 MOQ 协议架构协议层次结构 ★应层: AI多模态聊天应 ★发布者(Publisher): 负责将媒体内容发送到MoQ 络 ★中继(Relay): 分发媒体内容， ★QUIC层: 流控制、拥塞控制、加密传输★订阅者(Subscriber): 接收和消费媒体内容的终端持扇出和负载均衡 ★对象(Object): 媒体内容的基本单位，具有唯连接数据报传输、直播、视频会议组件 ★MoQ层: 媒体对象、轨道、订阅、发布机制 ★UDP: 核标识

11. Media Over Quic使用示例发布者API示例 // 创建发布者实例 const publisher = new MoQPublisher(transportCon g); // 声明个视频轨道 const trackId = publisher.declareTrack({ namespace: "public", name: "video.main", parameters: { codec: "h264", width: 1280, height: 720 } }); // 发布媒体对象 publisher.publishObject({ trackId: trackId, groupId: 1, sequenceNumber: 42, timestamp: 1636000000, data: videoFrameData }); 订阅者API示例 // 创建订阅者实例 const subscriber = new MoQSubscriber(transportCon g); // 发现可轨道 subscriber.discoverTracks() .then(tracks => { // 处理可轨道列表 console.log("Available tracks:", tracks); }); // 订阅个轨道 const subscription = subscriber.subscribe({ namespace: "public", name: "video.main", startSequence: 42, // 从序列号42开始 priority: 10 // 优先级设置 }); // 处理接收到的对象 subscription.on('object', (object) => { // 处理媒体对象 processVideoFrame(object.data); });

12. 部分可靠性传输可靠性级别选择 MoQ允许应程序为不同类型的媒体内容选择不同级别的可靠性，从完全可靠到完全不可靠之间的多个级别。FEC 作原理发送冗余数据，使接收能够在不请求重传的情况下恢复少量丢失的数据包，减少延迟并提流畅度。实现机制实现技术于完全可靠传输（如关键帧） ✓QUIC流 ✓灵活擦除纠正(Flexible Erasure Correction) 适应FEC编码率，根据络状况调整于不可靠传输（如关键帧）✓ 适应重传策略，基于帧重要性和络状况✓基于跳数(hop)特性的定制FEC策略 ✓时间敏感数据优先传输，过期数据动丢弃✓与编解码器级别的丢包隐藏技术结合 ✓QUIC数据报 ✓ 快速错误恢复早期检测基于序列号和时间戳的丢包早期检测，需等待超时 Media over QUIC 可靠性设计选择性重传仅重传关键数据，关键数据可通过FEC恢复或直接丢弃并恢复多流并恢复，单流错误不影响其他流的传输和恢复

13. MoQ vs 传统流媒体协议特性MoQWebRTCHLS 延迟极低 (<500ms)极低 (<500ms)(3-30s) 可扩展性极有限实现复杂度中等浏览器持通过WebTransport 络适应性低延迟与扩展性 ★ 持百万级并发观众的实时流媒体规模AI多模态聊天场景于络适应性与效率 ★多路复：单连接传输多个媒体流队头阻塞：单个流的丢包不影响 ★ ★保持HLS/DASH级别的持强扩展性结合 (<500ms) ★适原极强 ★同时实现WebRTC级别的低延迟 MoQ在多媒体传输中的优势其他流 ★连接迁移： ★弱 DASH 中- 极极低中等泛持泛中等环境下表现优异持中等简化架构与安全性 ★统协议：采集和分发使同协议 ★内置TLS 1.3加密：强安全性 ★简化实现：络切换时保持连接 (2-10s) WebRTC更易于开发 ★与CDN基础设施兼容

14. MOQ多路复WEBRTC的传输架构 Media over QUIC (MoQ) 使个 QUIC 连接来同时传输普通数据、频和视频内容WebRTC 的 DataChannel 和视频传输使的是不同的底层通道，但它们共享同个 DTLS 连接。 QUIC 连接 ├── Stream 1: 视频轨道 ├── Stream 2: 频轨道 ├── Stream 3: 元数据/控制信息 └── Stream 4: 其他数据通道 DTLS 连接（单个连接） ├── SRTP 通道 │ ├── 频 RTP 流 │ └── 视频 RTP 流 └── SCTP 通道 └── DataChannel（数据传输）单连接多流传输 • QUIC 协议原持在单个连接上创建多个独的流（streams） • 每种媒体类型（频、视频、数据）可以使不同的流进传输 • 流之间相互独，个流的阻塞不会影响其他流优势 • RTP 流之间可能存在队头阻塞（HOL blocking） • SCTP 的多流持有限制 • 不同协议间的协调较复杂视频传输 • 使 RTP/SRTP 协议 • 针对实时媒体优化（允许丢包） DataChannel • 使 SCTP 协议 • 可以配置为可靠或不可靠传输缺点 • 统的 QUIC 流机制，架构简洁 • 所有数据类型使相同的传输抽象 • 更容易实现和维护 MOQ和WebRTC传输架构对比

15. 关键技术差异关键技术差异协议层次 MoQ: 传输层协议，基于QUIC构建 WebRTC: 完整的通信框架，跨越多个协议层架构模型 MoQ: 发布/订阅模型，持对多分发 WebRTC: 点对点通信模型，需要信令服务器延迟性能 MoQ: 研究表明 WebRTC低约30%的延迟 WebRTC: 延迟较，特别是在连接建阶段连接建 MoQ: 0-RTT连接， WebRTC快约60% WebRTC: 需要ICE协商，连接建较慢复杂性 MoQ: 相对简化的协议，实现更加轻量 WebRTC: 复杂但功能全的框架 MOQ和WebRTC技术对比 Media over QUIC 功能特性连接建度速 WebRTC 说明 MoQ连接建 WebRTC快约60% 延迟性能MoQ在延迟点对点通信WebRTC专为点对点通信设计，MoQ主要服务器分发规模分发浏览器兼容性络适应性 WebRTC有约30%的改进向 MoQ设计于规模媒体分发，WebRTC需要额外的SFU/MCU WebRTC在主流浏览器中得到泛仍在发展中持，MoQ MoQ在不稳定络上提供更平滑的体验协议复杂度MoQ提供简化的媒体传输模型，WebRTC协议栈更复杂成熟度WebRTC 2011年发布以来在标准化过程中泛应，MoQ仍

16. MOQ和WebRTC性能对比分析时间带宽效率在带宽利率，Media over QUIC和WebRTC表现相近，但在不同场景下各有优势。在带宽稳定络环境中，两者的带宽利率差异不。然，在带宽波动较的络环境中，MoQ的带宽适应性更好，能够更快地调整到最佳传输速率。 WebRTC在低带宽环境下可能表现更好，因为它的适应特率控制机制更为成熟。

17. MoQ发展路线图 2021: QUIC协议标准化 IETF在RFC 9000中正式标准化QUIC协议，为MoQ奠定基础 2024: MoQ 作组成 IETF成 Media over QUIC (moq) 作组，开始开发低延迟媒体传输解决案 2025: 个商业实现 Cloud are推出全球个MoQ中继在330+城市的服务器上络，运前MOQ协议还在初步发展阶段，基本没有成熟的开源实现，淘宝团队在开源XQUIC的基础上结合我们些新的业务，进了些尝试 MOQ协议的发展和开源实现 kixelated/moq Rust 核特性 • MoQ-lite协议的完整Rust实现 • 持通实时数据传输，不仅限于媒体 • 提供发布者和订阅者API • 持WebTransport和原 QUIC 相关组件 • moq-relay: 转发和缓存服务器 • moq-web: WebAssembly实现 • moq-karp: 媒体特定组件 meetecho/imquic C 核特性 • 专为多媒体应设计的QUIC 库持RTP Over QUIC • 原 (RoQ) • 持Media Over QUIC (MoQ) • 低延迟实时媒体传输特功能 • 与WebRTC互操作性 • 提供中继和订阅者演示 • 持轨道状态管理 • 实验性QUIC堆栈

18. /02 淘宝基于MOQ的AI多模态应用实践技术架构设计服务端设计客户端设计数据对比未来展望

19. 客户端层频采集频播放通信层MOQ实时通信DNS解析服务层数据层淘宝基于MOQ的AI多模态应用实践：系统架构总览语处理服务对话管理服务户数据对话历史语识别(ASR) 语合成(TTS) 意图识别上下管理端侧VAD编解码关负载均衡模型服务户服务 MOQ 语内容成知识检索户管理个性化配置知识库模型数据志

20. XMOQ SDK 基于XQUIC SDK的MOQ协议实现(C/C++) XMOQ 应核应层实现Media over QUIC应协议，负责媒体流的分段、打包和传输控制。持多种媒体格式，提供低延迟的实时媒体传输能。层 Media Over Quic 应协议 XQUIC协议层基于阿巴巴开源的XQUIC实现，提供可靠的传输保障。包含四个核件： QUIC传输层：基于UDP的可靠传输，持连接迁移和0-RTT连接建 TLS 1.3加密层：提供端到端加密，保障数据传输安全拥塞控制：适应拥塞控制算法，优化络吞吐量流量控制：多路复流控制，避免队头阻塞问题 XQUIC协议层 QUIC传输层TLS 1.3加密层拥塞控制流量控制并发管理层线程池多线程管理层实现效的多线程并发处理，提升服务器性能：线程池：动态调度线程资源，优化CPU利率 SO_REUSEPORT：持多线程同时监听同端 SO_REUSEPORT 异步IO层，实现负载均衡异步IO层提供性能的事件驱动IO处理机制，持两种异步IO库： libevent：功能丰富的事件通知库，提供级事件处理能 libev：轻量级事件循环库，提供更低的资源占 libev libevent 组件说明组

21. XQUIC SDK XQUIC 是阿里自研的IETF QUIC标准化传输协议库 [1]

22. XMOQ 模块设计

23. XMOQ 服务端多线程设计线程池设计动态线程管理根据系统负载动调整作线程数量，确保资源效利。持线程数量的动态扩缩，适应流量波动。任务队列优化采锁队列设计，减少线程间同步开销。实现任务优先级调度，确保关键请求优先处理。负载均衡策略实现作窃取算法，允许空闲线程从繁忙线程队列中获取任务。监控线程负载，动态调整任务分配策略。 SO_REUSEPORT机制内核级负载均衡 Linux内核实现的连接分发机制，允许多个线程/进程同时监听同端。内核根据哈希算法均匀分配新连接，避免"惊群效应"。性能优势消除了传统多线程服务器中的锁竞争，显著提并发场景下的性能。测试表明，在负载下可提升吞吐量30-50%，降低延迟波动。实现式在socket创建后，bind前设置SO_REUSEPORT选项。每个作线程独创建 socket并绑定到相同端，内核负责分发连接。

24. 关层 XMOQ 服务端动态路由转发 * 此案允许根据业务定义的路由字段（如集群名称，机器ip等）进动态转发决策。

25. 基于加密连接ID (CID)的转发 ● MoQ Proxy接收到客户端的Initial Packet后，使 CID进其本地存储的相同密钥对解密。 ● 解密成功后，提取出标服务器的IP与端。 ● 为保证内安全，Proxy会校验该IP是否存在于对应业务注册的VIP Server机器列表中，防恶意访问。 ● 验证通过后，Proxy将该QUIC连接的所有后续流量直接转发该指定服务器。

26. 动态路由转发

27. 网络传输层优化拥塞控制算法 SQP算法概述 SQP (Swift Queue Processing) 是由Google开发的种专为低延迟交互式视频流应设计的拥塞控制算法，特别适于AR流媒体平台。 • 设计标：最化延迟同时保持吞吐量 • 核特点：基于队列感知的速率控制 • 应场景：AR/VR、云游戏、远程桌 • 发布时间：2022年由Google研究团队发布 Pudica算法概述 Pudica是种专为云游戏等低延迟交互式应设计的拥塞控制算法，由研究员于2024年提出。其核标是实现近零排队延迟和链路利率，同时保持跨流公平性。核设计标我们在线上环境进了 AB 实验，相较于 WebRTC， MoQ 案的平均码率提升了约 40%，操作延时降低了约 7% • 实现近零排队延迟，提升交互式体验 • 保持链路利率，避免带宽浪费 • 尊重跨流公平性，与其他流量和谐共存 • 适应动态络条件，快速响应变化

28. FEC（Forward Error Correction 前向纠错技术）是种可以通过在发送正常数据包之外同时发送些冗余数据包，在部分原始数据包丢失的情况下，可以利这些冗余数据包来快速恢复原始数据包，从避免重传的RTT，利极的额外带宽开销，来减少这长尾情况下重传的时延。对于MOQ ，我们主要是以个频/视频帧来作为传输的基本单位，也会持在帧级别灵活的开启和关闭FEC 这功能：对于视频，I帧（关键帧） P帧（普通帧）更为关键，I帧体积是明显于P帧的，重传的代价更。我们希望通过FEC来减少I帧重传带来的延迟；对于P帧传输或者频传输的场景，则视具体情况由户选择是否开启FEC。此外我们可以根据不同的业务场景来调整FEC冗余率的，可以允许对不同场景下的重传率，调整FEC冗余率以获得最低时延，达到最好的效果。前，MOQ+FEC已经在线上取得了些传输效果的优化。我们能够以5%的冗余率取得约10%左右的单向时延降低。网络传输层优化 FEC+MOQ流程结构

29. 连接耗时 ( 次)连接耗时 (0RTT)单向通信延迟 150ms<50ms40~60ms 蜂窝和Wi 性能数据麦克风初始化耗时389ms 络连接耗时23ms 次505ms 频数据发出耗时络数据耗时次收到可渲染动切换项次收到网络优化效果本数据耗时 63ms 1737ms

30. 端到端语音处理流程

31. 3A算法机操作系统（IOS/安卓/鸿蒙）都带频采集系统 API，并且提供了频处理的 3A 算法实现，包括： 1.AEC（Acoustic Echo Cancellation，声学回声消除）作：在免提或会议场景中，扬声器的声会被麦克风再次拾取并形成回声。AEC 通过估计扬声器到麦克风路径的回传信号并将其从麦克风信号中抵消，去除回声。 2.AGC（Automatic Gain Control，动增益控制）作：根据说话声的强弱动放或衰减量，使语保持在相对恒定、合适的响度范围，避免忽忽。 3.ANS / NS（Automatic Noise Suppression 或 Noise Suppression，动噪声抑制 / 降噪）作：检测并衰减背景噪声，如空调声、键盘声、风噪等，突出语本，提升清晰度和可懂度。频引擎初始化端侧VAD 回声消除向性声端侧音频引擎优化录制

32. 音频引擎初始化

33. 什么是回声？当扬声器发出的声被者时，就会产回声。克捕获并传回给原始发送回声消除的标识别并消除回声信号，同时保留原始语性和清晰度。回声产信号的完整的原因 1 声学耦合扬声器和克之间的直接声学路径导致声被重新捕获。 2 环境反射声从墙壁、桌和其他表反射回克，产复杂的回声路径。 3 设备特性移动设备的尺使扬声器和克距离很近，增加了回声险。 4 线性失真扬声器和克的线性特性导致回声信号变形，增加消除难度。回声消除和方向性音频录制作原理 • 声以不同时间到达各个克 • 通过计算时间差或相位差确定声源向时间延迟"补偿各克通道 •应 ” • 合成处理后的信号，增强标向声

34. 端侧VAD可以有效控制成本输单价（每千Token）模型名称 0.0016元0.025元0.006元0.0064元0.018元输出：本+ 频仅频计费 0.05元 0.0016元0.025元0.006元0.0064元0.018元0.05元 0.0016元0.025元0.006元0.0064元0.018元0.05元输 qwen-omni- turbo-realtime qwen-omni- turbo-realtime- latest qwen-omni- turbo- realtime-2025-0 Token和频时：：频：图 /视输出：本仅纯本输输出：本多模态输 1秒频的token数 1分钟频的token数 Qwen3-Omni503,000 GPT-4o Audio1509,000 Gemini321,920 输的对应关系模型本输频输出单价（每千Token）

35. 端侧VAD技术架构采用模块化设计，通过流水线处理实现高效的语音活动检测。系统在保证实时性的同时，平衡资源占用，适配iOS和Android平台的特性语音活动检测技术在移动应用中有广泛的应用，特别是在AI语音聊天应用中发挥关键作用。语助交互准确检测户何时开始和结束说话，提交互然度语识别优化过滤语段，提语识别准确率，减少错误识别络带宽优化仅传输有语的频段，减少数据传输量，节省带宽电池寿命延减少不必要的频处理，降低设备能耗，延电池寿命核 SNAudioStreamAnalyzer 设计频采集与预处理 VAD核检测 • 频采集：16kHz采样率，16bit深度 • 特征提取：MFCC/Fbank/频谱特征 • 帧：20-30ms，帧移：10-15ms • 轻量级神经络：CRNN/ResectNet • 预加重、分帧、加窗处理 • 流式处理：逐帧实时决策 • 噪声抑制与频增强。 • 模型量化：INT8/FP16优化端侧语音VAD技术架构设计场景 CPU内存延迟 8-17%30 MB< 100ms 多个分类器15-25%50 MB< 150ms 定义模型20-40%80 MB100-300ms 单个声分类

36. 语音服务架构 ASR+LLM+TTS 核技术 ASR Whisper、Conformer等先进模型，持多语识别LLM 接 Qwen、Claude、Llama 等本模型 TTS VITS、FastSpeech2等模型，持然语合成流式处理在语输过程中就开始处理，减少等待时间优化技术多线程和并执 LLM 成和TTS合成可并操作，减少总体延迟流式API 同时优化STT、LLM和TTS的流式处理，实现实时交互组件共置将ASR、LLM和TTS进程部署在同服务器以减少络延迟模型量化和蒸馏减模型，加快推理速度，降低资源消耗缓存机制常响应和部分成结果可以缓存以提响应速度

37. 技术架构核能多语本图像频视频单语输出语开始和结同时输出本和实时交互体验端到端语处理直接从语转换步骤到语然语，实现流畅的处理，需中间本技术优势 ✓简化架构：单 ✓ 原端到端多模态架构，单模型处理多种输 ✓ Thinker-Talker架构：Thinker负责推理，Talker 负责语输出 ✓ 基于先进Transformer架构，专为跨模态信息处理优化输活动检测内置VAD功能，动检测语束，提升交互然度多模态模型本输出实时流式响应持持119种本语，19种语和10种语输出语语语音服务架构多模态大模型模型替代传统的ASR+LLM+TTS管道 ✓更低延迟：端到端处理减少了模块间传递的延迟 ✓更然的交互：实时流式响应使对话更加流畅 ✓更效的资源利：单模型多模型管道需要更少的计算资源

38. 核对适 ASR+ 本模型+TTS Qwen3 Omni Flash 架构复杂性(多模块串联)低 (单端到端延迟(300-700ms)低 (可达200ms以下) 技术成熟度(成熟技术栈)中 (新兴技术) 定制化能(各组件可独优化)低 (整体模型需重新训练) 模型) 资源消耗(多模型部署)中 (单可解释性(模块化为可追踪)低 (端到端盒特性) 中 (模块间信息损失) 然度对维度交互两种方案优缺点对比模型) (保留语特征) 场景 ASR+LLM+TTS适合: ✓ 需要度定制化的应 ✓ 需要频繁更新和迭代的系统 ✓对语种有特殊持需求 Qwen3 Omni Flash适合: ✓ 需要极低延迟的实时对话 ✓ 资源受限的部署环境 ✓ 需要然流畅交互体验

39. XMOQ 流式 qwen3-omni- ash-realtime 本输出频打断端侧VAD 基于XMOQ的AI多模态聊天Demo

40. 浏览器兼容性 (safari不内置TLS加解密开销态不够成熟 MOQ存在的问题持) 服务端中间件兼容性协议发展中，变化较

41. Media over QUIC 核 WebRTC 核优势与局限泛的浏览器持所有主流浏览器原安装持，需插件或额外队头阻塞和多路径持个包的丢失不会影响其他包的传输，提了在不稳定络环境下的性能成熟的态系统丰富的开发具、库和社区难度持，降低开发规模分发能发布-订阅模型和中继系统设计，天然持规模媒体分发强的点对点能为型视频会议和性能标准化进中和兼容性问题作为新兴技术，标准化作仍在进能临变更复杂的协议栈多种协议组合导致实现复杂，连接建优势与局限超低延迟基于QUIC协议，提供约100ms的端到端延迟， WebRTC低约30% 态系统不成熟相 WebRTC，总结中，可具、库和持资源较少对通信场景提供优秀规模分发挑战需要额外的SFU/MCU服务器体分发持时间规模媒

42. 协议优化与标准化混合架构的兴起 MoQ将继续在IETF进标准化，预计在未来年内完成。同时，WebRTC将与 WebTransport、WebCodecs等新兴标准集成，提供更灵活的媒体处理能。两种技术都将持续优化其性能和安全性。随着技术的发展，我们可能会看到MoQ和 WebRTC在同系统中协同作的混合架构。例如，使 MoQ进规模媒体分发，同时利 WebRTC进组互动。研究表明，这种互操作性已经在实验室环境中得到了验证。技术融合与互操作随着标准化的推进，MoQ和WebRTC将实现更好的互操作性，允许两种技术在同系统中协同作。研究表明，已有实际演示证明WebRTC和MoQ之间的互操作性是可的。 AI与实时通信结合智能将与实时通信技术深度融合，提供更智能的媒体处理、动内容分析、实时翻译和个性化体验。WebRTC和MoQ都将受益于这趋势。市场增与采 WebRTC市场预计在2025-2029年间增 2477亿美元，CAGR约为62.6%。同时，随着Cloud are等型企业推出MoQ服务，MoQ的采率也将快速增，特别是在规模直播和内容分发领域展望未来互补替代 MoQ和WebRTC更可能是互补关系替代关系。MoQ专注于规模、低延迟的媒体分发， WebRTC专注于点对点通信和型会议。未来的实时通信系统可能会根据具体场景动态选择最适合的协议。统 API的可能性随着标准化的推进，我们可能会看到统的API 出现，允许开发者缝切换或同时使 MoQ和 WebRTC。这将简化开发流程，并为不同场景提供最佳性能。

43. 参考 https://www.meetecho.com/blog/moq-webrtc/ https://datatracker.ietf.org/group/moq/about/ https://blog.cloud are.com/moq/ https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Media-Over-QUIC-and-the-Future-of-High- Quality-Low-Latency-Streaming-167165.aspx https://www.qualabs.com/blog/media-over-quic-the-streaming-protocol-rede ning-low-latency-scalable-and- secure-media-delivery https://www.meetecho.com/blog/moq-webrtc/

44. Thanks