编者按

2021，对我个人的人生来说，是一个重要的节点。跟随自己的内心，从打工族变成了创业者，期望通过自己和团队一起努力，把梦想变成现实。

2020年10月2日，《软硬件融合》图书定稿发给出版社，在编辑们精心修订以及各种复杂的出版流程之后，2021年4月底终于跟大家见面。2021年1月1日，正式开始“软硬件融合”公众号，到现在刚好一整年的时间。当前，一篇文章平均可以达到1500+的阅读量，技术领域的关系，这些阅读量基本上可以算是专业领域知名自媒体了，自夸：-）。

2020年10月6日，NVIDIA在其GTC 2020大会上大张旗鼓宣传其DPU以后，DPU作为一个重要的赛道，在国内也迅速的兴起了若干DPU方向的Startup公司。经过大半年的“狂热”之后，目前行业整体进入了一个“冷静”期，回归了理性。

DPU到底是什么，为什么会出现DPU，未来要往何处去？接下来，让我们从“软硬件融合”的视角，来探寻一下支撑这一切发展的底层逻辑。

1 基于CPU的摩尔定律已经失效，如何延续摩尔定律持续向前？

CPU

上世纪80/90年代，CPU性能狂飙，每18个月，CPU的性能就会翻倍，这就是著名的摩尔定律。如今，CPU性能提升，每年只有不到3%，要想性能翻倍，需要20年。

CPU是最灵活的，原因在于运行于CPU的指令都是最基本的加减乘除外加一些访存及控制类指令，就像积木块一样，我们可以随意组合出我们想要的各种形态的功能，形成非常复杂并且功能强大的程序，或者称为软件。

GPGPU

之后，GPGPU出现，通过数以千计的更高效的小CPU核组成并行系统，能够实现非常高的并行性。这样，GPGPU相对CPU的性能，有了数量级的提升。

就像硬币的两面，有所得必有所失，GPGPU快速提升性能的同时，其编程难度也进一步提升。在CPU算力足够满足大部分场景需求的时候，GPGPU由于其编程的难度一直没能成为算力的主流平台。

随着IT行业继续发展：一方面，CPU的性能提升变得越来越缓慢；另一方面，CUDA和OpenCL等支持GPGPU并行编程的框架出现，降低了GPGPU的编程难度，再辅以丰富的编程资源库，使得GPGPU的软件生态逐步丰富起来。

等到AI时代来临，这个时候CPU已经完全性能瓶颈，难堪算力大任。对算力的渴求，使得GPGPU算力平台得到了更加广泛的采用。这也是NVIDIA成为目前市值最高芯片公司的根本原因。

DSA

2017年，图灵奖获得者David Patterson和John Hennessy在其“体系结构的黄金年代”主题演讲中，提出了DSA架构。DSA是在定制ASIC的基础上回调，使其具有一定的软件可编程能力。AI是DSA最大、最典型的场景，第一款DSA架构处理器是谷歌的TPU 1.0。

虽然AI-DSA架构能够提供相比GPGPU数量级提升的更高算力，但由于：

• 不同用户场景的差异性以及上层软件快速迭代；
• AI-DSA可编程能力依然较差，无法满足软件的快速迭代；
• 不同厂家硬件平台编程模型各不相同，没有形成共同的软件生态。

这些原因，共同决定了AI-DSA的大规模落地的困境。

总结

性能（算力）和灵活性（通用可编程能力）是一对矛盾，是我们在设计和选择处理器平台过程中需要权衡的。当我们在追逐极致性能的时候，平台灵活的可编程能力或者说开发易用性都逐渐损失殆尽。

如果不能提供很好的灵活性，用户难以驾驭，即使提供再高的算力，这“无源之水，无本之木”又有多少意义？

2 为什么数据中心算力主要靠CPU，而不是像终端一样用SOC？

手机芯片是超大规模SOC的典范，基于个性化的SOC计算平台，配套厂家提供的个性化驱动，然后操作系统和应用程序就可以运转了。但在数据中心领域，依然是以CPU为主的服务器算力平台。

在手机端已经非常成熟的SOC实现，在数据中心端为何没有大规模应用？原因在于，手机端运行的都是相对确定的任务，而数据中心对灵活性的要求远高于对性能的要求：

• 手机端是软件附属于硬件，软件实体和硬件实体是绑定的。而在数据中心，软件和硬件是隔离的；同一个软件实体会在不同的硬件实体迁移，而同样的一个硬件实体也需要运行不同的软件实体。这对硬件平台的一致性提出了很高的要求。
• 数据中心业务应用Workload，具有非常大的不确定性。或者说，在数据中心部署服务器的时候，并不确定这些服务器将被用于何种用途。
• 数据中心是各种复杂系统交织在一起，运行形形色色各种任务混布，并且这些任务随时可能被创建、复制、迁移和销毁。
• 数据中心的各种系统通常一直处于快速迭代优化的状态，软件的迭代周期大概在1-3个月。而硬件的研发周期通常是2-3年，其生命周期通常是4-5年。
• 等等。

如果想提供尽可能好的通用灵活性，最优的做法必然是采用CPU。但不幸的是，当前的CPU已经到了性能瓶颈，在系统对算力的要求持续不断提高的情况下，我们不得不求助于GPGPU及DSA等新的算力平台。但这些平台反过来，其糟糕的灵活性又对我们的软件系统构成了很大的挑战。

我们该如何平衡好性能和灵活性，甚至能够兼顾性能提升的同时，依然能够给用户提供接近于CPU一般极致的灵活可编程能力？这是需要我们思考和解决的。

还有，云系统是各种复杂场景的叠加，我们该如何在一个硬件平台整合这么多的场景加速优化，还能够不破坏其灵活可编程性，并且能够适配已经成熟的软件生态？这更是一个复杂而挑战的问题。

3 网络，应该更简单还是更复杂？

简单还是复杂

在《软硬件融合》图书的引言里，我们就探讨了“简单和复杂”的问题。“产品设计要学会做减法，给用户极致的简单”。我们的系统设计通常是这样的：每个层次都调用下一层的接口，在自己内部封装具体实现的复杂度，然后再给上层提供尽可能简单的接口。

但是，这样设计也存在问题：

• 某个功能接口的提供方提供的接口是自己定义的，但是不是调用方想要的？
• 不同层次的子系统实现，一方面可能存在功能重复，而另一方面可能存在功能缺失。如何弥补或优化这个问题？谁来统筹？
• 巨系统存在潜在缺陷，并且单个子系统局部的问题会扩展到整个系统全局。作为个体，自成体系，给外部用户提供简单的访问接口。但站在系统全局考虑，这个做法有可能是错误的甚至致命的。例如，传统的SSD控制器包含虚拟化FTL功能，到如今不包含FTL功能的ZNS存储开始流行。

设计应该在整个系统的层次统筹规划，根据系统的特点，决定每个层次应该实现的功能以及访问接口，决定某个功能应该是集中或是分布，是应该近存储计算还是应该远存储计算，等等。

具体到网络。网络通过分层协议给上层用户提供足够方便的通信接口。应用通过socket接口使用网络，而网络底层协议栈到底采用了哪些协议，上层是不关心的（也是无法关心的）。比方说，我们可以把TLS/IPSec、Overlay网络、防火墙/DDoS防护等做到协议栈里，甚至把应用计算做到网络的Inline计算里。而这些，上层用户完全不可见。

并且，这些计算可以运行在CPU侧的协议栈里，智能网卡的硬件加速里，甚至交换机侧的软硬件“加速”里。

SDN发展

我们回顾SDN的发展。SDN发展的背景：

• 网络芯片是一个紧耦合的ASIC芯片设计，随着支持的网络协议越来越多，其复杂度急剧上升，使用门槛也越来越高。然而，网络芯片提供的众多功能，每个用户能用到的只是一小部分，这反而拖累了ASIC的性能和资源效率。
• 网络都是完全硬件ASIC实现，上层的用户对网络没有太多的话语权，只能是在供应商已经定好的设计里修改一些配置参数。
• 并且，要连接到数以千计甚至万计的设备中手动的去配置。
• 并且，这些设备可能来自不同的厂家，其配置接口完全可能大相径庭。

于是，SDN最开始推出了控制面和数据面分离的Openflow，通过集中决策，再分发到分布式的支持SDN功能的交换机中。更进一步的，还有了支持数据面编程的P4语言以及网络包处理引擎PISA。这样，还可以通过P4软件程序把功能编程到硬件中去。PISA是一种网络领域专用DSA架构处理器，能够在达到ASIC级别性能的基础上仍然具有非常好的编程能力。

总结

关于网络，我们的基本的观点是：集中决策，分布执行；软件定义，硬件加速。

网络大致分为三层功能：

• Underlay网络。也就是我们通常说的基础物理网络，目标是网络的互联互通，高性能是其目标。这里需要强调的数据中心内部网络和外部互联网网络是两个不同层次的网络，内部对整个堆栈的效率和延迟都极度敏感。
• Overlay网络。则需要可软件编程的网络加速引擎支持，来支持虚拟网络、负载均衡、安全防火墙等上层网络协议和应用支持。
• 网络应用。网络应用和网络控制面，负责网络的管理和表项更新等，负责网络数据面功能编程动态更新。

关于网络任务的处理器平台，也相应的，应该分为三级混合协同处理：

• 把非常确定的并且通用的功能放在ASIC；
• 把用户关心的需要自定义的协议包处理放在可编程DSA；
• 把软件和控制面等算力消耗小的部分放在CPU。

此外，网络不是问题的全部，还有存储、安全、虚拟化、以及用户应用，整个系统需要一个解耦的模块功能划分、标准的并且高效交互的接口互联组成的一个具有很好扩展性的系统。并且这些对软件是可见的，由软件人员通过编程可以去掌控。

4 通用还是专用？

通用（平台化）还是专用（定制）？这个问题其实从来不是一个问题：

• 许多时候，为了提供最高效的解决方案，我们不得不根据场景做专门的定制。于是陷入了Case by Case永无休止的开发中无法自拔。并且，为了尽可能的扩大产品的覆盖范围，尽可能提高产品的应用范围，我们又不得不做功能超集，这样，之前因为定制积攒的性能和成本优势就变的不是那么明显。
• 系统的发展遵循一定的规律：前期快速迭代，后期逐渐稳定。与此对应的，系统一开始通常是在CPU平台，随着功能逐渐稳定和性能需求越来越强劲，处理器平台逐渐从CPU过渡到GPU等，直到过渡到ASIC。
• 而云计算等复杂场景业务更新迭代很快，因此，大部分情况，可能都无法用ASIC架构来支撑业务的快速发展。在既需要性能又需要灵活性的场景下，DSA和其他灵活处理器引擎混合架构成为比较合适的选择。

简而言之，定制的ASIC很难适合灵活多变的云计算等复杂场景。

图 Nitro和NVIDIA DPU的演进对比

如上图所示，芯片公司（NVIDIA）根据自身对业务的理解，做定制ASIC。但这些ASIC实现的加速功能是芯片公司对业务场景的理解，并把业务逻辑固化到定制的设计中，使得云厂家很难基于此硬件平台开发出差异化的创新功能。并且，定制的设计，限制了云厂家的创新能力，并且使得云厂家不得不跟硬件平台厂家深度绑定，这些对云厂家来说，并不是一件好事。

AWS Nitro和NVIDIA DPU代表了两种不同方向的演进：

• NVIDIA DPU演进：从硬到软，NIC -> SNIC -> DPU（DPU = SNIC+嵌入式CPU）；定制设计，用户无法差异化，与云系统发展规律相悖。
• AWS Nitro演进：从软到硬，CPU基础上，逐步增加足够弹性的加速引擎；通用的设计，符合云系统发展规律。

NVIDIA，一开始就是完全ASIC的设计。虽然性能足够好，但却很难覆盖用户五花八门的各种差异化场景以及各种场景未来2-3年的中长期迭代。即使非常熟悉自身的场景需求，AWS所做的硬件优化，依然是非常审慎的。AWS并没有贸然的做ASIC，而是做足够灵活弹性的硬件加速。这使得，整个Nitro芯片，具有非常强大的灵活可编程能力。

5 DPU是什么？

层次一，DPU是CPU任务的卸载和加速

由于CPU的性能瓶颈，把网络、存储、虚拟化及安全等性能敏感的底层任务从CPU卸载到DPU加速，减轻CPU的压力。这样，DPU作为独立的加速平台，不断的会有工作任务从CPU软件卸载到DPU硬件加速。

DPU和GPU等加速引擎的区别：

• DPU/IPU用于底层通用任务加速；
• GPU/FPGA/DSA用于应用层的业务加速。

层次二，IPU是基础设施，支撑上层应用

我们为DPU的演进定义了四个阶段，从智能网卡到DPU到IPU再到eIPU。IPU成为集成加速平台，既完成基础设施层工作任务处理，也完成部分业务应用的加速。IPU作为基础设施层，支撑CPU和GPU的应用层工作。

层次一和层次二详细总结如下：

PS：NVIDIA 2020年5月发布DPU，10月份大张旗鼓宣传；作者2020年8月份提出四阶段论；Intel 2021年6月份发布IPU。

层次三，DPU/IPU是计算的核心

需要把IaaS甚至PaaS、SaaS等云计算核心服务，融入到DPU软硬件。并且，DPU图灵完备，是一颗独立SOC芯片，在有些服务器上，可以完全代替CPU的角色。

CPU、GPU和DPU，既相互协作，又相互竞争。按照互联网法则：得入口者得天下。

上述这些原因，使得DPU成为计算的核心，而CPU和GPU成为计算的扩展。

层次四，DPU/IPU的本质是超异构计算

DPU内部包含嵌入式的CPU、GPU、FPGA、DSA、ASIC等处理引擎，本身就是自成系统的超异构算力平台。算力持续提升，不管是单DPU，还是“DPU+独立CPU+独立GPU”组成的服务器大系统，都是超异构算力平台。

站在系统的角度，传统SOC是单系统，而超异构系统则是多个系统整合到一个更加庞大的宏系统。传统SOC和超异构SOC的区别和联系：

• 设计规模的不同。MCU级别SOC通常跑RTOS级别的操作系统，进行一些简单的控制和处理。手机SOC，则需要运行大型操作系统。而超异构架构，则不简单是运行操作系统和各种软件，而是聚焦提供既性能强劲并且软件能够灵活充分使用的庞大资源池；在底层软件的协助下，把硬件变成一个无差别的计算平台资源池，供软件随意的切分组合，把算力更灵活的提供给用户。
• 单系统和多系统。传统的SOC，有一个基于CPU的核心控制程序，来驱动CPU、GPU、外围其他模块以及接口数据IO等的工作，整个系统的运行是集中式管理和控制的。而超异构由于其规模和复杂度，每个子系统其实就是一个传统SOC级别的系统，整个超异构的系统呈现出分布式系统的特点。
• 数据流驱动还是指令流驱动。传统SOC中，CPU是由指令流（程序）来驱动运行的，然后CPU作为一切的“主管”再驱动外围的GPU、其他加速模块、IO模块运行。而在超异构的多SOC系统中，由于系统复杂度的影响，指令流的设计模式很难“同步”不同系统间的控制交互。整个交互实际上是由数据交互产生的。并且，由于要处理的数据带宽的急剧增大，很多处理引擎都是数据流驱动的模式，而不是指令流驱动。表现在整个宏系统上，都可以理解为数据流在驱动整个系统运转。

超异构需要确保整个系统接近于CPU软件的通用可编程能力的基础上，实现相比传统基于GPU或DSA的异构计算10倍甚至100倍以上的性能提升，并且需要实现整体接近于ASIC/DSA的极致性能效率。

6 未来，需要什么样的计算平台？

超高算力

毋庸置疑，算力是最需要的，我们期望算力相比当前再提升1-2个数量级。

可驾驭

简单的处理引擎堆叠毫无意义，需要提供开发人员可相对轻松驾驭的算力才有意义。那什么是软件人员可轻松驾驭的算力？

• 首先，整个系统的编程能力要接近于CPU的易用编程能力；
• 其次，不改变原有的系统架构、软件生态和编程习惯；
• 最后，软件定义，跟现有软件定义的系统兼容，渐进式优化。

用户掌控一切

以网络芯片为例，传统的网络芯片是供应商定义功能并实现为ASIC，当用户使用过程中遇到问题，需要更新功能和协议的时候，通常需要1-2年的时间，等待供应商把新的功能更新到新一代的硬件平台中，然后用户再去购买新的硬件。

后来“逼得”互联网公司不得不自己定义并研发自己想要的硬件产品。即便如此，如果互联网公司自己对硬件功能理解的不是很完善，同样会出问题。

如果这样的话，在极度复杂、并且业务应用更新迭代很快的云计算等场景，ASIC不合适。主要，势必需要通用的、可软件编程的平台。当然，需要的是实现极致的性能情况下的可软件编程。

所有的场景都有一个规律，“二八定律”：同样一个场景，不同用户的共性达到80%左右，差异性20%左右；同一个用户场景，未来一定时期，只有其中20%功能可能会被迭代，有80%会大约处于稳定状态。

这样，我们就可以针对性的实现软件定义的并且硬件加速的软硬件融合处理引擎，用户在特定条件下实现掌控“一切”。

软硬件融合架构

CPU、GPGPU、ASIC以及DSA四种平台的优劣势详细分析如上图所示。

软硬件融合架构（Converged Architecture of Software and Hardware，CASH）的目标：

• 性能。相比GPGPU，性能再提升100+倍；相比DSA，性能再提升10+倍。
• 灵活性。接近于CPU的灵活性、通用可编程性。
• 资源效率。跟DSA接近的资源效率，单位晶体管消耗下最极致的性能。
• 设计规模。软硬件融合，驾驭10+倍更大规模的设计。
• 架构。基于软硬件融合架构的超异构计算：CPU + GPU + DSA + ASIC + etc.。
• 生态。开放的平台及生态，开放、标准的编程模型和访问接口，融合主流开源软件。

第四代算力革命，基于软硬件融合架构的超异构计算

我们从硬件和软件两个角度分析：

• 一方面，只有硬件思维，也许可以把算力堆砌到x1000+，但是一定是软件开发人员难以驾驭的。
• 另一方面，只有软件思维，也许可以保证整个系统接近100的非常好的灵活可编程能力，但是其一定难以构建如此“庞然大物”般的芯片系统。

唯有软硬件“融合”在一起，深度协同，才能够构建既超高算力又有极致可编程能力的面向未来5-10年的新一代算力平台。

（全文完）

作者：Chaobowx
来源：https://mp.weixin.qq.com/s/dgZIdJLGHh_dRPhosZsAwA
微信公众号：

相关文章推荐

• 第四代算力革命：基于软硬件融合的超异构计算
• 软硬件融合：从DPU到超异构计算

更多软硬件技术干货请关注软硬件融合专栏。