算力网从“资源接入”走向统一调度：企业如何评估异构算力的性能、成本与可用性？

企业评估算力，过去习惯先问“要买多少卡、建多大机房、签多长合约”。全国一体化算力网络从资源接入进入统一调度后，这个问法已经不够用。智能算力规模在快速扩张，但机架上架率和任务匹配效率并没有同步抬升；GPU、国产加速芯片、通用CPU和边缘节点同时存在，跨地域机房与多云资源池也同时在线。真正决定交付质量的，不再是账面算力总量，而是调度系统能否把训练、推理和通用计算放到合适的架构、合适的时延圈，以及可验收的服务等级上。对技术负责人和架构师来说，采购决策要从“买多少算力”转向“如何调度和验收算力”。

算力网真正改变的不是机架数，而是调度边界

算力网要解决的核心问题，是算力孤岛。过去，企业自建机房、单一云厂商资源池、地方智算中心往往各自成体系：芯片指令集不同、集群调度接口不同、网络时延和计费口径也不同。任务进不了空闲集群，空闲集群也接不住外来作业，结果是一边排队、一边闲置。

2023年6月，中国信通院联合中国电信发布全国一体化算力算网调度平台1.0版，目标就是把通用算力、智能算力、高性能算力和边缘算力放进同一套感知与分发体系，实现不同厂商异构资源池的动态感知和作业智能调度，尤其在AI训练流程中支持跨资源池、跨架构、跨厂商分发。当时天翼云、华为云、阿里云已接入该平台。平台设计强调“三跨四互联”，把网络状态、综合算力和调度引擎绑在一起，而不是只做资源目录展示。相关背景可见证券时报当时的报道。

规模侧的变化同样快。工业和信息化部相关数据显示，截至2025年6月底，全国在用数据中心标准机架数达1085万架，智能算力规模提升至788EFLOPS，400G高速端口部署量增至14060个，数据中心平均PUE优化至1.42。到2026年6月底，智能算力规模已达2185EFLOPS，同比增长177%。机架总量和上架率也在同步抬升：2023年底在用算力中心约810万标准机架、平均上架率66%；2026年3月底标准机架达1445万架，整体上架率71.4%。北京市算力互联互通平台则给出了区域样本：以北京为核心，汇聚天津、河北、内蒙古等地智能算力，资源累计超60EFLOPS，接入30余家算力服务商，标识注册量超9万条，初步形成跨地域、跨主体、跨架构的匹配能力。上述数据分别见武汉市数据局转载的产业综述和《经济参考报》对智算供给的梳理。

这些数字说明两件事。第一，智能算力已经从“有没有”变成“如何用”；第二，如果没有统一调度，增量机架很难自动转化成可交付产能。对企业而言，算力资源池不再只是本地机柜或某一朵云的配额，而是一张可感知、可编排、可验收的供给网。

三种供给模式，先统一比较维度

落地时最常见的不是“要不要上算力网”这种抽象选择题，而是本地部署、单云资源池、跨地域统一调度三条路径如何取舍。比较必须用同一套维度：性能一致性、网络时延、任务迁移成本、资源利用率、服务稳定性、综合成本和运维复杂度。任何只比较单价或峰值算力的方案，都容易把异构差异藏进后期事故里。

本地部署适合对数据主权、模型保密和训练吞吐极度敏感的场景。它的优点是性能曲线可预测：同一代加速卡、同一套存储和同一套集合通信，checkpoint和梯度同步不容易被未知网络抖动打断。代价是弹性差。任务峰值一来，扩容以月计；任务一停，电费和折旧继续发生。如果企业只有一条稳定的大模型训练流水线，且数据不能出域，本地或托管式专有集群通常仍是第一选择。

单云资源池适合已经把开发、训练、推理和业务系统放在同一套云计算账户里的团队。镜像、对象存储、密钥、观测和权限可以复用，弹性伸缩也比自建快。风险在于“看起来统一、实际仍可能异构”：同一厂商内部也有不同加速卡、不同代际实例和不同区域库存。如果只按GPU数量下单，不锁定驱动、CUDA/运行时、互联带宽和抢占策略，训练任务的可复现性会下降。单云方案能减少多栈运维，但不能自动解决芯片代际差和区域库存波动。

跨地域统一调度是算力网真正要交付的能力。它把东部高时延敏感业务和西部低电价、大规模智能算力衔接起来，也把通用算力与智算资源池衔接起来。适合它的作业通常具备三个特征：可中断或可checkpoint、对单次请求时延不极端敏感、数据和镜像已经标准化。批量微调、离线推理、渲染、科学计算和部分数据治理任务，往往比在线对话推理更适合“算力搬家”。如果不先做任务画像，就把核心在线服务丢进跨架构调度，节省的是目录上的单价，增加的是故障定位时间。

验收不能只看峰值算力，而要看六类可测量指标

异构算力调度一旦进入采购和验收，企业最容易犯的错误，是把不同架构的算力折算成同一个“卡时单价”。FLOPS不能在GPU和NPU之间直接兑换，通信带宽、显存容量、算子覆盖率和编译器成熟度都会改写实际吞吐。建议把验收拆成六类指标，并在合同或内部SLA里写成可复测条目。

第一是有效性能，而不是标称性能。对训练，至少要测到稳定的tokens/s或samples/s、扩卡后的并行效率、长时间任务的性能漂移。对推理，要区分首token时延、吞吐和批处理效率。同一模型在不同芯片上的表现差，往往来自算子缺失、精度策略和通信库，而不是“卡不够”。

第二是网络时延和带宽稳定性。跨地域调度的上限通常不由芯片决定，而由数据能否及时到达计算节点决定。需要分开看控制面时延、数据面吞吐、集合通信带宽和跨枢纽传输费用。训练作业对东西向带宽和丢包极其敏感；批量推理可以容忍分钟级排队，但不能容忍数据反复回传。

第三是任务迁移代价。镜像体积、检查点频率、数据集分片方式和编译产物是否可移植，决定一次调度是“换个队列”还是“重做工程”。如果每次换架构都要重新适配训练脚本、重切分数据和重验证精度，所谓统一调度只是多了一个工单入口。

第四是资源利用率。要同时看集群维度的平均利用率和作业维度的有效占用。很多资源池表面上很忙，实际大量时间耗在排队、数据预热、失败重试和碎片化显存上。利用率提升只有在作业可打包、可抢占、可回收时才有意义。

第五是服务稳定性。包括故障切换时间、训练中断后的续跑成功率、推理副本的自动恢复，以及跨厂商时的责任界面。统一调度把故障域变大了，如果没有统一的日志、指标和追踪，排障会从“看自己的集群”变成“在多个运营主体之间对证据”。

第六是综合成本。除了卡时和机架租金，还应计入电费或云上折扣后的真实单价、存储和出网、模型转换和回归测试、人员值班，以及因排队导致的业务等待。西部低电价对长周期训练有吸引力，但对需要高频回传特征数据的在线系统，网络和延迟成本可能把电费优势吃掉。

按场景给出评估清单，而不是一套通用评分

不同作业对调度的容忍度差别很大。企业不需要先建一张“全能算力网”，而需要按模型训练、批量推理和通用计算分别设定准入条件。下面清单适合作为内部评审表，而不是对外招标的唯一技术规范。

模型训练

先确认数据能否按法规和内部制度离开原集群。不能出域的，只评估本地或同城专有资源池；可以出域的，再看目标枢纽的网络和存储是否支撑全量数据预热。接着锁定芯片代际、互联拓扑、集合通信库和混合精度策略，要求供应商提供与生产模型同结构的多机多卡扩展曲线，而不是单卡跑分。检查点必须可在目标集群续跑，失败重试不能依赖人工拷盘。成本上应比较“完成一次有效训练”的总价，包含失败重跑和等待时间，而不是最低卡时报价。若目标是跨架构调度，还要预留精度回归窗口：同样的训练步数，损失曲线和下游评测必须达到可接受偏差。

批量推理

批量推理是算力网最容易先打穿的场景。它对单次时延不极端敏感，却对排队长度、单位成本和夜间闲置消化很敏感。评估重点应放在：任务能否切片、结果是否可后处理校验、冷启动和模型加载耗时、不同芯片上的数值一致性。若推理框架和量化策略已经标准化，跨地域、跨厂商调度的工程阻力会小很多。此时可以主动把低优先级作业导向低电价区域或低峰库存，但必须设置超时回退：超时未调度成功，自动回到原资源池，避免业务积压。成本验收应看每千条样本或每百万token的完整费用，包含存储读取和结果回传。

通用计算

通用计算覆盖数据分析、仿真、渲染、代码构建和传统高性能计算。这类任务不一定需要顶级智能算力，却最容易被“全部上GPU”的采购惯性带偏。评估时先按CPU、GPU、NPU做画像，能在通用算力资源池完成的不要挤占训练队列。对时延敏感的业务查询、风控和交易链路，应固定在本地或同城云资源，只把可异步的部分交给统一调度。兼容性上要检查容器镜像、调度API、身份权限和审计日志能否与现有云计算平台对接，否则统一调度会变成第二套运维体系。可用性目标也要分层：核心链路按原SLA执行，可迁移作业允许降级和重试。

落地边界：先可调度，再谈更大范围接入

统一调度不是把所有资源登记进目录就算完成。企业落地时，建议把边界写清楚，避免项目从架构升级退化成资源堆叠。

先做任务分级。只有可中断、可校验、对架构不敏感的作业，才进入跨地域调度白名单。在线推理、核心交易和未脱敏数据默认不跨架构，除非完成同等压力的演练。再做运行时收敛。芯片可以异构，但训练框架、容器基础镜像、观测探针和权限模型应尽量统一，否则调度器只能做“人工派单”。接着做网络和数据平面验收。没有稳定的传输带宽、没有对象存储就近缓存、没有跨域身份，算力网的控制面再完整，数据也到不了计算节点。最后做对账和责任界面。多云、多枢纽意味着故障、账单和安全事件会同时出现多个主体，必须事先约定监控口径、日志留存、切换条件和赔偿边界。

实施顺序上，不宜一上来就追求全国范围内的最优匹配。更稳妥的路径是：先把企业内部已有的本地集群和单云资源池纳管成统一视图，打通队列、镜像和成本账单；再选择一类批量作业做跨区域试点，用真实任务验证时延、精度和回退；最后才把调度范围扩展到外部算力网和更多异构芯片。北京市这类“核心枢纽+区域协同”的实践说明，跨地域、跨主体、跨架构是可以形成匹配能力的，但前提是标识、接入和服务商治理已经先于业务流量完成。

对制定算力采购方案的管理者，决策可以收成三句。能预测且必须可控的训练，优先同构、近数据和可独占的资源；能切片且可验收的批量作业，优先进入统一调度以提升利用率；不能降低时延和合规要求的在线系统，不要为了目录上的低价去换不可控的路径。算力网的价值，不在于让企业看见更多机架，而在于让每一类作业都能被调度到可测量的性能、可解释的成本和可追责的可用性上。