二代IPU：怎样做一颗秒杀超算的芯片？

去年的《观点》特刊中，我们花相当大的篇幅谈了作为CPU、GPU之外“第三类”芯片存在的IPU——简单地说是Graphcore的一种通用AI芯片（虽然现在看来，它可能还在寻求HPC其他方向的可能性）。当时初代IPU构成的32个IPU-POD，算力弹性扩展至0.5 ExaFLOPs的程度，已经令人印象深刻。

近期Graphcore又发布了二代IPU芯片Colossus MK2 IPU (GC200)（以下简称MK2），以及包含四颗MK2芯片系统方案的IPU-Machine: M2000 (IPU-M2000)（以下简称M2000）。扩展至1024个IPU-POD，即512个机架，至多64000个MK2芯片集群之后，其16bit FP算力能够达到16 ExaFLOPs.

在上周的媒体分享会上，Graphcore高级副总裁兼中国区总经理卢涛还提到，“日本前一阵发布了超算，做到0.5 ExaFLOPs的算力”。这应该指的是富士通A64FX芯片构成的Fugaku（富岳）超算——A64FX也是一颗很有意思，芯片之上融入片上HBM2，并且偏向融合CPU+GPU架构的通用芯片，未来我们将就这颗芯片做更多分析。

实际上卢涛所说的0.5 ExaFLOPs，应该是指Fugaku的FP64算力，其FP16算力在2.15 ExaOPs上下。而Fugaku超算内部堆了158976个A64FX板卡。从这个层面来说，Graphcore的MK2的确能够在单纯的算力上轻松超越前者，即便A64FX作为一颗通用芯片，还是用了更多的资源在控制流方面——而且A64FX更偏向于一个完整的系统。

在谈Graphcore的二代IPU之前，仍然建议首先读一读《芯片专用好还是通用好？遥想20年前GPU也面临这一抉择》这篇文章，其中相对详尽地介绍了IPU这一类芯片的技术路线和理念，亦便于理解二代IPU产品。

用料还在加

初代IPU给人留下印象深刻的地方就在于堆料相当充沛，不仅是超过1200个低精度浮点运算核心（每个核心至多跑6个线程），还包括令人咂舌的300MB片内SRAM资源，算力水平125 TeraFLOPs。

而这次的MK2在架构上与前代还是基本相似的，不过核心数目增加到1472个（多出20%），片内SRAM则增加到900MB（多出3倍）；在互联扩展性方面，Graphcore官方给的数据为可扩展性是前代的16倍——这个数据应该是根据前代至多4096个MK1，到这一代至多扩展64000个MK2（即16 ExaFLOPs），差不多是16倍的关系；同时开始采用台积电的7nm工艺。

显然在计算、数据和通信扩展层面，MK2都算是延续了Graphcore堆料狂魔的传统。我们去年就有问过卢涛，像900MB这么大的片内SRAM，是如何确保芯片良率、控制成本的。这次，Graphcore中国区技术应用总负责人罗旭还是有提到：“Graphcore其实是使用了分布式的存储技术，相当于做了很多小核，多做一些冗余在芯片里，使其可以达到很高的良品率，也能够较好地控制成本。”

上面这张图可以相对清晰地展现MK2的内部架构。这里的每个IPU-Tile，即包含了核心与独立SRAM的一个单元，总共1472个IPU-Tiles，8832个可并行执行的线程。

“In-Processor-Memory从上一代的300MB提升到了900MB，每个IPU的Memory带宽是47.5TB/s。同时还包含了IPU-Exchange以及PCIe Gen 4与主机交互的一个接口；另外有IPU-Links 320GB/s的芯片到芯片的互联。”卢涛说。

在构成系统时，IPU-M2000即是包含了4个IPU芯片的设备。现在的芯片制造商为了加速产品上市，通常都会采用这种系统交付的方式，为客户提供更多的便利。这样一个1U的M2000设备，提供大约1 PetaFLOPs的算力。

系统层面，还提供了针对4颗IPU的至多448GB DRAM内存支持，Graphcore将其称作“Streaming Memory（流存储）”，“通过IPU Exchange Memory技术，提供超过100倍的带宽以及大约10倍的容量，这对于很多复杂的AI模型算法是相当有帮助的。”

这里的100倍和10倍，对比的是英伟达现有面向AI计算的GPU产品HBM2存储。这个对比，应该是纯粹基于IPU的多层级存储结构，与Exchange Memory乃至更多优化技术加成，将其作为一个整体与GPU的HBM2存储作比较。是否真的能同时在带宽和容量上达到100倍与10倍的优势，与Exchange Memory技术应该有着莫大关联。有关IPU存储系统的部分，还将在下文详述。

M2000本身集成了扩展网络，可从一个小系统扩展到大规模的机架部署。Graphcore采用一种名为IPU-Fabric的技术来连接前文提到的IPU-Tiles，以及其他IPU，乃至盒子和机架。 “2.8Tbps超低延迟结构”，最终可以扩展到64000个IPU，“通过直连或者通过以太网的交换机等技术做互联。”卢涛说，“IPU-Fabric是专门为AI应用从零开始设计的一个技术。”

M2000设备内部包含了一颗Gateway网关芯片（这是个Arm CPU，其上跑Linux系统，通过PCIe与四个IPU连接），提供对DRAM、100Gbps IPU-Fabric Links、连SmartNIC的PCIe接口、1GbE OpenBMC管理接口，以及M.2接口的访问。

Graphcore宣称，M2000在神经网络训练的性能表现上，是上一代的7-9倍，推理则也有超过8倍的性能提升。

“上图是三个比较典型的应用场景，一个是BERT-Large的训练，有9.3倍的性能提升；BERT-3Layer推理，有8.5倍性能提升；而像EffcientNet-B3这样一个计算机视觉应用模型，有7.4倍性能提升。”

单纯从算力的角度来说，Graphcore还列举了自家8个M2000设备，与8个英伟达DGX-A100的比较，如上图所示——虽然我们认为这样的对比意义可能并没有数字看起来的那么大，毕竟后者在生态构建上要完善很多。不过做纯算力投入时，IPU仍然是明显更加高效和经济的选择。

卢涛举例说，“在EfficientNet-B4图像分类训练方面对比，客户只需要259600美金（8个IPU-M2000），就能使用需要投资高于300万美金（16个DGX A100）的GPU设备。如果是做EfficientNet-B4训练的话，可能性价比要高10倍都不止了。” 这本身就是专用与通用之间，在效率上的差别。

谈谈存储与通信

我们认为，在AI或者HPC芯片产品中，IPU的独特之处主要在于其存储子系统，与通信系统/扩展能力。这一点在过去的文章中，我们就不止一次地提到过。Graphcore也在官网对这这两方面的技术做了相对详尽的分享。虽然我们过去就介绍过，但这次的二代IPU，在这两个方面又有了深入。

如前所述，IPU的每个Tile都带独立SRAM，一个MK2总共有900MB SRAM，相比上一代提升3倍，实际上由于片内存储还包括了程序占用的部分。所以MK2实际带来，可供weights（权重）和activations（激活）使用的片内SRAM容量是上一代MK1的6倍。

除此之外，Graphcore在上个月发布的文章中提到，要确保IPU能够通过Exchange Memory通信技术访问其他存储资源，用于更大的模型和程序——这对于现在的机器学习负载来说还是很重要的，“如何访问内存，与如何执行计算一样重要。”

所以除了片内SRAM之外，也需要Streaming Memory流存储。上面这张图片是戴尔DS8440 IPU服务器的内部结构。这台服务器的存储子系统，给16个IPU配了256GB的可寻址流存储。这台服务器用的还是初代MK1，所以IPU的片上SRAM是300MB。每个IPU分得16GB流存储。

存储资源的使用，是由软件高度支配的，这样一来存储访问便具备了相当的弹性。Exchange Memory实际上是Poplar SDK内，用于管理片内存储与流存储的一个功能特性。最新发布的 Poplar SDK 1.2 针对这项特性面向开发者开放了一些API。简单来说，它是一种在片内存储与流存储之间做带宽与容量平衡的方案，就类似于本地存储和外部存储那样。

从Graphcore的文档来看，除了Exchange Memory之外，针对两种存储的数据高效利用，还有更多的方案。比如说对于开发者而言，低层级的Poplar Graph编程框架中可以进行显式的存储管理；像TensorFlow这样的机器学习框架，也能利用模型的分阶段执行，实现任意时间点，仅模型所需的部分参数，才存放在本地SRAM存储器中（虽然现在似乎仅基于开发者的用户注释）等等操作——而且看起来Graphcore还在强化其自动化能力。

虽然我们并不清楚Exchange Memory的实现细节（Graphcore官网有探讨一些针对深度神经网络优化片内存储利用率的方案[1][2]），但显然这些操作都依托于大容量的片内SRAM，另外再配合Exchange Memory这一系列优化技术，达成Graphcore宣传中相比GPU带宽高100倍，容量大10倍的目标。

实际上相关存储，或者“数据”部分的设计，Graphcore有比较多的思考，毕竟存储容量与带宽矛盾是DNN网络的重要挑战之一。即便MK2如今的片内SRAM达到900MB，在模型尺寸每3.5个月就翻倍的当下，也必须依靠更多优化技术来解决其中的矛盾。鉴于篇幅的关系这里无法探讨更多。接下来我们再谈谈 “通信” 与扩展部分。

从相对更微观的层面来看，先前的文章中，我们特别提到过，IPU采用BSP（Bulk Synchronous Parallel）模型进行多核协同工作——这是一种比较古老的方案，但是是第一次在芯片上实现的，在核心与存储分别在“计算阶段”和“交换阶段”两个状态间切换；IPU再藉由专门的硬件保证全局同步。而IPU-Fabric以及BSP编程模型，显然是实现IPU可扩展性，以及网络通信开销最小化的保证。

这里的IPU-Fabric是三种网络互联技术的集合。这种集成互联通讯结构，在设计上从数据和模型并行层面都是在全力支持BSP的。 “Graphcore的IPU-Fabric主要由三种网络组成，IPU-Link、IPU Gateway Link，以及IPU over Fabric。” 卢涛说，“其中IPU-Link，像是IPU-POD64里面，一个机架之内提供IPU之间的通讯的接口。”

“IPU Gateway Link提供机架与机架之间横向扩展的网络。IPU over Fabric，则是将IPU集群与x86集群进行非常灵活以及低延时、高性能组合起来的网络。”

也就是说，IPU集群通过IPU over Fabric接入到x86集群中；同时在IPU集群内部，一个IPU-POD64机架内部通过IPU-Link连接——每个IPU-POD64支持16个IPU-M2000；机架间连接网络则采用IPU Gateway Link——至多1024个IPU-POD64，即512个机架（64000个IPU）。

IPU-Link用的是2D-Torus拓扑结构，Graphcore提到这种结构最大化了IPU-Link的带宽，全缩减（All-Reduce）效率比网状拓扑快2倍。而机架到机架之间的扩展，则借助于100GbE以太网。

这里尤为值得一提的是，IPU-Fabric采用一种比较灵活的disaggregation模型，CPU与加速器之间的数量比例没有特别的限制。比如自然语言模型对于CPU的需求比较低，CPU与AI加速器之间的数量比例可以做到1:100，而CNN卷积神经网络就可能需要 1:4/1:8 这样的比例。这种设计也就提供了比较大的部署灵活性。Moor Insights & Strategy针对这种disaggregation模型的评价是，“可能是第二代Graphcore IPU平台最大的优势特性”。

生态构建在持续：开源

随MK2芯片与M2000盒子一同到来的，不可缺少的当然还有软件方面的Poplar SDK。去年的文章中我们也详细介绍过Graphcore的Poplar。它主要解决的问题是，在编译、优化流程的自动化过程中，IPU这种独特的架构带来的编程挑战；在不需要开发者手动调整指令集编程的情况下，就能充分利用IPU硬件进行大规模并行计算。

罗旭表示，“Poplar包含几个部分，第一部分是PopART和PopLibs。PopLibs相当于最底层的SDK这块。”前端的ML框架通过PopART接口来对接整个Poplar。上层的ML框架支持，包括主流的PyTorch、TensorFlow、ONNX、mxnet，以及即将支持的百度PaddlePaddle等。（早前的宣传中，TesnorFlow似乎有个单独的XLA）

这里的PopLibs应该包括了很多库，如PopNN、PopLIN、PopOPS等，针对包括线性代数、常见神经网络函数等操作。这部分实际上就包含了针对IPU分布式处理器与存储架构的，数据与工作分区。它构建起了针对各种操作的一个定制化层，而且为IPU执行做了高度优化。

再往后是Graph Compiler（计算图编译器），这是为开发者提升编程易用性的核心所在，据说Graphcore开发了超过5年时间。它有两部分工作，其一是对计算进行编译（计算图顶点），其二是生成代码进行BSP通讯（计算图边缘）。这部分需要优化代码，尽可能让数据迁移动作变少，充分利用好片内存储，做好大规模并行工作。对开发者而言，因为Graph Compiler仅呈现单个“Multi-IPU”，而不是一大堆独立的处理器，开发者就可以更加专注于数据和算法。

还有一些组件这里也省略了，比如与Graph Compiler并列的实际上还有个Graph Engine，为IPU提供运行时支持，包括连接主机CPU的软件和IPU的软件；管理数据移动；针对I/O、应用加载、debugging等管理IPU设备。

Graph Compiler编译过程，实际上就是构成计算图的过程，也是实现IPU通用性的基础。在这个简化的模型里，再往后计算图就会加载到IPU硬件。当然，理论上这其中应该还包括IPU硬件抽象层、驱动等。

而这次Poplar SDK 1.2的提升主要包括“更多ML框架的支持”；“进一步开放低级别的API，开发者针对网络性能可做进一步调优”；“还有优化的卷积库和稀疏库”。API部分，Exchange Memory“也做了一些开放，包括API以及它的管理功能的开放。应用开发者可以基于Exchange Memory对模型的性能做极大程度的调优。”

与此同时，在实际生产部署中，Graphcore软件能够扩展到云与企业本地基础设施。Microsoft Azure支持IPU，戴尔也在早前就开始在服务器中支持双C2卡；在虚拟化、安全、编排工具支持上，Graphcore开始支持Kubernetes、Docker、Hyper-V。

另外“Poplar SDK以及Graphcore的drivers、工具链等，都完全支持Ubuntu、RedHat、CentOS”这样的主流操作系统。作为一家初创公司，在短时间内做到这个程度的部署，是相当迅速的；可见其生态部署积极性有多高。

在生态部署上尤为值得一提的是，7月6日，PopLibs计算图库在GitHub上正式开源。这一步对Graphcore而言应该是相当重要的。开源策略应该能够扩张IPU平台的参与度，引导社区共同开发更多的库。生态资源本身就是Graphcore当前面临的最大挑战。

率先在中国部署开发者云

“目前Graphcore在中国的首款IPU开发者云是部署在金山云之上的。这里面使用了三种IPU产品，分别是IPU-POD64，还有浪潮的IPU服务器NF5568M5，以及戴尔的DSS8440。这是个面向商业用户进行评测，以及高校研究机构，甚至个人开发者可提供免费试用的资源。”卢涛表示。

在Graphcore看来，第二代IPU应当会在NLP自然语言处理方面首先落地。“因为NLP方面，模型规模超级大，数据规模超级大，这就导致现在NLP都用比较大规模的算力集群来处理问题。”“当然，在机器视觉、视频等方面目前也可以看到一些新的突破，可能会驱动非常大的算力需求。”

“目前IPU的开发者云支持当前一些最先进和最复杂的AI算法模型的训练和推理的工作，比如说自然语言处理类的、高级计算机视觉类的应用，主要是以分组卷积为代表的一些机器视觉的应用，像ResNeXt、EfficientNet等等。

“基于一些时序分析类的应用，譬如像LSTM、GRU等等大量应用在语音应用、广告推荐、金融算法等方面的模型。在排名和推荐类的，譬如像Deep Autoencoder，在概率模型方面，譬如说基于MCMC的一些算法交易的模型方面都有非常好的一些表现。”

从去年我们采访Graphcore的CEO Nigel Toon，到今年二代IPU问世还不到一年的时间，从Graphcore现有的宣传资料（比如出现类似Exchange Memory这样的市场词汇），能明显感觉出Graphcore在产品推广方面纯熟了很多。虽然在产品应用上，Graphcore还有很长的路要走，但从Graphcore的技术分享，以及现有资料来看，IPU的确是时代下大有可为的芯片。

“IPU不是GPU，这个可能是最大的一个挑战，但同时也是最大的一个机会。IPU并不是GPU的替代品或者类似品，Graphcore IPU有自己独特的赛道。重要的一点是我们拥有IPU思维，不能拿GPU的逻辑来套用IPU的逻辑。对用户、对自己的员工都是如此，需要建立IPU的思维模式，我们需要和用户就此积极地沟通。”

责编：Yvonne Geng