大模型时代计算平台为何走向全栈重构

一、计算平台升级正在从“换芯片”变成“重构系统”

过去，计算平台的代际升级通常围绕单个核心部件展开：提高处理器频率、增加计算核心、扩大显存容量，或者使用更先进的制造工艺。在传统应用负载下，这种渐进式路线往往能够带来较为稳定的性能提升。

大模型训练和推理改变了这一逻辑。模型参数、上下文长度、并发请求和生成量都在持续增加，系统所承受的压力不再集中于算力，而是同时分布在计算、内存、互联、网络、存储、调度和供电等多个层面。

如果只增强加速器，其他组件就可能迅速成为新瓶颈。例如：

• 加速器算得更快，但高带宽内存无法及时提供数据；
• 单机性能提高，但多芯片之间的通信时间抵消了计算收益；
• 训练节点增加，但跨节点网络拥塞导致扩展效率下降；
• 推理吞吐提升，但主机侧的数据预处理和请求调度跟不上；
• 理论性能上升，但功耗、散热和故障率限制了实际部署规模。

因此，新一代AI计算平台的竞争焦点，正在从“单颗芯片有多快”转向“整个系统能否以更低成本稳定地产出有效结果”。这也是处理器、加速器、互联、网络接口、基础设施处理器和光网络交换组件需要协同演进的根本原因。

二、为什么传统迭代方式难以满足大模型需求

1. 制程缩放不再自动转化为等比例性能收益

先进制造工艺仍然能够增加晶体管密度并改善部分能效，但晶体管数量增长并不意味着应用性能必然同比提升。芯片设计还受到功耗密度、布线复杂度、存储访问延迟、芯片面积和封装能力等条件约束。

对于大模型而言，性能还取决于数据是否能够持续送入计算单元。若计算单元等待内存或通信数据，即使理论算力很高，实际利用率也可能偏低。平台设计因此必须同时优化计算密度、内存带宽、互联带宽和数据流动方式。

2. 模型增长速度可能快于硬件常规升级速度

大模型系统的压力不只来自参数量。更长的上下文、更多模态输入、更高并发和更长输出，都会显著增加计算及存储开销。

以推理为例，系统通常包含两个差异明显的阶段：

• 输入处理阶段：需要并行处理较长的输入序列，计算密度较高；
• 逐步生成阶段：每次生成少量内容，需要频繁读取模型权重和中间状态，更容易受内存带宽与访问延迟影响。

这意味着同一套硬件需要同时适应计算密集型和带宽敏感型负载。若系统仅针对峰值算力优化，就可能在真实推理任务中无法获得预期吞吐。

3. 扩展规模越大，通信成本越不可忽视

当一个模型无法放入单个加速器时，就需要采用数据并行、张量并行、流水线并行或专家并行等策略。这些策略都会引入通信。

一次分布式任务的执行时间可以抽象为：

总时间 = 计算时间 + 通信时间 + 数据等待时间 + 同步时间 + 调度开销

如果计算时间不断缩短，而通信和同步成本没有同步下降，那么加速器越快，通信在总时间中的占比反而越高。达到一定规模后，新增节点带来的性能收益会逐渐降低，甚至可能因网络拥塞和同步等待而出现负收益。

因此，平台必须把芯片内计算、芯片间互联和节点间网络视为一个连续的数据通路，而不能分别设计、最后再进行拼接。

三、全栈重构涉及哪六类关键组件

全栈重构并不等于简单地同时发布多个新部件，而是围绕统一目标重新定义组件之间的边界、协议和资源分工。

1. 通用处理器：承担控制、调度与数据准备

通用处理器负责操作系统运行、任务编排、数据解析、请求调度和部分通信控制。它通常不是大模型计算的主力，但会直接影响加速器的利用率。

如果数据预处理、内存拷贝或请求排队效率不足，加速器就会出现等待。新一代平台需要减少主机内存与加速器内存之间不必要的数据搬运，并提高通用处理器与加速器之间的协作效率。

企业评估时不能只看通用处理器的核心数量，还应关注：

• 单节点能够稳定驱动多少加速器；
• 数据预处理是否会形成瓶颈；
• 主机内存容量和带宽是否与模型负载匹配；
• 调度线程、网络中断和存储访问是否相互争抢资源。

2. AI加速器：从追求峰值算力转向有效吞吐

AI加速器负责矩阵计算、向量计算和模型执行。传统指标往往强调峰值计算能力，但在生产环境中，更有价值的指标是有效利用率和单位成本产出。

有效性能会受到以下因素影响：

• 数据精度及其数值稳定性；
• 模型结构与计算单元的匹配程度；
• 内存容量是否能够容纳权重和中间状态；
• 内存带宽能否持续供给计算单元；
• 编译和执行调度能否减少空闲时间；
• 多加速器通信是否阻塞计算流水线。

因此，企业不应根据单一峰值指标做采购判断，而应使用自身模型、输入长度、输出长度和并发模式进行端到端验证。

3. 节点内互联交换组件：决定多芯片能否接近“一体化”

单个服务器通常包含多颗加速器。节点内互联承担参数同步、激活值交换和中间结果传输，其带宽、延迟与拓扑结构直接影响并行效率。

仅提高链路带宽并不够。平台还需要解决：

• 多条通信流同时出现时的拥塞；
• 不同芯片之间的路径不对称；
• 通信与计算能否重叠执行；
• 集合通信是否能够充分利用拓扑；
• 芯片故障后能否隔离并重新编排任务。

理想状态下，软件能够理解底层拓扑，将通信频繁的任务放置在更近的计算单元上，从而减少跨层级传输。

4. 高速网络接口芯片：连接计算节点与集群网络

当任务跨越多个服务器时，网络接口承担节点间数据交换。其职责已经不只是“收发数据包”，还包括队列管理、拥塞控制、数据搬运和部分通信卸载。

在大规模训练中，多个节点可能在相近时间集中发送数据，形成突发流量。若网络缺少合理的拥塞控制，少数热点链路就可能拖慢整个任务。

在在线推理中，网络问题则会体现为尾延迟升高。即使平均延迟较低，只要部分请求出现较长等待，就会影响服务稳定性。因此，网络评估应同时观察吞吐、平均延迟、尾延迟、丢包恢复和持续高负载下的稳定性。

5. 基础设施处理器：隔离计算任务与系统服务

计算节点还需要执行虚拟化、网络、安全、存储和监控等基础设施任务。如果这些工作全部占用通用处理器，就可能与模型任务争夺资源。

基础设施处理器的价值在于，将部分数据面任务从主机侧分离，使通用处理器更专注于业务控制和模型调度。它还可以帮助实现计算、网络和存储资源之间的隔离。

不过，卸载并非越多越好。企业需要确认哪些任务适合下沉，哪些任务仍应保留在主机侧，并评估下沉后是否会增加调试复杂度。错误的边界划分可能让故障排查跨越更多层次，反而增加运维成本。

6. 高速光网络交换组件：支撑更大规模的集群扩展

随着集群规模扩大，电气连接在距离、功耗和布线密度方面会面临更大压力，光连接因此成为重要的数据传输方式。

光网络交换组件需要解决的不只是端口速率问题，还包括：

• 大规模组网下的路径规划；
• 不同业务流量之间的隔离；
• 链路故障后的快速收敛；
• 长时间高负载下的热稳定性；
• 光电转换带来的能耗与维护成本；
• 机架间布线和扩容的工程复杂度。

对于大型集群，网络架构必须与机房供电、散热和物理布局共同规划。如果仅从逻辑拓扑出发，而忽视线缆距离、机架功率和故障域，设计很可能无法顺利落地。

四、全栈重构的核心不是“全部更新”，而是统一约束

将六类组件全部重新设计，真正困难的地方在于它们必须共享一组系统目标。任何一个组件单独追求局部最优，都可能损害整体效率。

例如，加速器提高并行度后，可能产生更多通信流量；网络接口增强卸载能力后，可能需要新的内存管理方式；更快的交换系统可能增加整机功耗，进而降低加速器可用功率。全栈设计需要在这些相互制约的条件中寻找平衡。

可以把系统目标抽象为以下优化问题：

在功耗、成本、空间和可靠性约束下，最大化单位时间内完成的有效训练量或有效生成量。

这里的“有效”非常重要。重复计算、失败重试、无效等待和过度预留的资源都不应被计入实际产出。

五、软件必须同步完成架构适配

硬件重构若没有软件协同，理论能力很难转化为业务收益。软件层至少要完成四方面适配。

1. 计算图与算子优化

执行系统需要根据硬件特点选择合适的数据精度、算子实现和融合方式。将多个小算子合并执行，可以减少中间结果写回内存的次数，但融合过度也可能增加编译时间或降低调度灵活性。

优化时应关注模型端到端耗时，而不是单个算子的局部速度。

2. 并行策略与拓扑感知

任务调度器需要理解节点内和节点间的连接差异。通信频繁的计算分片应尽量部署在高速互联范围内，通信较少的任务才适合跨越更远的网络层级。

一种示意性调度逻辑如下：

读取模型规模、内存需求和通信矩阵
识别计算密集阶段与通信密集阶段
根据互联层级对设备进行分组
优先将高通信分片放入同一高速互联组
检查显存、带宽、功耗和故障域约束
若约束不满足，则调整并行策略并重新放置

这类调度不是一次性操作。实际运行中还需要根据节点状态、任务优先级和故障情况动态调整。

3. 推理服务的批处理与缓存管理

在线推理需要在吞吐与延迟之间取舍。较大的批次通常有利于提高计算利用率，但也会增加请求等待时间。较小的批次响应更快，却可能造成加速器利用不足。

中间状态缓存同样需要精细管理。缓存过少会导致重复计算，缓存过多则可能挤占模型执行空间。系统应根据请求长度、并发量和服务等级动态分配，而不是使用固定比例。

4. 可观测性与故障定位

全栈系统的故障可能发生在算子、内存、互联、网络、存储或调度层。仅监控设备利用率无法定位根因。

建议建立跨层指标体系，包括：

• 模型执行时间与各阶段耗时；
• 加速器计算利用率及内存带宽利用率；
• 节点内互联的吞吐、等待和重传；
• 节点间网络的拥塞、丢包和尾延迟；
• 数据读取速度及缓存命中率；
• 任务失败、重试和检查点恢复耗时；
• 单位训练量或单位生成量的能源消耗。

只有把业务指标与底层指标关联起来，才能判断性能下降究竟来自模型变化、资源争抢还是硬件异常。

六、企业应如何评估新一代计算平台

1. 用真实工作负载替代单一理论指标

测试模型应覆盖企业实际使用的参数规模、输入长度、输出长度和并发模式。训练场景还应覆盖不同并行策略和检查点频率，推理场景则应同时测试低并发交互请求与高并发批量请求。

如果只测试短输入或理想批次，结果往往无法代表生产环境。

2. 同时衡量吞吐、延迟、成本和稳定性

建议至少建立四组指标：

• 性能指标：训练吞吐、生成吞吐、首段响应时间、单步生成延迟；
• 扩展指标：节点增加后的加速比与并行效率；
• 经济指标：单位训练量成本、单位生成量成本和资源闲置率；
• 可靠性指标：任务成功率、故障恢复时间和长时间运行波动。

对企业而言，峰值速度不是最终目标。稳定、可预测且可控制成本的产出通常更重要。

3. 验证长时间运行能力

短时基准测试可能掩盖热降频、内存泄漏、网络拥塞累积和任务碎片化等问题。建议进行持续压力测试，并模拟节点故障、链路波动和存储延迟。

训练任务尤其需要验证检查点恢复能力。一次长任务若因局部故障全部重启，前期性能优势可能被恢复成本完全抵消。

4. 评估迁移成本

全栈平台升级往往伴随编译、算子、调度和运维体系变化。企业需要提前盘点：

• 现有模型能否顺利执行；
• 自定义算子是否需要重写；
• 训练脚本与推理服务是否需要调整；
• 监控和告警体系是否能够接入；
• 运维团队是否具备跨层故障定位能力；
• 新旧资源能否在过渡期统一调度。

迁移成本应纳入总体拥有成本，而不能只计算硬件采购费用。

七、推荐采用分阶段落地策略

全栈升级风险较高，更适合按照“小规模验证—代表性试点—生产扩展”的路径推进。

第一阶段应验证基础兼容性，包括模型能否运行、结果是否正确、显存是否充足以及核心监控是否可用。

第二阶段选择具有代表性的业务进行试点，重点观察端到端吞吐、尾延迟、长时间稳定性和故障恢复能力。

第三阶段再扩大规模，同时建立容量规划和成本模型。容量可以用以下方式估算：

所需资源量 ≈ 峰值业务需求 ÷ 单资源稳定产能 × 冗余系数

其中，“稳定产能”应来自持续压测，而不是理论峰值；“冗余系数”则需要综合业务波动、故障切换和维护窗口确定。

八、结语：系统协同将成为下一阶段的关键能力

当制程缩放带来的自然收益放缓，而大模型负载持续增长时，依靠单个组件渐进升级已经难以满足需求。计算、内存、互联、网络和基础设施之间必须共同演进，平台设计也必须从芯片级优化上升到数据中心级优化。

全栈重构的价值，不是简单地让每个部件都变得更强，而是减少数据搬运、通信等待、资源争抢和故障恢复造成的无效消耗。对企业用户而言，判断平台是否先进，也不应只看某一项峰值参数，而应关注真实模型下的有效吞吐、扩展效率、单位成本和长期稳定性。

未来的AI基础设施竞争，本质上将是系统工程能力的竞争：谁能让计算、网络、存储、软件和运维形成统一闭环，谁就更有可能在快速增长的模型需求面前获得持续而可控的计算效率。