贾扬清离开英伟达：DGX Cloud并非输在技术

所以DGX Cloud在弹性伸缩和多租户隔离这块具体差在哪？我最近也在对比几家云服务做推理部署，AWS的EKS确实灵活，但GPU实例价格太贵。你们那次大规模训练最后是迁移到别家了吗，还是有什么workaround能凑合用？

这个帖子抛出的几个点确实值得深挖，尤其是“DGX Cloud并非输在技术”这个论断，我个人觉得需要更辩证地看。作为从2016年开始接触分布式训练、后来在两家国内云厂商负责过AI基础设施架构的老兵，我想从几个不同维度补充一些实操层面的观察。

先直接回应帖子里的核心矛盾：英伟达的DGX Cloud到底输在哪。帖主说技术不是主因，但我认为技术恰恰是最根本的绊脚石，只是这个“技术”不是指芯片算力，而是指云服务特有的系统工程能力。我在2023年Q2帮一家自动驾驶公司评估过DGX Cloud和AWS p5实例的对比。当时我们跑了三个典型场景：一个是大规模多模态模型的预训练（约2000张H100），一个是LLM的在线推理服务（需要处理突发流量），还有一个是混合精度微调任务。结果很有意思：在纯算力层面，DGX Cloud的单卡性能确实比AWS的H100高大约5-8%，这得益于英伟达更精细的散热和电源管理。但一旦涉及多节点通信，差距就出来了。我们用的一个32节点、每节点8卡的拓扑，在DGX Cloud上做AllReduce时，端到端吞吐量只有理论峰值的68%，而在AWS的EFA（弹性结构适配器）优化过的p5集群上，同配置能达到85%左右。这30%的差异，帖子说是因为NVLink跨节点拓扑没优化好，这个判断对了一半。更深层的原因是英伟达在通用云网络栈上的积累太薄弱。DGX Cloud的底层网络基于Mellanox（英伟达收购的）的ConnectX网卡，但它的调度和拥塞控制算法是针对HPC场景的，比如MPI通信模式，而大模型训练更依赖AllReduce这样的集合通信，对延迟抖动和带宽抢占非常敏感。我们当时用NCCL的分析工具发现，在DGX Cloud上，当多个任务混跑时，网络流会频繁撞到PFC（优先级流控制）的死锁，导致通信链路反复降速。这个坑在AWS上几乎不会出现，因为AWS的SRD（可扩展可靠数据报）协议本身就是为云原生设计的，能自动做负载均衡和重传。

再说说帖子提到的“裸金属GPU云在弹性伸缩和多租户隔离上不如AWS/GCP”，这点我完全同意，而且可以补充一个更具体的案例。去年我们尝试在DGX Cloud上部署一个推理服务，需要根据请求量动态扩缩容。结果发现它的节点启动时间平均是12分钟，而AWS的GPU实例冷启动只需要3分钟。为什么差这么多？因为DGX Cloud的镜像分发机制是中心化的，所有节点从同一个NFS拉取容器镜像，而AWS用了分布式缓存和预拉取策略。更致命的是，DGX Cloud不支持抢占式实例，这意味着你为了应对突发流量必须预留大量冗余资源，这对成本控制是灾难性的。我们算过一笔账，如果用DGX Cloud跑一个每天请求量波动3倍的推理服务，月成本比AWS高约40%，因为浪费的空闲资源太多了。而AWS的弹性推理加速器（Elastic Inference）加上自动扩缩组，可以把资源利用率做到70%以上。

现在来回答帖子最后提出的两个问题。第一个问题，英伟达是否该放弃自建云？我的看法是，它不应该完全放弃，但必须转换策略。目前英伟达在DGX Cloud上犯的最大错误是试图做“全栈云”，从芯片到网络到调度到计费都想自己搞。但云服务是一个高度依赖规模效应和运营经验的行业，英伟达的基因里根本没有运维团队、计费系统、合规认证这些东西。更现实的路径是学习谷歌的TPU云服务模式：谷歌并没有把TPU直接卖给企业，而是通过Google Cloud提供TPU实例，但保留了对自己硬件的深度优化能力。英伟达完全可以和AWS、Azure、GCP达成更紧密的合作，比如提供定制的DGX SKU，允许云厂商直接接入英伟达的NCCL优化库和NVLink拓扑，但把调度、计费、弹性这些交给云厂商。这样英伟达既保住了硬件溢价，又不用亲自下场卷运维。事实上，我看到一些信号表明英伟达已经在调整方向，比如它最近推出的AI Enterprise软件套件，本质上就是通过软件锁定生态，而不是靠自建云来卖硬件。

第二个问题，AI infra的未来，硬件层优化和软件层弹性调度哪个更重要？我认为这是一个伪二分法。在2024年这个时间点，两者已经不是“二选一”，而是“都要”且“必须协同”。硬件层优化决定了单节点性能和通信天花板，比如NVLink 4.0能把节点内带宽做到900GB/s，这对减小梯度同步延迟至关重要。但软件层弹性调度决定了你能在多大规模上逼近这个天花板。举一个我最近在做的项目为例：我们正在为一个万亿参数MoE模型设计训练框架。这个模型有128个专家，每个专家分布在不同的H100节点上。最关键的挑战是，当某个专家负载不均衡导致通信热点时，如何动态重新分配专家所在的物理位置。纯硬件方案解决不了这个问题，因为NVLink是固定的物理拓扑，无法在运行时重配。我们最终的做法是写了一个自定义Kubernetes调度器，它能把专家的网络拓扑需求（比如“我需要和另外三个专家在同一个NVSwitch域内”）转换成节点亲和性规则，然后在训练过程中实时监控NVLink的带宽利用率，一旦发现某个链路的利用率超过75%，就触发专家迁移。这个调度器的核心是一个基于强化学习的路由决策模块，输入是当前节点的NVLink拓扑矩阵、专家间的通信模式（用NCCL的trace工具抓取）、以及节点的GPU显存利用率，输出是专家应该迁移到的目标节点。我们用了大约两周时间调优，最终把端到端训练吞吐量提升了22%，同时把通信热点出现的频率降低了60%。这个例子说明，硬件优化提供了基础能力，但软件弹性调度才是把硬件能力兑现成实际生产力的关键。

再分享一个踩坑经历，关于多租户隔离。我们曾经在DGX Cloud上同时跑三个团队的微调任务，每个团队用10张卡。结果发现，某个团队的训练任务会周期性“卡住”几分钟，NVIDIA的smi显示GPU利用率从100%突然降到0。排查了三天才发现，是另一个团队的推理服务在高峰期占用了大量PCIe带宽，导致训练任务的梯度同步超时。这个问题在裸金属环境下非常难解决，因为所有任务共享同一个PCIe总线。后来我们不得不在调度层面做了两个改进：一是给每个任务分配独立的PCIe带宽上限（通过nvidia-smi的PCIe速率限制功能），二是引入了基于时间片的GPU共享机制（类似MPS但更细粒度）。这些工作本质上是把硬件的隔离能力不足，用软件调度来弥补。如果英伟达能在DGX Cloud的原生调度系统里内置这类功能，就能省去用户的大量头疼时间。

最后说说帖主提到的“硬件厂商直接做云服务的模式”需要时日验证，我完全认同。但我认为这个模式并非完全不可行，只是需要找到正确的切入点。目前我看到的一个潜在机会是边缘AI推理。很多企业需要在工厂、医院等边缘节点部署私有化的大模型，这些场景对延迟和合规要求极高，无法使用公有云。英伟达如果推出一款“DGX Edge”设备，配上基于K3s的轻量级调度系统，并提供和云端DGX Cloud一致的API和模型管理界面，那就能形成一个从云到边的统一平台。这个模式比直接在公有云领域和AWS硬碰硬要聪明得多，因为边缘市场目前还没有巨头垄断，而且英伟达的硬件在能效比上确实有优势。我去年给一家医疗器械公司做过边缘推理方案，他们需要在CT扫描仪旁边实时运行一个视觉大模型，要求端到端延迟低于50毫秒。我们试过用Jetson Orin，但显存不够；用DGX Station又太贵。如果当时有英伟达官方支持的边缘推理云服务，能按需租用硬件并自动更新模型，那商业上会顺畅很多。

总结一下，DGX Cloud的现状是“硬件太强，软件太弱”。英伟达如果想在云服务上站稳脚跟，必须放下“我芯片无敌所以我做什么都行”的傲慢，老老实实把Kubernetes调度、网络拥塞控制、多租户隔离这些“脏活累活”做好。或者更聪明一点，就像我前面说的，通过深度绑定云厂商来发挥自己的硬件优势。贾扬清的离开，可能正是英伟达内部在战略摇摆后的一个必然结果。对于AI infra从业者来说，这件事最大的启示是：永远不要低估系统工程的价值。一个能稳定运行99.99%时间、自动处理网络故障、弹性应对突发流量的云平台，其技术壁垒比单卡算力高出一个数量级。而英伟达目前离这个目标，至少还有两年的工程差距。