算力网络：把计算变成可调度的公共品，难在哪？

先看一个不太好看的场景：某地智算中心机柜上电了，上架率却不高；另一边，高校团队排了一周队，只拿到几小时训练窗口。算力网络要处理的，正是这种错配。它不等于把机房连起来，也不等于做一个调度大屏。更准确的表述是：让异构算力在业务约束下可发现、可预约、可计量、可追责。定义很短，工程很长。

前几天在南京，一个做智算中心运维的人说，最怕演示时一切正常，割接时全在排队。这话粗糙，却点中了要害——网络把资源连起来之后，调度系统面对的不是一个干净的资源池，而是一堆型号、拓扑、框架版本和运维边界都不同的孤岛。

调度不是把任务丢过去

算力不是单一标量。GPU型号、显存、互联拓扑、存储带宽、CUDA版本、甚至驱动补丁，都会改变一个任务能不能跑、跑得多快。把算力抽象成“多少P”或“多少卡”，只适合做广告，不适合做调度。真正可用的资源描述，至少要带拓扑感知和运行时约束。跨数据中心训练尤其明显：参数同步对带宽和时延敏感，链路抖动会放大成迭代周期的不稳定。推理任务相对好迁移，训练任务未必。别急着谈全局调度。

另一个隐形问题是度量。算力并网之后，买方怎么确认拿到的算力没有被超卖？计量粒度是卡时、作业时，还是按有效吞吐结算？不同框架的利用率口径不同，账就对不上。没有可审计的计量，算力交易很难从试点走到生产。这不是写个API能解决的。

时延和成本之间没有免费午餐

算力网络常被描述成“把计算送到最近的地方”。这句话只对了一半。数据搬运有成本，模型切分有代价，跨域调度还会引入新的故障域。边缘推理适合低时延、数据不出园区的场景；中心训练适合大规模并行和弹性资源。两者之间不是谁替代谁，而是按预算分工。

确定性网络、算力路由、在网计算这些方向有价值，但都有适用条件。比如在网计算要求业务可拆分、网元可编程、运维可观测；确定性网络要求端到端路径可控，跨运营商时约束会变松。反例也清楚：工业控制、高频交易这类场景，不会轻易把计算放到广域网上碰运气。时延预算不够时，再漂亮的调度算法也只是把排队换了个地方。

从试验网到生产网，几道坎

试验网可以只跑一个示范业务，生产网要面对多租户、计费、安全隔离和故障定位。算力并网听起来像电力并网，实际更难。电有相对统一的频率和电压，算力没有统一“插座”。异构资源池化需要接口标准，但标准太粗会丢信息，太细又难落地。调度器还要处理资源碎片：大任务要连续拓扑，小任务要低碎片率，两者的策略经常打架。

结算也是坎。按卡时计费简单，却容易掩盖空转；按作业计费合理，又依赖可信的运行时采集。跨域调度还涉及责任划分：任务失败是算力节点的问题，还是网络链路的问题？没有清晰的SLA和可观测数据，扯皮成本会超过算力成本。前几天在南京听到的那句吐槽，后半句是：故障夜里，大屏不会替你定位。

边界与风险：别把网络当万能胶

算力网络有明确边界。数据合规不允许出域的，别调度；时延预算极紧的，别绕路；故障容忍度低的，别把控制面集中到一个点上。集中调度能提高利用率，也会扩大单点故障的影响面。资源超卖在短期能提高收入，长期会破坏信任。调度震荡同样值得警惕：价格信号一变，任务来回迁移，网络和存储先扛不住。

趋势上看，算力路由、算力交易、在网计算会继续推进，但落地节奏取决于计量标准、安全边界和运维体系，而不是某一次发布会。应用侧更现实的做法是先把可迁移任务识别出来，再谈跨域。训练任务看互联，推理任务看时延，数据预处理看本地存储。条件不同，路径就不同。

算力网络真正的门槛，不在演示大屏，在故障夜里谁值守。话不好听，但工程就是这样。