算力网络：你那张闲着的GPU卡，为什么共享不出去？

去年秋天，我去一个高校实验室串门。他们买了8张A100，白天跑推理，夜里基本空着。隔壁组做训练的，排队等卡等到骂娘。有人提了一嘴“算力网络”，说把闲卡挂上去，大家互通有无。听起来很美对吧？结果折腾了两周，卡是挂上去了，但真跑起来的跨组任务，一只手数得过来。

为什么？不是网线不够粗，是数据搬不动。

这事儿特别典型。一说算力网络，很多人脑子里浮现的是“把全国GPU连成一张大网，像拧自来水一样用算力”。但现实是，你拧开龙头之前，得先修好下水道。而算力网络的下水道，比大多数人想象的要堵。

先别聊“算力”，聊聊“搬运”

算力网络这个词，字面上容易误导人。它听起来像是“算力”是主角，“网络”是配角。但在工程现场，顺序经常反过来——网络决定了算力能不能被用上。

我打个比方。电网为什么好用？因为电是标准化的、无状态的。你家的灯泡不关心电是从三峡来的还是从内蒙古来的，插上就能亮。但GPU不是发电机，它更像一个带缓存、带内存、带操作系统的加工厂。你要让它干活，得先把原料——数据——运进去，还得把半成品和成品运出来。这个搬运过程，要穿过网卡、交换机、路由器、防火墙，每一跳都在收过路费。

实验室那个案例，数据集不大，也就200GB。但两个组在不同校区，走的是校园网出口，实测带宽跑满也就200Mbps。算一下：200GB等于1600Gb，除以0.2Gbps，大概8000秒，两个多小时。训练一个BERT微调任务，在8卡上跑三个小时。也就是说，搬数据的时间比算的时间还长。这还没算上传输中断、权限审批、存储挂载的折腾。你说谁愿意用？

所以算力网络的第一性原理，不是“把卡连起来”，而是“让数据和任务找到彼此”。连起来容易，拉根光纤的事。难的是让调度器知道哪张卡闲着、闲多久、数据在哪、搬过去要多久、跑完结果怎么拿回来。这一串问题，每一个都能让工程师掉头发。

调度器眼里的世界，和网线眼里的世界不一样

现在业内聊算力网络，绕不开几个技术词：算力路由、SRv6、RDMA无损网络、算网大脑。听着挺唬人，拆开看其实都是解决具体麻烦的。

比如算力路由。传统网络路由只看“到目的地哪条路近”，不看“目的地那台服务器忙不忙”。你发一个训练任务过去，路由说“这条路延迟5毫秒”，结果到了发现GPU利用率100%，排队排到明天。算力路由想干的事，就是把算力的状态——利用率、显存剩余、任务队列长度——注入到路由决策里。听起来合理吧？但落地的时候你会发现，网络设备是运营商管的，算力状态是云厂商管的，两边数据不通。跨域调度，光接口对齐就能开半年会。

再说RDMA。这玩意儿是为了让服务器之间传数据不经过CPU，直接内存到内存，延迟低、带宽高。但RDMA对网络质量极其敏感，丢一个包，性能可能掉一半。所以你得搞无损网络，配PFC、ECN，调参数调到怀疑人生。我见过一个团队，为了跨机房跑RDMA，光交换机配置就折腾了三个月。最后跑通了，但运维复杂度直线上升。说实话，大部分中小团队根本养不起这样的网络。

还有个更隐蔽的坑：异构。你调度过去的任务，代码是基于CUDA写的，结果对面是昇腾的卡，跑不起来。或者对面是AMD的卡，ROCm版本不兼容。算力网络理想状态下应该屏蔽这些差异，但现实中，软件栈的碎片化比硬件碎片化更致命。所以很多算力调度平台，悄悄做成了“同构优先”——先把一个云内的同型号卡池化，跨云只做镜像同步和冷数据备份。宣传材料上不写，但工程上大家都懂。

数据搬运的账，比算力本身贵

我特别喜欢算一笔账，每次讲算力网络都拿出来用。假设你有1PB的冷数据，想从东部搬到西部训练。走100Gbps专线，理论时间：1PB等于8000Tb，除以100Gbps，80秒？不对，单位搞错了。1PB等于8,000,000Gb，100Gbps等于100Gb每秒，那就是80,000秒，约22小时。实际上专线不可能跑满，加上协议开销和存储读写，两三天很正常。这还只是一次性搬迁。如果数据要频繁更新呢？每天增量1TB，走1Gbps专线，大概两个半小时。训练任务等得起吗？

所以“东数西算”这类工程，真正适合的是离线训练、冷数据归档、模型批量推理。实时推理、小样本微调、交互式训练，老老实实在本地或者边缘做。算力网络不是万能钥匙，它解决的是“大规模、可容忍延迟、数据相对静态”的场景。

那什么场景真能用上？我观察到两类。一类是模型分发：一个大模型在中心训练好，通过算力网络推到各个边缘节点做推理。数据不用回传，模型下去就行。另一类是联邦学习：数据不动，模型动。各个节点本地训练，只交换梯度。这两类场景的共同点是搬的东西比搬数据便宜。算力网络的经济账，核心就在这儿。

别被“算力表”骗了，算力度量还没统一

电网有电表，按度收费。算力网络想学这个，但算力的“度”是什么？FLOPS？显存带宽？卡间互联速率？存储IOPS？没有一个指标能单独衡量。A卡的100 TFLOPS和B卡的100 TFLOPS，跑同一个模型可能差出30%。再加上稀疏计算、混合精度、算子优化，纸面算力和实际吞吐完全是两码事。

我见过一些算力调度平台，界面上列着“可用算力：500P”。你问他这500P怎么算的，他给你看一个表格，把各种卡的峰值算力加起来。这不是算力网络，这是算力加法。真正的算力度量，得跑基准测试，得看实际任务吞吐，得考虑网络和存储的瓶颈。但基准测试又依赖模型和框架，换个模型排名就变。所以到现在，行业里也没有一个公认的“算力折算系数”。这事儿吧，急不得，但也不能装看不见。

还有一个常被忽略的边界：安全。你把任务调度到别人的数据中心，数据出去了，代码出去了，模型权重出去了。万一对面偷数据怎么办？万一任务跑了没给钱怎么办？区块链、可信执行环境、联邦调度，方案一堆，但落地成本高。很多算力网络试点，最后卡在法务和审计上，不是技术不行。

回到开头那张闲着的GPU卡。真正的解法，可能不是把它挂到公网算力网络里，而是在实验室内部先做容器化、配额管理、任务队列。把闲置率从70%降到30%，比跨城调度实在得多。算力网络是大方向，没错。但别被概念带着跑。每次有人跟我聊算力网络，我都先问三个问题：数据在哪？任务等不等得起？出了故障谁背锅？这三个问题答不上来，网线插得再粗，也就是个摆设。