王少冬说实话，今年以来我接触了不少正在搭智算中心的团队，发现一个很有意思的现象：大家选GPU的时候研究得特别细，A100、H800、国产卡折腾得明明白白，但是问到网络方案，大部分人的回答是“先用着，交换机买好点的就行”。前阵子看到联想提出的数据网络训推一体解决方案，再对照这些真实项目踩出来的坑，我突然觉得这个话题很值得展开聊聊。所谓“三位一体”和“全能ACE”听起来像市场宣传，但拆开看，它其实是在回应一个非常具体的痛点——训练和推理负载，在AI时代到底该怎么共用一张数据网络。这篇文章我就从实际组网和运营的角度，把这个方案从头到脚拆一遍。
1. 为什么AI集群的瓶颈，正从GPU转向数据网络
1.1 算力越强，数据搬运越吃力
先看一个被很多人忽略的物理事实：分布式训练的效率，很大程度上不是由单卡算力决定的，而是由“数据能不能及时搬到需要它的地方”决定的。大模型训练是个典型的通信密集型任务，每完成一步训练，所有GPU都要做一次梯度同步，术语叫AllReduce。参数越多，梯度数据量越大，同步一次要搬的字节数就越可观。
我举个具体的数：一个70B参数的大模型，光权重文件就是140GB（按FP16算）。每训练一步，要把几十GB的梯度数据在集群里同步一遍。如果你用的是一张100Gbps的网卡，理论峰值每秒只能搬12.5GB，扣掉协议开销、拥塞重传，实际能跑到8~9GB/s就算不错。也就是说，一次梯度同步需要好几秒钟。如果这一步训练本身的单步耗时只有10秒，那将近三分之一的时间都耗在“等数据”上。
这还没算checkpoint保存、数据集加载、推理时的批量请求。传统数据中心网络“尽力而为”的转发逻辑，在AI集群里完全不够用。结果就是GPU经常处在“干活5分钟，等数据5分钟”的状态，但你从监控面板上看，GPU利用率却始终上不去。这不是GPU的问题，是网络这个“搬运工”拖了后腿。
1.2 训练和推理的流量特征天然“对冲”
这里就得说到“训推一体”这个词了。很多人以为训推一体就是把训练服务器和推理服务器插到同一台交换机上，其实远远没那么简单，因为这两类业务对网络的要求是截然相反的。
训练流量是典型的持续大流量，带宽规格高、持续时间长，但对单次延迟不敏感，能容忍偶尔几百毫秒的波动。推理流量则相反，它是突发性很强的短连接，每一个请求都要求毫秒级响应，第一token时延稍微抖一下，用户体验立刻崩掉。这两种流量如果放在同一张物理网络上，冲突几乎是必然的：训练的巨量数据流会占满交换机缓存，导致推理请求排队；推理的突发流量又可能打断训练的连续传输，造成长尾时延——这会直接影响训练收敛速度。
所以“训推一体”的核心难点，不是把两种设备接进一台交换机，而是要让一张数据网络同时具备两种能力：扛得住训练的大带宽、稳得住推理的低时延。要做到这一点，必须从网络架构、流量调度、拥塞控制三个层面重新设计，这正是联想这个方案想解决的问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 拆解“三位一体”：联想到底把哪三件事塞进了一台方案
2.1 算力维度：把训练和推理放进同一个资源池
联想这个方案讲“三位一体”，我理解的第一层，是算力层面的融合。
传统做法是训练集群和推理集群分开建，各买各的GPU、各拉各的网。好处是互不干扰，坏处是资源浪费非常严重。训练任务通常是白天跑、夜里相对空闲，但如果模型正在持续验证迭代，可能24小时都有任务；推理业务则波动极大，白天流量大、夜间流量小。两套集群独立部署，意味着总有一边的算力在闲置，而闲置的GPU等于闲置的固定资产。
联想方案的思路，是把两类算力整合成一个可以被统一调度的资源池。网络不再区分“这是训练区”“那是推理区”，而是通过算力调度平台按需分配。比如白天跑训练，夜间训练任务减少，就把释放出来的算力切给在线推理，或者反过来，利用训练集群的空闲窗口跑批量推理。这样做的前提，是网络必须保证任务迁移动态且无感——今天这个业务跑在A区，明天切到B区，数据流不能断、性能不能缩水。这就对数据网络的灵活性和自动化提出了很高要求。
我见过不少团队把这一步想得太简单，以为装个K8s就能自动调度了。实际上，算力调度要落地，网络必须先做到“任意节点到任意节点”的连通和可预期性能，否则调度平台把任务切过去，网络却成了瓶颈，一样白搭。联想这套方案里，网络层和算力层是一条链路设计的，而不是“先有算力，再补网络”，这个顺序很关键。
2.2 网络维度：一张数据网，同时承受三类流量
“三位一体”的第二层，也是这个方案技术含量最高的地方：一张数据网络里，要同时承载三类完全不同的流量。
我用高速公路来打个比方。训练流量像满载的集装箱卡车车队，不追求速度，但必须是连续大流量，绝不能中途翻车——一旦丢包重传，整个车队都要停下来等待。推理流量像救护车，单辆车不大，但必须一路绿灯，时延一高就会出人命。存储流量像往返于仓库的物流车，吞吐量要够大，但晚到几分钟问题不大。
传统网络给不了这种差异化服务。联想方案的做法，是在同一张物理网络上做精细的流量分级和通道隔离：训练流量走有保障的无损通道，通过PFC和ECN机制确保零丢包；推理流量走低时延的优先队列，拥塞时优先转发；存储和checkpoint流量则利用空闲带宽，避免占用高优先级通道。
这里最见功力的是拥塞控制策略。RoCE无损网络名声在外，但E宣泄具体参数调起来折磨死人——ECN阈值设大了，拥塞反馈太慢；设小了，流量受限严重。PFC机制如果配置不当，还容易引发队头阻塞甚至死锁。联想方案里针对训推混跑场景做了动态QoS策略调整，能够根据业务负载自动切换带宽分配权重，这比我见过的很多“配一次就躺平”的方案要实用得多。
2.3 交付维度：软硬服一体，藏着最容易被低估的价值
“三位一体”的第三层，我理解是交付模式的融合。硬件只是载体，真正的价值在于整机交付、软件调优和长期服务能不能形成闭环。
交换机本身是个高度同质化的硬件市场，能做的厂家很多，真正的分水岭在于：谁能把网络规划、设备配置、流量调优、故障定位这套流程跑通。联想做这套方案时，比“卖交换机”多走了一步——它同时提供了网络操作系统、智能运维平台和算力调度中间层。硬件负责转发，软件负责认知，服务负责兜底。对客户来说，你不需要分别找网络工程师调RoCE、找软件团队做监控、再找外部专家处理训练中断，联想一家就能扛下来。
这个点，真正有过大规模集群运维经验的人会特别认同。用过多少种品牌的交换机不是关键，关键是出了问题能不能有人快速定位到是配置问题、硬件问题还是流量模型问题。软硬服一体化交付，天然缩短了这条排查链路。
3. 传统“传输网+数据网”架构图，为什么在AI时代需要重新画
3.1 过去的分层逻辑：传输归传输，数据归数据
既然热词里提到“运营商传输与数据网络架构图”，我就顺带多说几句。传统网络架构里，传输网和数据网是两套体系：传输网负责底层的物理承载，解决“管道够不够宽”；数据网负责上层的业务路由，解决“数据到哪去”。两层独立规划、独立运维，各管各的，这是过去几十年的成熟范式。
这套范式在传统业务里没什么问题，但在AI集群里就显得有点僵化了。AI的数据流是跨层流动的，从GPU到交换机、从交换机到存储、从存储到训练平台，每一跳的性能都会影响端到端效果。你单独把传输层的带宽扩容、单独把数据层的路由优化，都解决不了AI集群的整体性能问题。因为瓶颈可能不在任何一层，而在于层与层之间衔接处的拥塞、丢包和时延抖动。
3.2 AI训推网络的新逻辑：三平面协同，而不是物理隔离
AI数据中心里，一张物理数据网实际承载着三个逻辑平面：计算后端网络（GPU到GPU通信）、存储网络（读写训练数据）、管理业务网络（调度、监控、登录）。
传统做法是把这三个平面物理隔离开，用不同的交换机集群承载，目的是避免互相干扰。但这会带来三个代价：硬件成本上升、运维复杂度成倍增加、资源利用率降低。尤其是GPU集群扩容时，每个平面都要同步扩容，网络投资几乎翻倍。
联想方案的思路是“物理一张网，逻辑三个平面”。通过VXLAN和网络切片技术在底层共享、逻辑隔离，让三类流量各自跑在专属通道里，互不干扰。这样既保留了隔离带来的稳定性，又减少了设备数量和运维成本。用运营商的术语说，这就是“一网多用、一网多算”的落地形态。
从架构图上看，这套方案里已经看不到传统“传输层”“数据层”的清晰边界了，取而代之的是“算力层、网络层、存储层”之间紧密咬合的交互关系。画架构图的人必须开始把AI训练任务的通信模式、参数同步机制、数据读取路径画进网络拓扑里，否则画出来的图基本没法指导实际建设。
4. 现实检验：训推一体要落地，四个绕不开的检查点
4.1 规模上到千卡之后，RoCE还能不能“稳”
口号喊得再好，落地终归要看硬实力。第一道坎就是RoCE大规模部署的稳定性。
RoCE（RDMA over Converged Ethernet）是当前无损以太网的主流方案，优势是成本低、生态成熟，但不代表它没坑。PFC死锁、ECN参数失调、缓存分配不合理，都是最常见的故障源。我见过一个500卡集群，因为ECN阈值没调好，训练速度忽快忽慢，工程师排查了整整一周才定位到问题是交换机缓存被逻辑队列占满。
联想方案宣称支持千卡乃至更大规模的无损网络，但我建议客户在验收时不要只看厂商跑通的报告，要在自己的机房、用自己的流量模型真实压测。压测方法很简单：把NCCL的AllReduce测试任务跑起来，观察时延曲线和重传率。只要重传率超过万分之几，这个网络就不算“无损”。
4.2 训推混跑时，QoS策略会不会“互相踩脚”
第二道坎是训推混跑时的策略冲突。训练任务占用的带宽极大，如果它的优先级设置得不合理，推理流量就会在拥塞时被“饿死”；反过来说，如果把推理请求优先级设得太高，训练流量又可能频繁被降速，长尾效应让单步训练时间不稳定。
正确的做法，是要给不同业务设置明确的带宽下限和上限，而不是仅仅给优先级。训练流量可以占大头带宽，但要给它设一个可压缩的上限；推理流量需要在拥塞时被优先转发，但它不能无限占用带宽。这就需要在智能运维平台上做细粒度的策略编排，同时支持运行中动态调整。联想这套方案里，网络策略是可以跟随算力调度策略联动的——训练任务减少时，自动把更多带宽配额分配给推理链路，这正是我认为它的价值所在。
4.3 多芯片混布：不能只看“通不通”，还要看“认不认识”
第三道坎是异构算力支持。现在很多智算中心不是清一色NVIDIA，而是部分NVIDIA加部分国产加速卡的混合集群。不同芯片的通信库不同、对网络的要求也不同，NVIDIA走NCCL，国产卡可能走RCCL或者自定义协议。
如果在同一张数据网络里混跑多种芯片，网络必须做到“识别流量特征”。也就是说，它得能判断当前的流量来自哪种通信模式，自动调整拥塞控制参数和流表转发策略。联想方案强调“一网多芯”，本质上就是让网络层具备对异构算力的感知能力。这个能力在测试环境里看不出差别，但到了混合集群规模上到千卡的时候，如果网络对某一种芯片的通信模式不友好，整个集群的性能就会瞬间被拉垮。
4.4 运维团队，能不能守住长期SLA
还有一个最容易被忽略的检查点：运维能力。AI集群和传统数据中心的运维逻辑完全不一样。传统数据中心关注链路状态、丢包率、设备CPU负载，这些静态指标在AI集群里基本不够用。
AI集群的运维，需要把网络质量与训练效率关联起来。比如，某个GPU节点的梯度同步时间突然变长，到底是网络拥塞引起的、还是对端节点故障引起的、还是存储带宽被占满了？这要求运维平台具备全链路可视化的能力，从GPU通信模式到网络转发路径，到存储读写时延，一条链路打通来看。联想这套方案里的智能运维模块，会针对训推业务做主动监测和自动定位，我的感受是，这个能力比多买几台设备更能决定一个项目的长期成败。
5. 谁适合上这套“全能ACE”，我建议按这张清单自测
5.1 典型客户画像
不是所有客户都需要训推一体方案，也不是所有客户都能用好它。根据我这段时间的观察，适合采用“联想数据网络训推一体解决方案”的客户，一般符合这几个特征：
- 已有或者正在建设规模在数百卡以上的GPU集群；
- 同时存在训练和推理业务，或者一两年内会同时出现两类业务；
- 资源预算有限，无法接受训练和推理两套网络独立建设；
- 运维团队愿意接受更自动化的网络管理模式；
- 对供应商的集成能力和长期服务有明确要求。
如果你只是跑小规模的模型推理，或者GPU集群只有几十卡，那没必要上这么复杂的一套体系，传统接入交换机加合理的网络规划就够了。训推一体是个“越大规模越划算”的生意，规模太小反而体现不出优势。
5.2 给IT负责人的五条实用建议
第一，把“GPU利用率”当作最核心的采购指标，而不是单纯比端口速率和交换机价格。同样的GPU集群，网络方案做得好，利用率上浮10到20个百分点，比便宜采购交换机划算得多。
第二，在合同里明确要求供应商提供针对NCCL集合通信模式的调优服务，而不是只交付设备。因为不同模型的通信模式差异很大，不改参数甚至影响模型是否卡死。
第三，做PoC验证时，一定要用客户自己的数据流和行为模式，千万不要只跑厂商提供的基准测试。场景不一样，结果可能天差地别。
第四，要求供应商给出从千卡到万卡的可扩展路径。现在的方案只需要覆盖当前规模，但你得知道未来翻十倍时，网络架构需不需要推倒重来。
第五，关注运维平台能不能实现网络、算力、存储一体化监控。AI集群里，这三者之间互相影响非常明显，如果监控体系割裂，故障定位效率会低到让人崩溃。
5.3 我的两点观察
训推一体这个方向，我判断是对的。把训练和推理放在一张数据网络上，在成本、运维和资源利用率上都有明显受益。但网络只是必要条件，不是充分条件。算力调度平台、容器编排、存储系统这三者必须跟网络同步适配，才能真正把“一体”的价值落到位。联想这套方案，在“网络与算力协同”上迈出的步子比较大，这也是它叫作“数据网络训推一体解决方案”的原因。
另外一点：我比较看好愿意算总账的用户。如果你的决策逻辑是“方案能帮我把GPU利用率从35%提到55%，那我愿意为这个网络方案买单”，那你会觉得这个方案很有价值。如果你的决策逻辑是“交换机比别家贵了百分之十，不能接受”，那确实只能错过这波算力效率升级的红利。行业都已经卷到这个程度了，省运维的钱、省GPU闲置的钱，才是真正的大头。