大模型与AI底层技术揭秘（27）食神挑战烤肥肠

小H最近因为沉迷学（you）习（xi），瘦了不少，小伙伴们打算把小H带去搞点好吃的。

大家来到一家卖烤羊腿和肥肠的食肆，虽然人有点多，但老板娘热情地招呼，告诉大家里面有包间，刚好能坐下6个人。于是，小H和小伙伴们就到了包间落座。虽然包间看起来很简单，就是用屏风隔开的，但也比大厅强。这样的小包间还有很多个，看起来都是相互独立的。

吃了一会儿，大家听到外面吵起来了：

“碱水面没有过冷水，所以面里面全是碱水味，鱼丸也没有鱼味，但是你为了掩饰特意加上咖喱汁，想把它做成咖喱鱼丸，但这么做Too simple, sometimes naive！好好的一颗咖喱鱼丸，让你做得是既没有鱼味又没有咖喱味，失败！萝卜没挑过，筋太多，失败！猪皮煮得太烂，失败！猪血一夹就散，失败中的失败！最惨的就是肥肠，里面根本没洗干净，还有一坨……”

“你以为这里是你们香港啊？我们北方人吃肥肠就讲究不洗干净，洗干净没味道！滚！”老板娘指着来踢馆的人骂。

此时，外面有人因为喝多了，并且听了老板娘说的，开始吐（Core Dump）。

小H和小伙伴们看着桌上的一盘吃了一半的烤肥肠，腹中百转千回，然后也有人吐了。大家趁乱走了，钱也没付。

方老师听到小H讲的这个故事，先去笑了一会儿，然后问小H：

上期学的NVidia vCUDA GPU虚拟化，你记住了吗？这个方案有啥缺陷呢？

小H想了想，总结了一下：vCUDA是替换掉虚拟机上的CUDA，让它去找宿主机上的vCUDA Stub，然后调用宿主机上GPU计算的方案。如果使用其他的API库，就没有办法在虚拟机上用GPU了。

小H突然想到，如果GPU可以支持SRIOV技术，把PF虚拟化为多个VF并且直通给虚拟机，是不是就可以让多个虚拟机共享GPU的算力了呢？

实际上，NVidia在GPU领域的竞争对手AMD（收购ATI的GPU），就使用了基于SRIOV的GPU虚拟化方案。

如图，AMD的GPU本身为PCI-E SRIOV的PF（Physical Function），而每个虚拟化实例为一个VF（Virtual Function），并直通给一个VM。

GPU的VF直通给VM的方式，和我们在前几期中学习过的，物理设备直通给VM实际上并没有实质的差异，GuestOS看到的是经过Hypervisor调用IOMMU，进行映射后的配置空间、Virtual BAR和DMA地址，CPU上的IOMMU和MMU会将地址翻译为物理地址，也就是让虚拟机能够操纵真实的硬件。同时，VF产生的MSI中断也可以由vAPIC送给虚拟机进行处理。

VM能够访问GPU后，就可以使用原生的CUDA APP和GPU驱动来访问VF设备，提交计算任务并在GPU中计算完成。

但是，SRIOV方式实现的GPU虚拟化有一个严重的缺陷：只提供对虚拟机可见的多个设备，无法实现内部资源的隔离。也就是说，任何一个VM的CUDA程序越界访问GPU内存，会导致其他VM的CUDA应用被异常终止！

小H想到了昨天晚上在饭店遇到的情景，虽然表面上自己在独立的包间用餐，但实际上并没有真正实现物理隔离。其他食客的异常操作（Core dump）导致了小H和小伙伴们的用餐任务异常终止（也有人Core dump了）。

看来，基于SRIOV的GPU虚拟化并不是一个好的方案。

那么，为什么网卡的SRIOV虚拟化在NFV场景能够得到广泛的应用呢？

这是因为，网卡实际上是一个无状态（stateless）的。网卡本身不承担计算任务，数据包的收发、关键字段的提取计算和收到的数据包分发到目标队列，实际上都是硬件定义的原子操作，不会被软件程序所打断。因此，网卡的SRIOV实现实际上只是把一定数目的收发队列分配给VF。

但是GPU的复杂度远超网卡。它是一个有状态（stateful）的。GPU内部有各种计算单元、缓存和RAM控制器，这些部件的状态是由GPU计算指令来决定的。实际上，GPU可以认为是一个高度并行，图灵完备的向量计算机。在这样的一个复杂的硬件中，实现硬件级别的虚拟化隔离，其难度甚至超过Intel在x86中引入VT-X系列特性！

因此，即使是在硬件虚拟化技术方面有深厚积累的Intel，在其GPU虚拟化路线上，也没有采用SR-IOV，而是使用了其他的方案。

请看下期。