孙滔：算网一体及其网络技术问题探索

孙滔中国移动研究院2023.10 目录 智算DSN展望 几个网络问题探索 算力网络及算网一体 算力网络——迎接智算时代 常规内容页标题微软雅黑30号字•我国数据中心规模近五年年均增速达到近30%；截至2023年8月，我国在用标准机架超过760万架，算力总规模达197EFLOPS，位居全球第二（工信部2023.10世界5G大会） •中国移动对外可用IDC机架47.8万架，累计投产算力服务器超80.4万台，算力规模达到9.4EFlops（半年报2023.8）•2022年2月，“东数西算”工程正式全面启动，8个国家算力枢纽节点，规划10个国家数据中心集群•算力网络从未来网络的技术名词成为产业发展的旗帜， 中 国 移 动 呼 和 浩 特 智 算 中 心 ， 总 能 力 将达 到5 . 8 E F L O P S， 万 片 级A I加 速 芯 片 哪些“东数”要“西算”？ 是否存在一个量化的指标，来指导“东数西算”仍然是待研究的问题 不敏感中电联《中国电力行业年度发展报告2023》报告显示2022年全国电力传输线损率4.82% 时延 Ø东数西算协同调度，需要考虑多种因素，如业务需求、时延、成本、能效等。 ØHPC天气预报等计算过程中不需要频繁交互的应用，可以异地计算。 Ø短视频、电子游戏、网络即时通信等时延敏感应用，异地计算无法保障用户体验。 当前，大模型训练往往是同一数据中心内跨框跨机架训练，不会涉及跨数据中心联合训练 大模型训练通信需求 大模型训练方式 •训练过程中的数据同步延迟可能导致整体训练流程停滞 •模型规模扩大造成通信量剧烈增长，需提供充足的网络带宽 •张量并行：将单个数学运算拆分到不同的GPU上运行•流水线并行：在不同GPU上运行模型的不同层•数据并行：在不同GPU上运行不同的batch data 例如，在100Gbps网络下，在16 GPU之间执行128MB AllReduce需要至少消耗5ms；数据量进一步增加，理论传输时间会等比例上升。 端边云协同是工程领域的难题 端、边、云协同主要包括资源层面和服务层面的协同，不同协同模式在实际应用时均会面临挑战 ②服务协同需要改动已有服务支持服务分解，但服务改动驱动力不足 ①协同调度需要获取端、边、云的状态信息，跨域、跨主体信息获取难度大 •端、边、云分属不同信息域，信息域内存在不同资源供给主体•打破不同信息域的信息边界缺乏需求驱动，缺乏实际机制屏蔽差异性统一获取状态信息•如即便在云计算信息域内，存在多家大中型云计算提供商，且信息不互通，难以实现跨资源供给主体的协同调度 •协同将单个服务分解为多个子服务分散部署，对服务提出新需求•缺乏协同对服务性能提升的有效量化机制，服务侧改动现有机制的驱动力不足•需均衡考虑协同各参与方的目标诉求，在提升性能的同时均衡各方诉求，以驱动服务协同 ④需找到开销和性能提升的平衡点，目标场景仍需明确 ③对网络提出了新的需求，网络需增强服务能力 •协同带来了性能提升的同时也引入了额外的开销等，需进一步量化分析开销，寻求性能提升和开销的均衡点•需仔细论证现有研究假设，如端侧、边侧资源不足需要协同或云侧提供服务无法满足时延需求等问题在现网中的实际情况，避免“为了协同而协同”，需继续明确协同场景 •同一个服务分散部署在端、边、云不同位置的服务流量特点不同，需提供差异化的网络服务•协同拉长了服务提供环节，任一个环节的状态变化都需要网络灵活反应，对网、端、边、云的融合与协同提出新需求，保障服务一致性和稳定性；且有隐私性和安全性问题 算网一体——算力网络技术发展的方向 趋势：网络和计算需要一体化统筹考虑 •业务：网络和计算时延需求趋于同一数量级(<=10ms)•计算：大规模分布式计算等的通信问题成为瓶颈•网络：从连接主机(互联网)向连接算力（算力网络）转变 优势：算网一体化可以提升系统整体性能和资源利用率 •通过泛在、平台化网络连接计算资源孤岛，提升资源利用率•通过网络和计算因子的深度融合和一体化调度，实现低成本和高性能兼具 核心问题 •匹配的协议：大量数据如何长距离高吞吐传输，东数如何西送？•优化的路由：网络资源与计算资源的协同选择，业务在边边/边云之间调度•高效的计算：能否网中算，如高性能计算能否卸载在网内？ 目录 智算DSN展望 几个网络问题探索 算力网络及算网一体 1.如何设计匹配的协议？（1/2) 常规内容页标题微软雅黑30号字智算、超算业务对广域数据传输提出新的要求，在有损长肥网络中高效传输海量数据 科学计算、影视制作，云间灾备等亟需广域超高吞吐传输 属于长肥网络（LFN）RFC1323，大BDP网络传输带宽：>10Gbps传输时延：20ms~50ms 网络复杂多样，无法完全无损 数据量在TB/PB级别 天文观测：TB~PB/次基因测序：TB~100TB/次影视渲染：10TB~100TB/节目 链路层误码率不可避免大象流负载不均，存在拥塞丢包多流竞争，存在微突发丢包 传统TCP协议在广域数据传输中吞吐受限，有效吞吐与链路时延、丢包率成反比 多流传输使得单流吞吐下降，且受主机CPU性能限制，同样存在吞吐瓶颈 TCP网络吞吐= ——————1.22*MSSRTT*Sqrt(L)单流传输时，时延由1ms增加到10ms时，吞吐下降约10倍 1.如何设计匹配的协议？（2/2) 端网协同的广域高吞吐网络协议体系 4个关键技术，实现广域高效数据传输 数据传输测试结果 ①端侧RoCE协议优化，消除端侧吞吐瓶颈②新型拥塞控制算法，提升网络有效利用率③丢包快速恢复算法，降低数据重传尾时延④端到端多路径传输，实现带宽聚合与均衡 RoCE协议优化单流7.36Gbps 传统TCP协议单流435Mbps RoCE协议优化是传统TCP协议吞吐的16倍 2.路由转发中如何结合算力信息？(1/3） 问题：在对网络和计算都有高要求的场景中，算网的协同调度仍存在待优化的空间 技术路径分析 1.当前缺乏将计算资源与网络状态相结合以决定最优路径和节点的方案。 AR/VR时延需要低于20ms保障用户体验，包括： •传感器采样延迟：＜1.5ms（客户端）•显示刷新延迟：≈7.9毫秒（客户端）•GPU的帧渲染计算延迟≈5.5ms（服务器）•网络延迟（预算）=20-1.5-7.9-5.5=5.1ms（网络） 2.现有的解决方案通常为off-path，如DNS、ALTO或L4/L7负载均衡，查询地址/状态的时延随着协议层的升高而升高! 观察1：计算延迟和网络延迟在同量级 •仅根据负载选择边缘站点1，总延迟≈22.4ms•仅根据网络选择边缘站点2，总延迟≈23.4ms•根据两者选择边缘站点3，总延迟≈19.4ms 观察2：仅根据网络或计算资源状态，找不到最佳服务器实例 结论：算力路由将具备更高的性能 结论：需要同时考虑网络和计算资源状态，将流量动态引导到适当的服务节点 IETF立项文稿：draft-ietf-cats-usecases-requirements IETF文稿：draft-draft-yao-cats-gap-analysis 2.路由转发中如何结合算力信息？(2/3） 算力路由在路由系统引入计算信息，是对传统互联网设计理念的挑战 技术方向：简单高效的算力信息封装 挑战1：算力建模和度量 算力信息维度较多，需要定义面向路由的高可用性计算信息，兼顾报文封装成本以及可用性 统一量纲，使用与网络和业务相同的度量维度信息，应用于路由调度，例如通过BGP Path Attribution扩展封装计算时延信息 技术方向：自适应的算力通告 挑战2：算力感知和通告 提出分域通告、分类通告，约束算力信息更新的范围，减少算力信息的无效通告通过仿真建模量化分析算力信息通告信令开销的影响，得到通告信令开销与路由调度成功率的最优解 通告频率越高，算力信息越实时，但开销越大，如何找到通告信令开销与信息实时性的平衡点 技术方向：新型算网多因子算路算法 挑战3：多维路由选址 构建算力路由信息表（CA-RIB），考虑距离因子、算力因子以及权重，生成算网cost=w1*网络cost+w2*算力cost 在距离矢量上叠加算力向量，改变了传统选路方法，简单叠加将导致路由不收敛 2.路由转发中如何结合算力信息？（3/3） 已经完成场景和需求立项，即将推动面向AI大模型的场景写入项目标准 推动CATS架构立项 Ingress CATS-Router： 基于CATS的分布式推理 基于CATS+AI的内容获取 •CATS Traffic Classifier(C-TC):区分是否是CATS流量，决定服务节点•CATS Path Selector(C-PS)：选择网络转发路径 AI-based MediaDistribution andTraffic Steering Egress CATS-Router： •CATS Network Metric Agent(C-NMA):收集和分发网络指标•CATS Service Metric Agent(C-SMA):收集和分发服务和计算指标 CATS-control center： 数据中心多节点之间联合推理，基于CATS完成高效地计算和调度任务 多边缘计算节点同时提供内容获取服务，基于CATS完成智能化的多媒体内容获取和调度 BBC:ai4me.surrey.ac.uk •CATS Computing information Base(C-CIB)：维护细粒度的计算信息•CATS Network Metric information Base(C-NIB):维护细粒度的网络信息•CATS Path Calculation Unit(C-PCE):计算最合适的网络路径和选择服务节点•CATS-SBI interface:CATS-control center与CATS-Router的接口 阿里：draft-an-cats-usecase-ai 3.如何高效的算？（ 手段：引入在网计算实现AI集群计算性能跃升 需求：大规模AI计算集群通信瓶颈问题显著 带宽资源占用高 在网计算主要优势 千亿参数大模型基于MoE并行模式训练，单机单轮次Allreduce流量达数10GB，占用大量带宽资源【1】 【1】DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training toPower Next-Generation AI Scale 数据迁移成本大 大模型约37%的运行时间消耗于访存算子【2】，计算节点间存在大量数据搬运 【2】Data Movement Is All You Need: A CaseStudy onOptimizing Transformers 通信模式不匹配 进程间多对一、一对多及多对多的通信在计算节点间以单播实现，物理网络存在大量冗余信息 考虑基于开放Ethernet设计在网计算架构，优化应用处理逻辑，为系统算效提升带来质变 3.如何高效的算？（ 在网计算改变互联网数据传输模式，从“端到端”到“端网端” 理念转型 技术挑战 拓扑感知+在网计算 消息-报文语义映射2 应用-IP一发多收机制3 “端网端”可靠性1 复杂网络拓扑结构下，拓扑感知算法需要与在网计算相结合，实现计算任务网内合理分配 AI业务中集合通信的一发多收逻辑目前基于点到点IP通信实现，需要进一步与IP组播结合优化 进程message传输与网络packet转发需要映射匹配，将影响packet组合、buffer管理以及消息收发速率 TCP、QUIC等传输层可靠性机制面向点到点设计，难以实现多对一通信可靠性机制 https://wiki.ietf.org/meeting/118/sidem