最近学习 AI 基础设施相关资料时，发现 Scale-Across 被提及的频率越来越高。2025 年，NVIDIA 发布 Spectrum-XGS Ethernet，探索如何通过专用网络连接分散的数据中心；2026 年，中国移动推出 GSE-DCI，烽火通信也在推进 800G 与空芯光纤等技术的用于 Scale-Across 应用。
这些进展背后，是要解决一个共同的问题：当电力、机房空间和散热条件限制了单个园区的扩容，能不能把不同地点的算力组织起来，让它们共同完成 AI 任务？
这就是我理解的 Scale-Across。它把数据中心连接起来，其重点在于判断哪些任务适合跨域执行，如何选择算力和网络路径，以及新增的算力能否真正转化为任务效率。
这篇笔记先聚焦概念本身。Scale-Across 是什么，和 Scale-Up、Scale-Out 有什么区别，它要解决什么问题，以及有哪些不能忽略的限制。
三个 Scale：从单机扩展到跨域协同
要理解 Scale-Across，最好的方式是把它放在 AI 算力扩展的全景视图里看。
目前，AI 数据中心的扩展方式大致可以分成三个层次。
Scale-Up ：扩大单个计算系统。
通过高带宽、低时延互联连接多颗 GPU，让它们对外尽可能表现得像一个更大的计算单元。核心追求是极低延迟，减少计算单元之间的通信开销。距离通常很短，铜缆互联仍是主流。
Scale-Out ：扩大集群规模。
单个系统塞不下更多 GPU，就在同一个数据中心内增加服务器和计算节点，通过数据中心网络承载节点间通信。核心关注的是带宽、拥塞、抖动和资源调度。
Scale-Across ：跨数据中心组织算力。
单个园区受到电力、空间、散热或其他基础设施条件限制，就让不同地点的算力共同承担合适的任务。跨园区、跨城市，甚至跨州、跨国。
这个类比不严谨，但好记。
- Scale-Up 像是"把一台电脑的多个 GPU 插在一起"；
- Scale-Out 像是"把同一个机房里几台算力服务器组合在一起"；
- Scale-Across 则是"把分布在不同地域机房的算力服务器连成一台超级计算机"。
Scale-Across 面临的问题在于不仅要处理更多计算节点，还要面对更长的通信距离、不同地点的资源状态，以及算力、数据和网络之间的协调问题。
把两地的 GPU 连起来，并不意味着它们就能像同一机房里的 GPU 一样工作。物理距离带来的传播时延不会消失，网络拥塞和数据搬迁也可能抵消一部分算力收益。
因此，Scale-Across 首先要解决的不是"能不能连接"，而是 “什么任务值得跨域，以及怎样跨域才划算” 。
为什么需要"跨出去"？
答案很直接：一个数据中心装不下了，没法扩容了。
AI 模型的规模在指数级增长。训练这些模型需要数万甚至数十万张 GPU 协同工作。但物理世界有硬约束。
传统云数据中心的功率通常在几十到几百兆瓦之间，而新一代 AI 集群对电力的需求正在向吉瓦级迈进。单个地区的电网容量、土地资源和散热条件，很难支撑如此大规模的算力集中。
能源分布也并不均衡。有些地区电力资源丰富，有些地区气候适合散热，有些地区土地成本更低。把所有算力都集中在一个园区，虽然有利于统一管理和缩短通信路径，但也会集中供电压力和扩容风险。
跨地域部署能够利用不同地区的资源条件，为后续扩容提供空间。但分散部署之后，原本在本地完成的通信需要经过更长的网络路径，系统组织方式也随之变复杂。
不得不跨出去。 单一数据中心正在触及物理环境的天花板，而 AI 对算力的需求还在往上冲。Scale-Across 就是在这样的矛盾中诞生的架构方向。
Scale-Across 到底要解决什么？
跨域算力协同，至少要解决三个问题。
第一，任务调度：哪些任务适合跨域？
不同任务对网络的依赖程度并不一样。需要频繁同步参数的分布式训练，对通信时延和稳定性比较敏感；批量推理、离线计算和部分可独立执行的任务，则更有机会利用异地闲置算力。
第二，算力分配与路由：任务放在哪里，数据走哪条路？
调度系统不能只看哪里有空闲 GPU，还要考虑模型和数据的位置、任务的通信特征，以及目标算力节点的网络条件。网络路径也不能只追求物理距离最短，还需要综合考虑可用带宽、拥塞、可靠性和任务时限。
第三，网络承载：怎样让跨域通信尽可能高效？
光层负责大容量传输和光路资源，IP 层负责路由、流量工程、业务隔离和可达性。两层需要协同提供适合任务需求的网络能力，并把必要的网络状态反馈给上层调度系统。
这三个问题是连在一起的：任务特征影响算力选择，算力位置影响通信路径，网络状态又会反过来影响任务执行效果。
因此，Scale-Across 的核心是 让合适的任务找到合适的算力和网络 。
它和 Scale-Out 的本质区别
从表面看，Scale-Across 和 Scale-Out 都是"用网络连接更多计算节点"。但距离一变，问题性质就变了。
首先是传播时延。同一数据中心内，节点间距离通常在几十米到几百米，传播时延可以忽略。但跨域场景下，100 公里光纤路径的单向纯传播时延就约为 0.5 毫秒，往返约 1 毫秒。实际网络还会叠加设备处理、排队和路径绕行等开销。
其次是抖动和拥塞。广域网络的流量环境更复杂，路径更长，经过的设备更多。跨域通信的抖动和拥塞控制，比数据中心内部更难。
第三是数据位置。跨域调度时，模型、输入数据和中间状态可能分布在不同的存储系统中。数据搬迁的时间和成本，可能抵消远端算力带来的收益。
第四是运维边界。跨域网络往往涉及多个管理域、多个运营商、多套运维体系。故障定位、服务等级和计费方式都更复杂。
所以，Scale-Across 不是简单地把 Scale-Out 的网络拉长。它需要针对长距离、跨域、算网协同的特点，重新考虑网络架构、调度策略和业务适配。
几个不能忽略的技术限制
Scale-Across 可以改善分散算力的组织方式，但无法消除分布式计算本身的约束。
第一，传播时延存在物理限制。
100 公里光纤路径往返传播时延约为 1 毫秒。评估跨域算力协同时，需要关注真实网络路径和往返时延。因此，Scale-Across 不存在统一的距离限制，和其算力任务类型有关，训练类业务、推理类业务、数据类业务对时延有不同的要求，也就限制了 Scale-Across 的业务类型。采用空芯光纤，能使Scale-Across的可选业务类多一些。
第二，带宽高不代表训练一定快。
频繁同步参数或交换中间结果的任务，对时延和通信轮次较为敏感。即使链路带宽很高，新增的传播时延仍可能限制任务效率。
对于大块数据传输、批量推理或对时延不敏感的任务，增加带宽则更容易带来收益。网络方案必须结合任务的通信模式来判断。
第三，数据搬迁可能抵消算力收益。
远端有空闲 GPU，不代表把任务迁过去一定划算。如果模型、输入数据或中间状态需要大量搬迁，传输耗时和成本可能超过新增算力带来的收益。数据还可能受到隐私、合规或业务边界约束。
因此，算力调度需要同时考虑算力位置和数据位置，减少不必要的数据移动。
第四，并非所有训练任务都适合跨域。
不同模型、并行策略和通信模式对网络的依赖程度不同。可以拆分、通信较少的任务，更容易利用异地资源；需要频繁同步的训练，则必须更谨慎地评估跨域通信开销。
第五，算网协同也会增加系统复杂度。
跨域调度涉及算力管理、任务编排、网络控制、数据管理、安全和故障恢复。如果各系统缺少一致的状态定义和协同接口，可能出现调度与网络状态不匹配、故障定位困难等问题。
因此，算网协同不只是网络技术问题，也是系统集成、运营管理和服务设计问题。
小结
Scale-Across 不是某一种设备或协议，而是一种跨域组织 AI 算力的架构方向。它的价值在于让适合的任务使用合适的资源和传输路径。
从概念上看，它至少包含三层含义。
・ 连接层：把分散的数据中心通过高性能网络连接起来； ・ 调度层：判断哪些任务适合跨域，选择算力和网络路径； ・ 协同层：让网络状态参与算力调度，让任务执行效果反馈网络优化。
网络连接是基础，算网协同是手段，任务效率与综合收益是最终目标。 对 Scale-Across 更合适的态度或许是，积极探索，谨慎部署，场景验证，逐步演进。
它能不能真正创造价值，最终要看它是否让任务完成得更快、更稳定，或者以更低的综合成本使用算力。连接了多少数据中心、提供了多高的带宽、汇聚了多少 GPU， 这些数字本身说明不了价值 。
说明：本文为个人技术学习笔记，主要是用于理解 Scale-Across 的概念。错误之处，欢迎留言指正。