前阵子帮一个团队梳理GPU集群8卡A100的节点业务方接二连三地申请GPU结果一看监控每张卡利用率长期在10%上下显存只占用了不到10GB。排障的时候发现大部分Pod一申请就是整卡而实际跑推理模型用的显存也就4到6GB。这种场景在K8s云原生环境里太常见了——大家都说GPU不够用但真相往往是GPU不够分。现在云原生里谈GPU早就不只是简单地在YAML里写个nvidia.com/gpu就能糊弄过去的时代了从硬件层MIG切分到软件层显存隔离从Device Plugin到调度策略调整一套完整的GPU虚拟化切分与算力调度链路才是把集群利用率真正跑起来的关键。这篇东西就是我在这类项目里摸爬滚打后的实战笔记适合正在为GPU利用率头疼、想搞懂怎么把一张卡拆给多个任务用的K8s运维和平台开发同学。1. 为什么说GPU不够分比不够用更常见1.1 一个让运维头疼的场景很多团队采购GPU服务器的时候预算都是照着大模型训练的需求去批的等机器到了才发现真正跑在上面的任务千奇百怪有小规模推理服务模型量化完只要2GB显存有数据处理脚本偶尔用一下GPU加速也有测试环境里跑几个Pytorch用例的。这些任务要是都按整卡分配一张40GB的A100瞬间就被四五个小Pod占满了每个Pod只用几GB剩下的显存全在睡觉调度器却认为这张卡已经没有资源。我自己就遇到过更极端的某个团队在K8s里跑一个深度学习训练平台用户提交的作业五花八门但K8s调度器只认nvidia.com/gpu这个计数器一个Pod要1卡就是1卡不管它实际需要多少显存和算力。结果就是集群的GPU平均利用率长期在15%以下排队作业却排到天荒地老。这个问题不解决堆再多的GPU卡也只是让成本黑洞变得更大。1.2 GPU资源调度的几个看不见的浪费如果把GPU资源拆开看真正能被切分的维度其实有三个显存、算力、显存带宽。不同任务的吃法完全不一样显存敏感型推理服务、模型微调主要瓶颈在显存容量算力往往用不满。算力敏感型大规模训练、科学计算每个GPC都在拼命跑但显存可能只用了一半。带宽敏感型多机多卡通信、embedding密集的场景吃的是HBM带宽和NVLink互联带宽。整卡分配的视角根本没办法区分这些差异。所以GPU虚拟化切分要解决的本质上是把一个物理GPU的容量包拆成不同配比的小套餐让每个任务按需取用。这也是后面MIG、时间片、软件层隔离这些方案存在的理由。2. 三条主流切分路线MIG、时间片、软件层拦截选型时我看重什么2.1 MIG硬件切分A100上真正的性能隔离MIGMulti-Instance GPU是NVIDIA在Ampere架构A100/A30之后推出的硬件级切分方案到了Hopper的H100依然保留。它的核心逻辑是把GPU里的GPC图形处理簇和HBM显存控制器拆成多个独立的硬件实例每个实例拥有独立的计算单元、L2缓存切片、显存控制器和显存带宽。拿A100 40GB举例一张卡最多可以切成7个实例常见的Profile包括1g.5gb、2g.10gb、3g.20gb、3g.40gb、7g.40gb等。这些数字的意思是前面是GPC数量后面是显存大小。比如3g.40gb表示3个GPC加上40GB显存——注意这是专门为大模型推理设计的一种怪胎规格GPC少但显存给满。MIG最大的价值是隔离性。一个实例里的任务跑到再疯也不会抢旁边实例的算力和显存带宽这对多租户场景极其关键。代价就是切分粒度比较粗A100最多7个实例而且不同型号支持的Profile差异很大A30只能切出1g.6gb、2g.12gb、4g.24gb这几种。2.2 时间片切分成本最低但隔离性偏弱时间片切分就是NVIDIA Device Plugin里的timeSlicing功能。原理很简单多个Pod共享同一张物理GPUGPU的执行单元按时间片轮转给不同任务使用有点类似操作系统的CPU调度。配置起来也简单给Device Plugin挂一个ConfigMapversion: v1 sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 failRequestsValutation: falsereplicas: 4的意思是每张物理卡模拟出4个虚拟GPU上报给K8s后调度器会认为节点有4倍的GPU数量。failRequestsValutation这个参数值得单独说它默认是true含义是请求的GPU数量必须是replicas的约数比如replicas是4时你申请1、2、4都能过申请3就直接报错。我遇到过团队在这里卡了半天所有Pod都调度失败最后才发现是这个默认校验在起作用。时间片方案的优点是不挑卡消费级显卡也能用缺点是隔离性弱。任务之间没有显存隔离一个Pod把显存吃满同卡的其他Pod直接OOM。算力上也没有硬隔离A任务密集计算时B任务的延迟会明显抖动。它只适合跑一些低优先级、对延迟不敏感的任务。2.3 软件层拦截方案阿里cGPU、腾讯qGPU这类实现软件层切分是另一个方向思路是通过拦截CUDA API调用来控制显存分配和算力使用。阿里云的cGPU、腾讯云的qGPU都属于这一类。这类方案通常在宿主机上装一个内核模块/Agent配合K8s Device Plugin扩展实现显存和算力的细粒度隔离。软件层方案的好处是粒度细可以按MB分配显存、按百分比限制算力还支持超卖坏处是需要额外部署组件而且兼容性要跟着CUDA版本走。如果你用的是云厂商的GPU实例这类方案用起来比较省心如果是自建机房就要评估一下内核模块和驱动版本的适配成本踩坑概率不低。2.4 三种方案对比与选型建议维度MIG硬件切分时间片切分软件层拦截cGPU/qGPU隔离级别硬件级GPC/显存/L2独立无硬隔离共享显存和算力软件级隔离显存算力可限制切分粒度粗A100最多7实例细可配置任意副本数很细显存可按MB、算力按%性能损耗几乎无损耗无显存容量损耗算力有争抢有少量API拦截开销适用卡型A100/A30/H100等数据中心卡几乎所有NVIDIA卡视具体实现通常支持较新的数据中心卡运维复杂度中等需管理实例分配低配置即用较高需关注兼容性我的选型经验是生产环境最优先做MIG它是唯一让我对邻居噪声放心的方案时间片适合测试环境或低优先级批处理软件层方案适合云上环境或对切分粒度要求极细的团队。如果条件受限只能选一个先上MIG。3. 从宿主机到K8sGPU环境与Device Plugin的全链路搭建3.1 GPU节点准备四件套要让K8s节点被调度器认为有GPU可用需要在每个GPU节点上依次完成四件事驱动、容器工具集、运行时配置、Device Plugin。任何一环出问题Pod都可能在ContainerCreating状态卡死。驱动层面重点是要让nvidia-smi在宿主机上能正常输出。注意K8s里跑GPU Pod时宿主机驱动版本最好统一混用不同版本会让排障非常痛苦。容器工具集方面官方方案是NVIDIA Container Toolkit安装后要把运行时注册给容器服务。如果你用的是containerd现在K8s默认的运行时需要在/etc/containerd/config.toml里配置nvidia运行时[plugins.io.containerd.grpc.v1.cri.containerd.runtimes.nvidia] privileged_without_host_devices false runtime_engine runtime_root runtime_type io.containerd.runc.v2还要确认containerd里已经注册了nvidia container runtime的可执行文件路径。这块经常有人漏掉后面会让Device Plugin上报了GPU数量但容器启动时完全拿不到GPU设备。如果是docker作为K8s运行时老集群常见则是在/etc/docker/daemon.json里加default-runtime: nvidia并配置runtimes字段。时间有限的话检查运行时配置有没有生效可以直接手动创建一个测试容器试试设备能否挂载进去。3.2 安装Device PluginDaemonSet方式NVIDIA官方提供了一个Device Plugin DaemonSet部署后每个GPU节点会自动运行一个Pod负责向Kubelet上报GPU资源。最核心的启动参数是--mig-strategy默认值是none也就是不做MIG上报。我建议一开始就把这个参数设成single哪怕当前还没有启用MIG后面启用后不用再改DaemonSet。apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: tolerations: - operator: Exists priorityClassName: system-node-critical containers: - image: nvcr.io/nvidia/k8s-device-plugin:v0.16.2 name: nvidia-device-plugin-ctr args: - --mig-strategysingle - --pass-device-specs env: - name: NVIDIA_VISIBLE_DEVICES value: all - name: NVIDIA_DRIVER_CAPABILITIES value: utility securityContext: privileged: true volumeMounts: - mountPath: /var/lib/kubelet/device-plugins name: device-plugin - mountPath: /var/lib/kubelet/device-plugins/nvidia name: nvidia volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins - name: nvidia hostPath: path: /var/lib/kubelet/device-plugins/nvidia有一个小坑新版Device Plugin会挂载额外的/var/log和/var/lib/kubelet/device-plugins/nvidia目录如果宿主机上没有这个目录DaemonSet可能起不来。提前mkdir -p /var/lib/kubelet/device-plugins/nvidia可以省去后面的麻烦。3.3 验证资源是否上报成功部署完Device Plugin后最直接的验证方式kubectl describe node node-name | grep -A 5 nvidia.com/gpu正常情况下会在Allocatable里看到GPU数量。比如启用MIG后一张切成4个3g.20gb实例的A100这里会显示nvidia.com/gpu: 4。如果这里没有看到GPU说明Device Plugin没有成功连接Kubelet的Socket先查一下Pod日志再继续。4. nvidia.com/gpu从节点到容器的流转链路4.1 Device Plugin机制Kubelet与插件之间的Unix Socket对话很多人不理解为什么K8s能认识nvidia.com/gpu这种自定义资源。答案就是Device Plugin机制。Kubelet启动时会监听一个Unix Socket/var/lib/kubelet/device-plugins/kubelet.sock。第三方插件比如NVIDIA Device Plugin以gRPC的方式连上这个Socket通过ListAndWatch接口上报自己管理的设备列表。Kubelet收到后把这些设备转成Extended Resource写入节点状态。这个过程中有一个很容易忽略的点插件和Kubelet可能因为Socket目录权限、SELinux之类的因素连接失败。排查时第一件事就是看/var/lib/kubelet/device-plugins/目录下有没有nvidia.sock文件和kubelet.sock文件同时存在两个都在再考虑下一步。4.2 调度器如何看到GPU资源K8s调度器在调度Pod时会把Pod声明的资源比如nvidia.com/gpu: 1和节点的Allocatable做比对。这么看似乎没问题但实际上调度器只是把GPU当作一个普通整数资源来匹配它不知道节点上有几张卡、卡的型号是否一致、显存是不是够用、这些卡是不是已被MIG切分。这也是为什么后面要引入外部调度器或调度扩展器来做更细粒度的控制。调度器选中节点后Kubelet会再次确认资源并调用Device Plugin的Allocate()接口。这里才是GPU虚拟化真正生效的地方Allocate接口会根据Pod请求的设备ID生成一组环境变量和设备挂载规则最终注入到Pod里。4.3 Allocate之后环境变量与设备挂载的秘密以官方Device Plugin为例Allocate成功后会向容器注入两个关键东西一是环境变量NVIDIA_VISIBLE_DEVICES值为分配的GPU UUID列表二是设备的hostPath挂载。然后容器运行的GPU加速包如PyTorch、CUDA Runtime会通过NVIDIA Container Toolkit读取NVIDIA_VISIBLE_DEVICES来决定把哪些设备暴露给进程。这也解释了一个常见现象如果宿主机上没装Container Toolkit或者运行时没配置对nvidia.com/gpu资源照样能被调度但容器启动后执行nvidia-smi却看不到GPU。因为K8s只是完成了资源记账真正把设备塞进容器的动作依赖于运行时那一层。5. 把一张A100拆成7张小卡MIG实战与调度约束5.1 宿主机侧的MIG启用与实例划分MIG的启用其实就几步命令但每一步都有坑。首先是切换GPU到MIG模式nvidia-smi -mig 1执行后nvidia-smi会提示让正在使用GPU的进程全部退出某些卡甚至要求重启节点才能生效。这个要求重启不是闹着玩的我见过有人在跑着训练任务的时候直接切MIG模式结果驱动直接崩了几台机器的业务全部中断。重启或确认MIG模式已启用后查看这张卡支持哪些Profilenvidia-smi mig -lgip然后创建所需的GPU实例和计算实例。这里有个容易混淆的点MIG下有两个概念GPU InstanceGI和Compute InstanceCI。GI是资源切分的边界CI是计算队列的边界。用官方命令创建时通常一步同时创建两者nvidia-smi mig -cgi 3g.20gb -C-cgi指定GPU Instance Profile-C表示同时创建对应的Compute Instance。如果想创建多个同类型实例可以用-cgi连续指定多次或者循环执行。查看当前实例状态nvidia-smi -L清空所有MIG实例nvidia-smi mig -dgi -gi GPU实例ID nvidia-smi mig -dci -ci 计算实例ID5.2 Device Plugin的MIG策略single vs mixed这是MIG和K8s集成时最关键的配置。--mig-strategy有几种取值none不感知MIG整卡上报Pod只能拿整卡。single节点上所有MIG实例都是同一种Profile比如都是3g.20gbDevice Plugin把所有实例统一上报为nvidia.com/gpuPod只要声明nvidia.com/gpu: 1就能拿到一个MIG实例。mixed节点上存在多种Profile比如1g.5gb和3g.40gb混合Device Plugin会为每种Profile单独生成资源名例如nvidia.com/mig-3g.40gbPod必须按资源名精确申请。我推荐的组合是计算节点按用途打标签训练节点用single策略统一成一个Profile推理节点混合几种常用Profile然后用mixed策略。这样既能保证调度简单又不会让整张卡被一种规格绑死。5.3 MIG模式下的Pod声明与调度限制MIG模式下Pod声明资源和整卡模式看起来一样只要把nvidia.com/gpu或nvidia.com/mig-xxx写进limits和requests即可。这里要说一个K8s非常容易踩的规则Extended Resource必须requests和limits相等如果你只声明limits不声明requests或者两个值不一样调度直接报错。apiVersion: v1 kind: Pod metadata: name: mig-inference spec: containers: - name: inference image: nvcr.io/nvidia/pytorch:24.01-py3 resources: requests: nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1 command: [nvidia-smi, -L]任务启动后进容器执行nvidia-smi -L如果看到的是MIG UUID说明实例划分正确如果看到物理卡UUID说明容器还是拿到的整卡Device Plugin的MIG策略没生效。5.4 MIG实战里的三个坑容器内识别不到MIG实例通常是Device Plugin启动参数没有带--mig-strategy默认none模式下它上报的是物理卡数量MIG实例被完全忽略。CUDA版本与算力不匹配A100的SM算力是8.0如果镜像里的CUDA版本太老比如10.x它不会去使用MIG实例的计算能力表现为容器能启动但计算速度奇慢或者misaligned address报错。显存边界不是整数的错觉比如3g.40gb并不是说你有40GB可用实际留给应用的显存可能因为驱动和上下文预留少几百MB。分配显存时别顶着上限规划留10%余量。6. 算力调度实战Binpack、配额控制与Volcano6.1 默认调度器的局限是不会算账前面已经提到默认kube-scheduler在面对GPU时就是个加法器。它能算清楚你申请了几个GPU但算不清楚这些GPU在哪些节点上、哪些卡已经被部分占用、哪些任务适合跑在一起。因此做GPU算力调度通常有两层动作一层是K8s调度器本身策略的调整另一层是引入更懂GPU的第三方调度器。6.2 用NodeResourcesFit的scoringStrategy做Binpack或Spread如果你只想做最基础的优化不用装额外组件改一下kube-scheduler的配置就可以。K8s从1.19版本开始把节点资源打分逻辑统一到了NodeResourcesFit插件里通过scoringStrategy可以切换两种模式LeastAllocated偏向把Pod调度到资源占用最少的节点相当于Spread分散好处是节点负载均衡坏处是GPU碎片多。MostAllocated偏向把Pod调度到资源占用最多的节点相当于Binpack装箱能把任务尽量压缩到少数节点上适合节省成本。修改kube-scheduler的ConfigMapapiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler pluginConfig: - name: NodeResourcesFit args: scoringStrategy: type: MostAllocated resources: - name: nvidia.com/gpu weight: 100 - name: cpu weight: 1 - name: memory weight: 1注意resources里要显式写nvidia.com/gpu并给足权重否则打分时GPU只按默认权重参与效果不明显。这里有个微妙点Binpack策略虽然省机器但会把高负载任务挤在一起导致延迟敏感型任务互相干扰生产上建议把这类节点与在线业务节点分开。6.3 用ResourceQuota和LimitRange管住多团队配额算力调度不止是往哪放的问题还有谁能用多少的问题。在多团队共用集群的场景里一定要用ResourceQuota做硬性配额不然几个大作业一上来整个集群的GPU就被瓜分干净了。apiVersion: v1 kind: ResourceQuota metadata: name: gpu-quota namespace: ml-team-a spec: hard: nvidia.com/gpu: 4更细一点可以用LimitRange限制单个Pod最多申请几块GPUapiVersion: v1 kind: LimitRange metadata: name: gpu-limitrange namespace: ml-team-a spec: limits: - max: nvidia.com/gpu: 2 min: nvidia.com/gpu: 1 type: Pod这类控制的背后逻辑是GPU是最贵的资源必须通过配额让不同团队之间形成排队公平性而不是靠抢。配额设好之后配合节点亲和性把训练任务引导到指定GPU节点池集群的管理边界一下就清晰了。6.4 Volcano调度器层面的GPU细粒度调度如果团队规模大到需要队列排队、公平调度、抢占、以及GPU显存级别的调度那就要认真考虑上Volcano了。Volcano是CNCF里的云原生批量计算调度器天然支持AI训练作业常见的Gang Scheduling也就是一个训练作业的多个Pod必须全部满足调度条件才一起调度避免部分Pod跑在节点上、部分Pod永远等资源的尴尬。Volcano对GPU虚拟化的支持在于它除了识别nvidia.com/gpu还能通过annotation识别显存、算力百分比等细粒度需求。比如apiVersion: v1 kind: Pod metadata: name: volcano-gpu-job annotations: volcano.sh/gpu-mem: 8Gi volcano.sh/gpu-core.percentage: 50 spec: schedulerName: volcano containers: - name: main image: nvcr.io/nvidia/pytorch:24.01-py3 resources: limits: nvidia.com/gpu: 1这样调度器可以根据每张卡的显存占用情况把小需求的任务塞进已有Pod没占满的卡上实现类似GPU池化的效果。加上Volcano自带的队列模型可以实现多团队分队列、按优先级调度比裸用默认调度器顺手得多。7. 一次GPU Pod卡在ContainerCreating的完整排查链路这里分享一个特别典型的排障过程整个过程走完能帮你把GPU虚拟化链条里的每个环节都复查一遍。7.1 现象所有GPU Pod都起不来某次在集群里部署一个MIG切分后的推理服务Pod一直处于ContainerCreatingevents里有一句很关键的错误Failed to create pod sandbox: rpc error: code Unknown desc failed to create containerd task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: Error response from daemon: unknown device: nvidia0: unknown device看到nvidia0和unknown device第一反应就是运行时没有把GPU设备正确暴露出来。7.2 第一步先看Device Plugin是不是真的定位到了设备kubectl -n kube-system logs device-plugin-pod查一下日志正常情况它会输出节点上发现的设备列表。如果日志里有类似no devices found的输出说明Device Plugin本身没看到GPU那问题就出在宿主机驱动或者MIG实例没创建成功。这次排查时Device Plugin日志是正常的上报了4个MIG实例说明问题不在这一层。7.3 第二步检查容器运行时配置在宿主机上手动创建一个测试容器看能不能正常挂载GPU设备ctr run --rm --runtime nvidia docker.io/nvidia/cuda:12.0-base nvidia-test nvidia-smi如果这个命令也报同样的unknown device: nvidia0就基本锁定是containerd的nvidia运行时配置问题。打开/etc/containerd/config.toml检查nvidia runtime的配置果然发现runtime_type写错了指向了一个不存在的二进制路径。这里有个经验很多发行版装的containerd默认路径是/usr/bin/nvidia-container-runtime但配置里写的是/usr/bin/nvidia-container-runtime-hook两者容易混淆。runc和hook不是同一个程序配置错了自然找不到设备。7.4 第三步复测与回归修正配置后重启containerdsystemctl restart containerd再手动跑一次ctr run正常输出nvidia-smi信息然后把原来的Pod重新调度发现还是卡住。继续看events这次换了错误Error: failed to create containerd task: ... /dev/nvidia-caps: no such file or directory这个错误更隐蔽。查了一下MIG模式下NVIDIA驱动会在宿主机上生成/dev/nvidia-caps目录里面有一堆nvidia-cap*设备节点Device Plugin和运行时需要把这些设备挂载给容器。但宿主机上这个目录不存在说明驱动加载后没有创建对应的设备文件。这时候需要确认MIG模式是否真的启用成功。执行nvidia-smi -mig 1后我又手动创建了MIG实例发现设备节点这不就出现了吗。原来之前漏了一步启用MIG模式后没有创建任何GPU InstanceDriver只会在有实际MIG实例存在时才生成/dev/nvidia-caps下的设备节点。创建完nvidia-smi mig -cgi 3g.20gb -C之后这个目录出现Pod也正常启动了。7.4补这个坑的教训排这个故障花了将近一个小时但根因一点都不复杂MIG模式必须跟实际划分实例联动只切模式不切实例等于把卡的资源命名空间改了但没填内容设备节点自然不会生成。以后只要是MIG相关的问题我都会先跑一条命令确认当前实际可用的实例nvidia-smi -L如果输出的是物理GPU的UUID而不是MIG实例列表就说明MIG还没有真正生效后面所有容器启动问题都往这个方向查。8. 从能跑到健康跑GPU池化后的监控、混部与成本账8.1 监控不能只看GPU利用率把GPU切成小块之后监控的维度也要跟着变。很多团队还是只看DCGM_FI_DEV_GPU_UTIL这个指标其实它代表的是SM流处理器的活跃程度并不等于显存带宽或显存占用率。切分后至少要多看四个指标显存占用、GPU SM占用率、显存带宽利用率、GPU温度/功耗。这里有个直观的案例一个推理服务明明GPU利用率只有20%但显存已经占了90%说明它属于显存瓶颈型任务再给它加算力也没用应该换一个MIG切分规格。DCGM-Exporter是NVIDIA官方的GPU指标导出器配合Prometheus和Grafana可以便捷地做出这些仪表盘。需要提醒一下MIG模式下DCGM-Exporter默认会为每个MIG实例暴露独立的指标这在多租户场景下很好用但要注意Prometheus的采集量会成倍上涨提前做标签聚合和采样降频。8.2 混部与潮汐调度训练和推理该不该放一起GPU池化之后很多人会想当然把训练任务和推理任务混部到同一张卡上。理论上显存够用就行但实践中我要给个忠告按算力占比混部之前先搞清楚任务的延迟容忍度。时间片方案本身就存在算力争抢训练任务一跑满推理P99延迟可能直接翻两三倍。上了MIG切分两者在硬件层面确实隔离了但前提是MIG实例规格和任务特征匹配否则照样互相干扰。如果集群里的推理任务有明显的波峰波谷比如白天在线服务占资源多、晚上离线训练跑得多更合理的做法是做时间维度的潮汐调度用CronJob或自定义控制器在固定时间点调整不同队列的资源配额把同一个MIG实例在白天挂给推理服务、晚上挂给训练任务。这种方式比强行混部要稳得多。8.3 原地升级与GPU Pod的重启策略GPU应用和普通Web应用在发布策略上有很大的不同。大模型推理服务经常需要加载好几个GB的模型权重冷启动要一两分钟如果每次发布都重建Pod用户体验会很差。所以这类任务建议用StatefulSet或Deployment配合updateStrategy: RollingUpdate并且设置足够的terminationGracePeriodSeconds让旧Pod优雅退出。另一点是不要轻易给GPU Pod设置restartPolicy: OnFailure因为GPU任务崩溃后显存可能没有被CUDA Context完全释放直接重启容易撞上显存泄漏导致的OOMKilled。先让Pod退出在新Pod里处理更干净。8.4 算这笔成本账最后聊聊成本。一台8卡A100的服务器如果按整卡分配摸鱼跑利用率20%那等于80%的采购费用在折旧蒸发。用MIG切分后哪怕只把利用率提到50%相当于多出了好几张逻辑卡给业务用省下的采购成本非常可观。但这不等于说切分得越细越好因为实例规格越多碎片越多调度复杂度越高。我见过一个团队把A100切成7个1g.5gb实例结果模型要8GB显存只能占两个实例又要跨MIG实例通信性能反而远不如直接用时间片。所以切分前先梳理业务模型的实际显存和算力需求按需求的分布来确定Profile永远比先切再调效率高。回到开头那个场景后来我用MIG把8张A100的节点切成了32个3g.20gb实例配合Volcano的队列调度原来排队两小时的训练任务基本半小时内就能跑上。GPU虚拟化和算力调度不是一步到位的工程它是一套持续迭代的策略但每往前走一步回报都很实在。希望这篇东西能帮你少走点弯路。