过去几年，AI 基础设施的重点主要放在智能在哪里被计算。接下来的挑战，是这些智能如何被连接起来。随着 AI 推理逐步分布到云、边缘和终端设备，应用性能越来越取决于计算资源部署位置、网络状态与数据流动之间的协同关系。这些已经不再是彼此独立的架构决策。
我们已经开始在行业中看到这种趋势，包括推理感知路由、分布式模型服务，以及边云协同等能力的出现。我们认为，这些变化正在带来一种新的基础设施需求：网络层不仅需要理解应用意图和实时网络状态，还需要能够据此动态调整。
本文将进一步探讨，为什么这一变化值得关注，以及为什么网络正在逐渐成为 AI 技术栈的一部分。
在互联网发展的绝大多数时间里，各个环节的分工都相对清晰。应用决定要完成什么任务，计算资源负责处理请求，而网络则负责在两者之间建立连接并传输数据。
这种分工能够长期有效，是因为底层通信模式相对稳定。对大多数应用而言，网络可以被视为一种传输基础设施：它非常重要，但通常与应用本身的逻辑相对独立。
分布式 AI 正在开始打破这一假设。
随着推理不断分布到云、边缘和终端设备，应用性能越来越取决于计算资源位于哪里、数据存放在哪里、信息能够多快在不同位置之间流动，以及当网络状态发生变化时，底层基础设施能否及时作出响应。
因此，网络所扮演的角色也正在发生变化，从单纯提供连接，逐步走向更主动的协同与协调。
第一轮 AI 基础设施投资的重点，大多集中在模型训练上。这并不令人意外。训练前沿大模型需要高度集中的计算能力，因此，大规模 GPU 集群和集中式 AI 计算中心自然成为主流架构选择。
推理则不同。
推理发生在每一次模型被实际调用的时候。随着 AI 逐渐融入客户交互、企业工作流、搜索、推荐、自动化以及自主系统，推理已经从偶发的计算任务，逐渐转变为一种必须在真实业务环境中持续、稳定运行的生产工作负载。
智能体应用进一步放大了这一特征。一个请求可能涉及信息检索、规划、推理、策略检查、多次模型调用，以及与外部工具或其他智能体的交互。每一个步骤都可能依赖上一步的结果，因此，延迟不再只是某一个环节的独立问题，而会在整个任务链中不断累积。
生产环境的数据已经开始体现这种变化。在 Akamai 2026 年针对 AI 推理技术决策者的调研中，82% 的受访者表示，其最重要的 AI 应用要求端到端响应时间不超过 500 毫秒；其中 64% 的应用要求低于 250 毫秒。同一份研究还显示，50% 的受访企业认为，在高峰负载下维持可接受的延迟，是扩展推理业务时最困难的问题之一。
这意味着一个重要变化：AI 基础设施的设计，已经不能只考虑“哪里有最多算力”，还必须考虑决策需要在哪里发生、需要什么数据，以及计算与数据能否足够快地汇聚在一起。
这并不意味着所有 AI 工作负载都应该迁移到边缘。
集中式基础设施仍将在模型训练、微调以及高计算强度推理中发挥关键作用，因为大型 GPU 集群在这些场景下依然具备显著的性能和经济优势。
真正发生变化的是，推理带来了更丰富、更复杂的计算位置需求。
有些工作负载需要靠近用户，因为响应速度至关重要；有些需要靠近数据，因为长距离传输大量数据并不经济；有些必须依赖特定类型的 AI 加速器，而这些硬件可能只部署在某些位置；还有一些任务则完全可以在规模较小的分布式基础设施上运行。
具身智能（Physical AI）尤其能够体现这种差异。一台机器人可能在本地执行即时控制，在附近的边缘基础设施上进行感知或轨迹规划，同时依赖云端系统完成更高层次的推理或长周期规划。端、边、云并不是彼此替代，而是在同一个分布式系统中承担不同角色。
行业实践也开始朝这一方向演进，只是实际部署仍落后于架构需求。Akamai 的研究显示，60% 的受访者认为靠近用户和决策点非常重要或至关重要，但与此同时，仍有 46% 的企业将推理运行在单一集中式云区域中。
这个差距非常值得关注。
架构演进的方向正在变得清晰，但基础设施本身还没有完全跟上。
一旦计算资源分布在多个位置，问题就会变得更加复杂。
选择正确的目标，不再只是找到最近或负载最低的服务器这么简单。
AI 工作负载带来了更多状态信息需要被考虑。例如：某个节点是否已经加载了所需模型？是否已经缓存了可复用的上下文？合适的加速器是否可用？GPU 当前负载如何？如果切换到另一个位置，降低的网络延迟是否足以抵消迁移成本？
这些考虑已经开始进入实际生产基础设施。
以 Kubernetes Gateway API Inference Extension 为例，它在传统网关能力之上增加了针对 AI 推理的路由机制。系统不再只根据标准 HTTP 或基础设施信号来分发请求，还可以结合模型身份、请求优先级和实时服务指标，选择更合适的推理端点。
NVIDIA Dynamo 也在分布式模型服务中采用了类似思路。其路由机制可以参考 KV 缓存重合度以及当前工作节点负载，将请求发送到更有可能高效执行任务的计算节点。
需要特别强调的是，这些机制主要运行在推理服务层，而不是底层网络传输层。但它们共同说明了一个重要的架构变化：
路由决策，正在越来越多地理解它所承载的工作负载。
这与传统静态路由，或单纯基于网络拓扑进行转发，已经有了明显不同。
当推理本身进一步被拆分和分布式执行时，计算与网络之间的关系会变得更加紧密。
在大型语言模型服务中，可以将 Prefill 阶段，也就是对输入 Prompt 进行处理的阶段，与 Decode 阶段，也就是逐步生成 Token 的阶段分离，并分别运行在不同的 GPU 资源池上。这样做的原因是，这两个阶段对计算资源的需求特征并不完全相同。
这种架构可以提升 GPU 利用效率，但同时也引入了新的依赖关系：Prefill 阶段产生的中间模型状态必须足够高效地传输到 Decode 节点，否则，计算拆分所带来的效率提升，就可能被数据传输过程中的延迟抵消。
NVIDIA Dynamo 的架构明确将高效 KV 缓存传输视为分布式推理服务中的重要组成部分。
这个例子体现了一个更普遍的规律：
当计算开始分布式执行，计算节点之间的数据流动也会成为整体计算效率的一部分。
一些新兴标准研究也开始从网络角度讨论同样的问题。2026 年 7 月的一份 IETF Internet-Draft 就大规模分布式推理的传输问题，讨论了 KV 缓存传输、路径负载感知、流量引导以及差异化可靠性等需求。
这些工作仍处于探索阶段，并不是已经形成行业共识的标准，但它们释放出了一个重要信号：分布式推理正在产生跨越计算与网络传输的新型基础设施需求。
因此，计算编排与网络编排之间的边界，正在逐渐变得模糊。
传统网络主要回答的是一个连接问题：
一个端点能否以足够的带宽和可接受的性能连接到另一个端点？
分布式 AI 增加了第二个问题：
在当前这一时刻，结合应用真正需要什么，以及基础设施正在经历什么，通信究竟应该如何进行？
这一区别非常重要，因为计算环境和网络环境都在持续变化。某条网络路径可能突然拥塞，某个推理区域可能接近容量上限，无线连接可能发生波动，而最有价值的模型状态也可能已经存在于另一个位置。
目前，企业主要通过负载均衡、流量引导、重试、备用路径、可观测性工具和人工运维等方式来处理这些情况。Akamai 2026 年的研究显示，64% 的受访者认为流量引导对生产级 AI 推理“非常重要”或“至关重要”，而 AI 运营成熟度更高的企业，对运行时控制的重视程度还要更高。
与此同时，一些新兴 IETF 工作也开始研究计算与网络之间更紧密的协同。近期关于分布式推理的 Internet-Draft 已经涉及边云协作、智能调度、可预测的时延表现以及计算与网络联合可视化等议题。
这些都还不是已经确立的标准，但它们探索的方向值得关注：
计算资源放在哪里，以及网络应该如何运行，正在越来越多地被视为相互依赖的问题。
我们认为，这些变化正在共同指向一种新的基础设施能力，我们将其描述为智能网络层（Intelligent Network Layer）。
它不是一种新的网络协议，也不是用来取代 IP 网络、SD-WAN、云基础设施、推理网关或边缘平台。
更准确地说，它是一种协同层，将两类信息结合起来：应用需要什么，以及当前基础设施能够提供什么。
从网络侧看，这些信息可能包括延迟、丢包、拥塞、路径可用性和地理位置；从应用和计算侧看，则可能包括工作负载优先级、模型位置、加速器可用性、缓存状态以及服务等级要求。
它的目的，并不是让网络替应用做决策。应用仍然决定“要完成什么”；智能网络层帮助解决的是“为了完成这个目标，必要的数据应该如何到达合适的计算资源，并满足应用所需要的运行条件”。
这一点非常重要。
我们并不是在说，网络会突然变成一个可以自主思考的 AI 系统。
我们认为真正发生的是：为了有效支撑分布式 AI，网络需要拥有更多上下文、更强的可视性，以及更及时的运行时控制能力。
这种演进，也在改变我们对“可靠性”的理解。
传统基础设施通常通过可用性、平均延迟和总吞吐量等聚合指标来衡量性能。这些指标依然重要，但实时 AI 对一致性以及高百分位性能的要求正在变得更高。
问题已经不只是一个服务在一个月里是否保持可用，而是当分布式应用需要作出决策的那个瞬间，通信是否依然稳定。
这也是为什么生产级 AI 运营团队越来越关注 p95、p99 延迟，建立故障切换路径，并持续投入流量引导和更快的恢复机制。Akamai 的研究显示，已经运行生产级推理的企业越来越关注高百分位性能和运行时韧性，而不再只看平均表现。
对于实时智能系统而言，可靠性因此不再只是一个静态 SLA 指标。
它必须在应用运行过程中持续被维持。
这意味着，可观测性、路径多样性、恢复速度以及运行时自适应能力，正在从传统的网络运维问题，逐渐成为应用性能的一部分。
这些变化丝毫不会削弱模型和 AI 加速器的重要性。
计算依然是现代 AI 的基础。
但仅有计算，并不能构成一个真正的分布式智能系统。
模型需要接近数据，推理需要触达用户，智能体需要与应用以及其他智能体交互，边缘系统需要与云平台协同，而具身智能系统则必须持续在数字智能与物理世界之间交换信息。
这些交互越分布式，连接它们的基础设施就越重要。
因此，我们相信，未来 AI 技术栈与网络技术栈之间的边界将越来越难以清晰划分。
网络当然仍然负责提供连接，但它也会越来越多地参与到工作负载放置、路由、韧性保障和系统协同之中。
网络成为 AI 技术栈的一部分，并不是因为网络本身负责完成推理，而是因为：
分布式推理正在越来越依赖网络像系统的一部分一样运行，而不只是静静地存在于系统底层。
在本系列的第一篇文章中，我们提出了**智能数据流动（Intelligent Data Movement）**这一新兴能力：确保正确的信息，在正确的时间，通过最合适的路径，到达正确的位置。
智能网络层，是这一理念逐渐形成架构的一种方式。
智能数据流动描述的是最终结果，而智能网络层描述的是实现这一结果所需要的基础设施能力：持续可视、上下文感知的路由、跨分布式环境的编排，以及实时自适应。
我们已经可以看到，这些能力正在行业不同层面独立出现，包括推理网关、缓存感知路由、分布式模型服务、计算感知型流量引导，以及边云协同。
这些技术的名称未来还会继续变化，整体架构也远未定型。
但底层的发展方向已经越来越清晰：
当智能变得越来越分布式，连接这些智能的基础设施，也必须更加理解应用本身，以及不断变化的网络环境。
十多年来，Caton 一直在关键任务级实时媒体领域解决一个高度专业化的类似问题。
实时媒体对网络提出了非常特殊的要求：大量数据必须持续通过不可预测的公网进行传输，对中断的容忍度极低，同时运营者还需要实时了解网络正在发生什么。
这些长期需求推动我们不断发展持续可观测性、智能路径编排、主动流量管理以及高韧性传输等能力。
分布式 AI 是一个完全不同的应用领域，但其中一些底层基础设施问题已经开始显得非常熟悉。
当多条路径同时可用时，流量应该如何选择？系统能多快识别网络性能下降？当某条路径、某个区域或某个服务提供方出现问题时，通信能否继续？网络能否在应用真正受到影响之前就完成调整？
我们相信，随着 AI 推理不断向云、边缘以及物理世界扩展，这些问题的重要性会持续提升。
未来的网络不会取代模型，也不会取代云或边缘。
但当智能越来越多地分布在这些环境之间时，网络将逐渐成为让它们能够作为一个整体协同运行的关键基础设施。
下一代 AI 的能力，不仅取决于智能在哪里被计算，也取决于这些计算能够被多么智能地连接起来。