AI 基础设施正在变得越来越动态。工作负载可以在云端、边缘端和设备之间迁移；算力资源可能出现拥塞，也可能随时释放；网络路径会发生劣化，也会恢复。某一时刻最适合执行工作负载的位置，下一刻未必仍然是最佳选择。
但无论底层基础设施如何变化，应用仍然必须正常运行。如果某个工作负载需要在特定时间窗口内获得响应，需要一定程度的连续性，或对通信表现有明确的可预测性要求，那么这些服务目标仍然需要被满足。
这也提出了一个对分布式 AI 越来越重要的问题：基础设施究竟应该优化什么？
今天，关于 AI 的讨论很自然地聚焦于各个独立组件：更强大的模型、更快的加速器、更高的推理吞吐量，以及更低的延迟。这些都很重要。但随着 AI 应用越来越多地跨越不同的计算环境和通信路径，任何单一组件的性能，都越来越难完整反映整个应用是否真正按照要求运行。
换句话说，组件表现良好，并不意味着整个系统就一定表现良好。
因此，对于分布式 AI 来说，下一阶段的基础设施挑战，或许不再只是让每一个组件都达到最大性能，而是要确保整个系统即使不断变化，仍然能够持续满足工作负载的要求。
我们可以把它理解为应用与基础设施之间的一种**“性能约定”**：明确基础设施需要维持哪些运行条件，才能让工作负载按照预期运行。
物理 AI（Physical AI）让这个问题变得格外直观，因为基础设施的选择最终会直接影响现实世界中的实际结果。
以移动机器人为例。感知、导航、推理和物理动作所需要的算力以及对时间的要求可能完全不同。有些功能必须在设备本地执行，另一些则可能更适合借助边缘或云端更强大的计算资源。问题在于，并不存在一个适用于所有场景的最优计算位置。
微软研究院在 2026 年的一项研究中，对移动机器人操作任务在本地、边缘和云端 GPU 环境中的运行进行了测试。研究发现，较小型的本地 GPU 难以承担完整的工作负载，而更强大的本地 GPU 则会带来更高的能耗。将部分推理任务卸载到远端虽然可以缓解算力限制，却会引入新的问题：额外的网络延迟会影响任务准确性，而带宽需求也可能令简单的云端卸载方案变得不切实际。
这里最重要的结论，并不是云端优于边缘，也不是算力越强越好。
真正值得关注的是：应用的最终表现，是多个系统要素共同作用的结果。
更快的处理器可能改善工作流程中的一个环节；更低的网络延迟可能改善另一个环节；更高的能源效率则可能延长设备运行时间。但任何一个指标单独来看，都无法判断机器人是否能够在所需条件下完成任务。
这个问题也并不限于机器人。现实中的 AI 工作负载已经表现出非常不同的服务需求。微软研究院针对大规模 LLM 服务的研究表明，从高度重视响应速度的交互式应用，到对处理时间要求相对宽松的任务，不同工作负载需要在请求路由、算力分配和模型部署之间做出不同的协调。
这些应用可能完全不同，但背后的规律却很相似：
不同的应用，会对底层基础设施提出不同的要求。
因此，“实时 AI”很可能不会存在一个统一的定义。
对话式 AI 服务可能更强调响应速度；工业视觉系统可能要求在稳定的时间窗口内完成处理；自动化设备的安全关键功能可能必须留在本地，因为它不能依赖外部连接；而复杂的推理任务，则可能愿意接受更长的处理时间，以换取更强大的算力支持。
因此，更有意义的问题并不是：
延迟还能做到多低？
而应该是：
这个工作负载究竟需要什么？
根据不同应用，这些要求可能包括响应时间、尾延迟、带宽、连续性、韧性、恢复能力，甚至地理位置限制。当这些需求被明确之后，就可以进一步转化为可衡量的服务等级目标（SLO）。
相关研究也已经开始朝这个方向发展。一项发表于 2026 年《IEEE Transactions on Services Computing》的研究，针对边缘 LLM 工作负载中不同的首 Token 时间（TTFT）、单 Token 输出时间以及端到端延迟目标进行了分析。研究发现，如果主要追求吞吐量最大化，反而可能无法满足不同工作负载各自的 SLO，因此提出了基于差异化服务目标进行调度的方法。
比任何单一指标更重要的是背后的原则：
单个组件的最高性能，并不一定等于应用真正需要的性能。
对于基础设施负责人而言，这意味着设计逻辑需要发生变化。首先应该明确应用需要怎样的运行条件，然后再考虑工作负载应该在哪里执行、所需数据如何到达、应该如何衡量整个执行链路的表现，以及当现实环境发生变化时，系统应该如何应对。
基础设施可以不断变化，但当前的服务目标仍然需要被满足。
在本系列的上一篇文章中，我们探讨了网络决策与算力决策正在变得越来越相互依赖，以及这为何推动网络层向更加智能的方向演进。
最近的一些发展进一步印证了这一趋势。
2026 年 10 月，IETF 发布了关于 Computing-Aware Traffic Steering（CATS，算力感知流量调度）的 RFC 10053 和 RFC 10054。该框架在将流量引导至不同服务实例时，不再只考虑网络连接本身，而是同时考虑计算资源的状态。值得注意的是，RFC 10054 明确将分布式 AI 推理和训练列为其应用场景之一。
商业基础设施也在朝类似方向发展。NVIDIA 提出的分布式“AI Grid”架构，正在将加速计算从集中式基础设施延伸至区域节点和边缘环境，并逐步根据具体性能要求来决定工作负载的部署位置和路由方式。
这些发展表明，现在的问题已经不只是网络和算力是否应该更加协同。
更重要的问题是：
这种协同最终应该优化什么？
我们的观点是，答案越来越需要来自工作负载本身。
最低延迟的网络路径、负载最低的计算节点，或可用带宽最高的连接，都可能是重要的输入条件，但它们本身并不一定是最终目标。
真正的目标，是帮助应用维持其所需要的运行条件。
这也让网络智能有了更明确的意义。
一个具备应用感知能力的通信层，需要知道当前基础设施正在发生什么，也需要明确工作负载本身需要什么。基础设施可视性告诉系统“现在发生了什么”；应用意图告诉系统“什么才是重要的”；而运行时控制能力则让系统能够作出响应。
所谓“应用感知”，并不是指网络可以自行理解应用。应用需求仍然需要通过策略、服务目标、编排系统或工作负载元数据等方式明确表达。
但一旦这些应用需求可以与实时基础设施状态结合起来，路由、韧性和传输策略就能够越来越多地根据应用真正需要的条件进行动态调整。
其中的原则并不复杂：
了解基础设施当前能够提供什么，了解工作负载真正需要什么，并在两者开始出现偏差时及时调整。
这正是“智能数据流动（Intelligent Data Movement）”开始变得更具意义的地方。
它不再只是更高效地传输信息，也不只是寻找一条更优的网络路径，而是逐步演变为帮助分布式智能维持其正常运行所需要的通信条件。
随着智能不断分布到设备、边缘基础设施和云端资源之间，通信已经不再只是连接两个端点。
数据、上下文信息和决策结果，可能需要持续在不同的智能节点之间流动，而每一个节点对时间和可靠性的要求都可能不同。
对于 Caton 来说，这类问题并不陌生。多年来，我们一直专注于如何在网络条件不断变化的情况下，让对时间敏感的数据依然能够可靠地实时传输。专业实时媒体曾经成为这一能力非常严苛的验证场景：持续的大带宽数据必须跨越不同网络和地域实时传输，同时对中断几乎没有容忍空间。
实时媒体是这一底层能力的重要验证场景，但它所代表的基础设施问题并不局限于某一种应用。
分布式 AI 和物理 AI 带来了更广泛、也更复杂的挑战。算力位置开始成为整体架构的一部分，通信可能是双向的，而不同工作负载对于延迟、连续性和可靠性的要求也可能截然不同。为实时媒体所发展出来的技术不能简单原封不动地复制到 AI 场景中，但其背后的基础设施方法仍然具有重要意义：明确应用需要什么，观察通信环境当前能够提供什么，并在两者开始出现偏差时及时调整。
随着 AI 进一步进入物理世界，这种能力将变得越来越重要。
模型决定智能如何产生，算力决定智能在哪里被处理；但分布式智能能否真正发挥作用，还取决于数据、上下文和决策能否在这些不同位置之间，以应用所需要的条件可靠地流动。
我们认为，这也是通信层下一步需要演进的方向：从可靠传输，进一步走向更加智能、更加具备应用感知能力的数据流动。
底层基础设施仍然会不断变化。网络状况会波动，算力负载会转移，工作负载也会迁移，但应用所需要的服务目标依然必须得到满足。
对于分布式智能而言，真正的挑战并不只是让每一个端点变得更聪明，而是让这些端点之间的连接足够可靠，使整个系统能够真正协同工作。