1. GPU 利用率困局为什么你的卡明明买了却总在“摸鱼”做企业级 AI 基础设施这行十来年我见过太多机房里堆着几十上百张卡、账面算力看着很唬人、实际利用率却长期趴在 15% 到 30% 之间的场景。老板看着采购单心疼算法团队抱怨排队排到天亮运维夹在中间两头受气。这个矛盾的核心其实不是卡不够而是GPU 资源池化没做透。先把话说直白GPU 资源池化不是装个调度器就完事它是一整套从硬件抽象、隔离切分、调度策略到计量回收的工程体系。很多团队一上来就冲着“共享”去结果发现显存打架、上下文切换开销爆炸、任务互相拖垮最后又退回一人一卡的原始模式。问题出在跳步了——池化这件事有它内在的先后顺序跳过任何一步后面都会以更痛的方式还回来。这篇文章面向的是正在或准备做 GPU 统一调度的运维工程师、平台开发、AI 基础设施负责人以及被“卡不够用”折磨的算法团队 leader。我会把资源池化拆成 5 个必须走完的步骤每一步讲清楚为什么这么排、关键参数怎么算、实操里会踩什么坑。你不需要是内核专家但看完应该能拿着这套框架去评估自己团队的现状知道下一步该补哪块短板。先给一个我常用的判断标准如果你的集群里单卡日均有效计算时间占比低于 40%或者任务平均排队时长超过实际运行时长那基本可以确定池化没做到位。这两个数字不是拍脑袋来的后面讲计量的时候会展开。2. 第一步硬件抽象与统一纳管把异构卡变成“同一种资源”2.1 为什么必须先做抽象而不是直接调度很多人会问我直接上 Kubernetes 加个 device plugin 不就能调度了吗能但那只解决了“发现卡”没解决“描述卡”。不同型号的卡显存容量、算力档位、支持的精度格式、互联拓扑都不一样。如果不先做一层统一的资源描述调度器眼里的“一张 GPU”可能是 16G 的入门卡也可能是 80G 的旗舰卡它没法做正确的匹配决策。硬件抽象这一步的目标是把物理卡映射成一组标准化资源属性显存容量、计算能力等级、互联带宽、是否支持特定精度、健康状态。这层抽象通常落在设备插件和节点标签体系里。我习惯用节点标签把卡的型号、显存、代际打上去比如gpu.modela100、gpu.memory80g、gpu.archampere调度时用 nodeSelector 或亲和性去匹配。注意抽象层不要做得太细。我见过有团队把卡的每一个硬件参数都做成标签结果标签组合爆炸调度器匹配性能急剧下降。抓住显存、算力档、互联这三四个维度就够了。2.2 异构纳管的实操要点异构环境是常态别指望全集群一个型号。实操里我会把卡按“能力档位”归成几类而不是按具体型号。比如把 80G 显存、支持高带宽互联的归为 A 档把 24G 显存、无高速互联的归为 C 档。任务提交时声明需要哪一档而不是声明具体型号。这样调度灵活度最高也不会因为新采购一批卡就要改所有任务的配置。纳管过程中有个容易被忽略的点驱动和运行时版本的一致性。同一档位里的卡如果驱动版本差异过大容器镜像里的 CUDA 运行时可能在某些节点上跑不起来。我的做法是在抽象层里额外记录驱动大版本调度时做一次软约束——优先匹配驱动一致的节点匹配不到再降级。这个逻辑写在调度器的打分插件里比事后排查“为什么这个任务在 A 节点能跑 B 节点报错”要省心得多。2.3 健康检查与故障隔离抽象层还要承担健康检查的职责。卡是会坏的ECC 报错、掉卡、温度墙降频都是家常便饭。我见过最坑的一次是某张卡间歇性算错结果任务不报错但输出全是垃圾排查了整整两天。所以纳管时必须定期跑健康探针简单的矩阵运算校验、显存读写测试、温度与功耗读取。探针失败的节点自动打上不可调度标记任务重新排队。这一步做完你得到的是一个“卡池”的逻辑视图所有卡被描述成带属性的资源健康状态实时可见调度器有了做决策的基础数据。但注意这只是池化的地基还没到真正的“共享”。3. 第二步隔离与切分让一张卡安全地服务多个任务3.1 隔离的三个层次池化要共享共享就要隔离否则就是灾难。GPU 隔离分三个层次从粗到细分别是整卡独占、时间片轮转、空间切分。整卡独占最简单一个任务占一张卡利用率天然上不去但胜在稳定。时间片轮转是让多个任务分时复用同一张卡靠上下文切换实现开销大但兼容性好。空间切分是把显存和计算单元硬切多个任务真正并行效率最高但对硬件和软件栈要求也最高。我的经验是训练任务优先整卡或空间切分推理任务适合时间片或小粒度切分。训练对显存和算力连续性要求高频繁切换会拖垮收敛速度推理任务通常短小、并发高时间片轮转反而能填满空隙。3.2 显存隔离的参数计算空间切分里最关键的是显存分配。假设一张 80G 的卡你要切给 4 个任务不能简单除以 4 给 20G因为每个任务除了模型权重还有激活值、梯度、优化器状态、通信缓冲区。经验公式是单任务显存 模型参数量 × 精度系数 × 冗余倍数。以 FP16 训练为例精度系数约 2 字节/参数加上梯度、优化器状态和激活冗余倍数通常取 4 到 6。也就是说 10B 参数的模型FP16 训练大约需要 80G 到 120G 显存一张 80G 卡根本放不下得靠模型并行。推理就宽松得多FP16 推理的冗余倍数取 1.2 到 1.5 即可。所以切分策略要按任务类型区分不能一刀切。提示显存切分一定要留安全余量。我一般预留 10% 到 15% 不分配防止某个任务显存峰值超出预期把整张卡拖崩。这个余量在监控里单独看长期用不满可以考虑缩小。3.3 计算单元切分的现实约束计算单元SM的切分比显存难得多。显存是静态资源切了就是切了计算单元是动态的任务运行时抢占 SM 会导致互相干扰。目前比较成熟的做法是给每个切分实例限定 SM 配额靠底层运行时做限流。但要注意限流太狠会让任务跑不满限流太松又失去隔离意义。我通常按任务的算力需求档位来配比如高优先级任务给 50% SM低优先级给 20%剩下的留作弹性。这里有个实操心得切分粒度不要小于单卡算力的 1/8。再细下去调度开销和上下文切换的损耗会超过共享带来的收益得不偿失。我实测过 1/16 的切分小任务确实能塞进去但整体吞吐反而下降了 20% 多。4. 第三步调度策略设计决定谁先用、用多少、用多久4.1 调度器的核心决策维度调度策略是池化的“大脑”。它要回答三个问题哪个任务先跑、分到哪些卡、跑多久。对应的维度是优先级、亲和性、时限。优先级好理解高优任务插队。亲和性是指任务和卡的匹配关系比如大模型训练需要高带宽互联的卡放在同一拓扑域内推理任务则无所谓。时限是给任务设一个最长占用时间超时释放防止某个任务长期霸占资源。我见过不少团队只做了优先级结果高优任务一来就把低优任务全挤掉低优任务永远跑不完。正确的做法是优先级加配额每个团队或用户有基础配额保证低优任务也有最低资源高优任务可以借用空闲资源但空闲资源被收回时要能优雅让出。4.2 抢占与让出的实现细节抢占是池化里最容易出问题的环节。抢占不是简单地把任务杀掉而是要保证被抢占的任务能保存状态、重新排队、恢复运行。训练任务如果没做 checkpoint抢占一次等于白跑几小时团队会跟你拼命。所以抢占策略必须和 checkpoint 机制绑定只抢占那些最近有 checkpoint 的任务或者抢占前先触发一次 checkpoint。让出则是抢占的反面。高优任务结束后资源要还给低优任务。这里有个坑如果低优任务已经被抢占重新排队了资源还回去它也不一定马上能拿到因为可能被其他任务占了。我的做法是给被抢占的任务保留一个“优先恢复”标记资源释放后优先匹配给它减少重复排队。4.3 调度策略的配置示例下面是一个简化的调度策略配置思路用伪代码表达方便你对照自己团队的实现scheduler: policies: - name: high-priority-training priority: 100 resource: gpu-tier-a preemption: true checkpoint-required: true max-duration: 72h - name: low-priority-inference priority: 10 resource: gpu-tier-c preemption: false max-duration: 4h quota: team-alpha: 40% team-beta: 30% shared-pool: 30%这个配置的意思是高优训练任务可以抢占但必须支持 checkpoint最长跑 72 小时低优推理任务不可抢占最长 4 小时资源按团队配额分配留 30% 作为共享池给突发需求。配额不是硬隔离而是软约束空闲时可以互相借用。注意max-duration 不要设得太短。我见过设 1 小时的结果大任务刚热身就被踢反复重启反而更浪费。训练任务至少给 24 小时推理任务可以短一些。5. 第四步运行时管理与弹性伸缩让资源跟着负载走5.1 运行时环境的标准化池化做到调度层任务能分到卡了但能不能跑起来还取决于运行时环境。CUDA 版本、驱动版本、Python 依赖、框架版本任何一个不匹配都会导致任务失败。所以运行时管理的第一步是镜像标准化为每一档 GPU 能力维护一个基础镜像里面预装好匹配的驱动、CUDA、常用框架。任务提交时基于基础镜像构建避免各自为政。我踩过最深的坑是驱动和 CUDA 的版本矩阵。某个框架的新版本要求 CUDA 12.x但集群里一半节点还是 11.x 的驱动结果任务随机失败。后来我们强制所有节点升级到统一驱动大版本基础镜像按 CUDA 小版本分几个 tag任务声明需要的 tag调度时匹配。这个改动之后环境类故障率下降了 70% 以上。5.2 弹性伸缩的触发条件弹性伸缩是池化效率的关键。负载高时扩容负载低时缩容听起来简单触发条件却要仔细设计。常见的触发指标有队列等待任务数、平均 GPU 利用率、显存占用率。我一般用队列等待数加利用率的组合等待任务超过阈值且利用率高于 70%触发扩容利用率低于 30% 持续一段时间触发缩容。缩容要特别小心。正在跑的任务不能直接杀要等它自然结束或者迁移。迁移训练任务成本极高所以缩容通常只针对推理任务和无状态任务。有状态任务靠 max-duration 自然释放。5.3 弹性伸缩的实操记录分享一次真实的扩容记录。某次业务高峰队列里积压了 30 多个推理任务平均等待 40 分钟。监控显示现有卡池利用率 85%显存占用 78%。触发扩容后从备用节点池拉起了 8 张卡加入集群纳管、打标签、加入调度池整个过程大约 6 分钟。新卡加入后等待任务在 15 分钟内消化完利用率回落到 60% 左右。这里的关键是备用节点池要预热。如果临时去申请机器、装驱动、拉镜像没有半小时下不来高峰早过去了。我们平时保持 10% 的备用容量驱动和基础镜像都装好扩容时只需要加入调度池几分钟就能生效。6. 第五步计量、计费与回收池化的闭环6.1 为什么计量是池化的最后一环也是最重要一环没有计量的池化是不完整的。你不知道谁用了多少、用得好不好就没法做配额调整、成本分摊和效率优化。计量要采集的指标包括任务占用 GPU 时长、显存峰值、算力利用率、排队时长。这些数据既能用于内部计费也能用于发现浪费。我见过一个团队做完池化后利用率从 25% 提到了 55%但再往上就上不去了。后来上了计量发现有几个任务长期占着卡但利用率只有 5%一问是调试任务忘了关。清理掉这些“僵尸任务”后利用率直接冲到 70%。所以计量不只是算账更是发现浪费的眼睛。6.2 计量数据的采集与聚合采集粒度建议到分钟级太粗了看不出波动太细了存储压力大。每个任务记录开始时间、结束时间、分配的卡数、显存配额、实际显存峰值、实际算力利用率。聚合维度按团队、用户、任务类型、时间段。这些数据落到时序数据库里配合看板展示。算力利用率的采集要注意不能只看 GPU 的 SM 占用率还要看显存带宽利用率和 Tensor Core 利用率。有些任务 SM 占用很高但都在做访存实际算力没跑满。我一般把这三个指标加权成一个综合利用率权重按任务类型调整。6.3 回收机制与僵尸任务清理回收分两种正常回收和异常回收。正常回收是任务结束后释放资源这个靠调度器自动完成。异常回收是任务卡死、节点失联、进程僵死等情况下的强制释放。异常回收要配合健康检查节点失联超过阈值就标记不可用上面的任务重新排队。僵尸任务的清理我建议做成定期巡检每天扫一遍所有运行中的任务利用率低于阈值且运行超过一定时长的发告警给负责人确认。确认是僵尸的直接回收确认是正常但低效的记录下来做优化。这个机制跑起来之后我们集群的“无效占用”从 15% 降到了 3% 以内。7. 常见问题与排查技巧实录7.1 池化落地过程中的典型问题速查问题现象可能原因排查思路解决方法任务分到卡但启动报 CUDA 错误驱动与运行时版本不匹配对比节点驱动版本和镜像 CUDA 版本统一驱动大版本镜像按 CUDA 小版本分 tag多任务共享一卡时互相拖慢隔离不足SM 抢占严重查看各任务 SM 占用和切换频率提高切分粒度限制单任务 SM 配额高优任务抢占后低优任务饿死只有优先级没有配额统计各团队任务完成率引入基础配额保证低优最低资源扩容后新卡任务仍排队新卡未正确纳管或标签缺失检查节点标签和 device plugin 状态完善纳管流程扩容后自动打标签利用率虚高但吞吐上不去计量指标单一只看 SM 占用补充显存带宽和 Tensor Core 指标综合利用率加权识别访存瓶颈任务卡死占用资源不释放缺乏异常回收机制检查任务心跳和节点健康状态加健康探针失联节点自动回收7.2 独家避坑技巧第一个坑是过度切分。前面提过切分粒度小于 1/8 卡算力时收益为负。我建议从 1/2 或 1/4 开始观察实际效果再决定要不要更细。很多团队一上来就追求极致切分结果调度开销吃掉了所有收益。第二个坑是忽视网络拓扑。多卡训练任务如果分到的卡跨了 NUMA 节点或跨了交换机通信带宽会断崖式下跌。调度时一定要考虑拓扑亲和性把需要高速通信的卡放在同一拓扑域内。这个在抽象层打标签时就要规划好。第三个坑是计量数据不准。有些采集工具在容器里读不到真实的 GPU 指标读到的是宿主机的或者干脆是 0。上线计量前一定要做校准拿一个已知负载的任务跑一遍对比采集数据和实际值。数据不准比没有数据更可怕会误导所有决策。第四个坑是忽略冷启动。任务从提交到真正开始计算中间有镜像拉取、环境初始化、模型加载的时间。这段时间卡是被占用的但没产出。优化冷启动能显著提升有效利用率方法包括镜像预热、模型缓存、环境预初始化。我们做过统计冷启动优化后短任务的卡占用时间平均缩短了 40%。7.3 一个真实的排查案例有段时间集群利用率突然从 60% 掉到 35%但任务队列并不长。排查发现是某个团队提交了一批大显存任务每个任务申请 70G 显存但实际只用 20G导致大量卡被“占着茅坑不拉屎”。调度器按申请量分配卡分出去了但算力闲置。解决方法是引入显存超卖加实际监控允许任务申请超过实际需求的显存但运行时监控实际占用超过配额就告警甚至限流。同时调整调度策略优先把任务塞进已有部分占用的卡而不是开新卡。这个改动之后利用率回到了 65% 以上。这个案例的教训是调度不能只看申请量要看实际使用量。申请量是用户的“保险”实际使用量才是真实需求。两者之间的差距就是池化可以挖掘的空间。8. 从 5 个步骤看池化的长期演进走完这 5 步你的 GPU 池化算是成型了硬件抽象让卡可描述隔离切分让卡可共享调度策略让卡可分配运行时管理让卡可运行计量回收让卡可优化。这是一个闭环缺一环都会漏水。但池化不是一劳永逸的。业务在变模型在变大硬件在迭代池化策略也要跟着演进。我个人的体会是每半年做一次池化健康度评估看利用率趋势、看排队时长、看故障率、看计量数据里的浪费点。根据评估结果调整切分粒度、调度权重、配额分配。最后分享一个我一直在用的小技巧给池化系统本身也做监控。调度器的决策延迟、纳管层的健康检查频率、计量数据的采集延迟这些元指标能提前预警池化系统自身的问题。池化系统挂了整个集群就瘫了它的稳定性优先级应该和业务任务一样高。这套框架我在几个不同规模的集群上都落地过从几十张卡到上千张卡核心逻辑是通的区别只在实现的复杂度和自动化程度。小集群可以手动多一些大集群必须全自动化。你可以根据自己的规模从这 5 步里挑最痛的一步先做逐步补齐。