简介：本文围绕AI算力增长中“传统渐进式演进”与“极限协同设计”两种路线展开对比，分析它们在架构、系统耦合度、性能提升、运维复杂度和适用场景上的核心差异，帮助技术决策者理解高算力AI基础设施的演进逻辑与选型依据。
在AI基础设施规划中，“算力增长”常被当作一个线性、可预期的变量。传统经验认为，按照工艺与架构的渐进改进，计算性能大约每十年提升一百倍。这一判断长期影响数据中心容量规划、模型训练周期预估和AI业务投资节奏。
但在大规模模型训练与高吞吐推理场景中，另一种增长路径正在形成：不是只更换更快的芯片，而是把芯片、互连、系统拓扑、冷却方式、软件栈和部署形态作为一个整体重新设计，从而在相同时间跨度内获得远超传统路径的性能提升。公开行业演讲中提到的对比是：传统路径十年约一百倍，而整体协同设计路径在同一周期内可达到一百万倍。
这两种路线并非单纯的技术参数差异，它们代表着完全不同的基础设施构建逻辑、运维模式与成本结构。对于技术负责人和架构师来说，关键问题不是“哪一个数字更惊人”，而是：在自身业务条件下，应该选择渐进式升级，还是提前布局高度耦合的协同设计体系。
传统渐进式演进路线，指的是以单芯片或单节点性能提升为核心，按照工艺节点进步、架构局部优化、主频与核心数增加的节奏，逐步替换计算设备。每一次升级通常保持与上一代在接口、机箱、散热、驱动和上层软件上的兼容性，使得数据中心可以在不改变整体架构的前提下完成性能提升。
这种路线的核心特征是：
极限协同设计路线，指的是把计算芯片、互连结构、系统拓扑、供电与散热、整机柜设计、部署形态以及上层系统软件作为一个整体进行联合优化。每一代架构升级时，不是只更换芯片，而是重新定义节点间的通信方式、整机装配方式、液冷散热方案和软件调度模型。
这种路线的核心特征是：
尽管两条路线在实现方式上差异很大，但它们在目标层面仍有一些共同点。
第一，二者都服务于同一个核心目标：提升AI工作负载的吞吐能力，缩短模型训练时间，提高推理效率。无论采用渐进式升级还是协同设计，最终评价标准都是单位时间内的有效计算产出。
第二，二者都依赖芯片架构的持续演进。协同设计路线并不是放弃芯片创新，而是在芯片创新的基础上叠加系统级重构。芯片仍然是计算能力的起点。
第三，二者都面临能耗与散热的约束。随着单机柜功率密度持续上升，无论是渐进式路线还是协同设计路线，都必须解决供电、散热和能效比问题，只是解决的时机和方式不同。
第四，二者都需要配套的软件生态支持。硬件性能再高，如果缺少编译器、驱动、调度器和算法库的适配，实际可用性能都会大打折扣。
传统渐进式路线以“单节点”为最小升级单元。每个计算节点通常包含CPU、加速卡、本地存储和网络接口，节点之间通过标准网络协议通信。升级时，只需替换节点内的加速卡或增加节点数量，整体拓扑保持不变。
极限协同设计路线以“整机系统”为最小升级单元。以公开资料中提到的方案为例，数十块加速卡通过高带宽互连组成一个紧耦合计算域，整机采用全液冷设计，装配时间从上一代的小时级压缩到分钟级。系统不再是“服务器加加速卡”的简单叠加，而是一台由高速互连背板、统一电源和液冷分配单元构成的整体计算设备。
这意味着，传统路线下可以灵活选择不同厂商的组件进行组合，而协同设计路线下，硬件选择范围更窄，但组件之间的配合效率更高。
传统路线的性能提升主要来自三个来源：工艺进步带来的晶体管密度提升、架构微调带来的指令级效率提升、以及增加核心数或节点数带来的规模扩展。这三者叠加，长期来看呈现对数级或线性增长。
协同设计路线的性能提升来源更复杂：
这些因素叠加后，性能提升不再是简单的加法，而可能呈现乘法效应。这也是为什么同一演讲中会出现“一百万倍”与“一百倍”的巨大差距。
传统路线强调向后兼容，软件栈变化缓慢。运维团队可以继续使用熟悉的监控、日志、告警和部署工具，升级风险主要集中在单节点稳定性上。
协同设计路线要求软件与硬件同步演进。每一代架构升级都可能涉及调度器、资源管理器、故障恢复策略的重新适配。例如，当整机从风冷变为液冷，监控系统需要增加对冷却液压力、流量和漏液检测的感知能力；当装配时间从两小时缩短到五分钟，意味着设备上线前的初始化与验证流程必须高度自动化，人工干预窗口大幅缩短。
对于运维团队来说，协同设计路线不是简单的硬件替换，而是一次完整的平台迁移。
传统路线下，数据中心通常按机柜、按节点分批采购和部署。设备到达现场后，需要人工安装到机柜、连接线缆、配置网络、调试散热。从到货到可用的周期以天或周计算。
协同设计路线倾向于预制化交付。整机在工厂完成装配、液冷管路连接、内部布线和基础软件预装，以集装箱或整机柜形式运抵现场。现场只需接入外部电源、冷却管路和网络上行链路，即可在数天内开始产出计算能力。这种交付方式大幅缩短了建设周期，但对现场的基础设施配套要求更高，例如必须提前预留液冷冷量分配单元和适配的电力容量。
| 对比维度 | 传统渐进式演进路线 | 极限协同设计路线 |
|---|---|---|
| 最小升级单元 | 单节点或单加速卡 | 整机柜或紧耦合计算域 |
| 性能提升来源 | 工艺进步+架构微调+规模扩展 | 系统级重构+互连优化+软硬件协同 |
| 十年性能提升参考 | 约一百倍 | 约一百万倍 |
| 散热方式 | 以风冷为主，逐步引入液冷 | 整机全液冷，设计与交付一体化 |
| 装配与上线周期 | 小时级到天级 | 分钟级到天级，预制化交付 |
| 软件栈变化速度 | 较慢，强调兼容 | 较快，软硬件同步迭代 |
| 组件选择灵活性 | 较高，可组合不同来源组件 | 较低，组件强耦合 |
| 运维技术门槛 | 中等，工具链成熟 | 较高，需掌握液冷、整机柜管理、自动化运维 |
| 适用场景 | 常规业务、中小规模AI负载、渐进式扩容 | 大规模模型训练、高密度推理、快速投产需求 |
| 迁移成本 | 较低，可逐步替换 | 较高，涉及机房配套、软件平台和运维流程全面调整 |
当团队规模有限、AI负载尚处于探索阶段或业务增长预期较为平稳时，传统渐进式路线更为务实。它可以利用现有数据中心的基础设施，按需增加计算节点，避免一次性大规模改造。对于需要与多种现有系统兼容的企业，渐进式升级能减少对上层应用的冲击。
当业务核心依赖大规模模型训练、高吞吐在线推理或需要快速扩充算力时，协同设计路线的时间收益会非常明显。尤其是需要数百甚至数千加速卡协同工作的场景，传统节点间网络很容易成为瓶颈，而协同设计通过紧耦合互连和整机柜级优化，能显著减少通信开销。对于电力与散热条件符合要求的新建数据中心，预制化交付还能大幅压缩投产周期。
选型不应只看峰值性能数字，而应综合评估以下条件：
优先考虑传统渐进式路线的情况：
优先考虑极限协同设计路线的情况：
需要强调的是，两条路线并非绝对互斥。在实际生产环境中，企业可以选择混合形态：核心训练集群采用协同设计整机柜方案，边缘推理节点继续采用渐进式升级。关键是明确每一类负载的核心约束，再匹配对应的基础设施路线。
如果企业考虑从传统渐进式路线向协同设计路线迁移，需要重点关注以下方面：
1. 机房配套先行。 全液冷系统对冷量分配、管路压力、漏液检测和电力容量有严格要求。在设备到达之前，必须完成机房侧的基础设施验收，否则设备无法正常上线。
2. 软件平台适配。 协同设计架构通常需要配套的调度器、资源管理器和监控系统。迁移前需要评估现有应用是否依赖特定硬件抽象，是否需要重新编译或调整资源申请方式。
3. 故障域重新划分。 传统路线下，单节点故障影响范围较小；协同设计路线下，故障域可能扩大到整个计算域或整机柜。运维团队需要更新故障处理预案，明确降级策略和快速替换流程。
4. 数据与模型迁移。 如果训练任务需要在不同架构之间切换，需验证模型检查点、数据管线和分布式训练策略的兼容性。不同代际之间的软件栈差异可能导致需要重新调优。
5. 成本结构变化。 协同设计路线的前期投入更集中，包括机房改造、整机柜采购和运维平台建设。其长期收益需要结合任务吞吐提升和投产周期缩短进行综合核算，不能只比较硬件单价。
AI算力增长正在分化为两条路径：一条是传统渐进式演进，以兼容性和低迁移成本为核心优势，十年量级提升约一百倍；另一条是极限协同设计，以系统级重构和软硬件深度耦合为手段，在相同时间跨度内实现数量级更高的性能提升。
这两种路线的差异本质上不是“快一点”和“慢一点”的问题，而是两种完全不同的基础设施构建哲学。前者优化单点、保护既有投资；后者优化系统、追求整体效率极限。
对于技术决策者而言，关键不是追逐某个惊人的性能倍数，而是明确自身业务的负载特征、基础设施条件、团队能力和投资节奏，选择与之匹配的演进路径。在一个算力需求持续分化的时代，真正有效的策略往往不是二选一，而是在正确的时间、正确的场景中对正确的工作负载采用正确的路线。