再论软硬件融合

前面专门写过一篇“软硬件融合”的系统性介绍文章，之后有很多朋友私信交流。不断汲取大家对软硬件以及软硬件相互协作方面的观点，逐步深化和完善“软硬件融合”概念和技术体系。

简单总结一下。一方面，大家对未来认识的大方向是趋同的，就是“软硬件要深度结合/协同”。但另一方面，对软硬件融合观点的认识，也存在如下一些常见的误区：

第一个误区，关于软硬件结合。软硬件结合和软硬件耦合几乎是一致的。而软硬件融合不是软硬件耦合，软硬件融合是不同层次软硬件解耦基础上的再协同。

第二个误区，关于系统分层。软硬件系统分层解耦是正确的，但分层解耦并不意味着每一层是“独立王国”，也不意味着一劳永逸。软硬件融合强调，分层需要从全系统视角审视，分层后每一层都不宜黑盒，不同层之间仍然需要联动，全局的、动态的、长期的统筹系统分层。

第三个误区，关于软硬件垂直整合。软硬件融合不仅仅指的是垂直向的从上到下、不同层次系统堆栈的深度协同，它还有其他更加丰富的内涵。

第一个误区，道理比较浅显易懂，这里不再赘述。今天这篇文章，接着第二个和第三个误区的话题，来详细介绍一下软硬件融合的丰富内涵。

1 软硬件融合的内涵

软硬件融合的内涵，可以简单总结成“三融一通”，指的是：

第一个融合，垂直向的软硬件跨系统堆栈分层的融合。第二个融合，水平向的软硬件跨不同架构处理器的融合。第三个融合，斜向的软硬件跨计算节点的融合。一个通用，整个系统需要通用性，也即性能和灵活性的极致均衡。

接下来，我们详细展开。

2 垂直向，软硬件跨系统堆栈融合

垂直向的软硬件协同或融合，是目前大家最大的共识。软硬件系统通过分层实现系统的拆分，同时实现不同子系统的解耦。即使系统分层非常的科学和准确，分层仍然无法一劳永逸。随着系统的发展，原有的分层必然逐渐不再适应系统发展的需要。系统的每一层均不宜是黑盒或“独立领地”，不同层之间需要联动。从系统的视角，需要全局的、动态的、长期的、持续的重构系统分层。

举存储分层的一个例子。   传统的观点认为，模块或层次之间的调用，是在模块内部封装复杂的功能，然后给外部提供简单的访问接口。这种观点没有错，但是是静态的观点。站在系统发展的角度，就产生了如上图的问题。上图是以RocksDB为例的存储的整个系统堆栈，在这个系统堆栈里有三层虚拟化：SSD内部的FTL地址映射、系统层的文件系统、应用层软件的地址管理。三层虚拟化比较冗余，会影响到存储的延迟。目前行业逐渐流行的ZNS存储，就是取消了存储控制器中的FTL虚拟化层，只完成简单的控制。然后把SSD块的管理交给软件，实现软件定义存储。如果只考虑本层，而不考虑系统整体：

一方面，会产生很多冗余和浪费；另一方面，如果个体的功能存在问题，会拖累整个系统。

所有层次的设计，都需要考虑全局统筹。

也以算力提升为例。算力的提升，是一个复杂而庞大的系统工程。不仅需要各个相关领域的持续优化，还需要跨领域的协同创新。需要从数据中心多层次挖潜，整体协同优化。优化的主要方向有：

工艺和封装：更先进的工艺、3D集成，以及Chiplet封装等。芯片实现（微架构）：通过一些创新的设计实现，如存算一体、DSA架构设计以及各类新型存储等。

系统架构：比如开放精简的RISC-v，异构计算逐渐走向异构融合计算，以及驾驭复杂计算的软硬件融合等。

系统软件、框架、库：基础的如OS、Hypervisor、容器，以及需要持续优化和开源开放的各类计算框架和库等。

业务应用（算法）：业务场景算法优化、算法的并行性优化等；以及系统的灵活性和可编程性设计；系统的控制和管理、系统的扩展性等。

硬件设备：包括服务器、交换机等，多个功能芯片的板卡集成，定制板卡和服务器，服务器电源和散热优化。

数据中心：网络可维护性、高速网络、网络平台化等；

基础设施：如绿色DC，液冷、PUE优化等；

运营和管理：如超大规模DC运营管理，跨DC运营和管理调度等。

更宏观的系统：如高性能的城域网、互联网，云网边端深度协同和融合等。

3 水平向，软硬件跨处理器架构融合

按照指令的复杂度，典型的处理器平台大致分为CPU、协处理器、GPU、FPGA、DSA、ASIC。从左往右，单位计算越来越复杂。性能越来越好，而灵活性越来越低。   假设CPU是100%软件，ASIC是100%硬件；那么，其他处理引擎则介于两者之间，是不同比例软硬件的混合态。因此，CPU、GPU、DSA等各种类型的处理器，本质上是在不同层次的软硬件解耦基础上的软硬件再协同。

计算架构，从同构计算走向异构计算；再从异构计算，走向更多异构相互协作的异构融合计算。异构计算仅有一种加速处理器类型，仅关注CPU和加速处理器的协同；而异构融合计算，具有两种或两种以上的加速处理器类型，关注的重心在于所有处理器之间的协同和融合。异构融合计算中的协同，指的是系统的工作由两个或两个以上处理器协作处理，协作可以是CPU和CPU之间的协作，也可以是CPU和加速处理器之间的协作，还可以是加速处理器和加速处理器之间直接协作。

异构融合计算中的融合，指的是某个具体工作任务可以跨CPU、GPU和DSA等不同类型处理器运行，也可以跨同类型中的不同架构处理器运行。

以Intel的XPU和OneAPI为例。XPU它不是一个新的处理器或产品，而是一个架构组合，包括CPU、GPU、FPGA 和其他加速器。OneAPI是Intel构建的一套开源的跨平台编程框架，底层可以运行CPU、GPU、FPGA或其他DSA加速器，通过OneAPI为应用提供一致性的编程接口，使得应用能够轻松实现跨平台复用。

4 斜向，软硬件跨计算节点融合

随着算力需求越来越高，而单芯片算力提升有限，通过Scale Out实现的分布式集群计算越来越成为主流。计算系统，不再是基于单个芯片、单个设备，而是基于数以百计甚至千计的计算节点的计算集群。甚至，计算系统还要进一步扩展，计算需要跨集群，跨不同位置，进而扩展到跨云网边端。

一方面，底层的芯片，需要有非常多异构架构的处理器引擎，同时支持异构融合计算。另一方面，上层的计算集群需要跨云边端，实现云边端硬件计算平台的融合，软件可以非常方便地在云边端不同的计算节点动态自由迁移。

同时，为了更好的支撑宏观的跨云边端融合计算，微观的芯片也需要做很多调整。以异构融合计算处理器单芯片HCU为例，其和传统的SOC在功能特征方面存在很多的不同：

区别1：单系统vs分布式混合多系统。在SOC中，系统和芯片一一匹配。而HCU：需要通过集群协作来完成任务；单个HCU硬件上会运行多个不同的软件系统和任务；多个宏观的分布式大系统，混合交叉地运行在多个HCU上。

区别2：弱虚拟化vs硬件原生虚拟化。虚拟化是HCU和传统SOC最核心的能力区别。SOC面向单个系统，通常不需要支持虚拟化；有的SOC中的嵌入CPU核支持虚拟化，但虚拟化的性能损耗较高。HCU不仅仅需要嵌入式CPU、内存的完全硬件虚拟化，其他I/O和加速卡也需要实现完全的硬件虚拟化。

区别3：软硬件一体vs软硬件分离。SOC中的软件通常附着于硬件之上，两者是匹配的关系。HCU上的软件和硬件没有直接的关系。软件可以运行在硬件A，也可以运行在硬件B，也可以运行在任何其他硬件之上。软件在不同硬件资源上的运行和迁移是完全动态的，并且从宏观角度看，是非常频繁的。

区别4：控制驱动vs数据驱动。传统计算，是以CPU为核心的控制流驱动模式。而未来，随着数据量的增大，数据流驱动计算的架构变成算力的主力担当。

区别5：软件的多异构协同vs硬件的多异构融合。SOC仅仅是异构的集成，而HCU则需要实现异构的融合。

区别6：软件可编程vs多层次可编程。SOC里，其他加速器通常是ASIC层次的，只有嵌入式CPU能支持软件编程的。而在HCU里，可编程能力要更加丰富一些：DSA、GPU和CPU等多个层次的软件可编程。

区别7：资源确定vs资源弹性可扩展。在SOC内部，除了CPU可以支持可扩展外，其他模块基本上都是性能确定的设计，无法支持资源的扩展能力。在HCU里，每个计算资源，甚至I/O资源，都支持多个层次的资源可扩展能力。

区别8：定制Chiplet vs原生支持Chiplet。SOC中的Chiplet设计，通常需要针对性地设计若干个小芯粒。HCU采用资源弹性扩展的设计，可以轻松实现基于Chiplet的不同规格HCU芯片。

区别9：设计规模小 vs 设计规模数量级提升。传统SOC架构所能支撑的系统规模逐渐逼近上限。HCU采用可扩展的分布式系统架构设计，每个子系统相当于一个SOC系统。HCU可驾驭的系统规模可以做到SOC的10倍甚至100倍。

区别10：专用vs通用。SOC是针对特定的场景，定制开发的芯片。HCU面向的是通用的、综合的复杂计算场景，定位在以不变应万变。

5 贯穿全局，通用计算，性能和灵活性的极致均衡

性能和灵活性是一对矛盾：一方面，随着系统规模和复杂度的上升，系统对灵活性的要求也越来越高；而另一方面，系统对性能的要求越来越高，越需要专用优化的加速处理器来优化性能，进而使得系统的灵活性越来越低。

每个处理引擎都有优势，也有劣势。通过单兵作战，只能“权衡”；但通过“团队协作”的异构融合计算，每个处理器做自己最擅长的工作，从而实现优势互补，把性能和灵活性都拉扯到极致。软硬件融合，强调的是，如何在确保系统灵活性的前提下，实现最极致的性能。我们给出的解决方案是：通过更多异构处理器的深度协作，通过团队合作，实现整体最优。

一方面，依据依据灵活性特征，把系统分为基础设施层、弹性加速层、业务应用层。

另一方面，针对上述三个层次，采用最符合每一层次系统灵活性特征的处理器。基础设施层通常采用DSA，弹性加速层通常采用GPU，而业务应用层通常采用CPU。通过上述三类处理器，让处理器的灵活性恰恰好的符合工作任务灵活性的要求，从而确保性能和灵活性的极致。

此外，性能和灵活性的平衡仍在动态变化。可能随着系统的发展，有的任务会“上浮”，越来越需要更多灵活性；有的任务会“下沉”，灵活性要求逐步降低，可以通过更高效的硬件加速来极致的提升性能。