万字干货分享 | 阿里云 CIPU 技术解析

2023-08-14
北京
本文字数：11181 字
阅读完需：约 37 分钟

2023 年 7 月 26 日，阿里云弹性计算团队与智东西公开课联合出品的系列课程【阿里云弹性计算技术公开课】第四节正式播出，阿里云资深技术专家杨航带来了主题为《阿里云 CIPU 技术解析》的课程分享，本期课程在阿里云官网、智东西官网、钉钉视频号、阿里云微信视频号、阿里云开发者微信视频号、阿里云创新中心直播平台 &视频号等多平台同步播出。

2022 年 6 月，阿里云发布了云基础设施处理器 CIPU（Cloud Infrastructure Processing Unit），将其定义为取代传统 CPU 的新一代云计算体系架构的核心。在这个全新体系架构下，CIPU 向下对数据中心计算、存储、网络等底层基础设施快速云化并进行硬件加速，向上接入飞天云操作系统，将全球数百万台服务器构建为一台超级计算机，实现资源的灵活编排和调度，给用户提供高质量弹性云计算算力集群。

本篇文章根据杨航的课程整理而成，供读者阅览：

一、什么是云计算：计算和云计算是什么关系

什么是云计算？2009 年美国的伯克利大学对云计算做了精确的定义：

1、云计算可以按需使用无限量的计算资源。这句话可以看出云计算与计算的巨大差别。比如传统 IT，线下我们在 HP/Dell 买服务器，它不是按需的。传统 IT 是 on premise，需要把这些服务器、交换机、存储，在使用前就要在线下机房构建好。云计算的服务是按需使用所需，而且计算资源是无限的，而不是买了两台，最大就只有两台，想扩容和缩容，想伸缩都是比较难的。

2、消除云用户的预先承诺。即用户在任何一个 region 区域或 AZ 可用区，只需要用支付宝或信用卡付费，付费成功即可按量使用计算存储网络的资源。用户并不需要跟 CSP(Cloud Service Provider)云提供商预先承诺要在哪一个地方部署多少资源。

3、根据实际需要支付短期使用计算资源的费用。即用户不需要承诺他购买的计算资源的预期使用时间。用户购买后即使只用一分钟也可以，对于云计算所使用的容器或者函数，计时单位可以精确到毫秒级，哪怕使用几十毫秒都可以，只要用户希望如此使用即可；当一个计算资源必须让用户使用四年、五年或者整个生命周期，即说明它不是云计算，而是 IDC（服务器托管），或者说是一个私有云。在此引用王坚院士的比较极致的说法：严格意义上来说，私有云不是云，只有公有云的公共计算资源池才是云。

4、通过规模经济显著降低成本。即我们希望通过使用超大的数据中心，通过规模经济，放大供应链效益，摊薄研发成本。规模经济很重要，例如芯片，大家一定知道，没有规模是一定不能做芯片的，因为其研发成本太大。软件产业、芯片产业或者整个 IT 行业，核心的逻辑就是规模经济，通过无限低的复制成本，来把初研发成本等摊到零。

5、通过资源虚拟化技术简化操作并提高资源使用率。我们希望通过资源虚拟化做到什么呢？把客户使用的资源虚拟化，把计算、存储、网络抽象后，达到简化操作，提升资源利用率的效果。在此不展开具体细节，大家可以自行搜索相关信息。比如 VMware 的一些经典论述，虚拟化是可以有效地提升比如 CPU 利用率、内存利用率，IO 利用率以及网络利用率。这点我不展开，大家可以把它当作结论。

6、通过多路复用的方式运行来自不同组织的负载，提高硬件资源利用率。核心是多路复用。因为公有云的池子，比如淘宝在双 11 使用公有云的计算资源池；而到了春节，大家使用 12306 抢火车票的时候，12306 也使用同样的公有云计算资源池。这样就可以削峰填谷，通过多租户使用同一套的计算资源池，保证此公有云的硬件的资源利用率显著提升。

按照伯克利的定义，只要满足这六点，就是云计算。不满足这 6 点就是“忽悠的云计算”，这是我的看法。当然我想讲的主旨是什么呢？今天我们可能被很多的短期行为，有很多所谓的转售服务器、转售 CDN 或者转售 GPU 卡，事实上它们不是云计算，没有通过技术创造社会红利，也没创造客户价值。从长期来看它们是不可持续的，这就是为什么我要在开篇的时候重新 recap 伯克利在 2009 年提出的云计算的定义。

相信大家比较关心云计算与计算的关系 --- 它们是正交关系，不是替代关系。比如，目前 AI 分布式系统中，我们希望 AI 分布式系统横向 scale out 后，它的加速比能保持 1。微软开源了 deep speed，它做的是计算维度的事情；比如我们构建 Hadoop 和 Spark 是在构建计算，但是云计算还有一个很重要的目标，就是把云的资源池放在一起，做到弹性极致的伸缩，然后再做到多租。

多租就是整个资源池，可以给淘宝用，也可以给 12306 用，这个才是我们真正想要的云计算。当然弹性多租需求发生在 IaaS 层，就需要做虚拟化；到了 PaaS 层，比如大数据，演进出存算分离等需求。

总的来说，计算和云计算这两个维度是正交关系，不是替代关系。但从长远来看，我们会看到计算一定会演进到云计算。比如 NVIDIA，现在的 NVIDIA 市值 1 万亿美金在做加速计算没有问题。我们要持续地增强计算能力，还需要云厂商把计算通过弹性多租，让计算更具普惠化和高效，然后让创新的成本变得很低。

而从阿里云的角度看待云计算，我们认为是四个目标：稳定、安全、性能，成本。

稳定和安全是所有事情的 1，性能和成本都是后面的 0。当然不是说性能和成本不重要，如果只有稳定安全的 1，是没有竞争力的；如果没有后面的 0，前面的 1 也没有价值，所以说他们是相辅相成的。

其实大家可能会发现，如果没有在稳定和安全上交过学费，便得不到这样的认知。因为稳定和安全被认为是售后，售前大家永远关心的是性能和成本，这是云计算的大目标。

可能大家会有疑问：稳定、安全、性能和成本事实上是计算的目标。

其实更严格来看云计算的目标还需要加两点：弹性和可持续。可持续指什么？我们的环境可持续。因为我们的计算资源逐步部署于云后，这些绿色计算，还有与之相关的，包括我们的架构可持续也是很重要的事情。

当然弹性和可持续，也是云计算厂商的目标。我们以客户视角列出如上稳定、安全、性能和成本四个目标，更完整的是把弹性和可持续加上去，云应该是有六个目标。有了这六个目标呢，我们就会分 IaaS、PaaS、SaaS。

SaaS 做的最成功的就是微软的 Office 365，还有 Salesforce。PaaS 层，就是大家会看到的大数据、AI 和数据库，典型就是这三个业务。这三个业务主要是数据智能、数据治理相关的。然后再到下面，狭义的云主要是指 IaaS，就是基础设施即服务。

二、公有云 IaaS 有哪些业务痛点

基于弹性计算上下文，我主要讲公有云的 IaaS 有哪些业务痛点。我们已经讲清楚阿里云如何看云计算：还是从客户视角，是否安全、是否稳定的性能、是否有竞争力、成本是否有竞争力。

1、安全，做过几年云计算后，会发现安全是我们如何做业务决策的规则。这个规则是什么呢？核心是因为什么呢？公有云这个大的计算资源池，计算、存储、网络都是多租户使用的。多租户场景中数据安全永远是最重要的。因此对于公有云来说，没有数据安全，就没有公有云，安全永远是第一位的。

在此展开，在没有 CIPU、DPU、IPU、神龙之前，我们遇到什么问题？

第一，大家对虚拟化都有一些了解，QEMU 里面有大量的冗余的设备仿真代码。它不是仅仅仿真 virtio，它还仿真了很多很多设备，其代码量是很大的。当代码量大的时候，这些安全攻击敞口无法收敛，所以我们就会看到大量的注入攻击。这种注入攻击，特别是 c 代码缓冲器溢出等问题，是很难根本性解决的，根本性解决方法就是把这部分被攻击的代码删除掉。

第二，在公有云里，数据在计算、存储、网络等子系统流动，需要把它们完全的加密。因为一旦安全被击破，这个云公司能否生存都是问题。

第三，我们看到很多客户，不论是内部客户还是外部客户，他们希望在云上构建安全容器。传统 Xen 和 KVM 架构是无法实现的，事实上就是安全上，我们看到传统的非神龙、AWS Nitro、IPU、IPU 或者 CIPU 这些架构下会遇到什么样的挑战。

2、稳定，稳定一定是数据驱动的，我们通过线上的监控和诊断，线上的数据采集，采集后就可以针对稳定性做提升。比如我们对至强 CPU 的 DDR 系统里面，采集到单比特 DDR 失效这样的数据之后，是可以预防性地对 VM 做热迁移，这只是举个例子。

更通用的原则是什么呢？我们希望看到计算网络存储芯片的实现细节，可以拿到更多的稳定性数据，在系统在变得不可用之前能预先诊断。那么我们就可以提前把这个机器热迁移，或者宕机迁移，或者提前让客户做主动运维。若我们不深入做这个软硬件系统的时候，是很难实现更极致的稳定性。

3、性能，大家都知道，在公有云中一定要网络虚拟化。拿阿里云举例，在 Xen 时代的网络虚拟化在内核做，网络虚拟化时延做到了 150 微秒，时延抖动是很大；在 KVM 时代基于 DPDK，网络时延做到 50 微秒。在线业务对时延抖动是相当敏感的。Xen 架构网络转发 pps，要承载企业级业务，也有一些关键性瓶颈。

更进一步，我们今天的数据密集型，不管是大数据、 AI，还是数据库系统，它们对高 IO 和网络带宽的全程零拷贝需求强烈。为什么要零拷贝呢？因为当带宽达到 50G 全双工，100G 全双工，甚至 400G 全双工的时候。当有数据拷贝，至强或者 GPU 系统的缓存子系统和内存子系统，它们的性能会遇到很大挑战。比如 2×100G，要在 XEON 的 LLC 缓存或者 DDR 里面拷贝数次，那么 IO、DDR 和缓存子系统都会出现严重的性能瓶颈。

4、成本，当今很热的大规模 AI 分布式训练，需要高带宽的 RDMA 互联。而在各种 HPC 业务对长尾时延和静态时延都有严格要求。在这种情况下，我们对性能实际上是有很高的要求。我们做 IaaS 的虚拟化，拿阿里云举例，在 Xen 时代，DOM0 耗掉了一半的 CPU；到 KVM 时代，我们耗掉了 10%的计算资源和内存资源，还要加网卡来做 IO 的虚拟化。这个成本实际上是需要进一步做优化的。

总的来说，公有云的 IaaS 业务痛点总结为：要解决安全问题，进一步提升安全需求，稳定性如何进一步提升？性能如何做到极致的高，成本如何做到极致的低。

三、什么是 CIPU，以及 CIPU 解决什么问题？

1. CIPU 从何而来？

CIPU ( Cloud Infrastructure Processing Unit)，即云基础设施处理器。它并不是新技术，我认为 CIPU 主要的源头是两点。

第一点，以 intel VT-d 作为一个典型的代表，它代表 IO 硬件虚拟化技术的成熟。因为这项技术的成熟，才会有 CIPU，DPU，IPU，所以这是前置条件。Intel VT-d 等 IO 虚拟化技术的成熟，会推动 PCIe 社区做标准化，比如 PCI 社区里面有 SR-IOV 技术，MR-IOV 技术等的标准化。

第二点，和 CIPU、DPU、IPU 很相近，对于做通信的同学，一定会觉得很似曾相识，它的近亲是 NPU，即网络处理器(network processing unit)。它是很早的技术，国内第一波做网络处理器的可能是 2001、2002 年开始的。

网络处理器的用途是可编程，处理网络效率高，但它不是算力加速和 offloading，它是让网络研发同学精确控制各种访存有多少个 Cylce 和访问次数，所以它其实是对内存使用的机制优化。可编程的网络处理器把缓存一次性剥掉，就可以形成 many core 架构。

2012 年，最先是 AWS 在 Xen 这套系统在处理 IO 遇到了性能瓶颈，AWS 便开始引入比如 Cavium 的 LiquidIO，还有 82599 外连网线做直通。不止 AWS，Broadcom、Cavium、Freescale、ezchip、 intel iXP 等也在开始在 2012 年左右关注这个市场。如果站在博通、思科或者华为做通信的视角，它是一个智能网卡。但今天它确实不再是智能网卡了。

在 2012 年通信市场，最火的技术之一是 SDN 和 NFV。那时希望把网络设备、网元通过类似云的技术，通过虚拟化的技术，使通信设备硬件软件解耦合。软件独立运行，独立开发，不与硬件耦合，因为硬件的铁盒子不是关键，软件才是灵魂。

当年 SDN 和 NFV 流行的时候，通信行业已经在设想通过 NFV，通过云化的设施承载无线核心网络甚至基站。那时，通信在网络虚拟化也遇到了大量的问题。自然就想到把网络处理器放在网卡里面来做。

所以在 2012 年时，云上的 IT 和通信形成了合流。最终通信领域的网络处理器，或者称之为智能网卡的技术进入了云的视野。

此后，2015 年 AWS 收购了以色列的 Annapurna Labs。当然阿里云也开始的比较早，从 2015 年起，阿里云和上文提到的供应商，比如博通、英特尔都有不少的接触。在那个时间点大家对技术发展的预见是一致的。

2014-2015 年，阿里云在预研，到了 2016 年开始真正的大规模投入，2017 年神龙发布，此时 AWS 也发布了同样产品。当然，我们也不必为此震惊，因为只要有足够大的规模，遇到了相同的问题，一定会找到相似的解法，这纯粹是业务驱动的问题。

阿里云 CIPU 的诞生,完全是业务驱动的结果。2015-2016 年，我们并不知道原理，也不知道计算机体系结构，纯粹基于解决业务痛点改进了系统架构。2009 年，阿里云开始做云；2013 年做飞天单集群 5K；2017 年，发布神龙架构； 2022 年，发布了 CIPU。

阿里云内部做了三代神龙。第一代神龙发布于 2017 年 10 月，这一代只想做一件事情，就是弹性裸金属。在上图第一个截图可以看到这个弹性裸金属的性能，比如网络可以做到 450 万 PPS，存储可以做到 20 万 IOPS，接口做到 20GbE。

第二代神龙发布于 2018 年 9 月，在网络、存储、接口性能大幅提升，到 2018 年底 2019 年初，我集团的全部业务从 ECS 切换到神龙架构，比如淘宝、天猫、菜鸟、高德和饿了吗等。如今阿里云新增的每一台计算服务器其实都是在神龙和 ECS。

第三代神龙发布于 2019 年 9 月 26 日，这一代我们做了一些存储网络快速路径的芯片加速。你会看到它的 IOPS 在上升，PPS 在上升，延迟在下降。

其实，当 PPS 超过 1000 万的时候，再提高 PPS 意义并不大，所以我们就会看到 AWS Nitro V5 做到 20Mpps 就够了。再提高 PPS 也只是在做内卷，网络上真正重要的是解决丢包、抖动、时延的问题，这些对业务真正重要的。

神龙走到今天，它的核心逻辑是要规模化，没有规模，无法实现垂直整合，因为研发成本并不低。

CIPU 是为云而生的，没有云，CIPU 便如同废铜烂铁，毫无价值。只有在云的环境下它才有价值，因为它解决云的弹性、多租户问题。它把存储资源、网络资源、CPU 资源，全部通过 CIPU 纳管，就是物理资源加上 CIPU 后就是一个云化的虚拟计算资源池。

我们希望通过构建虚拟计算资源池，虚拟网络资源池，虚拟存储资源池，把通用的计算集群，AI 弹性计算集群，大数据弹性计算集群和各种数据库系统，统一到一套池子里来解决他们安全诉求、稳定性诉求、性能诉求，成本诉求、同时这套架构富有极致弹性并且是可持续的。

上图是 CIPU 的展示，它通过硬件加速，比如上图中的 VPC、EBS、Elastic RDMA 都于硬件加速，还有硬件相关的，比如安全可信根、存储处理引擎、安全加密等，都在实现在芯片里，通过软件跟硬件的深度融合来实现更高效率。对外，我们可以生产安全容器沙箱，也可以生产虚拟机，也可以把裸金属直接卖给客户让其生产自己的安全容器。

我们可以把云原生简单理解成一个容器，用户可以生产安全容器的沙箱，它可以 50 毫秒快速启动，一台机器可以生成 2000 个这样的容器。同时 IO 速度是极致的，比如 50M PPS， 300 万 IOPS。EBS 300 万 IOPS，4Kbyte per IO request 的话，可以做到 128Gbps 存储 IO 带宽。

对我们的业务来说，长尾时延是真正重要的。当然平均时延也很重要。在这一代，本地盘的虚拟化也得到了根本性的提升，我们希望本地盘虚拟化，比如带八个盘，一个盘是 50Gbps IO 带宽，八个盘就 400Gbps。我们希望这 400Gbps 都能分给安全容器和虚拟机使用，我们希望能达到八个盘 800 万 IOPS。

当然安全在云中永远排在第一位，所以持续加强数据加密、硬件可信、固件验签等是云的底线。因为没有这些，一个云公司但凡在安全上出了问题便是灭顶之灾。后面我会继续展开介绍弹性 RDMA，这就是第四代神龙，已经大规模上线了。第五代、第六代正在研发之中。

总结起来，CIPU 系统根本性要解决十个业务痛点：

第一，IO 硬件设备虚拟化。我们不希望自己造一套设备模型，对于阿里云 ECS 和 AWS EC2 来说，OS 太多了，有 Windows、Linux；Linux 有 CentOS6、7、8，有 ubuntu，有 FreeBSD，维护这些驱动会把绝大部分公司搞崩溃。所以我们选择用 virtio，核心是要靠生态。因为对于 ECS 和 EC2，生态永远是第一位的。没有生态，性能和成本是毫无价值的。

具体实践上，IO 硬件设备虚拟化，包括这些设备虚拟化的可编程的弹性，BD Ring 的池化。网卡中断汇聚，如何做到性能和时延的平衡，这里面有大量细节，不是简单的事情。网络的丢包和时延抖动等，要做大量持续打磨。

第二，VPC overlay 网络硬件数据加速。我们希望把三层或者 3.5 层的 VPC，将它的转发做成硬件路径。硬件路径不仅仅卷 pps，今天第四代神龙做到 50Mpps，就是 5000 万 pps，已经远远超过需求，但是你要把它 P50 时延，P99 长尾时延，抖动，丢包这些解决好，才是真正意义上的竞争力。

第三，EBS 分布式存储接入硬件数据加速。EBS 也是一样，比如 P999 长尾时延如何，P50 平均时延如何？这些平均时延和长尾时延决定了数据库系统真正运行时的状态。

第四，本地存储虚拟化硬件数据加速。主要是在计算机头做缓存，核心竞争力是性能，比如 BPS、IOPS，P50 平均时延，P999 长尾时延。

第五，弹性 RDMA。大带宽双向 200Gbps，也就是 400G 的满线速要处理，以及延迟是能够做到多少。对于 HPC 来说，静态延迟和长尾动态延迟都是十分重要的,而 AI 分布式训练场景，更重要的是带宽，带宽双向打满的需求。

第六，安全硬件数据加速。所有 200Gbps 的数据是要加密的，因为安全出问题，对公有云来说是极其严重的问题。

第七，云可运维能力支撑。可运维是所有组件要能热升级，虚拟机要能热迁移。同时数据可采集，可以以数据驱动来提升稳定性。

第八，弹性裸金属支持。比如安全容器、AI 分布式训练需要极致性能。单是计算和内存虚拟化就有 3~5 个点的性能开销，而在很贵的 GPU 服务器上的话，这个开销就会更为显著。

第九，CIPU 池化能力。我们希望更充分的使用 CIPU 的资源，这本身就包含池化逻辑。比如 200Gbps 带宽通常情况下是用不完时，我肯定希望通过 CIPU 池化技术，提升 CIPU 本身资源的利用率。

第十，计算虚拟化支撑。

接下来和大家分享一下 ECS 八代的性能。ECS 八代每台机器有双向 200Gbps 能力，EBS 云盘 IOPS 可达 300 万 IOPS，30 微秒。VPC，5000 万 PPS，时延 16 微秒，包括 999、9999 的抖动，丢包等在 ECS 八代都有很好的优化。

弹性 RDMA 是第四代重点推的能力，我们不仅把它定位到 HPC 和 AI 的场景中，我更希望把它推到数据库等这些通用场景，从 HPC 和 AI 场景应用的小众技术，变成主流场景。因为只有 IaaS 具备的时候，其上的业务才会逐渐切换过来，比如大数据，缓存才会切。除了 AI、HPC 拓展到大数据、数据库、缓存等等，我希望把它做成数据密集型业务的核心竞争力的产品。

刚才我讲的都是性能层面 Micro-Benchmark，但是大家一定把真实应用 E2E 的运行起来，比如 MySQL，PK 的就是云盘的性能。

同时 Redis，我们可以看到在 eRDMA 上有 130%的性能提升，它就是应用 E2E。

阿里云 CIPU 是为 IaaS 的全方位计算安全做支撑的。比如底层硬件，现在使用 TPM2.0 等，全部由可信硬件构成。信任根确保在第一行代码运行就是可信的，并且这个信任根一直能传递到 OS，传递到 VM，确保每一行代码都是可信的。这个极度重要，这个是 CIPU 提供的。当然在固件安全这一层包括 BIOS、BMC、网卡、FPGA、GPU 等等，确保所有固件都可信。再到存储网络全链路一定是加密的。也就是说 IaaS 尽最大可能降低安全隐患。

我们讲了启动的信任链是完全可传递的，传递到虚拟化的可信任根。到虚拟化这一层会有机密计算，包括虚拟化 Enclave。上图右边列表与友商的对比的六个维度：虚拟化 Enclave、SGX（裸金属/VM）、SEV、可信启动、整个系统的可信方案、虚拟可信。这里表明阿里云对安全是认真的。因为安全发生故障的代价没有人能承受。

性能稳定性极度重要。比如计算虚拟化一定不能有抖动；比如 ECS 为什么要搞企业级实例？是让 CPU、内存有性能隔离，不要多租户之间互相影响；比如某个微服务调用了一个百多次链路的业务，抖动过后，它的这个长尾时延会让这个业务彻底受不了。网络也是，之前有同学在问网络带宽怎么隔离，做通信的同学一定会对层级化的 HQOS 很了解。但是怎么让这些老技术在新场景里面发挥作用，再通过软硬件融合，适合硬件做的让硬件做，适合软件的用软件做。

QOS 就是有资源争抢。比如带宽只有 1Gbps，但是需求是 2Gbps，那么就需要分高低优先级，高优先级的先处理，低优先级的做限流， CPU、内存、Cache 等也可以同样方式处理，所以 QOS 只有在资源需求争抢的时候才会形成。QOS 也没有万能药，一定要有取舍，就是高优先级的先处理，低优先级的受损失。核心目标就是在资源增强的时候保障高优先级的请求，低优先级的做限流。这是我们实现性能稳定性的逻辑。

弹性 RDMA，这是 CIPU 引入的新特性，上面的图就能阐述清楚：

第一，RDMA 是生态兼容的，这意味着什么呢？比如客户 HPC 在线下的业务，直接把镜像和代码拷贝到 ECS 里面，可以做到二进制兼容一行不改。大家可能认为代码一行不改动不是 IaaS 应该做到吗？但是如果你用 AWS EFA 和 SRD，它就不是二进制兼容的。AWS 定义了 SRD，它不是 RDMA 的 RC，RC 是 reliable connection。使用 AWS SRD 需要使用他的特定库，但是这点有背 IaaS 的原则。IaaS 的原则是代码零修改、二进制间兼容的运行。这也是阿里云为什么不做 SRD 的原因，因为我们希望做到生态兼容。

第二，RDMA 是超大规模的，为什么呢？因为云里面，我们的 VPC 是同一区域，跨 AZ 是毫秒级时延。更为极端的使用场景，比如张北的一个机房，跟上海的一个机房通信，这是一个几十毫秒级的通信系统，弹性 RDMA 也能够胜任这个场景。而上面这种情况下，如果采用传统 RoCE 技术，基于 PFC 这个 RoCE RDMA，跨一个 pod 机可能出现严重的技术挑战。

第三，是要基于 VPC 之上。因为 VPC 才能在三层或者 3.5 层把网络租户隔离，然后才能保证 ECS 的弹性。在此再次强调，如果说云没有弹性，没有多租户，事实上就是短期的卖铁行为。卖铁行为是不可能产生社会价值，也不可能产生客户价值的。这就是传统的 IDC 或者是高级版的 IT。

我们的弹性 RDMA 性能做到双向 200Gbps，8 微秒时延，后续有优化版本能做到 5 微秒时延，今年年底可以交付。现今的弹性 RDMA 能交付 3000 万 message pps，请注意，RDMA 的 message 最小是一字节，最大是 2GByte，这个 message 跟 packet 不是一一映射关系。比如一个 2GByte 的 message，按 1.5k MTU 来分解，便是大量的报文。

ECS 八代实例的全量支持。用户购买的 ECS 八代都是可以通过弹性 RDMA 互联互通的，后续我们会逐渐把六代、七代全部做到通过弹性 RDMA 互联互通，因为网络只有互联互通才能真正上做出业务价值。

我们希望焦点在哪里呢？弹性 RDMA 不仅仅是做 HPC 应用或者 AI 应用或者数据库应用。因为传统的这些应用，这三个应用就基于 RDMA 长出来的。希望做些缓存应用，大数据应用，甚至是在线交易应用，在基础设施可以提供支撑的时候，上面的应用才能长出来。Open API、Intel MPI、libfabric、NCCL、UCX、SMC-R，这些都可以代码零修改的兼容，我们希望做到普惠。

技术上是全栈自研：首先是弹性 RDMA 虚拟化、LUNA TCP 网络传输协议、HPCC 网络拥塞控制算法和多路径支持。多路径对于 AI 大带宽业务非常重要，支持多路径，带宽利用率会提升 70%。也就是说比如 800Gbps 的系统和一个 1.6Tbps 的系统，如果通过多路径使得带宽利用率提高 70%，这个意味对于现今大带宽 AI 来说，是核心竞争力。

下面介绍以下大家比较关心的，云上怎么构建 AI 高性能的系统。

对于通信来说有以下四个问题：

1、多打 1 的通信 incast。比如 MOE 这种专家系统，它的 all to all 通信，都是多打 1 的 incast。

2、大象流 hash 冲突。就是消耗几十毫秒的这种 200Gbps/400Gbps 的通信，被称为大象流，大象流在典型的数据中心网络里会有三个 hash 冲突点：

· 网卡 2x100G 或者 2×200G 的出接口，这个地方有哈希不均衡。

· ASW 上行 PSW 时，ECMP 的等价多路径会有哈希不均衡。

· PSW 下行 ASW，会由于 ECMP 路由，导致 NIC 入方向的 incast 不均衡。

这三个哈希冲突点解决不好，大象流冲上去，会导致很低的交换网利用率。

3、云特有的多租户网络流量干扰。因为带宽太大，甚至需要占满交换网。这时如果多租户之间的流量有耦合，会有很大的问题。

4、多轨道资源调度碎片化。业界其实在做多轨道碎片优化，核心是把这些机器的处于相同 rank 的 GPU 放置到一个 ASW 中，让同组 GPU 的流量尽量终结在 ASW 中。好处是流量终结在 ASW 中，不流入 PSW，但是会导致调度域碎片化。因为一个 ASW 如果带 32 台机器，这 32 台机器客户申请和释放几次后，这 32 台机器在同一个 ASW 会碎片化，到时候对调度会有 co-locality 的要求，这对调度是一个很难的问题。

这是我们的一家之言。我们希望构建端到端的拥塞控制，比如从 GPU 到 GPU -- GPU -> PCI -> PCIe Switch -> 网卡-> ASW -> PSW-> ASW->网卡->PCIe switch -> GPU 完整的端到端拥塞控制。因此需要把 PCIe 相关的流控信号到网络内部的拥塞控制信息要全链路打通，否则就会缺一环。

此外，多路径打散大象流，也需要通过端到端的多路径来解决，而不是只解决网卡或者只解决网络。同样我们希望把去多轨道，回到通用网络，构建同 pod 对等网络来解决我们这些多租户网络流量干扰和资源碎片化问题。

思考过后，我们认为传统交换机的自适应路由、flowlet，VOQ 等技术，在部分场景里面解决了一些问题，但是他们很难全方位解决好这些问题。这是我们看到的一个难题。我们考虑的解决办法就是端到端的拥塞控制，端到端多路径打散大象流，同时去除去多轨道和双平面转发。

四、CIPU 计算体系结构实质

CIPU、CPU、GPU 的差别，总结了以下三点：

1、安全。上文我们讲到云要求极致的安全，比如数据端到端加密，IaaS 安全需求催生数据 inline 处理。安全容器到今天既保持容器的接口，又有虚拟机的安全。弹性裸金属，数据 inline 的安全处理事实上都是安全需求驱动的。

2、加速数据。CPU 是通用计算，GPU 是加速计算，CIPU 是加速数据。什么是加速数据？CDN、存算分离下机头缓存、CIPU 芯片和系统中的数据和控制分离，到处理器内部的 L1/L2/LLC 缓存体系，到冯诺依曼内存墙，到存内计算。这些技术的全部实质是：数据是有重力的，搬运和移动数据的成本极大。CIPU 数据加速的目的，就是通过 CIPU 芯片的数据控制分离，减少数据在 CIPU 的移动（比如减少数据的 offchip 等），来提升处理吞吐和降低业务平均时延和长尾时延

3、IaaS 池化。云支持弹性多租，它是 composable and disaggregated Infrastructure。CIPU 是高性能池化的中心节点，所有计算、网络、存储节点都围绕 CIPU 做池化。

CIPU 在计算机体系结构中只有这三个定位。CIPU 绝对不是做算力加速和卸载，不是与 GPU 抢生意，不是做所谓的旁路卸载。CIPU 是做加速数据，如今的算力是富裕的，我们定义算力就是峰值算力，就是 data 命中 L1 Cache 之后的 CPU 算力。同时 GPU 的算力极度富裕，GPU 的问题是内存墙问题，功耗问题和通信墙问题。所以算力是不需要任何加速的。CIPU 是同时完成安全容器和基础设施池化的关键业务支撑。

五、CIPU 和 DPU/IPU 的关系

CPU 处理数据，GPU 也是处理数据的，TPU 也是处理数据的，FPGA 也是处理数据的，DSP 也是处理数据的，是不是所有处理数字信号和处理数据的芯片，都应该叫 DPU(data processing unit)呢？除了处理模拟信号，比如通信用的视频处理的，只要是数字芯片，它都可以叫 DPU。

那么 DPU 这个名字是不是取的太大，太通用了，是否需要业界更进一步精确的定义？其实取名是极度重要的，因为科学和工程的第一步是做分类，分类的第一步就是命名，命名的原则是越小越好，这个名字覆盖的内容越少，说明想的越清楚。即一定要回答做什么，不做什么，这是最重要的。所以 DPU 这个名字，我认为业界需要做精确的探讨，什么是 DPU，如果定位是数据，我确实认为有值得商榷的地方。

IPU，在我们的视角，IPU 比 DPU 定义的好一些，因为它名字小，Intel 叫它 Infrastructure Processing Unit, 这是比 DPU 小的名字，但凡是小的名字，我就认为是好名字。但是为什么我们没有沿用英特尔的 IPU 这个名字，因为我们认为 IPU 只要脱离云的弹性多租上下文，便不是是刚需。也就是说 DPU、IPU、 CIPU 如果不是做云的弹性多租，我们认为它就是废铜烂铁。在这种情况下，我们就定了这么一个名字。我们希望后续 DPU 会有精准的定义。