算力就是企业的生命线。然而当我们兴高采烈地采购回昂贵的GPU服务器，准备大干一场时现实却往往给我们泼了一盆冷水。你有没有发现，那些动辄几万甚至几十万一块的GPU卡，hen多时候并没有像我们预期的那样满负荷运转？受限于业务模型的特性、SLA的严苛要求，GPU的利用率常常低得让人心疼。硬件算力被严重浪费，这不仅是成本账本上的刺眼数字，geng是技术架构师心中的痛。

为了解决这个痛点，GPU隔离技术应运而生。简单来说我们希望Neng在同一张显卡上“塞”进geng多的任务，让它们既Neng共享算力，又互不干扰。但这事儿说起来容易，Zuo起来却充满了坑。今天我们就来扒一扒GPU隔离技术到底该怎么玩，从NVIDIA的官方方案到各大厂的“黑科技”，kankan我们是如何一步步把这块硬骨头啃下来的。

在深入技术细节之前，我们先得明白一个核心逻辑：要在单个GPU上跑混多个任务，无非就是从两个维度下手——空间和时间。

想象一下GPU就像一个巨大的工厂车间。Ru果车间里只有一条生产线在运作，那肯定是hen浪费的。所谓的空间维度切分，就像是把车间隔成几个小房间，每个房间独立运作；而时间维度切分，则是让不同的任务轮流使用这条生产线，你干一会，我干一会。

但是这两种方案各有各的难处。在空间上，一次调度上GPU运行的任务，往往体型不一，hen难把车间的面积填满，这就导致了资源饱和度不高。而在时间上，多个任务交替运行，中间必然存在切换和等待的开销。这就好比换班的时候要停机整理一样，这种损耗对于延迟敏感的高优业务来说是不可接受的。为了保障SLA，以前我们只Neng让这些“大客户”独占GPU，结果就是利用率极其低下。

说到空间切分，NVIDIA从A100系列开始引入了MIG技术。这玩意儿听起来hen美好，它Neng在硬件层面把一张GPU切成好几个独立的实例，每个实例dou有自己的显存和计算核心，隔离性Zuo得那是相当好。

但是且慢高兴。这项技术有个让人头疼的门槛：它并非所有型号dou支持，通常只出现在那些高端昂贵的GPU上。而且，MIGZui多只Neng支持7个独立实例，这在需要geng多微隔离的场景下就显得捉襟见肘了。geng要命的是这种切分是静态的。一旦你把资源分给了某个任务，就像把地砌成了墙，运行时想改dou改不了灵活性极差。

除了MIG，NVIDIA还提供了MPS。它的思路是把多个任务的CUDA Context整合到一个Context里让大家共享GPU算力和显存。这确实Neng提升利用率，但就像几个人合租一套房子，虽然热闹，但风险也大。Ru果其中一个任务“挂”了可Neng会导致整个Context崩溃，这就是所谓的故障传播问题。再加上CUDA内部hen多逻辑是不透明的，出了故障想诊断dou难，这就像是在黑盒子里走夜路。

既然空间切分有这么多限制，大家自然把目光投向了时间维度。也就是我们常说的时分复用。在这个领域，业界的探索主要分为两派：一派是在用户态搞事情，另一派则是深入内核态。

早期的方案，比如腾讯的GaiaGPU，采用的是CUDA劫持。这发生在CUDA Runtime和CUDA Driver之间。简单说就是拦截一下API调用，kankan这次发射的内核会不会让GPU“过载”。Ru果会，就推迟一下等GPU闲下来再说。

这招虽然简单，但问题不少。算力消耗缺乏反馈机制，只Neng靠轮询去猜，既浪费资源又不准。一旦任务下发去了GPU，我们就失去了控制权，hen容易超算力配额，误差hen大。

为了geng精准地控制，大家开始把拦截点下沉到内核层。也就是在CUDA Driver API和NVIDIA Driver之间动手脚。不管是腾讯的qGPU、阿里的cGPU，还是百度的方案，本质上dou是这个路子。

这种方案虽然比用户态劫持好一些，但依然面临挑战。因为CUDA和GPU的交互本质上是个黑盒，我们只Neng去修正一些关键参数。一旦NVIDIA驱动geng新版本，这些交互逻辑可Neng会变，我们的拦截代码就可Neng失效，维护起来简直是噩梦。

面对这些困境，我们分析了B站自身的业务场景，发现具备弹性Neng力的时分方案才是Zui合适的。但是官方不提供，劫持方案又不稳，难道就没辙了吗？转机出现在NVIDIA驱动开源之后。通过分析开源的驱动代码，结合GPU运行原理，我们找到了一条新路——Bilibili GPU Manager。

我们的思路hen直接：既然API劫持不靠谱，那就直接在驱动层Zuo文章。通过引入BGM内核模块，联动Linux的Cgroup子系统和显卡驱动，实现真正的算力和显存隔离。

要理解BGM怎么工作，得先搞清楚GPU内部是怎么调度的。从驱动的角度kan，为了提交计算或数据拷贝请求，每个程序dou会创建一个或多个通道。这些通道会被组织成TSG。同一个TSG里的通道共享相同的GPU上下文。

GPU内部由多个功Neng单元组成，驱动里叫Engine，比如计算引擎、拷贝引擎等。每个Enginedou会绑定到一个runlist上。GPU Host会像个交通指挥官一样，读取runlist，找到待处理的命令，然后按照时间片轮转的方式摘取一个TSG，再从TSG里选个通道，调度到特定的Engine上运行。

在A10机器上，我们通过trace发现，一个常见的CUDA程序默认会创建16个channels，3个TSG和3个runlist。其中8个计算通道归到一个TSG，用Compute/Graphics Engine；另外8个拷贝通道分给两个TSG，对应两种COPY Engine。

显存是GPUZui宝贵的资源之一。BGM是怎么Zuo到显存隔离的呢？其实有点像“骗”驱动。

具体步骤是这样的：用户通过cgroup接口配置一个显存上限limit。当驱动去获取设备可用显存总量时BGM会介入，调用限制API，把这个limit成总量告诉驱动。这样，驱动就以为显卡只有这么点内存了。

而在驱动分配显存时BGM也会实时统计Yi用的量。当有新请求来时驱动会判断剩余显存left够不够。Ru果不够，直接报NO MEMORY。通过这种方式，我们既实现了显存隔离，又Neng通过cgroup统计显存使用情况，一举两得。

显存搞定了接下来是geng难的算力隔离。BGM的设计原理框图里核心在于控制TSG的时间片。

默认情况下runlist里的每个TSGdou有一个默认执行时间，比如2ms。这意味着，一个任务要么跑完2ms，要么提前跑完，才会切换到下一个任务。Ru果GPU上混部了好多业务，那高优任务等待的时间就会hen长，严重影响性Neng。

BGM的Zuo法是：用户通过cgroup配置算力slice。当CUDA程序运行时驱动调用方法设置TSG时间片，BGM就会介入，用用户配置的slice替换掉默认的时间片。

这有什么用呢？假设我们有三个任务APP0、APP1、APP2。Ru果不隔离，大家轮流跑2ms，APP0跑完得等4ms才Neng轮到下一次。但Ru果我们把时间片改成1ms，APP0等待的时间就减半了。

geng绝的是我们Ke以不均分算力。比如给APP04ms的时间片，给APP1和APP21ms。这样，APP0一次Neng跑geng久，既减少了切换损耗，又Nenggeng快完成任务，而低优任务虽然分到的少，但也Neng分到算力，不至于饿死。这就是通过隔离手段，达到切分算力和保障高优的目标。

理论说得再好听，还得过过实战的检验。我们在A10卡上，针对TensorFlow的ResNet50模型Zuo了benchmark测试，对比了不同batchsize下的表现。

我们配置了2个不同算力的pods进行混跑，结果显示吞吐比在不同batchsize下基本dou在理论值3附近。又配置了4个不同算力的pods混跑，表现也和算力配置基本一致。

这说明，我们的方案在保障高优任务性Neng的同时确实有效地实现了算力的灵活切分。虽然Bilibili GPU Manager本质上还是时分复用，高优任务对离线业务的抢占受限于物理极限，但通过在内核层的精细控制，以及在用户态调度策略上的配合，我们Yi经Zuo到了非常细致的隔离效果。

通过这项隔离技术，我们终于在GPU混部中Zuo到了geng可控、geng灵活。当然技术探索永无止境。CUDA内部的某些逻辑至今仍像迷雾一样不透明，文中阐述不当之处，还请各位业界专家不吝赐教，多多指正。

随着NVIDIA驱动的进一步开放，未来我们还Ke以榨干每一滴性Neng，dou是我们技术人不变的追求。请大家继续关注我们的进展，一起在GPU优化的道路上走得geng远~~