算网一体及其网络技术问题探索-18页.pdf

2023-11-09 22:15
算网一体及其网络技术问题探索-18页.pdf

算网一体及其网络技术问题探索孙滔中国移动研究院2023.10目录算力网络及算网一体01几个网络问题探索02智算DSN展望032常规内容页标题微软雅黑30号字算力网络——迎接智算时代•我国数据中心规模近五年年均增速达到近30%;截至2023年8月,我国在用标准机架超过760万架,算力总规模达197EFLOPS,位居全球第二(工信部2023.10世界5G大会)•中国移动对外可用IDC机架47.8万架,累计投产算力服务器超80.4万台,算力规模达到9.4EFlops(半年报2023.8)•2022年2月,“东数西算”工程正式全面启动,8个国家算力枢纽节点,规划10个国家数据中心集群•算力网络从未来网络的技术名词成为产业发展的旗帜,3端侧算力20ms骨干时延圈枢纽算力省级/区域算力城市边缘算力枢纽算力5m省域时延圈1ms地市时延圈打造“1-5-20ms”三级算力时延圈连续两年财报公布算力规模中国移动呼和浩特智算中心,总能力将达到5.8EFLOPS,万片级AI加速芯片单位/EFLOPS2022年报2023半年报89.4建设亚洲最大单体智算中心哪些“东数”要“西算”?4是否存在一个量化的指标,来指导“东数西算”仍然是待研究的问题数据传输时延不敏感Ø短视频、电子游戏、网络即时通信等时延敏感应用,异地计算无法保障用户体验。数据交互不频繁西部东部ØHPC天气预报等计算过程中不需要频繁交互的应用,可以异地计算。当前,大模型训练往往是同一数据中心内跨框跨机架训练,不会涉及跨数据中心联合训练大模型训练方式大模型训练通信需求•训练过程中的数据同步延迟可能导致整体训练流程停滞•模型规模扩大造成通信量剧烈增长,需提供充足的网络带宽例如,在100Gbps网络下,在16GPU之间执行128MBAllReduce需要至少消耗5ms;数据量进一步增加,理论传输时间会等比例上升。中电联《中国电力行业年度发展报告2023》报告显示2022年全国电力传输线损率4.82%量化指标Ø东数西算协同调度,需要考虑多种因素,如业务需求、时延、成本、能效等。F=A1Delay+A2Cost+A3Energy+...•张量并行:将单个数学运算拆分到不同的GPU上运行•流水线并行:在不同GPU上运行模型的不同层•数据并行:在不同GPU上运行不同的batchdata[1]JaeyongSong,JinkyuYim,JaewonJung,HongsunJang,Hyung-JinKim,YoungsokKim,JinhoLee,2023,Optimus-CC:EfficientLargeNLPModelTrainingwith3DParallelismAwareCommunicationCompression,https://arxiv.org/pdf/2301.09830.pdf端、边、云协同主要包括资源层面和服务层面的协同,不同协同模式在实际应用时均会面临挑战端边云协同是工程领域的难题5①协同调度需要获取端、边、云的状态信息,跨域、跨主体信息获取难度大④需找到开销和性能提升的平衡点,目标场景仍需明确•协同带来了性能提升的同时也引入了额外的开销等,需进一步量化分析开销,寻求性能提升和开销的均衡点•需仔细论证现有研究假设,如端侧、边侧资源不足需要协同或云侧提供服务无法满足时延需求等问题在现网中的实际情况,避免“为了协同而协同”,需继续明确协同场景②服务协同需要改动已有服务支持服务分解,但服务改动驱动力不足③对网络提出了新的需求,网络需增强服务能力•同一个服务分散部署在端、边、云不同位置的服务流量特点不同,需提供差异化的网络服务•协同拉长了服务提供环节,任一个环节的状态变化都需要网络灵活反应,对网、端、边、云的融合与协同提出新需求,保障服务一致性和稳定性;且有隐私性和安全性问题•协同将单个服务分解为多个子服务分散部署,对服务提出新需求•缺乏协同对服务性能提升的有效量化机制,服务侧改动现有机制的驱动力不足•需均衡考虑协同各参与方的目标诉求,在提升性能的同时均衡各方诉求,以驱动服务协同•端、边、云分属不同信息域,信息域内存在不同资源供给主体•打破不同信息域的信息边界缺乏需求驱动,缺乏实际机制屏蔽差异性统一获取状态信息•如即便在云计算信息域内,存在多家大中型云计算提供商,且信息不互通,难以实现跨资源供给主体的协同调度算网一体——算力网络技术发展的方向趋势:网络和计算需要一体化统筹考虑•业务:网络和计算时延需求趋于同一数量级(10Gbps传输时延:20ms~50ms网络复杂多样,无法完全无损链路层误码率不可避免大象流负载不均,存在拥塞丢包多流竞争,存在微突发丢包传统TCP协议在广域数据传输中吞吐受限,有效吞吐与链路时延、丢包率成反比TCP网络吞吐=——————1.22*MSSRTT*Sqrt(L)单流传输时,时延由1ms增加到10ms时,吞吐下降约10倍多流传输使得单流吞吐下降,且受主机CPU性能限制,同样存在吞吐瓶颈科学计算、影视制作,云间灾备等亟需广域超高吞吐传输RFC3649:HighSpeedTCPforLargeCongestionWindows1.如何设计匹配的协议?(2/2)9端网协同的广域高吞吐网络协议体系广域高通量网络云PE云PE超算中心数据源(私有云/公有云)RoCE协议优化新型拥塞控制快速丢包恢复智算中心数据源(存储卡/磁盘)多路径传输贵州到北京数据快递测试贵州FAST北京国家天文台•传输距离远:约2200km•链路时延长:RTT约45ms•链路带宽大:10Gbps•网络类型复杂:云专网、传输网、城域网、DC网络长肥管道传统TCP协议单流435MbpsRoCE协议优化单流7.36GbpsRoCE协议优化是传统TCP协议吞吐的16倍数据传输测试结果①端侧RoCE协议优化,消除端侧吞吐瓶颈②新型拥塞控制算法,提升网络有效利用率③丢包快速恢复算法,降低数据重传尾时延④端到端多路径传输,实现带宽聚合与均衡4个关键技术,实现广域高效数据传输2.路由转发中如何结合算力信息?(1/3)10在路由系统中引入计算因子,实现网络和计算的联合调度优化——算力路由AR/VR时延需要低于20ms保障用户体验,包括:•传感器采样延迟:<1.5ms(客户端)•显示刷新延迟:≈7.9毫秒(客户端)•GPU的帧渲染计算延迟≈5.5ms(服务器)•网络延迟(预算)=20-1.5-7.9-5.5=5.1ms(网络)观察1:计算延迟和网络延迟在同量级•仅根据负载选择边缘站点1,总延迟≈22.4ms•仅根据网络选择边缘站点2,总延迟≈23.4ms•根据两者选择边缘站点3,总延迟≈19.4ms观察2:仅根据网络或计算资源状态,找不到最佳服务器实例结论:需要同时考虑网络和计算资源状态,将流量动态引导到适当的服务节点问题:在对网络和计算都有高要求的场景中,算网的协同调度仍存在待优化的空间IETF立项文稿:draft-ietf-cats-usecases-requirements1.当前缺乏将计算资源与网络状态相结合以决定最优路径和节点的方案。2.现有的解决方案通常为off-path,如DNS、ALTO或L4/L7负载均衡,查询地址/状态的时延随着协议层的升高而升高!技术路径分析L4Sc

点击免费阅读完整报告
© 2017-2023 上海俟德教育科技有限公司
沪ICP备17027418号-1 | 增值电信业务经营许可证:沪B2-20210551
回顶部
报告群
公众号
小程序
APP
在线客服
收起