第二十六章　从CPU到AI系统：不是一条单向晋升路线

在一些技术叙事中，计算产业被排列成一条清晰的阶梯：

CPU之后是GPU，GPU之后是AI加速器，最后走向更大的智能计算系统。

这样的顺序容易理解，却会产生误导。

CPU没有因为GPU兴起而失去作用，专用加速器也没有消除通用计算的需要。即使在大规模AI系统中，任务组织、数据准备、网络通信、存储管理和故障处理，仍然需要不同类型的处理器与软件共同完成。

变化的不是旧能力被新能力整齐替代，而是任务重新分配，系统边界持续扩大。

对工程师而言，这意味着职业迁移不能被理解为沿着一条技术阶梯向上走。

从CPU进入AI芯片团队，可能需要补充模型与编译器知识；从GPU进入系统公司，可能需要重新理解网络、调度和客户负载；模型研究者开始参与硬件设计，也需要学习制造周期、存储成本与可实现性。

因此，本章不把AI视为此前芯片历史的终点，而是把它看作新的重组环境。

当计算问题从执行程序扩大到运行模型、组织数据和协调集群时，哪些经验能够延续，哪些能力必须重新形成？

一、CPU、GPU与专用加速器：重叠经验与不同目标

CPU、GPU和AI专用加速器，不能简单按先进程度排列。

它们首先对应不同的设计取舍。

CPU通常重视通用性、复杂控制和较强的单线程响应能力。GPU围绕大量并行工作组织资源，适合能够提供足够并行度的任务。专用加速器则进一步针对某些计算模式，调整数据路径、存储和执行结构。

这些只是概括，不是严格边界。

现代GPU包含多种专用计算单元，CPU也拥有向量及矩阵相关能力。不同加速器的通用程度更不相同，不能仅凭名称判断它们能够运行什么。

人才经验也存在重叠。

流水线、缓存、互连、验证、物理设计和功耗管理，都是多个领域需要面对的问题。参与过CPU项目的工程师，可能具有很强的复杂状态处理与正确性验证经验；GPU工程师可能更熟悉大规模并行和带宽利用；网络芯片团队则可能带来数据移动与吞吐组织方面的知识。

但重叠不意味着可以直接替换。

熟悉分支预测，不等于已经理解模型划分；擅长矩阵单元设计，也不等于能够建立完整的软件平台。

因此，新团队需要先明确缺口，而不是只统计知名公司的工作经历。

AI系统最终也往往同时需要多类处理器。

加速器完成主要计算，CPU承担主机控制、服务与部分数据处理，其他器件负责网络、存储或安全。具体分工随系统而变，没有一种配置适用于全部任务。

新的计算平台不是旧处理器的葬礼，而是不同处理能力之间的新安排。

二、数据流、低精度与稀疏计算带来的新判断

AI计算使数据如何流动，变得更加重要。

同一组数学运算，可以按不同顺序划分和执行。权重、激活与中间结果放在哪里，重复使用多少次，何时移出片上存储，都会影响性能与能耗。

因此，架构设计不仅要问执行单元有多少，还要问这些单元能否持续获得合适的数据。

低精度计算提供了另一组取舍。

减少数据位宽，可能降低存储和通信需求，也可能让芯片在相同资源下完成更多操作。但数值范围、误差积累与模型质量，会限制这种变化。

训练与推理的要求也不相同。

某些推理任务可以通过量化有效降低精度，另一些则需要更谨慎地处理特定层或数据。训练中，不同计算环节也可能采用不同精度，并配合适当的累加与缩放方法。

所以，不能把“支持更低位宽”直接等同于更有用的算力。

必须说明它适用于什么模型、怎样保持结果质量，以及软件是否能够有效使用。

稀疏计算也存在类似问题。

如果大量数值为零，理论上可以跳过相关运算。但实际收益取决于零值分布、索引与调度成本，以及硬件是否支持相应模式。

结构化稀疏比较容易映射到规则硬件，却对模型形成方式提出条件；非结构化稀疏更灵活，也可能增加数据组织和执行负担。

这些取舍都要求硬件与模型知识结合。

旧有经验仍然重要，但评价标准已经扩大：不仅要确认芯片算得快，还要确认计算方式没有破坏任务所需要的结果。

三、内存、带宽、互连与封装成为关键约束

AI系统中的计算单元越来越强，但数据不会自动出现在它们旁边。

权重需要存储，激活需要传递，训练还可能保存梯度与优化器状态。生成式模型推理中的KV缓存，也会随着上下文、并发请求和其他条件增加资源需求。

这使内存容量与带宽成为不同但同样重要的问题。

容量不足，任务可能无法按预定方式运行；带宽不足，计算单元则可能长时间等待。

两者不能互相替代。

增加执行单元未必提高速度，增加内存容量也不保证数据能够更快到达。团队需要辨认工作负载究竟受到什么限制。

高带宽存储器和先进封装提供了重要条件，但也引入新的工程问题。

芯片与存储怎样连接，如何供电和散热，封装良率怎样控制，以及产品能否获得足够供应，都影响最终系统。

这些不是设计完成之后才交给供应链处理的细节。

它们会反过来改变架构能够采用的规模与布局。

多芯片系统还需要互连。

节点内部与节点之间的通信具有不同条件。带宽、延迟、拓扑、拥塞和集体通信实现，会影响任务扩展效率。

因此，单芯片表现优异，不意味着增加设备数量后能够按比例提高性能。

在这里，网络、存储和封装工程师不再只是辅助角色。

他们掌握的能力，可能直接决定计算资源能否转化为有效产出。

AI计算越大规模，越不能只围绕算术单元解释性能。

四、编译器、运行时与模型工作负载进入架构核心

专用计算能力要成为可用产品，需要软件把实际任务映射到硬件。

编译器负责将程序或计算图转化为可执行安排；运行时管理资源、执行顺序与设备交互；算子库则为常见操作提供优化实现。

这几层之间没有绝对固定的边界，不同平台会采用不同分工。

但无论怎样组织，软件都不能被视为芯片完成之后的附属工作。

一个矩阵单元即使具有很高的理论吞吐，如果数据布局、算子组合或调度方式不合适，也可能难以利用。某个操作缺少支持，还可能迫使任务回退到其他执行路径，增加转换与通信成本。

反过来，软件可以改变硬件需求。

算子融合可能减少中间数据读写，内存规划可以提高复用，模型划分与调度则影响需要多少通信和存储资源。

因此，编译器工程师不仅在优化既定硬件，也在帮助判断下一代硬件应该提供什么。

困难在于，模型与软件通常比芯片变化得快。

硬件立项时的重要操作，几年后可能仍然存在，却以不同规模、组合和执行方式出现。团队必须区分稳定的计算基础与暂时流行的实现细节。

如果设计过度依赖单一模型，效率可能很高，但适用范围也可能迅速收缩。

如果为了覆盖全部未来变化而保留过多通用性，又可能失去专用设计的收益。

这不是编译器能够单独解决的矛盾。

它需要模型、架构、软件和产品团队共同决定：哪些变化通过软件吸收，哪些必须由硬件预留空间。

五、从单芯片到机架与集群：系统边界不断扩大

当任务跨越大量设备，评价对象也随之改变。

单颗芯片的峰值吞吐只是起点。更重要的问题包括：完成一次训练需要多久，服务请求的延迟是否稳定，系统遇到故障能否恢复，以及设备长期利用率是多少。

不同任务需要不同系统安排。

大规模训练可能强调计算与通信的重叠、参数分布和检查点机制。在线推理则可能更重视请求调度、批处理、缓存管理和尾部延迟。

即使采用相同硬件，运行方式也可能显著改变成本。

过小的批量可能降低吞吐，过大的批量又可能增加等待。把更多模型装入设备可以提高资源利用，也可能造成争用和延迟波动。

因此，“让芯片满载”不一定等于服务最好。

系统还必须处理故障。

设备数量增加后，单个部件出现问题不再是罕见例外。网络、存储、电源和软件异常，都可能影响长时间任务。

这要求团队设计恢复方式，而不是只提高正常状态下的速度。

机架层面的供电与冷却，也开始进入架构选择。设备密度提高之后，数据中心是否能够部署，成为产品真实可用性的一部分。

系统边界因此不断向外扩展：

从芯片到板卡，从服务器到机架，再到集群及其运营环境。

但扩大边界不是把全部工作交给一个超级团队。

它需要更清晰的分层责任，以及能够连接各层的人。

六、芯片人才、软件人才与模型人才如何共同设计？

AI系统的共同设计，首先需要不同团队能够理解彼此的约束。

模型人员关心质量与能力，硬件人员关心面积、功耗与实现，软件人员关心可表达性、性能和维护。部署团队还需要成本、稳定性与可运维性。

这些目标不会天然一致。

一种模型修改可能提高结果质量，却增加不规则访问；一种硬件优化可能提高理论效率，却使编译器难以映射；一种调度策略可能提高平均吞吐，却恶化部分用户的响应。

因此，共同设计需要具体的决策机制。

可以先约定代表性工作负载，再共同确定测量方式；通过原型和性能模型比较方案；将准确率、延迟、能耗与成本同时纳入讨论。

代表性测试也必须更新。

如果长期只优化少数固定模型，团队可能得到越来越好的内部成绩，却逐渐偏离实际需求。

这种合作不要求所有人精通全部领域。

更现实的目标，是让成员理解相邻专业的关键限制，并知道哪些问题需要共同判断。

人才迁移在这里可能发挥重要作用。

具有跨领域经历的工程师能够帮助翻译问题，也可能更早发现局部优化的代价。但桥梁人物不能成为永久单点依赖。

接口、测试与知识需要逐步进入组织，让合作不只依靠少数人的个人关系。

跨专业人才的价值，不是替所有人作出决定，而是使不同专业能够围绕同一个结果工作。

七、AI Systems Architect：新的岗位，还是新的协作方式？

随着系统复杂度提高，“AI Systems Architect”越来越具有吸引力。

但这个名称并没有统一的职责定义。

在一家芯片公司，它可能侧重计算、内存与互连；在云服务组织中，可能更关注集群和部署；在模型公司中，则可能承担训练基础设施与工作负载之间的协调。

因此，不能仅凭头衔判断能力。

更值得观察的是，这个角色是否能够完成几项具体工作：

明确系统真正需要优化的目标；
识别跨层瓶颈，而不是只调整局部指标；
比较软硬件方案及其长期代价；
协调不同团队的责任与验证；
在需求变化时重新安排设计边界。

这些任务未必由一个人承担。

对于大型系统，团队化的架构机制通常比依赖单个全能专家更可靠。某位负责人可以提供方向，但必须让相关证据与专业判断进入决策。

因此，AI Systems Architect既可能是一种岗位，也可能是一种协作方式的名称。

它并不是CPU架构师、GPU专家或模型研究者的单向晋升终点。

来自不同领域的人，都可能通过补充知识承担其中一部分责任；也都可能因为缺少其他领域的理解而受到限制。

真正的新能力，不在头衔中，而在组织能否把计算、软件、模型与运营放入同一套可检验的系统判断。

结语　新的不是只有芯片，而是问题的边界

从CPU到AI系统，没有一条所有人才都必须沿着前进的路线。

通用计算、并行处理、专用加速、网络和软件各自继续发展，也在新的系统中重新连接。

过去的经验因此既没有失效，也没有获得无限适用性。

CPU团队需要重新理解模型与数据流，GPU团队需要面对新的服务条件，模型组织则需要学习硬件和基础设施无法即时改变的约束。

这些重组，正对应本书的中心问题。

有些迁移延续了熟悉的设计方法；有些通过跨领域协作形成新能力；还有些因为问题判断、软件支持或资源条件不足，没有转化为持续成果。

因此，AI时代最稀缺的能力，不只是设计更快的运算单元，也包括判断：

什么需要被计算，数据应该在哪里，任务由谁承担，以及整套系统怎样长期有效地工作。

下一章将进入具体的企业与创业路线。

NVIDIA、AMD、Google、AWS、Apple以及不同AI芯片公司，并没有在回答完全相同的问题。它们的客户、资源与组织边界不同，合理的技术选择也可能不同。

理解下一轮竞争，首先不是预测谁将成为下一个NVIDIA，而是辨认：谁定义了什么问题，又为这个问题建立了哪些真正能够工作的能力。

第二十六章 从CPU到AI系统：不是一条单向晋升路线