AI模型与数据中心专家圆桌：集群的扩展难题与功耗、内存、互联挑战全解析
本文为三部分系列报道的第二篇，半导体工程媒体Semiconductor Engineering就AI数据中心架构变化与多位行业专家展开深度对话，受访者包括：Arm全球云与AI基础设施芯片负责人Satadal Bhattacharjee、Axiomise首席执行官Ashish Darbari、Cadence杰出工程师Moshiko Emmer、Expedera首席科学家Sharad Chole、Siemens EDA高性能计算开发负责人Cameron Brunner，以及Synopsys战略营销总监Sumit Vishwakarma。
集群能否降低功耗，软件扮演什么角色？
Vishwakarma表示，功耗问题随集群规模扩大而持续加剧。
Brunner指出，许多客户的机柜中GPU无法以满功率运行，因为供电容量不足。目前一个常见的应对方案是"轻载识别"——让GPU在非最大功率下运行，同时评估其性能表现。比如以50%功率运行时，运行时间并不会翻倍，反而能获得更优的功耗性能比，即"每Token功耗"。软件可以帮助识别硬件使用的最优方式，并针对功耗对输出进行优化，这种智能集群中间件可以实现精细化的资源调度，而不是简单地将所有任务堆到一台机器上运行。
Chole认为，如果把集群定义为一组通过特定方式互联的节点，而不仅仅是连接到普通数据中心网络，那么问题的关键就在于：相比通用云拓扑，集群拓扑是否能带来实际价值。对于因单台服务器瓶颈而受限的纵向或横向扩展应用，集群是最合适的选择。典型应用场景包括HPC AI、靠近存储系统的数据库，以及需要超低延迟预测的金融系统。他还强调，硬件集群（预定义拓扑的节点连接）与软件集群（对硬件集群进行虚拟化分组和调度）是两个不同的问题，需要分开考虑。
运营商如何决定GPU功率的推送量？
Brunner表示，要解决功耗问题，需要了解历史工作负载、实时监控系统运行情况，并通过实验找出最优配置。他认为，将AI引入HPC系统的指标监控和控制流程，可以大幅提升自动化水平——Nvidia在功率控制方面的探索正是如此。不同GPU具有不同的性能画像，能够将工作负载调度到匹配的机器上，这在技术上是可行的。目前人工操作也能实现，但需要更多手动实验。
Bhattacharjee指出，功耗已成为当前最主要的瓶颈，而过去制约因素主要是GPU的可用性。他强调，CPU与GPU之间的紧密协同调度正在兴起：训练任务需要GPU持续高频运算，而推理任务（尤其是智能体工作流）则大量涉及非矩阵运算，如预订行程、搜索信息等，这些任务在CPU上运行效率更高。CPU完成处理后，再将需要深度推理的部分交给GPU或定制加速器。这种协同工作模式能有效降低整体功耗。他还预测，未来推理将占AI工作负载的80%以上，随着模型趋于稳定、部署增多，推理的重要性将持续上升。
Brunner补充道，训练任务是"批处理"型的，比如夜间提交、次日完成，可在低功耗模式下运行；而推理是实时的，用户在等待响应，往往需要更高功率。这两类工作负载的调度策略应有所区分。
Emmer表示，集群本身并不能解决功耗问题，如果架构导致过多数据搬运，反而会放大问题。真正的收益来自架构层面的智能专业化分工：CPU负责控制与编排，加速器负责密集数学运算，本地内存存放热数据，互联只承载真正需要跨节点传输的流量。他认为，关注的核心指标不应是原始功耗，而应是整个层级结构中每焦耳的有效工作量，即性能功耗比。
互联、I/O与数据流：不同规模下的挑战是否相同？
Darbari认为，集群将设计问题从"构建一台强大的机器"转变为"构建一个协调的分布式系统"。单台服务器关注本地算力、内存和I/O的平衡，而集群的性能则高度依赖工作负载分区、通信模式，以及互联是否能高效承载同步与数据传输。
Vishwakarma表示，架构师需要将集群视为一个整体单元，而非仅针对单一芯片封装进行设计，网络是最大瓶颈。随着推理负载增多，网络请求量远超训练场景，延迟问题随之急剧凸显。他提到，芯片本身也在演进，从单一裸片发展为多裸片设计，乃至3D IC，信号需要跨越裸片、节点等多个层级，每一跳都会累积延迟。从裸片间通信（如UCIe IP）到节点间互联（如以太网、UALink），业界正在积极推动相关标准化工作。
集群与机柜在内存使用上有何不同？
Bhattacharjee详细梳理了从芯片内部到系统级的内存层次结构：每核心的L2缓存速度最快（纳秒级），但容量仅1-2MB；共享L3缓存在多核间共享，总容量通常在百兆字节级别；DDR主内存容量达GB级，访问速度慢一些（毫秒级）；CPU与GPU之间通过高速链路（如NVLink或基于PCIe）传输数据；GPU侧使用高带宽内存（HBM），速度极快但容量小且价格昂贵。
他特别指出，在智能体群组和混合专家（MoE）模型中，当智能体处于非激活状态时，可将其KV缓存保存在容量较大的内存中，待其激活时再推回加速器内存。围绕这一机制，软硬件层面正涌现大量创新，以提升系统级效率。
Brunner表示，跨机器互联带来了全新的挑战维度。常见的低延迟网络方案包括HPE Slingshot和InfiniBand。当机柜数量扩展到数百台时，如何避免瓶颈成为关键难题。HPE提出的"蜻蜓网络拓扑（Dragonfly Network Topology）"正是为此而生，旨在最大化互联利用率，避免大规模协同作业中出现拥塞。他指出，传统的层级化组网策略在跨机柜作业时容易导致链路饱和，而蜻蜓拓扑能有效规避这一问题。
Emmer强调，纵向扩展（Scale-up）与横向扩展（Scale-out）并非同一问题在不同规模下的重复，二者处于完全不同的延迟与带宽区间。纵向扩展关注保持数据局部性、降低序列化/反序列化开销；横向扩展则需最小化同步代价、控制流量放大。封装内可实现极高带宽和细粒度通信，跨节点后成本迅速上升，跨机柜时则必须严格筛选哪些流量是真正延迟敏感的。他总结道，集群级别的性能往往不取决于峰值算力，而取决于数据被迫传输的距离。
Darbari指出，底层链路的带宽、延迟、顺序保证和故障行为，直接决定了上层能实现的上限。此外，正确性的保障在集群中也更加困难：单台服务器是一个紧密耦合的故障域，而集群由多个独立组件构成，各组件可能在整体服务持续运行的情况下单独发生故障、重启或变得不可达。这要求架构师不仅要考虑本地功能行为，还必须从协议、分布式状态和恢复语义的角度来思考系统设计。
Q&A
Q1：AI数据中心集群能解决GPU功耗问题吗？
A：集群本身并不能解决功耗问题，如果架构设计不当导致过多数据搬运，反而会放大功耗。真正的解法在于智能化的架构分工：CPU负责控制与调度，加速器专注密集数学运算，热数据留在本地内存，只有真正需要跨节点的流量才走互联网络。此外，软件层面的智能调度也至关重要，可以识别最优的硬件使用方式，根据负载动态调整GPU功率，从而优化每Token的功耗表现。
Q2：从训练到推理的转变，对AI集群架构有哪些具体影响？
A：训练任务以批处理为主，对算力要求高但对延迟不敏感，GPU满载运行是常态。推理任务则是实时的，用户在等待响应，延迟极为关键。更重要的是，推理中有大量非矩阵运算任务（如智能体执行搜索、预订等操作），这些更适合在CPU上运行，GPU只在需要深度推理时介入，从而降低整体功耗。业界预测推理将占未来AI工作负载的80%以上，这一转变正在深刻重塑集群的设计思路。
Q3：KV缓存在AI集群内存管理中起什么作用？
A：KV缓存存储的是智能体或模型的上下文信息，在推理过程中频繁被访问。由于GPU侧的高带宽内存（HBM）容量小且价格昂贵，一种新兴优化方式是：当智能体处于非激活状态时，将其KV缓存迁移至容量更大的主内存中；当智能体被激活时，再将缓存推回加速器内存。这种机制在混合专家（MoE）模型和多智能体协同工作场景中尤为重要，是提升系统级内存效率的关键创新方向。
