1. 先回答Rubin值不值得等网络设计才是真正的分水岭前阵子给新算力中心做平台选型朋友问了一嘴Vera Rubin这一代到底值不值得等按惯性思路我该对比HBM容量、单卡算力、能效比。但那次我脱口而出的反而是另一个问题你那一千多张卡打算怎么连起来不是卖关子。最近一年我参与过好几套大模型集群的规划也帮朋友排过不少网络故障最后拉开体验差距的从来不是单卡峰值有多高而是从机柜内部到跨机柜之间的整张网络是不是真的能打。尤其是智能体工作负载变成常态之后训练时代那套算力为王、网络跟着走的思路已经开始不成立了。很多人一听Vera Rubin第一反应是CPO共封装光学。这当然重要光互连确实是这代平台的关键增量但它远远不是全部。真正支撑起智能体AI算力底座的是一个完整的全栈互联体系芯片与芯片之间的铜互连、CPU与GPU之间的C2C、机柜内的NVLink域、机柜间的光交换结构再到存储和数据管理链路。这五个层面的网络各有各的使命各有各的瓶颈放一起才构成一张能支撑智能体业务的大网。这篇文章我想站在工程落地的角度把NVIDIA Vera Rubin平台这一波互连变革拆开来讲。内容会覆盖我理解下的五大网络域、CPO在里头真正承担的角色、以及从Blackwell迁移过来时哪些检查项最容易被漏掉。适合正在做AI Infra、算力规划、智体平台搭建的同行参考。2. 智能体工作负载到底怎么逼着互联架构改变2.1 训练负载和智能体负载对网络的要求完全相反我在不少技术分享里反复提过一句话传统AI训练把网络当管道智能体AI把网络当内存。为什么这么说先看传统训练。一个典型的LLM训练任务数据流是高度有规律的前向算一遍反向算一遍然后做一次全梯度同步。整个过程中数据在每个GPU上的分布基本固定通信模式是周期性、大批量、可预测的。网络只要保证峰值带宽够大管道够宽基本就能干好活。智能体推理则完全是另一种画风。一个智能体可能同时挂着十几条上下文外部工具返回结果的时间不确定多Agent之间要互相传递中间状态KV缓存还要根据路由决策在节点之间搬来搬去。这些流量特点是单条消息很小、频率很高、突发性强、对延迟极度敏感。可能一个任务只传几十KB的报文但它必须在几百微秒级别到达否则整个推理管线就像堵车一样越堵越长。我把两类负载的差异整理成了一张很常用的对照表维度传统训练负载智能体推理负载通信模式周期同步大批量事件驱动小消息高频网络敏感点峰值带宽尾部延迟与阻塞率流量可预测性高低动态路由常见内存依赖模型权重为主KV缓存、上下文快照频繁迁移对网络故障容忍度相对较高可重试极低一个超时会导致整条Agent流程失败2.2 KV缓存在节点之间流动是以前没遇到过的新压力智能体AI里有一个被低估的流量来源KV缓存迁移。现在的推理服务普遍做PD分离Prefill节点吃下长提示词、生成KV缓存Decode节点负责逐token生成。如果后面又要做多Agent协作、又要做记忆回看、又要做针对不同工具调用的分支推理KV缓存就不能一直待在原来那个节点上。它得跟着调度决策走从一个GPU搬到另一个GPU甚至从一个机柜搬到另一个机柜。KV缓存比模型权重更娇气。模型权重可以预先复制一份放在每个节点KV缓存是推理过程中动态产生的而且有严格的时效性。搬慢了整个token生成就卡住搬错了位置后面所有依赖它的Agent全部要重新算。这就导致网络不再是搬完一批数据就算完成任务而是变成了推理状态机的一部分。2.3 网络从按带宽规划转向按时延和QoS规划这两点叠加直接影响基础设施的规划逻辑。以前我跟别人聊网络规划大家开口都是你们带宽是400G还是800G。现在的智能体集群更关键的问题变成了单跳时延有多少拥塞控制能不能在毫秒级介入低优先级流量会不会把高优先级的KV迁移堵死这也是为什么NVIDIA这代平台要把网络架构放到和GPU架构同等重要的位置。Vera Rubin不只是换一颗更强的GPU而是把芯片间互连、机柜内互连、光交换网络、存储访问和管理通道全部重做了一遍。理解到这个层面才能真正看懂五大网络域这个概念。3. Vera Rubin平台全景芯片互连、机柜互连与光交换分层干活3.1 从三档连法看懂互连体系的物理分布NVIDIA这代平台的互连路径按物理距离基本可以分成三档。第一档是芯片级互连。Vera CPU和Rubin GPU之间走NVLink-C2C实现统一内存访问。对开发者和AI框架来说CPU和GPU之间不再是需要通过PCIe搬运的关系而是像同一台机器里协同工作的两个处理器共享一份地址空间。这对智能体场景特别重要因为Agent的调度逻辑跑在CPU侧算力消耗在GPU侧两边的数据交互量非常大。第二档是机柜级互连。Rubin平台延续并放大了NVL72那套思路做成NVL144级别的机架系统144颗GPU通过NVLink和NVSwitch组成一个大的GPU域。在这个域内GPU之间通信带宽极高延迟极低完全可以当成一颗巨大的虚拟GPU来用。第三档才是光互连。机柜与机柜之间、大规模集群之间通过Quantum-X或者Spectrum-X交换机构建scale-out网络。这里才是CPO共封装光学真正发挥价值的地方。3.2 CPO在平台里的精确位置它管的是长距不是短距我在各种技术群里看到不少误解以为CPO是接在GPU旁边、专门把卡与卡之间的电信号变成光的。实际上从工程逻辑和NVIDIA公开路线图来看CPO的典型落点是交换ASIC这一层也就是数据中心后端光交换网络里。为什么一个交换ASIC要驱动几十上百个光口如果每个光口都用传统可插拔模块光模块本身的功耗、体积和散热会把交换机的整机功率推得极高。CPO的思路是把光引擎和交换芯片封装在同一个基板上缩短电信号传输距离去掉一部分高性能DSP从而在同等功耗和空间内塞下更多带宽。但机柜内那十几米、几十米的NVLink连接走的是高密度铜缆和背板完全没必要也没法全部换成光。因为短距离铜互连的能效比远高于光互连功耗低、延迟小成本还便宜。该用光的用光该用电的用电这才是全栈互联的精髓。3.3 为什么我说不止CPO这一代平台发布之后舆论焦点几乎都压在CPO上。但我跟做基础设施的同行聊下来大家普遍认同一个结论如果你的视野里只有CPO那等于只看到了一台交换机的内部变化忽略了整张网络其他四个域。举个很实际的例子。假设你把scale-out光网络升级得再好但机柜内的NVLink域划分不合理导致KV缓存只能在两个机柜之间来回倒腾延迟照样下不来。再假设CPU与GPU之间的C2C带宽不够Agent调度逻辑频繁访问GPU显存照样会变成系统瓶颈。这就像给城市修了再宽的高速公路但连接高速和市区的匝道堵死车还是进不了城。这就是五大网络域这个框架的价值所在——它逼着你把注意力从单点技术拉到全局拓扑上。4. 五大网络域拆解智能体算力底座的互联骨架为了讲清楚整个平台我把Vera Rubin相关的互连体系拆成五个逻辑网络域。注意这里的域不是严格的物理隔离而是按职责和流量特征做的一种工程划分。实际部署中不同域的流量会复用同一套物理链路但设计时必须有边界意识。网络域典型范围主要技术核心职责智能体场景中的痛点域一Scale-up计算域机柜内GPU集群NVLink、NVSwitchGPU间高带宽低延迟通信KV缓存随注意力头动态迁移域二C2C与主机I/O域CPU-GPU、GPU-NICNVLink-C2C、PCIe调度、控制、数据输入输出Agent调度逻辑与GPU算力频繁协同域三Scale-out后端网络域机柜间、跨集群Quantum-X、Spectrum-X大规模集群互连多Agent通信、增量训练同步域四存储与数据流域存储节点到GPU节点NVMe-oF、GPUDirect Storage模型加载、数据集读取、检查点KV缓存落盘和记忆快照恢复域五管理与控制域所有节点的带外管理管理网、Redfish、Zero-Trust部署、监控、安全、固件管理大规模Agent编排与可观测性事件回传4.1 域一Scale-up计算域决定智能体推理的内存墙简单说这个域解决的是同一个逻辑任务里的GPU怎么快速交换数据。NVL144平台把上百颗GPU用NVLink连成一个域配合NVSwitch做全互联让任意两颗GPU之间都能以非常高的带宽通信。对智能体场景来说Scale-up域最核心的作用是支撑超长上下文和复杂Attention计算。当多个Agent并行处理同一段对话历史它们往往需要访问同一批KV缓存这种共享模式在NVLink域内实现起来成本最低、效率最高。如果这部分数据要跨域走光网络延迟可能直接差一个数量级。规划Scale-up域时我特别强调一点不要只看总带宽。NVSwitch的转发能力、NVLink端口在存储体和计算体之间的分配方式都会直接影响推理负载表现。最好在实际部署前用代表业务流量做一次小规模压测否则很容易出现规格看着够一压就露馅。4.2 域二C2C与主机I/O域把CPU和GPU变成一台机器这个域是Vera Rubin相比前几代最明显的架构变化之一。Vera CPU和Rubin GPU之间通过NVLink-C2C连接共享一致内存空间。对上层软件来说CPU和GPU之间的指针可以直接互相访问不再需要显式的数据拷贝。对智能体业务这个变化的意义非常大。Agent的决策、工具调用编排、任务状态管理等逻辑密集型操作都跑在CPU上而真正吃算力的推理计算跑在GPU上。两者之间是高频的、细粒度的交互。如果还是走PCIe搬运每一轮交互都要付出不小的驱动开销和拷贝延迟换成C2C之后交互成本极大降低Agent才能做到边决策边推理。这个域的潜在瓶颈往往出在NIC、DPU和PCIe通道的接驳上。很多AI服务器每台要插多张网卡和存储卡如果PCIe通道拆分不合理CPU和GPU之间的C2C带宽再高数据也送不到网卡。所以做整机设计时主机I/O的BOM配置值得反复推敲。4.3 域三Scale-out后端网络域跨机柜Agent协作的命脉机柜内部搞定了机柜之间怎么办答案就是后端光交换网络。这是CPO发挥作用的主战场也是集群规模突破单机柜限制的必经之路。对于智能体场景Scale-out网络主要承载三类流量一是增量训练或LoRA微调时的梯度同步二是大规模Agent之间的状态广播和结果汇总三是跨机柜的KV缓存转发。这三种流量特征完全不同有的追求带宽有的追求延迟有的则是低频但突发的。一个合格的Scale-out网络不能只是带宽大还需要有比较强的拥塞控制能力保证关键小报文不会被大流量挤到队尾。在技术选型上InfiniBand和RoCEv2各有支持者。我的实用主义建议是如果团队对网络调优的掌控力一般InfiniBand的天然无损特性会省很多心如果团队有成熟的RoCE调优经验且业务流量以短连接和动态路由为主RoCEv2的成本优势也很明显。Vera Rubin平台对两种生态都做了适配这点很关键。4.4 域四存储与数据流域别让数据供给拖后腿我见过很多集群GPU算力拉满网络互相连通都很好结果模型加载和数据读取环节慢得离谱。这个环节就属于存储域。存储域指的是从分布式存储集群到GPU显存之间的整条数据链路包括存储节点、存储网络、文件系统客户端以及GPU与存储之间的DMA通道。NVIDIA在Blackwell时代推GPUDirect Storage核心目的就是让数据从存储直接进显存绕开CPU内存拷贝这一道中间环节。Vera Rubin平台大概率会进一步强化这条路径。智能体业务里除了模型权重和训练数据集还有两类新数据特别依赖存储域一是海量的对话日志和Agent执行轨迹二是KV缓存和上下文快照的落盘。前者需要高吞吐顺序写后者需要低延迟随机读。规划存储域时如果只按传统模型加载检查点保存去估算带宽很容易在这两类新业务上踩坑。4.5 域五管理与控制域最不起眼但最不能断的命脉最后一域经常被忽略但一旦出问题就是灾难。管理网络负责所有节点的带外管理、固件升级、健康监控、日志回传和部署编排。它不直接传输业务数据却决定了一张网络能不能被有效调度和运维。智能体集群的管理流量比传统HPC集群大很多。原因是Agent任务状态变化快编排系统需要高频拉取节点状态再加上可观测性系统要跟踪每条Agent流程的调用链和网络路径产生的监控日志和指标数量非常惊人。如果管理网络带宽不够或者管理面和数据面没有做合理隔离那么当业务高峰来临时运维系统可能先崩。我在不少项目里都建议把管理网络单独划VLAN或者干脆独立网卡独立交换机带宽至少预留万兆级别。这个钱花得绝对值。5. 软件层面的全栈互联光有硬件还不够5.1 集合通信从训练专用走向智能体混合模式五大网络域最终能不能协同工作很大程度取决于软件栈。训练阶段常用的NCCL等集合通信库主要围绕全规约全收集这类规则模式做了深度优化。但智能体业务的通信模式更复杂。多个Agent之间要做消息传递、结果路由、任务分发同时还要穿插增量训练和缓存同步。这要求底层的通信库不是一个死板接口而是能灵活支持多种模式。Vera Rubin平台给我比较深的印象是NVIDIA明显把域间协同做成了系统级设计而不只是堆硬件。比如NIXL这类数据访问库的出现就是在尝试让上层框架直接感知底层网络拓扑让数据访问指令自动选择最优路径。5.2 内存池化与KV缓存远程访问智能体时代的一等公民另一个软件层面的突破点是内存池化。传统做法里GPU显存是主人的显存数据放进去别人就不能碰。但在多个智能体共享上下文、KV缓存需要动态迁移的场景里这种封闭模式效率太低。Vera Rubin延续并强化了NVLink共享内存概念让一个GPU域内的多颗GPU可以共享访问同一块物理内存。配合C2C域的内存一致性整个机柜仿佛变成了一台超大内存的计算机。对Agent编排框架来说这带来的直接好处是调度器不用再担心缓存放到哪颗GPU上因为放哪都能被快速访问。上层只需要告诉硬件这份数据需要被谁访问硬件自己会找最优路径。这是真正意义上的全栈互联。5.3 拓扑感知调度和网络QoS是最后一公里硬件再强如果调度器不感知网络拓扑一切白搭。现在成熟的AI平台在做Pod调度时都会尽量把有高频通信需求的GPU放到同一个NVLink域内避免跨交换机通信。Kubernetes配合NVIDIA的拓扑感知插件已经能做节点级和机柜级的亲和性调度。Vera Rubin平台把机柜内GPU域做得更大这种亲和性调度的效果也会更明显。另外就是QoS。智能体集群里的高优先级流量和高优先级任务应当有明确的服务等级。比如KV缓存迁移、Agent消息转发这类实时流量应该优先保证后台日志同步和训练任务则可以适当降级。没有QoS的网络不管物理带宽多大高峰期一样会出现文盲式的拥堵。6. 落地建议从Blackwell升级到Vera Rubin先检查这七项说完了体系我整理了一份实用性比较强的检查清单。这些项目是我在历次集群升级中反复踩坑总结出来的不保证覆盖所有场景但照着做至少能避掉大部分雷。第一重新核算网络带宽不要只盯着GPU间带宽。智能体负载有大量CPU到GPU、GPU到存储的流量这些流量并不都走NVLink。把CPU与NIC之间、存储与控制节点之间的带宽缺口先摸清楚再决定后端网该上多大规格。第二机柜内NVL144域划分要贴合业务。如果你有多个独立智能体业务它们可能更适合放在不同域里做故障隔离。如果你有大模型推理需要超大上下文那尽量让同一个任务的Prefill和Decode节点落在同一个NVLink域内。第三CPO交换机的维护策略要提前订。CPO把光引擎和交换芯片封装在一起之后光纤出问题就不再是像可插拔模块那样拔下来换一个了。配件备件、维修流程、甚至和厂商的SLA都要重新谈。很多团队没意识到这个变化直到设备上线才发现维护体系跟不上。第四存储域按上下文生命周期来设计缓存层。建议在存储集群前面加一层高性能缓存专门承接KV缓存快照和Agent上下文恢复的突发读。直接让GPU向远端冷存储读取上下文延迟和带宽都承受不住。第五管理网络按业务网络的标准来建设。带宽、冗余、隔离都按生产标准来不要用带外管理嘛差不多就行的心态去规划。智能体编排系统对管理网的依赖比我见过的大多数公司想象得要高一个量级。第六上线前一定用真实Agent流量做压测。不要只跑NCCL的AllReduce测试。要模拟多Agent并发、工具调用超时、上下文切换、KV缓存迁移这些真实血流量。最好能构造一个全链路场景把多个域同时打满看瓶颈到底在哪个环节。第七给软件升级留足时间窗口。Vera Rubin不只是一次硬件换代驱动、通信库、调度插件、监控体系都要跟着升。尤其是你们如果用了自研的Agent编排框架接口兼容性测试要留足时间。我见过太多项目硬件到货了软件适配还没做完机器只能空跑测试。最后分享一个我个人的体会。做基础设施的人容易把自己困在某个技术指标里比如CPO功耗降低了多少、NVLink带宽提升了几倍。但真正决定一套系统好不好用的是这些技术指标组合起来之后能不能刚好匹配你的业务流量特征。智能体AI的时代网络不再是GPU的配角。它是一个并行于算力的第一公民值得像选GPU一样认真去选、去设计、去测试。
