大频道分发、高清体验、智能编解码与 Agent 通信｜iRTE2026 新一代 RTE 技术专场回顾

几十万人同时观看一场直播，开播、抽奖或结束时可能出现瞬时流量高峰。一部普通手机上的高清视频通话，则要在有限的算力与电量下保持清晰、流畅。当实时音视频的接收者从人扩展到 AI Agent，通信系统还需要考虑机器能否及时获取关键信息，并用于后续任务。

这些场景对实时互动提出了不同的工程要求：大频道需要应对突发流量与故障扩散，移动终端需要平衡音画质量与资源消耗，面向 Agent 的通信则需要在传统音画指标之外考虑任务效果。支撑这些能力的分布式软件研发与编解码技术，也面临可靠性和效率方面的挑战。

10 月 24 日，在 iRTE2026 实时智能大会「新一代 RTE 技术专场」 ，由声网首席前端架构师郝连福 主持，六位讲者分享了各自的工程实践与技术探索：声网云平台负责人朱仁琪 、环信技术架构师邹勇 、声网视频工程负责人许振明 、北京理工大学信息与电子学院教授、博士生导师王晶 、杭州电子科技大学高级工程师赖昌材 ，以及资深通信与互联网音视频架构专家林正显。分享内容涵盖全球实时媒体网络、AI 辅助分布式软件研发、高清音视频体验、智能编解码与 RTC 技术演进。

朱仁琪｜58 万人同时在线，大频道如何应对瞬时流量与故障扩散？

声网云平台负责人朱仁琪以一场与 MrBeast、Whatnot 相关的海外直播活动为例，介绍了大频道的技术挑战。这场直播的单频道同时在线人数峰值约为 58 万，声网则提前准备了约 100 万并发用户的承载能力。

然而，容量充足并不意味着直播就能平稳运行，开播、抽奖或结束时，大量观众集中进入或离开频道，可能给媒体分发和调度带来瞬时压力，与此同时，实时互动对时延有严格要求，系统不能简单依靠增加缓冲或重传来维持稳定。

针对不同规模的频道，系统需要采用不同的媒体分发架构。较小频道可以采用网状分发，减少转发层级；大频道则通过分层的树状结构分散节点负载。在此基础上，依托 SD-RTN 全球实时媒体网络进行跨区域调度，并通过故障隔离机制，避免局部异常影响整个频道。

对于只有一位主播的大频道，风险还可能集中在源头。无论是主播设备、上行网络，还是源流分发链路发生异常，都可能影响大量观众。因此，需要重点监测主播侧关键链路，并通过链路切换、异常恢复和必要的资源冗余，降低故障带来的影响。

邹勇｜AI 生成代码变快之后，如何证明系统真的可靠？

AI 可以加快代码生成，却无法保证需求被准确理解。尤其在跨模块、长期运行的分布式系统中，错误假设可能同时进入实现和测试，让「全部通过」的结果掩盖真实问题。

环信技术架构师邹勇分享了 AI 辅助大型分布式软件研发的实践：先把业务需求转化为可检查的约束，再通过持续集成、自动化测试与人工审核验证生成结果。

在现场问答中，他进一步提出，应以独立的黑盒端到端测试检查系统对外提供的功能，尤其关注跨模块交互时才会暴露的问题，避免测试与实现依赖同一套错误假设。

许振明｜高清音视频体验，为什么不能只看分辨率？

同一场高清视频通话，在不同性能的手机上，用户获得的体验可能截然不同。提升画质往往意味着更高的计算开销、功耗和发热，甚至可能影响帧率与流畅度。如何让更多真实设备稳定获得高清体验，而不只是在理想测试条件下实现高清？

声网视频工程负责人许振明从质量保障体系出发，介绍了相关工程实践：上线前，通过云端测试覆盖不同设备、系统与使用场景；上线后，持续跟踪无图、无声、卡顿、回声、画质下降和时延过高等实际问题，并将异常与具体终端、网络条件和使用场景关联起来，避免仅凭整体平均指标判断用户体验。

发现问题后，还需要结合设备分级与 CPU 性能分析，判断瓶颈来自终端算力限制，还是具体处理环节。再针对不同设备调整画质、帧率和处理策略，在清晰度、流畅度、功耗与发热之间取得平衡。

王晶｜低码率语音怎样压缩，才能不把人说的话一起「消掉」？

语音压缩的难点，不只是把数据量降下来，还要保留足够的信息，让人听懂说话内容。在卫星通信和弱网通话等带宽受限的场景中，这种取舍尤为突出：码率越低，能够保留的语音信息越有限；如果再叠加降噪与增强，模型还可能将部分真实发音误判为噪声并去除，造成漏字或「吞字」。

北京理工大学信息与电子学院教授、博士生导师王晶介绍了将语音压缩与增强相结合的研究模型 UJCodec。该模型采用 U-Net 风格的编码器---解码器结构及跳跃连接，并利用 FSQ（有限标量量化）对中间语音表示进行离散编码，力求在低码率下保留语音的可懂度，同时减少噪声干扰。

针对「吞字」问题，团队采用分阶段训练，并模拟中间语音表示受损的情况，以减少模型在压缩和降噪过程中误删真实语音片段的风险。报告还展示了包括 750 bps 在内的低码率研究实验，以及 1--6 kbps 的卫星通信系统演示。

赖昌材｜JPEG AI 如何跨过开发板与手机的实时运行门槛？

神经网络模型能完成图像压缩，并不代表它已经能在开发板与手机上持续处理实时画面。算力分配、数据搬运以及计算单元之间的等待，都可能成为部署瓶颈。

杭州电子科技大学高级工程师赖昌材以 JPEG AI 为例介绍了异构部署优化：让 CPU 与专用加速单元分别承担适合的计算环节，通过跨帧流水线、缓冲区管理和同步调度减少等待与数据搬运；手机端则继续优化解码计算和内存使用。

报告分别展示了编码端和解码端的性能优化结果：在 AX650N 开发板上，1080p 图像编码由早期约 5 fps 提升至约 25.46 fps ；在搭载 Snapdragon 8 Gen 2 的安卓设备上，1080p 单帧解码耗时从 43 ms 降至 22 ms。前者衡量板卡编码吞吐，后者衡量手机单帧解码耗时。

此外，报告还展示了 「开发板编码---网络转发---手机解码与显示」 的验证链路。这一演示通过逐帧编码 JPEG AI 静态图像来形成连续画面，主要用于验证编解码与网络转发链路。演示界面显示约 26.1 fps 的画面帧率、25 ms 的解码耗时和 3.17 Mbps 的平均码率。

林正显｜从人与人到人与 Agent，RTC 的网络、编码与评测如何演进？

在人与人的实时通信中，画面清晰度、声音连贯性和响应时延，是评价互动体验的重要依据。但如果接收端是要识别画面并执行任务的 Agent，清晰并不总等于理解正确。

资深通信与互联网音视频架构专家林正显在「新业态下的 RTC 技术：挑战与演进」中，讨论了通信对象从人与人扩展到人与机器、人与 Agent 后带来的变化。他把后续挑战归纳为网络长尾延迟、传输与会话架构、神经编解码实时化，以及实时交互式 AI 四个方向。

围绕网络时延、媒体分发和编解码鲁棒性，林正显讨论了三个不同层次的技术方向：

L4S 侧重通过拥塞信号与反馈降低网络排队时延；
MoQ（Media over QUIC） 探索面向实时媒体的传输和分发架构；
JSCC（联合信源信道编码） 则在编解码设计中联合考虑信道影响与重建效果。

面向 Agent，还需要重新审视质量指标，PSNR 反映重建图像的误差水平，VMAF 用于评估视频的感知质量，MOS 体现主观质量评价；但这些面向人类观看或聆听的指标，不足以单独判断机器是否识别了关键信息、是否及时获得输入，以及任务是否成功。因此，面向 Agent 的评测需要兼顾音画质量与任务结果。

林正显还讨论了 RTC 与 AI 处理管线的编排问题，包括流式并行、打断与轮次控制、多模态处理及状态一致性。RTC 系统是否需要进一步感知 Agent 的运行状态，并参与模型路由与计算---网络协同调度，也成为值得探索的方向。

从六场分享中可以看到，一次技术优化究竟解决了什么问题，仍然需要放回真实的网络、设备与完整交互中检验。当通信对象与应用场景不断扩展，对「实时」的理解和衡量方式，也在随之改变。