在上一篇文章《从云连接到算力网络：重新认识 DCI、DCA 和 DCN》中，我们讨论了 DCA、DCI 和 DCN 的基本含义，以及运营商应该如何理解这几个概念。上一篇文章解决的是概念问题，接下来要讨论的是建设问题：AI 的发展究竟给运营商网络带来了哪些新的要求，现有网络应该如何演进，运营商又应该以什么方式提供连接服务。

DCA、DCI 并不天然对应两张独立的物理网络。 对运营商而言，它们更多是对不同连接需求的描述，也可以成为描述网络能力、解决方案和产品的一种形式。真正承载这些业务的，仍然是现有的光缆网络、光传输网络和 IP 网络。是否需要新建网络，应由业务需求和现有网络能力共同决定，而不应由名称决定。

从云计算时代的网络基础出发

经过多年建设，运营商已经形成了从骨干网到本地承载网的覆盖网络基础。在云计算时代，运营商已经围绕云服务的连接需求，并依托骨干本地一体的承载网络，为云服务商、互联网企业、金融机构、大型政企客户提供连接能力。这些网络并不是专门为某一种云服务建设的独立网络，而是面向多种业务共同形成的基础设施。

以中国电信公开介绍的 CN2-DCI 精品承载网、ROADM 全光网络、政企 OTN 精品网为例，运营商在广域覆盖、多层次承载、运营保障方面已有较好基础。

这些基础设施为算力互联提供三方面条件：

第一，广域覆盖能力。 运营商具备跨省、跨区域的网络资源和运维体系，能连接分布在不同城市、不同园区的数据中心。

第二，多层次承载能力。 IP 网络、光传送网以及光缆网提供了丰富的业务能力，从点到点专线到组网，从刚性隔离电路到弹性复用带宽，从2M到100G再到波长，从光纤直驱到系统，应对用户的不同需求。

第三，运营保障能力。 通过网络监测、故障定位、保护机制、服务等级管理，为不同等级客户业务提供差异化保障。

但是，大模型训练、推理服务、云端 AI 应用发展到今天，数据中心之间的连接早已不只是数据访问、业务互通、异地备份那么简单，而是向算力协同、任务分发、资源调度演进。

AI 时代真正要回答的，不是要不要另起炉灶建一张独立算力互联网，而是在既有网络基础上，如何适应算力资源布局、业务流量特征和连接性能要求的变化，持续完善网络覆盖、承载能力和服务方式。

基于这一认识，网络发展应坚持存量网络复用与增量能力建设相结合：全网完善 DCA，重点区域按需强化 DCI。 前者立足现有网络基础，持续补齐算力接入所需的覆盖和承载能力；后者面向真实的跨数据中心互联需求，在算力资源集中、互联需求明确的重点区域针对性增强。两者共同推动现有承载网向适应 AI 业务发展的方向演进，而不是简单地对应两张新建的物理网络。

AI 带来了哪些新的网络需求

AI 带来的变化，主要体现在部分业务的流量规模、性能要求和资源分布上。

大规模训练涉及多个计算节点之间的协同，检查点传输也可能产生较大的数据流量；部分推理业务对响应时间比较敏感；随着算力资源分布在不同的数据中心和区域，企业接入算力、数据中心接入以及跨区域连接的需求也可能发生变化。这些场景可能对带宽、时延、抖动、丢包和传输稳定性提出更高要求。

此外，AI 业务还可能推动算力调度从传统的资源选择与任务分配，向计算任务、数据位置、网络路径和服务质量的协同优化发展。

在一些对响应时间敏感的场景中，业务希望能够在毫秒级时间尺度内完成资源选择、任务分配或调度决策。要实现这一目标，除了算力资源本身，还需要网络具备可感知、可测量、可预测的性能，并与上层调度系统协同。

并非所有 AI 业务都需要新的网络。

普通用户访问 AI 应用、企业调用云端模型，与大型计算任务跨数据中心协同，是不同的业务场景。前两者在不少情况下仍可利用现有互联网、宽带、移动网络和专线能力满足需求。数据中心内部 GPU 集群的高性能互联，也不能直接等同于运营商外部承载网的建设要求。

目前还不足以认为 AI 已经对运营商网络带来了突破性的网络需求。 更重要的问题是，哪些业务确实提高了网络性能要求，哪些连接关系发生了变化，现有网络能否满足这些需求。

这也意味着，网络建设不能仅仅因为 AI 业务出现，就将现有网络整体升级为高性能专网。需要结合具体业务场景，区分普遍性的接入需求与局部性的高性能互联需求，在已有网络能力的基础上确定建设重点。

Scale-Across 值得关注，但不宜提前作为普遍建设依据

在算力互联方面，值得重点关注的是 Scale-Across 这类跨数据中心的算力协同场景。

传统 DCI 主要解决不同数据中心之间的数据交换、业务互通、容灾和资源访问等问题。Scale-Across 则试图将分布在不同数据中心的计算资源组织起来，使计算任务能够跨越单个数据中心的边界协同运行。在这种场景下，网络性能可能直接影响计算任务的执行效率，对带宽、时延、抖动、丢包和传输稳定性提出更高要求。

不过，跨数据中心的算力协同并非只要具备高速光通道就能实现。计算任务是否适合跨中心运行、数据是否需要频繁交换、不同中心之间的时延是否满足要求，以及网络性能波动会不会影响任务效率，都需要结合具体的计算框架和业务流程分析。

技术方向值得关注，并不等于现实需求已经成熟。相关业务能够形成多大规模、哪些任务适合跨数据中心协同、网络性能要求如何，以及建设成本与计算收益能否匹配，都还需要进一步验证。

Scale-Across 应当成为运营商研究下一阶段算力互联能力的重要场景，但不宜直接作为普遍升级本地承载网或大规模新建专用 DCI 网络的依据。现阶段更适合关注潜在算力集群之间的连接关系，评估现有光传输和 IP 承载能力，并在客户明确、业务真实、收益可验证的场景中开展针对性建设。对于此类需求，需要提前研究和适度准备，但要区分技术储备、试点验证与规模化建设。只有当业务规模、连接关系和性能要求逐步明确之后，才能进一步判断是否需要建设专用互联系统，以及需要达到什么样的带宽和保障水平。

从现有网络出发，推动全光底座与承载能力演进

既然云计算时代已经形成了较为完整的网络基础，运营商就没有必要因为 DCA、DCI 等概念的出现，重新构建一套完全独立的网络。更现实的路径，是以现有骨干网和本地承载网为基础，根据算力资源的分布和业务连接需求，逐步完善网络覆盖与承载能力。

骨干网主要承担跨区域、跨枢纽的连接需求；本地承载网则需要进一步覆盖算力中心及相关园区，为企业接入算力资源、数据中心接入和区域内互联提供支撑。两者共同形成从算力资源所在地到客户接入点的连接能力。

在这一过程中，全光底座仍然是运营商网络演进的重要基础。这里所说的全光，并不是要求所有业务都采用纯光交换，也不是取消 IP 层，而是充分发挥光缆和光传输网络在大容量、长距离传输及连接覆盖方面的优势，持续完善光层基础设施，为 IP 业务、专线业务和算力互联提供统一的底层连接能力。

对于本地承载网，全光底座首先体现在光缆覆盖和光层组网。光缆是否到达数据中心或园区，是否具备可用纤芯、路由和引接条件，决定了后续能否快速提供连接服务。对于有明确需求的重点算力园区，应优先完善光缆覆盖和接入条件，再根据业务规模、速率和保护要求建设相应的传输系统。

在这里，需要区分区域覆盖与实际接入能力。光缆到达某个城市或算力集群所在区域，并不意味着已经具备接入具体数据中心的条件；骨干网能够到达某个枢纽，也不意味着本地核心汇聚节点到数据中心之间的光缆和传输资源已经具备。对于运营商而言，应将骨干连接能力与本地光缆覆盖、园区引接和系统接入能力统筹考虑。

在系统层面，应结合现有 OTN、WDM 和 IP 网络的资源与能力，按需进行优化、扩容或新建。不同业务可以根据实际需求采用电路、波道、IP 连接或光纤资源等方式，不必预先规定所有算力互联都采用同一种技术路线。

随着算力中心规模扩大、跨中心互联带宽增长，传输系统也需要适应更高的单波速率和更大的系统容量。400G 可以作为光传输能力演进的重要方向之一：在骨干、区域互联和部分高带宽 DCI 场景中，根据传输距离、业务规模、光纤条件和设备能力，逐步引入 400G 及相应的高速光接口，提升单纤承载能力和大带宽业务供给能力。这里需要区分 400G 客户侧接口、400G 线路侧传输能力以及整条链路的实际业务带宽。它们并非完全相同的指标，具体方案需要结合设备架构、波分系统和业务接口确定。400G 也不是所有本地节点的统一建设要求。对于普通企业专线、一般算力接入和现有业务，现有速率体系仍可能具有较好的经济性；只有在业务规模和流量增长确实需要时，才有必要采用更高速率的系统。

在光层组网方面，可以结合网络规模和业务流量特征，逐步从传统环形组网向网状组网演进，并在算力资源集中、光通道调度频繁、跨节点互联需求较强的区域，研究引入 OXC（光交叉连接）等技术。OXC 的价值在于能够在光层对光通道进行交叉连接和调度，减少部分业务对电层逐跳处理的依赖，提升光通道组织和网络拓扑调整的灵活性。对于连接关系相对稳定、但业务带宽持续增长的区域，OXC 有助于构建更灵活的光层网状网络，为大带宽 DCI 和多数据中心互联提供支撑。不过，OXC 并不是部署之后就能自动实现低时延或消除所有网络瓶颈。它主要解决光层连接和调度问题，实际性能仍然取决于光传输系统、线路距离、业务处理方式及端到端网络架构。是否采用 OXC，应结合节点数量、光通道规模、调度频率、保护要求和建设成本进行判断，而不是把 OXC 作为所有本地网必须部署的设备。

从更长远看，空芯光纤也是值得关注的低时延传输技术方向。与传统实芯光纤主要在玻璃介质中传输不同，空芯光纤利用空心结构引导光传播，能够降低光在介质中的传播时延，并具有低非线性等潜在优势。在对时延敏感、带宽需求较高的特定互联场景中，空芯光纤有望成为未来光缆基础设施的补充。但空芯光纤的实际价值还需要结合工程条件判断。线路损耗、连接器和接续技术、系统兼容性、施工维护成本及产业成熟度，都会影响其规模化部署。即使光纤本身能够降低传播时延，也不代表端到端网络时延会同比例下降，因为设备处理、排队、路由和其他传输环节同样会产生时延。因此，现阶段更适合将空芯光纤纳入技术跟踪和重点场景验证，在有明确低时延需求、线路条件合适且经济性可接受的情况下探索应用，而不是直接作为全网光缆建设的普遍要求。

总体而言，网络演进应遵循从光缆资源覆盖到光层系统能力、再到 IP 与业务协同的路径，优先复用已有设施和系统。400G、OXC 等技术可根据业务增长逐步引入，空芯光纤则作为前瞻性技术储备。所有技术选择最终都应服务于实际业务，而不是成为独立于业务需求之外的建设目标。

运营商需要同时考虑网络能力与服务方式

从运营商公开发布的算力网络、云网融合和云互联实践看，各家都在探索如何把网络连接能力与算力资源、云服务和业务保障结合起来。相关产品和平台体现了不同的业务组织方式，但仅凭公开产品介绍，还不能直接判断其实际部署规模、网络覆盖深度或自动化协同程度。

对运营商实践的观察，不宜简单归纳为某一家应采用什么技术路线。更有价值的是关注共同的问题：如何发现算力资源，如何提供连接，如何根据业务要求选择承载方式，以及如何把网络能力组织成可销售、可交付的产品。

DCA 和 DCI 不应只被理解为网络建设项目。它们还涉及连接产品、服务流程和保障机制。运营商需要把现有的光纤、波道、电路和 IP 连接能力，组织成能够面向不同客户提供的服务，并根据实际需求提供差异化的带宽、保护、时延和服务等级保障。

未来，随着算力资源逐渐分布在不同的数据中心、园区和区域，连接服务还可以进一步与算力资源发现、网络状态感知和业务调度结合。在具备相应平台和接口条件时，网络可以向上层提供可用带宽、路径时延、拥塞情况及服务等级等信息，帮助业务系统选择适合的算力资源和连接路径。

但这不意味着网络必须直接承担所有算力调度工作。算力资源编排、模型调度和网络路径控制属于不同层面的能力，需要通过明确的接口和协同机制衔接。运营商可以逐步开放网络能力、完善业务保障和连接服务，不必将整个算力平台都纳入网络建设范围。

对于普通企业和一般 AI 应用，可以更多依托现有网络能力；对有专用连接、隔离或较高可靠性要求的企业，应提供与其业务需求相匹配的专线及相关服务；对大型算力互联项目，则需要结合规模、拓扑、性能和投资回报进行专项评估。

尤其需要注意的是，DCA 并不等于专线，DCI 也不等于专用传输系统。

它们描述的是不同的连接场景，具体可以通过互联网、专线、IP 连接、光传输电路、波道或光纤资源等方式实现。运营商应根据客户的连接目标和保障要求组织产品，而不是将业务名称直接对应到某一种网络技术或产品。

面对头部客户自建 DCI，运营商需要拓展服务模式

随着大型 AI 企业和数据中心运营商发展自身的网络能力，一部分头部客户可能选择自行建设 DCI 专网，以便更直接地控制网络拓扑、设备配置、扩容节奏和运维策略。

这对运营商既是挑战，也是服务模式调整的契机。

如果客户自行建设并运营网络，运营商原本提供的电路、波道和网络运维服务，可能部分转变为光纤或纤芯租赁。这样虽然仍能提供基础资源，但运营商在连接方案、网络运行和持续服务中的参与程度可能下降。

对此，运营商不能只考虑继续出租光纤或销售波道，也可以探索面向客户专网的设计咨询、网络代建、设备集成、代维和托管运营等服务。客户保留网络使用和管理方面的自主权，运营商则利用自身在光缆、传输系统、工程建设和运行维护方面的能力，承担客户愿意外包的工作。

当然，并非所有客户都需要托管服务，也并非所有 DCI 都适合由运营商统一建设运营。具体模式仍取决于客户对网络控制权的要求、长期成本、扩容需求和自身运维能力。

头部客户自建专网带来的变化，不一定源于 AI 对网络提出了全新的技术要求。客户也可能是出于规模、成本、控制权或运营效率的考虑。运营商既要研究网络能力如何演进，也要关注客户的建设方式如何变化，不能把商业模式变化完全归因于技术需求升级。

对于运营商而言，即使客户不再采购完整的 DCI 承载服务，光缆、纤芯、工程建设和网络维护仍然可能存在需求。关键在于，运营商能否根据客户的网络建设方式，调整资源供给与服务交付的组合，避免将自身能力局限于传统的电路销售。

结语：网络演进的方向，取决于业务需求与建设方式

回顾全文，DCA 与 DCI 的讨论，最终指向的是运营商如何组织网络能力、如何服务算力业务的问题。与前文一脉相承，本文的核心判断是：网络演进的方向，取决于业务需求与建设方式，而不是取决于概念本身。

对于运营商而言，DCA 与 DCI 不是需要新建的独立网络，而是对现有网络能力如何组织、如何服务算力业务的重新审视。400G、OXC 等新技术可以在业务增长和网络条件具备时按需引入，空芯光纤等前瞻技术则适合试点验证。真正需要持续投入的，是把网络能力组织成可销售、可交付的产品，并建立与客户建设方式相适应的服务模式。

毫秒级调度、算力资源发现与网络协同，是值得探索的方向，但应建立在网络能力开放和业务需求明确的基础上，而不是作为网络建设的先决条件。

网络演进不是给原有网络不断增加新名称，而是让原有网络能够更好地连接计算资源，并为新的业务提供真正可用的连接能力。