二代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的思维模式 , 我们需要和用户就此积极地沟通 。"
【二代IPU:怎样做一颗秒杀超算的芯片?】

    推荐阅读