★ FEATURED ARTICLE 有个做网络规划的朋友最近问我800G到底是不是噱头他说他手里的400G网络才跑满两年现在一下子冒出800G、112G SerDes还要提Terabit Ethernet是不是厂商在“挤牙膏”。这个问题背后其实是很多人共同的困惑——800G到底解决了什么真实问题为什么非要跑到112Gb/s这个速率而不能用现成的技术继续凑合。这篇文章我就把这个“Why”讲透。我会从三个角度拆数据中心到底缺不缺带宽、112G SerDes为什么是这个时代的最优解、以及800G落地过程中要面对的功耗和形态之争。最后把目光放到Terabit Ethernet这条更长的时间线上看看1.6T会在什么时候、以什么方式到来。文章内容偏技术但我尽量不用“术语轰炸”适合正在规划下一代数据中心网络的工程师、做光模块和交换机的硬件同学以及想知道“AI集群为什么需要这么高速率”的开发者。1. 带宽需求的“剪刀差”算力翻倍的速度远比网络快1.1 单机算力涨得越快网络就越容易拖后腿很多人以为数据中心网络升级是被“视频流量”“云服务”这些传统业务推着走的实际上真正把带宽需求推上800G的是AI训练集群这一波。过去CPU时代有个不成文的经验CPU单核性能每18个月翻一倍网卡速率也同步从1G升到10G、25G基本能维持平衡。但到了GPU和NPU时代这个平衡被打破了——计算芯片的并行能力按千卡、万卡规模横向扩展算力翻倍的时间从18个月缩短到几个月而网络SerDes速率的标准迭代周期仍然是三到四年。这里就出现一个“剪刀差”单卡算力提升速度远快于网络速率提升速度。拿大规模训练场景举例。千亿参数模型要把数据切到几百甚至几千张卡上并行计算每完成一步迭代所有卡都要通过集合通信把梯度同步一遍。这个同步过程是“木桶效应”——一个节点网络慢了整个集群都在等它。我实际见过的情况是某团队从100G接入升到400G接入后训练任务的GPU利用率从60%出头提到了80%以上同样的卡光靠换网络就把有效算力拉高了整整一截。这是非常直观的收益不是纸面收益。存储侧的压力同样不小。训练过程要周期性地保存checkpoint模型规模大了之后一份checkpoint就是几十个TB甚至几百个TB如果存储网络带宽不够保存状态的过程会让整个训练停下来等I/O。这本质上也是带宽缺口。所以“为什么要搞800G”的答案第一层很简单计算侧的吞吐到了只靠100G/400G喂不饱的阶段网络成了新一轮性能瓶颈。这跟当年“CPU太快、硬盘太慢”要引入SSD的逻辑一模一样。1.2 东西向流量爆炸交换机总吞吐才是最硬的指标第二个原因是数据中心的流量结构变了。传统数据中心南北向流量居多用户请求进来、数据返回去链路利用率不算极端。但现代的分布式架构里服务之间互相调用、数据副本同步、微服务通信、中间结果缓存绝大部分流量是东西向的也就是服务器之间横着跑。这种流量模式下真正决定数据中心能力的是交换网络的“总吞吐”而不是单个端口速率。而交换机前面板的空间是物理固定的在一个固定尺寸的设备里单端口速率越高整机总吞吐就越高布线复杂度也越低。举个例子一台交换机前面板能提供32个端口如果每端口是100G总吞吐只有3.2T升级到400G后总吞吐变成12.8T到了800G就是25.6T。对大型数据中心来说同样的总带宽需求端口少意味着光纤芯数少、链路少、运维点少总成本下降是实打实的。所以即便单模块更贵从整网投入看仍然可能是省钱的。这里还要补充一个容易被忽略的点光电互连的“每bit成本”其实在持续下降但下降的曲线取决于单通道速率提升。800G的价值不是把4个100G塞进一个模块那么简单而是用8个100G/lane的通道取代原来16个50G/lane的通道通道数砍半对应光纤、连接器、激光器数量都在减少。芯片引脚数是有限的通道数越少ASIC能带出来的总带宽就越高。这决定了800G不是“更快的400G”而是网络架构层面的一次密度升级。2. 为什么 SerDes 偏偏是 112Gb/s电域速度的“理性选择”2.1 从 56G 到 112G为什么不能继续用 50G/lane搞清800G之前得先把“112G”这个数字的来历搞清楚。很多文章把112G当成一个营销数字实际上它是SerDes串行器/解串器的电接口速率背后有严格的物理和标准化逻辑。400G时代主流的单通道速率是50G/lane对应SerDes实际运行速率是53.125G。如果你要在800G继续用53.125G的SerDes那么需要800除以50等于16个通道。16个高速通道意味着什么ASIC封装的引脚数量要增加一倍PCB走线面积成倍上升SerDes功耗也往上走光是这个通道数就能让交换机的成本和功耗都变得不可接受。而112G SerDes实际跑在106.25G对应100G/lane800G只需要8个通道通道数正好是50G方案的一半。同样总带宽下引脚数、功耗、占板面积都显著下降这让“800G”在工程上变得可实现。这里有一个关键点逻辑速率和物理速率不是同一个数字。所谓800G电接口在IEEE的标准定义里是8个100G/lane并行每个lane内部用PAM4编码符号率是53.125GBd。为什么不直接用128G甚至更高的电速率如果只追求单通道更快理论上128G能进一步减小通道数。但问题是单通道速率越高对PCB板材、连接器、封装基板的要求就指数级上升而且128G根本不是任何标准化组织定义的以太网逻辑lane速率。行业最终选112G本质上是“物理可实现性”和“标准整数映射”两个约束条件共同作用下的甜点区。打个比方高速公路限速不是越高越好而是要考虑路面材料、轮胎极限和交规的匹配。下面这张表可以很清楚看出56G、112G和未来224G的差别参数53.125G SerDes (50G/lane)106.25G SerDes (100G/lane)212.5G SerDes (200G/lane)800G所需通道数16841.6T所需通道数32168奈奎斯特频率约13.28 GHz26.56 GHz53.13 GHz对PCB板材要求普通低损耗板可应对需要低损耗/超低损耗板材需要极低损耗板材封装优化DSP均衡复杂度中等较高极高是否当前标准主流上一代当前代下一代2.2 PAM4用“四级电平”换带宽但代价不小另一个绕不开的概念是PAM4。很多初学者会问为什么112G不用NRZNRZ只有0和1两个电平一个符号代表1个bitPAM4有00、01、10、11四个电平一个符号代表2个bit。在符号率不变的前提下PAM4的带宽直接翻倍。这就是为什么106.25G的物理链路符号率只需要53.125GBd——用PAM4编码之后每个符号运载2bit波特率减半对信道带宽的压力就小了很多。理想很丰满代价也很直接。PAM4的四个电平挤在同样的电压范围内相邻电平之间的电压差只有NRZ的三分之一换算成信噪比大约要牺牲9.5dB左右。这意味着眼图开口变小接收端要分辨更细微的电压差误码率天然比NRZ差好几个数量级。想要把误码率拉回到可用水平光靠模拟前端不够必须依赖数字信号处理DSP。现在112G SerDes的接收端普遍集成了高性能均衡器、时钟恢复和判决反馈均衡配合链路两端的RS-FEC前向纠错。用一句生活化的话说NRZ是白天开车路牌清晰PAM4是雾天开车四个车道挨得很近你必须用好雷达和自动刹车还不能压线。所以“为什么是112G”的完整答案其实是“为什么是PAM4 106.25G 8通道”的组合。PAM4负责把符号率压下来同时把每lane带宽推上去106.25G负责与100G/lane生态对齐8通道则把芯片引脚和模块通道数控制在可接受范围。这套组合不是最优的单一指标但它是工程上整体最可实现的折中。2.3 用户能感知的变化板材、连接器、仿真一个都不能少从56G SerDes升级到112G SerDes变化最大的往往不是光模块而是PCB设计和整个信号链路。这一点很多做硬件的人会有共鸣我多说几句。先看频率。53.125G SerDes的奈奎斯特频率大约是13.28GHz这个频段用普通的FR4板材还能凑合走线长度限制也没那么苛刻。但到了112G奈奎斯特频率翻倍到26.56GHz普通FR4的介质损耗会大得离谱走线稍长一点接收端的眼图就完全闭合。行业里的常规做法是换用低损耗板材类似Megtron-6/7等级别的材料同时连接器也必须验收到28GHz甚至更高频段的回波损耗和串扰指标。更关键的是设计流程的变化。以前100G时代很多人还抱有一种“先布板再上仪器测试有问题慢慢调”的心态。到了112G这种试错思路基本行不通了必须把通道仿真前移到原理图阶段建IBIS-AMI模型跑插入损耗、回波损耗、串扰、电源噪声的全链路仿真把链路预算算清楚再动手画板。我说一个之前项目里遇到的例子一块交换线卡上某一段从SerDes到连接器的走线长度超过了设计规范仿真阶段看插入损耗就已经踩线但因为时间紧张没改板结果样机测试时连续几个通道的误码率都不达标最后只能降级到100G/lane的上一代速率来交付白白损失了一半带宽。这就是112G的残酷之处——它把“互联设计”从一门手艺变成了一门精确计算的科学任何侥幸心理都会在测试阶段加倍还回来。3. 800G 以太网落地光模块、交换机与功耗的“三方博弈”3.1 800G 的两种主流封装QSFP-DD 与 OSFP 怎么选800G以太网虽然标准定了但光模块形态还存在路线分歧。目前最主流的两种是QSFP-DD和OSFP它们各有各的物理逻辑。QSFP-DD延续了QSFP家族的接口尺寸可以向下兼容400G/200G的模块前面板密度高适合在TOR机架顶部交换机这类布线空间紧张的场景。而OSFP的尺寸比QSFP-DD更大它牺牲了一部分端口密度换来了更强的散热能力和更大的功耗容忍度。由于早期800G光模块的功耗普遍偏高OSFP在数据中心核心层和高功耗模块上有明显优势。我在实际项目里见过不少人在这个选择上纠结。我的建议是如果模块功耗预算可以控制在20W上下QSFP-DD的密度收益更划算如果明确要用长距离模块或者早期高功耗版本OSFP会让你省掉很多散热上的麻烦。具体选型的时候还要看交换机的风道设计和机柜功率上限不能只盯着“体积小好”这一个维度。对比项QSFP-DDOSFP外形尺寸更紧凑更大端口密度高中散热能力相对有限更强典型应用TOR交换机、短距离互连核心交换机、长距离/高功耗模块生态兼容性兼容QSFP系列主要面向新平台在光模块内部还有更细的分层。800G DR8是8×100G的并行单模方案适合500m以内的AI集群内部互连DR4/FR4这类2×400G方案部署起来更灵活长距离场景则需要更高规格的模块。每一层的选择都直接影响成本和功耗所以“800G模块”从来不是一个统一的型号而是一个按距离和功耗划分的矩阵。3.2 功耗大关一个机柜里塞进了四倍的发热800G时代最大的现实约束不是带宽而是功耗。单看一组数字400G光模块的功耗通常在12W到18W之间800G模块早期产品动辄25W到35W甚至更高。如果一台交换机有几十个高速端口光模块的总功耗就会占到整机功耗的相当大比例散热压力立刻成为系统级问题。我在一次部署评估里专门做过热仿真一个标准机柜里如果光模块平均功耗超过32W柜内进风温度会明显上升风扇需要提高转速来补偿随之而来的是噪声上升、耗电上升、风扇寿命下降。最后我们不得不给模块配置了降额运行的策略——把一部分链路从800G降到400G让功耗换安全。这件事给我的触动很大800G的规划已经不只是网络工程师的事而是结构、散热、供电多个团队一起的事。功耗还会反过来影响光模块的可靠性。高温是光器件最大的杀手之一激光器在高温下的波长漂移、发射功率衰减都会加速。所以我一直跟同行说部署800G的时候不要只看链路预算够不够还要看机柜的功率预算够不够。算力的提升本质上会在电和热两个方向同时放大压力。3.3 LPO 与 CPO可插拔光模块之外的“另一条路”正因为可插拔光模块在800G这个速率上把功耗和信号完整性推到了极限业界开始探索两种新的光互连路线LPO线性驱动可插拔光学和CPO共封装光学。LPO的思路是去掉光模块内部的DSP重定时芯片让交换机ASIC的SerDes直接线性驱动光器件。好处很直接模块功耗能降30%到50%成本和延迟也下降。代价是模块不再有独立的信号“再生”能力整个链路的均衡和时钟恢复全部压在交换芯片的SerDes上这对两端设备的协同设计要求极高互操作性风险也更大。CPO则走得更远直接把光引擎封装到交换芯片的同一颗基板上光信号不再需要经过PCB走线到面板再从面板进模块中间大量高频损耗被省掉了。理论上这是未来超高速率下的终极方案但它几乎颠覆了现有的可插拔光模块生态运维方式、器件可更换性都要重新设计。我的判断是短期内在AI集群内部的短距离、可控链路环境里LPO会先落地因为它能实实在在压低功耗而CPO会先在超大规模云厂商的定制交换平台里试点等生态成熟后再向外扩展。通用数据中心大概率还是可插拔模块的天下毕竟运维和供应链的惯性太强了。这也是为什么800G不是终点——下一代1.6T要解决的核心问题本质上还是功耗和信号完整性这对老冤家。4. 从 800G 看 Terabit Ethernet1.6T 与 224G SerDes 才是终局考卷4.1 标准路线已经铺好200G/lane 是下一个里程碑既然800G都还没完全铺开为什么标题里就敢提Terabit Ethernet因为行业其实早就往1.6T方向走了。IEEE 802.3dj工作组正在推进200G/lane的以太网标准OIF那边也在同步定义CEI-224G电气接口。按照现有节奏2025年前后这些标准会陆续成熟量产后正好是800G部署进入平稳期的阶段两代技术可以做一次无缝切换。1.6T端口可能的组合方式有三种8×200G、16×100G、4×400G。从芯片引脚数角度来看8×200G最理想——只需要8个高速SerDes通道就能凑够1.6T这几乎是把800G的结构直接翻倍。但真正的难度在于每一路的SerDes速率要从106.25G跳到212.5G光模块的每个通道也要同步做到200G/lane。这等于把当前800G已经烧脑的链路预算在最坏的情况下再压缩一半。所以1.6T不是“两个800G并排跑”这么简单它要求整个信号链路的每一个环节都再进化一次。Terabit Ethernet这个词组在这里代表的就是“单端口突破Tbps级别”的下一代以太网而不是字面上一条Tbps的光纤链路。4.2 未来踢到铁板的三个物理难题说到1.6T就不得不面对三个比800G时代更棘手的问题。第一是频率。212.5G SerDes的奈奎斯特频率大约在53GHz这个频段已经超出常规PCB材料的舒适区。走线上的插入损耗会随频率急剧上升工程师需要把走线长度压到极短甚至不得不用更高级的封装基板、2.5D/3D封装来缩短链路。换句话说到了这个速率“电信号能不能从芯片走到面板”都成了问题更别说还要保持信号质量。第二是光器件。单通道200G/lane意味着光模块里的激光器、调制器和探测器都要工作在更高速率。以PAM4来实现200G/lane符号率在100GBd以上在这个速率下激光器的带宽、非线性、噪声都会成为良率的杀手。成本能不能压到商用可接受的范围是1.6T能否规模落地的最大变数。第三是功耗和散热。224G SerDes的单通道功耗大概率会超过1.5W甚至2W一台51.2T交换机光SerDes就有上百个通道光是这部分发热就已经很可观。再加上每端口的光模块功耗可能飙到35W到40W以上散热方案几乎要重新发明一次。业界之所以都在研究线性直驱、共封装光学、相干下沉等技术本质都是在绕开“可插拔模块电功耗爆炸”这个问题。功耗问题的严重性怎么强调都不过分。我以为未来两代网络设备的竞争力很大程度会体现在“每Gbps功耗”这个指标上而不是单纯的带宽数字。谁能在功耗曲线上压得低谁就能在机柜功率受限的现实里赢得部署机会。4.3 给正在规划网络的人一个实用建议如果你现在正准备规划下一阶段的数据中心网络我的建议是别急着追“最高速率”先确认三件事。第一确认交换机的SerDes速率等级是100G/lane还是200G/lane。这会决定它以后能不能通过光模块升级来支持800G或1.6T而不是只能整机更换。第二确认光模块的形态和功耗预算是否匹配现有散热设计尤其是高密度机柜必须提前做热仿真而不是等设备到了再救火。第三确认整个链路从SerDes到模块到光纤的端到端预算别只听单点设备的“标称支持”。800G一路走来我见过太多“标称800G但实际只能跑400G”的尴尬案例原因大多出在链路预算和功耗余量上。我个人体会最深的一点是800G这个节点最需要转变的不是设备而是思路。不能再把高速链路拆成交换机、模块、线缆三段各自为政必须从端到端的信号链路去判断预算。这也是我为什么愿意花一整篇来聊112G SerDes的原因——它才是未来两代端口速率共同的地基。下一部分我会从一条典型的800G链路预算计算讲起聊聊各个环节的损耗和余量究竟怎么算、算完之后又如何指导选型。
阅读完成 · 觉得有帮助？
