用DDC来构建AI网络？这可能只是一个美好的幻觉

ChatGPT、AIGC、大模型……一系列眼花缭乱的名词横空出世，AI商业价值引发社会的高度关注。随着训练模型规模的增长，支撑AI算力的数据中心网络也成为热点。提升算力效率，构建高性能网络……大厂们各显神通，努力在以太产业宏图上开辟AI网络的“F1新赛道”。

在这场AI的军备竞赛中，DDC高调出镜，一夜之间似乎成为了构建高性能AI网络革命性技术的代名词。但真如看上去那么美好吗？让我们详细分析，冷静判断。

始于2019年，DDC的本质是以盒盒路由器替代框式路由器

随着DCN流量的快速增长，DCI网络升级需求日益迫切。然而，DCI路由器框式设备扩容能力受机框大小限制；同时设备功耗大，扩容机框时对机柜电力、散热等要求较高，改造成本高。在此背景下，2019年AT&T向OCP提交了基于商用芯片的盒式路由器规范，提出了DDC（Disaggregated Distributed Chassis）的概念。简单来说，DDC就是使用若干个低功耗盒式设备组成的集群替换框式设备业务线卡和网板等硬件单元，盒式设备间通过线缆互联。整个集群通过集中式或者分布式的NOS（网络操作系统）管理，以期突破DCI单框设备性能和功耗瓶颈的问题。

DDC宣称的优势包括：

突破框式设备扩容限制：通过多设备集群实现扩容，不受机框尺寸限制；

降低单点功耗：多台低功耗的盒式设备分散部署，解决了功耗集中的问题，降低机柜电力和散热的要求；

提升带宽利用率：与传统的ETH网Hash交换相比，DDC采用信元（Cell）交换，基于Cell进行负载均衡，有助于提升带宽利用率；

缓解丢包：使用设备大缓存能力满足DCI场景高收敛比要求。先通过VOQ（Virtual Output Queue）技术先将网络中接收到的报文分配到不同的虚拟出队列中，再通过Credit通信机制确定接收端有足够的缓存空间后再发送这些报文，从而减少由于出口拥塞带来的丢包。

DDC方案在DCI场景仅昙花一现

想法看起来很完美，可落地却并非一帆风顺。DriveNets公司的Network Cloud产品是业界第一个、也是唯一一个商用的DDC解决方案，整套软件适配通用白盒路由器。但至今在市面上未见到明确的销售案例。AT&T作为DDC架构方案提出者，在2020年自建的IP骨干网中灰度部署了DDC方案，但后续也基本没有多少声响。为什么这朵水花并没有掀起多大的浪呢？这应该归咎于DDC存在的四大缺陷。

缺陷一：不可靠的设备管控平面

框式设备各部件通过硬件高度集成、可靠性极高的PCIe总线实现控制管理面互联，并设备都使用双主控板设计，确保设备的管控平面高可靠。DDC则使用“坏了就换”的易损模块线缆互联，构筑多设备集群并支撑集群管控平面运行。虽突破了框式设备的规模，但这种不可靠的互联方式给管控面带来了极大风险。两台设备堆叠，异常时会出现脑裂、表项不同步等问题。对于DDC这不可靠的管控平面而言，这种问题更容易发生。

缺陷二：高度复杂的设备NOS

SONiC社区已有基于VOQ架构下的分布式转发机框设计，并持续迭代补充和修改以便于满足对DDC的支持。虽然白盒确实已经有很多落地案例，但“白框”却少有人挑战。构筑一个拉远的“白框”，不仅仅需要考虑集群内多设备的状态、表项信息的同步和管理，还需要考虑到版本升级、回滚、热补丁等多个实际场景在多设备下的系统化实现。DDC对集群的NOS复杂度要求指数级提升，目前业界没有成熟商用案例，存在很大的开发风险。

缺陷三：可维护方案缺失

网络是不可靠的，因此ETH网络做了大量可维护和可定位的特性或工具，比如耳熟能详的INT、MOD。这些工具可以对具体的流进行监控，识别丢包的流特征，从而进行定位排障。但DDC使用的信元仅是报文的一个切片，没有相关IP等五元组信息，无法关联到具体的业务流。DDC一旦出现丢包问题，当前的运维手段无法定位到丢包点，维护方案严重缺失。

缺陷四：成本提升

DDC为突破机框尺寸限制，需要将集群的各设备通过高速的线缆/模块互联；互联成本是远高于框式设备线卡和网板之间通过PCB走线和高速链接器互联，且规模越大互联成本越高。

同时为降低单点功耗集中，通过线缆/模块互联的DDC集群整体功耗高于框式设备。相同一代的芯片，假设DDC集群设备之间用模块互联，集群功耗较框式设备高30%。

拒绝炒剩饭，DDC方案同样不适用于AI网络

DDC方案的不成熟和不完善，在DCI场景上已黯然退场。但当前在AI风口下竟然死灰复燃。笔者认为，DDC同样不适用于AI网络，接下来我们详细分析。

AI网络的两大核心诉求：高吞吐、低时延

AI网络支撑的业务其特征是流数量少，单条流的带宽大；同时流量不均匀，经常出现多打一或者多打多的情况（All-to-All和All-Reduce）。所以极易出现流量负载不均、链路利用率低、频繁的流量拥塞导致的丢包等问题，无法充分释放算力。

DDC仅解决了Hash问题，同样带来众多缺陷

DDC使用信元交换将报文切片成Cells，并根据可达信息采用轮询机制发送。流量负载会较为均衡的分配到每一条链路，实现带宽的充分利用，并较好解决了Hash问题。但在这个之外，DDC在AI场景依然存在四大缺陷。

缺陷一：硬件要求特定设备，封闭专网不通用

DDC架构中的信元交换和VOQ技术，均依赖特定硬件芯片实现。当前DCN网络设备均无法利旧使用。ETH网的飞速发展，得益于其即插即用的便利和通用化、标准化。DCC依赖硬件并通过私有的交换协议构建了一张封闭的专网，并不通用。

缺陷二：大缓存设计增加网络成本，不适合大规格DCN组网

DDC方案若进入DCN，除去高昂的互联成本外，还背负着芯片大缓存的成本负担。DCN网络当前均使用小缓存设备，最大仅64M；而源于DCI场景的DDC方案通常芯片的HBM达到上GB。大规模的DCN网络相较DCI而言，更在意网络成本。

缺陷三：网络静态时延增加，不匹配AI场景

作为释放算力的高性能AI网络，目标时缩短业务的完成时间。DDC的大缓存能力将报文缓存，势必增加硬件转发静态时延。同时信元交换，对报文的切片、封装和重组，同样增加网络转发时延。通过测试数据比较，DDC较传统ETH网转发时延增大1.4倍。

缺陷四：随着DC规模增大，DDC不可靠的问题会更加劣化

相对DDC在DCI场景替代框式设备的场景而言，DDC进入DCN需要满足更大的一个集群，至少要满足一个网络POD。这意味着这个拉远的“框“，各个部件距离更远。那么对于这个集群的管控平面的可靠性、设备网络NOS的同步管理、网络POD级的运维管理要求更高。DDC的各种缺陷将会裂化。

DDC最多是个过渡方案

当然，任何问题都不是不能解决的。接受部分约束，对于这种特定场景，很容易成为各个大厂“炫技”的舞台。网络追求可靠、极简、高效，厌弃复杂度。特别是当前“减员增效”的大背景下，确实要考虑下DDC落地的代价。

在AI场景下面对网络负载分担问题，当前已经有很多案例通过转发路径的全局静态或动态编排解决，未来也可以通过端侧的网卡基于Packet Spray和乱序重排解决。所以DDC最多是个短期过渡方案。

深度扒一扒，DDC背后的推手或许是DNX

最后说下主流网络芯片公司博通（Broadcom），我们较为熟悉的有StrataXGS和StrataDNX两个产品系列。XGS延续高带宽、低成本的路线，快速推出小缓存、大带宽的芯片产品，在DCN网络占用率持续独占鳌头。StrataDNX却背着大缓存的成本，延续着VOQ+信元交换的神话，期望DDC进入DC续命。北美似乎并无案例，国内DDC或许是DNX最后的救命稻草吧。

当今GPU等大量硬件设施在我国已经受到一定程度的限制，我们真的需要DDC么？还是多给国产化器件留些机会吧！

以上是用DDC来构建AI网络？这可能只是一个美好的幻觉的详细内容。更多信息请关注PHP中文网其他相关文章！