云原生GPU资源池化实战：K8s显存切分与调度器扩展-北京尧图网络

1. 为什么需要自建GPU资源池化很多人一开始接触GPU集群第一反应就是“容器里挂GPU嘛nvidia-docker插上不就行了”。真到了生产环境你会发现这套想法在早期小团队里还行一旦规模铺到几百张卡、几十个项目组同时跑训练和推理事情完全不是那么回事。我在某大型互联网公司的AI中台团队做过一版GPU资源池化改造当时面临的核心问题非常典型各项目组的训练任务抢着独占整张卡但A100跑个小模型时显存利用率经常只有20%到30%推理服务为了高可用还会在每张卡上冗余部署好几份高峰期一过大量算力直接睡大觉。与此同时新来的项目申请GPU走流程要好几周因为卡被“名义上分配”出去了实际没人用也拿不回来。说白了就是资源卡在物理边界里谁也分不出去、调不动、借不走。云原生GPU资源池化要做的就是把“一张物理GPU卡”这种粗粒度分配方式拆成“算力池”这种可以按需切分、弹性伸缩、跨节点调度的细粒度资源视图。落地的形式就是容器化部署K8s集群作为统一调度面GPU通过设备插件和自定义调度策略接入集群暴露成可分配、可限额、可监控的池化资源。整个项目涉及三大块驱动虚拟化层怎么做、K8s侧的资源模型怎么扩展、调度与配额策略怎么设计。这篇文章不聊PPT上的架构图直接把我们在生产环境里真正落地的一套方案、踩过的坑、调过的参数都梳理出来。适合正在做GPU集群管理、想提高卡利用率的基础设施工程师也适合被老板要求做“算力中台”但又不知道从哪里下手的团队参考。2. 资源池化的核心设计思路与关键决策2.1 资源切分的三种主流路径怎么选要做GPU资源池化第一步绕不开的就是“怎么把一张物理卡切成多个逻辑卡”。这里我对比了三种主流路径各有各的适用场景。第一种是NVIDIA官方提供的MIGMulti-Instance GPU方案。A100和H系列支持把一张物理卡按显存和计算核心切成多个实例每个实例拥有独立的显存带宽、L2缓存和计算分区硬件隔离性最好。比如A100 80G可以切成7个1g.10gb的实例或者3个混合大小实例。优点是无需额外开发官方驱动直接支持缺点是只有特定型号支持显存切分的粒度和数量规则固定灵活性天然受限。例如我想把一个GPU切出2GB给一个小模型MIG根本做不到。第二种是vGPU虚拟化也就是在驱动层做显存和算力的逻辑划分。用户态进程看到的是一张“虚拟GPU”实际物理卡由驱动统一调度。这种方式切分粒度高可以做到1/8、1/16这样细的显存配额而且不限制必须用什么型号的卡。缺点是每个容器里跑的是经过虚拟化层接管的CUDA环境部分GPU特性比如某些NVLink通信、GPU Direct兼容性需要验证多用户相互干扰的场景还需要额外的算力限制策略。第三种是纯软件层的“显存隔离调度穿透”本质上就是用NVIDIA的MPSMulti-Process Service或者自研的代理层来限制进程访问显存的范围。我们最终采用的是“vGPU逻辑切分为主、MPS算力限制为辅”的组合方案原因很简单生产环境里既有大模型训练吃显存和算力都很猛又有大量小规模推理服务只需要一小段显存但要求快速启停单靠任何一种方案都有明显的盲区。2.2 资源抽象与上层的配额模型物理层的切分解决“能切成什么”上层的资源模型解决“切成的东西怎么被认知和分配”。在K8s原生的资源模型里GPU通常通过nvidia.com/gpu这个扩展资源暴露但它只能表示“整卡数量”无法表达显存大小、算力份额、卡型号差异这些信息。面对异构卡池我们有A100、H800、还有少量RTX 3090兜底只传一个整数根本没法用。我们的做法是自定义了一组CRD核心是GPU池对象和租户配额对象。GPU池对象描述一组同型号物理卡包含卡型号、总显存、切分粒度、可分配模式租户配额对象则描述某个部门或项目组可以申请的资源上限包括总显存配额、最大卡数、优先级、借用权限。底层K8s继续用扩展资源管理物理设备上层业务在申请时指定的是“显存大小和型号偏好”由自研调度器完成从虚拟请求到物理资源的映射。比如一个搜索团队想跑个线上推理服务申请12GB显存调度器会扫描当前所有节点的剩余显存找一个碎片足够放下12GB的物理卡把这张卡上的一段显存区间标记给这个容器。容器看到的是一整张逻辑卡实际上它在物理卡上和别的容器共享。这个过程对业务方透明他们不需要知道自己在哪个节点上和谁共用一张卡。这套抽象模式解决了几个关键痛点异构卡被统一建模业务不用关心底层具体型号显存按需分配不再是整卡的粗粒度交付配额可量化、可审计谁占了多少资源一目了然。3. 容器化部署全流程从驱动到调度器的落地细节3.1 GPU节点的初始化与底层环境准备容器化部署的第一步是把GPU节点干净地接入K8s集群。这一步看起来轻巧实际上最容易埋坑。我们需要统一节点镜像中的驱动版本、CUDA运行时、容器运行时配置。节点初始化执行的关键操作包括安装和宿主机内核匹配的NVIDIA驱动这里强调一下我们在生产中锁定驱动版本号为535系列并统一所有节点的CUDA版本为12.2避免不同业务镜像依赖不同CUDA版本导致的兼容性地狱。配置NVIDIA Container Toolkit让容器运行时能识别GPU设备。需要修改/etc/docker/daemon.json或者containerd的配置文件把nvidia-container-runtime挂为默认运行时。加载所需的NVIDIA内核模块比如nvidia_uvm并且在系统层面配置NVIDIA_REQUIRE_CUDA环境变量。容器运行时的配置里有一个极其容易忽略的参数默认的运行时参数。如果你用containerd需要在配置里加[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.nvidia] privileged_without_host false runtime_engine runtime_root runtime_type io.containerd.runc.v2 runtime_path /usr/bin/nvidia-container-runtime不加这段K8s调度GPU资源的时候会遇到Failed to create container sandbox或者unknown runtime nvidia之类的报错排查起来非常烦人。后来我们干脆用Ansible写了一整个节点初始化角色从驱动到运行时到节点标签一气呵成再没手工操作过。3.2 Device Plugin部署资源上报的细节与版本坑底层环境就绪后需要部署NVIDIA官方Device Plugin让K8s感知GPU资源。一般直接用DaemonSet方式部署它会自动在每个GPU节点上启动并把节点上的GPU数量作为扩展资源上报给Kubelet。这里有几个关键参数需要根据我们自己的切分模式来定制--resource-name必须和后面的调度策略一致我们直接沿用nvidia.com/gpu方便社区生态兼容--mig-strategy如果用的是MIG模式需要设置为mixed或single但我们走的是vGPU逻辑切分所以这个参数不生效用的是默认--fail-on-init-error建议设为true否则驱动加载异常的节点会被标记为可用但实际上调度不了任务害得任务无限Pending。Device Plugin在节点上的资源上报逻辑是每个GPU对应一个设备IDkubelet把这些设备以扩展资源的形式注册到API Server。我们部署完成后验证时发现一个典型问题每个节点上报的GPU数量是物理卡数但我们希望K8s看到的其实是“可切分的显存数”。Device Plugin做不到这一点它的单位就是“张”。所以我们在架构中加了一层Device Plugin负责发现物理设备真正的细粒度资源上报由我们自研的虚拟GPU Agent来做。这个Agent运行在每个节点上通过访问nvidia-smi获取每张卡的显存总量和已分配显存把自己节点的总资源换算成“可分配显存池”上报为一个自定义扩展资源比如ai.gpu-mem.gb。调度器真正参考的是这个细粒度资源数量当容器请求12GB时它分配的是12个单位的ai.gpu-mem.gb而Device Plugin保证物理GPU能被可靠挂载。3.3 调度器的扩展从请求到物理卡的映射K8s默认调度器只知道节点上有几张卡不知道显存碎片在哪里更不知道怎么把一个容器塞到一张卡的特定显存区间里。应对方案是写了一个Scheduler Extender挂载到默认调度器的filter和bind阶段旁边。Filter阶段的逻辑比较简单遍历所有节点根据每个节点当前的显存池余量、卡型号偏好、优先级筛出能容纳请求的候选节点。实际操作中还要检查一个关键条件——目标节点上是否存在“同一张物理卡内剩余显存 ≥ 请求显存”。这个条件决定了容器能否在单卡内完全放置还是需要跨卡占多个GPUID。我们的策略是优先单卡放置因为跨卡要消耗NVLink或PCIe带宽而且会引入额外的故障域。我举个例子说明映射过程。假设节点A物理上有4张A100每张80GB显存其中两张各自已经占用了30GB剩下50GB另外两张完全空闲。这时一个请求60GB的任务来了过滤逻辑会发现四张卡里没有任何一张的剩余显存 ≥ 60GB节点A被直接刷掉。调度器不会选择在这个节点上分配两个30GB的区间凑出60GB因为那样容器需要同时挂载两张物理卡通信开销和故障概率都不划算。Bind阶段做的事情是把调度决策写回K8s的Pod对象上。我们在Pod上追加一组Annotation标明这个Pod被分配的具体卡型号、物理卡ID、显存起始偏移和大小。业务容器启动时我们有一个瘦身版的CUDA拦截层会读取这些Annotation在进程内建立显存空间的映射关系确保业务进程只能操作自己分配到的显存区间。3.4 自定义CRD控制器配额与分池的逻辑闭环调度器解决的是“一次请求怎么分配”配额和归还的管理需要一个控制器来持续运作。我们定义了一个叫GpuLease的CRD每个租户的每次申请创建一条Lease记录字段包括租户标识、资源规格、起始时间、到期时间、优先级、状态。控制器维护的核心循环是这样的当业务方提交一个Pod调度器查一下该租户当前的Lease总量是否超过配额。超过就直接挂起排队等待。Pod跑起来后控制器根据调度器写入的Annotation更新对应Lease的已用字段。Pod结束或删除时控制器收到事件释放显存区间并把资源归还节点池。到期未续租的Lease控制器自动回收对应的Pod触发驱逐迁移。实际做的时候发现控制器要想稳定必须处理大量边界场景。例如节点宕机会导致该节点上的所有Lease失联但这些Lease在K8s里的状态还可能是Running。我们在控制器里加了一个NodeHealth监听器节点失联超过3分钟就触发Lease的强制回收并由调度器在其他节点上进行重调度。配额借用功能是另一个业务价值点。有的项目组季度末突然要跑一批评测配额不够但又不想走冗长的审批流程。我们的系统支持配额借用低优先级的租户可以借出自己的闲置配额给高优先级租户借出方保留随时回收的权利借用方在回收事件到达时需要优雅退出当前Pod。这个机制在内部落地的效果出乎意料地好资源利用率提升了大约17个百分点而且因为回收事件可以强制触发低优先级租户的“借出去收不回来”的顾虑基本被消除了。4. 实操过程与关键环节实现4.1 GPU节点的池化注册流程一步步照着做下面我把我们团队在新增一个GPU节点时执行的完整注册流程写出来照着这个走基本一次就能通过。第一步节点初始化。部署操作系统后安装内核头文件和编译工具链因为NVIDIA驱动需要针对当前内核版本编译模块。执行uname -r确认内核版本然后安装对应版本的kernel-devel包。第二步安装驱动。建议直接用NVIDIA官方runfile安装不要用发行版自带的驱动包后者经常出现版本被锁死、升级内核后驱动失效的问题。安装时加上--no-opengl-files避免和桌面环境冲突--silent模式方便脚本化。装完后运行nvidia-smi确认驱动识别这一步最常见的问题是“No devices were found”八成是内核模块没加载成功排查dmesg | grep nvidia。第三步安装NVIDIA Container Toolkit。官方提供了apt源直接安装nvidia-container-toolkit然后根据你用的容器运行时执行相应的配置命令。我们用的containerd执行sudo nvidia-ctk runtime configure --runtimecontainerd sudo systemctl restart containerd这一步做完可以用ctr run --rm --runc-binary nvidia-container-runtime测试一个CUDA容器是否能正常启动。测试镜像用nvidia/cuda:12.2.0-base-ubuntu22.04跑nvidia-smi看是否能识别GPU。第四步部署Device Plugin。K8s官方提供的DaemonSet YAML可以直接用但注意把镜像版本对齐你集群的K8s版本。我们集群是1.26用的Device Plugin版本是0.14.0。部署之后检查每个GPU节点的kubectl describe node看到nvidia.com/gpu资源以及对应的可分配数量说明插件上报正常。第五步部署我们的虚拟GPU Agent。它启动时会扫描节点上的所有物理GPU初始化显存池状态并通过节点标签上报可用的显存池总量。比如一张A100 80G的卡Agent上报的ai.gpu-mem.gb是72预留了约10%给系统使用和碎片整理。这一步完成之后节点就正式成为资源池的一部分可以接收业务请求了。4.2 容器请求GPU资源的方式与调度生效过程业务方使用新平台很简单他只需要在Deployment的resources里有如下声明resources: limits: ai.gpu-mem.gb: 12 nvidia.com/gpu: 1调度器看到这个请求后会先检查租户配额剩余量然后按Filter逻辑找目标节点再给Pod写上我们自定义的Annotation。这里有一个非常关键的设计点——我们在调度阶段就会把显存映射关系算好而不是等容器启动之后再去探测。调度器在Bind前会读取节点Agent上报的显存分配位图从里面挑一个合适的显存区间把区间元数据写进Annotation。容器运行时启动时我们的CUDA拦截层会拦截cuInit和显存分配调用把业务进程的内存分配引导到Annotation指定的显存区间内。对于业务方来说他以为自己在用一块独立的12GB GPU实际上是和别的容器共享一张物理卡。这种透明替换的好处是业务代码完全不用改坏处是一旦有问题比如某个显存越界排查起来非常考验底层功底。调度生效的验证方式我们一般看三个信号Pod被调度到正确节点容器内执行nvidia-smi看到的是被拦截后的显存视图宿主机的nvidia-smi能看到多个进程在共享一张卡的显存。4.3 配额管理的配置示例与权限设计配额管理的操作界面我们做在内部运维平台上但底层CRD配置是可以直接写YAML的。举个例子假设某项目组申请了一个月2TB总显存时长、最多同时占用400GB显存的配额对应的CRD这样写apiVersion: ai.example.io/v1 kind: GpuQuota metadata: name: search-nlp-quota namespace: ai-platform spec: tenant: project-search-nlp maxConcurrentMemGB: 400 maxTotalGBHours: 2000 maxConcurrentPods: 120 priority: production borrowPolicy: canBorrow: true maxBorrowGB: 100这段配置定义的是租户的“资源上限”。调度器做配额校验的时候会读取当前租户所有活跃Lease的总和和这里配置的上限做比较。如果申请超量Pod会进入Pending状态并且不会触发默认的K8s重调度而是由我们的队列控制器统一管理按优先级和申请时间排队。权限设计上我们把“谁能申请多少资源”和“谁能批准配额调整”分成两级。项目组的技术负责人只能查看自己的配额和申请Lease没有权限修改配额大小配额调整走平台审批流。这套权限模型的好处是资源治理有据可查避免“谁和平台关系好谁就能多拿卡”的暗箱操作。4.4 监控体系与资源可视化的落地情况GPU资源池化之后监控体系和物理GPU时代完全不同。以前看每张卡的利用率就行现在要看的是显存池的碎片率、租户的真实使用率、单卡多容器的相互干扰度。我们基于Prometheus做了一套四维监控第一维是物理层采集每张卡的GPU利用率、显存总量、温度、功耗。第二维是逻辑层采集每个Lease对应的容器实际用掉的显存和算力这个最能反映资源是否被浪费。第三维是配额层看每个租户的配额使用率、排队时长、借用情况。第四维是调度层记录每次调度决策的耗时、失败原因、各节点的碎片情况。实际操作中有一个指标特别有价值显存碎片率。我们定义成“物理卡剩余不可分配的显存大小占这张卡总显存的比例”。碎片率超过30%的卡需要管理员介入进行Lending回收或迁移腾挪。调度器在做Filter时会倾向于选择碎片率更低的节点减少资源碎片长期积压。可视化页面我们用Grafana搭了两个大屏一个给运维看展示节点健康度、每张卡的分配和实际使用对比一个给业务方看展示自己项目的配额用量、任务排队时长和资源趋势。业务方能直观看到自己占了资源但没用满的数据内部协调资源时就不再靠扯皮了。5. 常见问题与排查技巧实录5.1 容器启动报CUDA Error: Unknown Error这个是我们上线初期遇到最多的一个问题。容器启动后进程一调用CUDA就报CUDA Error: Unknown Error但宿主机上nvidia-smi是完全正常的。排查过程很有代表性。先看容器内的nvidia-smi是否能执行发现能执行且能看到GPU信息但调用CUDA API就崩。怀疑是CUDA版本问题换了好几个基础镜像还是不行。最后用dmesg看内核日志发现是nvidia-uvm模块没有加载而CUDA运行时依赖这个模块做统一内存管理。解决办法是确保nvidia-uvm模块在节点启动时加载。我们在节点初始化脚本里加入echo nvidia-uvm /etc/modules-load.d/nvidia.conf modprobe nvidia-uvm并且检查了/dev/nvidia-uvm设备节点是否存在。如果不存在需要手动创建或者重启一次容器运行时服务让它自动创建。这个问题产生的根源是部分节点镜像用云厂商自带的驱动包这些包在初始化时并不会自动加载uvm模块。5.2 调度器把Pod调度到节点后容器一直ContainerCreating这种现象多半和虚拟GPU Agent的上报状态不一致有关。比如调度器通过Filter阶段选出了节点A但容器尝试启动时节点A的显存池刚刚被另一个高优任务抢占实际可用显存低于调度器当时看到的。我们设计了双保险来避免这个问题调度器在Bind之前会再次调用节点Agent的“原子预留”接口如果预留失败就直接换节点不留脏数据Agent每30秒向调度器同步最新的显存位图在极端情况下即使有短暂不一致Agent也会在收到启动请求时做二次校验发现显存不足时返回明确的错误码Pod立即重调度而不是卡死。另外检查一下Device Plugin和虚拟GPU Agent的版本是否对齐也很重要。有一次我们升级了Agent但Device Plugin还停在旧版本导致设备分配和显存分配的ID错位容器起来看到的GPU设备和调度器记录的设备不一致直接导致探活失败。5.3 显存碎片严重新任务调度失败率居高不下运行了大概两个月后我们发现有部分节点的显存碎片率飙升到40%以上。原因是小容器的生命周期短频繁启停导致物理卡上的显存区间被切成无数小块而新来的大请求在单卡上找不到连续的显存空间。解决思路分两层。调度层面的策略是优先使用“剩余容量足够但碎片率低”的节点让大请求落到相对完整的卡上小请求才用碎片卡。运维层面我们加了一个定期整理的机制当某张卡的碎片率超过阈值时将该卡上的所有Lease标记为“可迁移”调度器在后续滚动更新时把Lease迁到其他节点空出来的卡重置显存池。执行一次整理操作需要谨慎不能直接kill业务容器。我们是通过把节点标记为unschedulable停止新调度然后按照Lease的优先级从低到高逐批迁移。迁移之前会通知业务方预留缓冲时间对无法优雅退出的任务采用强制驱逐但保留数据快照的策略。这套流程上线后碎片率基本稳定在10%以内。5.4 多租户互相干扰GPU算力被抢占导致推理超时显存隔离做得再好算力抢占有时候更致命。一个线上的A100节点上一半跑训练任务一半跑推理服务训练任务把GPU的SM都占满了推理服务的P99延迟从30ms飙到400ms线上告警直接被打爆。解决方案是在vGPU逻辑切分的基础上叠加了MPS的算力控制。每个容器在启动时通过环境变量指定算力份额比如CUDA_MPS_PIPE_DIRECTORY/tmp/mps-uuid和CUDA_MPS_ACTIVE_THREAD_PERCENTAGE30。MPS会根据这个百分比限制进程的并发计算线程数粗粒度地控制算力占用。效果还算理想推理服务的P99延迟能回到80ms以内训练任务的吞吐因此损失了大约10%但这是合理的代价。需要注意MPS方案对多进程并行计算的限制比较明显如果业务方用PyTorch的DataLoader多进程模式ACTIVE_THREAD_PERCENTAGE的语义会变得复杂。我们在生产上建议训练任务不用MPS限制只对推理任务启用并且MPS限制配置从节点级别的ConfigMap读取运维可以动态调整。5.5 节点宕机后的Lease悬挂与恢复流程节点物理宕机是不可避免的。默认情况下K8s会等tolerationSeconds结束后把Pod标记为Failed但我们的GpuLease资源记录的显存分配并不会自动释放导致这部分显存在资源池里凭空消失。我们在控制器里增加了一个节点失联处理逻辑节点心跳超过90秒触发Lease的故障标记超过180秒如果节点仍未恢复直接将Lease状态置为Lost释放对应的显存区间允许同等规格的新Lease在其他节点创建。同时控制器会尝试寻找该节点上有持久化存储的任务的副本数据确保重调度后的任务能恢复到最近一次checkpoint。这套设计的取舍点在于对于没有做分布式存储的临时训练任务节点宕机直接导致任务失败这是物理故障的客观代价无法完全避免只能靠任务方自己的容错机制来兜底。6. 一些心里话与实践建议整套GPU资源池化架构从设计到落地前后花了大概四个多月中间推翻过一次方案。最初我们想直接依赖社区的开源虚拟化方案省事但后来发现它没法满足多租户配额和显存区间映射的需求后期改造的成本远远大于自研Agent的成本。这个决策给我的教训是方案选型不能只看能完成多少功能更要看你想做的资源治理模型是否和底层实现匹配。另外一点很重要的是做资源池化不仅是技术项目更是组织协调问题。GPU资源从独占变成共享之后必然有人受益有人觉得被动了奶酪。我们当时花了大力气做资源可视化让每个业务方都能看到自己的使用曲线、排队情况和别人的借用情况配合成本账单的数据业务方自己就会优化资源申请策略。数据透明是推动资源治理最有效的杠杆。如果你们团队打算做类似的事情我建议从一个小规模试点开始先拿几台卡、几个非核心业务把流程跑通验证调度策略和Agent的稳定性再逐步扩大到全量节点。一上来就全量改造风险太大出了问题连回滚的机会都没有。这套架构后续我还在持续演进下一步计划是引入GPU拓扑感知调度把显存区间分配和NVLink拓扑结合起来减少多卡任务跨交换机通信的开销。技术方向是清晰的剩余的就是时间问题。希望这篇沉淀能帮正在做类似方向的同行少走几个坑。

云原生GPU资源池化实战：K8s显存切分与调度器扩展

相关推荐

应急响应排查思路与操作清单：从日志分析到Webshell清除

多Agent协作应用：一人公司并行推进多项目的架构与实践

N1小钢炮部署IYUUPlus：打造全自动辅种下载工作站

更多资讯

AI辅助学术论文写作：五步炼金术把灵感炼成SCI/SSCI

从零开发基于微信小程序的校园导航与信息服务系统全指南

开源CLI代码审查工具：基于Git与轻量LLM的自动化Code Review实践

AI重塑上位机系统：从数据采控到智能决策的工程落地指南

传送带模拟

Auto-GDA：用轻量模型实现RAG依据性验证的自动化方案

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？