半年前有个朋友让我去帮他分析GPU集群的利用率问题他的第一句话就是“卡不够用训练排期排到一个月后了”。我打开监控面板一看32张A100平均利用率不到40%很多卡凌晨到早上都是空的。这就是典型的“卡不够用又卡闲着”的矛盾。GPU资源池化要解决的根本问题就是这个把物理GPU的计算能力和显存抽象成逻辑资源统一管理、按需分配打破一张卡只能服务一个任务的传统模式让每一块卡都尽量被用满让真正需要算力的任务不用天天排队。这篇文章不打算写概念堆砌我会把池化的底层原理、不同切分方式的本质区别、调度层真正难在哪里、哪些应用场景适合池化、哪些场景硬上反而吃亏这些事一次性讲透。同时会穿插一些我实际落地时踩过、见过、补救过的坑。适合手里有GPU集群、正在做算力规划或者准备上池化的工程师和管理者阅读。1. 为什么GPU资源池化会成为基础设施标配从一个矛盾说起GPU独占模式在资源少、任务单一的时候没什么问题可一旦集群规模上到几十张卡冲突立刻出现。问题从来不是“单卡算力不够”而是“大规模的算力无法被灵活拼装”。1.1 独占模式下GPU利用率为什么这么低训练任务并不是全程把GPU打满的。数据加载、预处理、checkpoint写入、模型评估、跨卡同步等待这些阶段GPU都在空转。我见过很多PyTorch训练脚本data loader写得不好GPU利用率在20%到80%之间剧烈波动。另一个原因是团队之间的忙闲不均做CV的团队在疯狂跑实验做NLP的团队任务没排上但他们的卡已经提前预定了别人根本不能碰。这种“预设资源不动”的分配方式让全局利用率天然上不去。1.2 池化到底在“池”什么东西很多人以为池化就是把几张卡放一起这样理解太粗略。真正被池化的是四类资源第一个是计算单元也就是SM/CUDA核心控制的是并行算力第二个是显存控制的是任务能不能装得下也直接影响瓶颈第三个是显存带宽很多模型瓶颈根本不在算力而在访存第四个是GPU间互联带宽也就是NVLink/NVSwitch和PCIe通路这决定了多个GPU被组合成一个“逻辑大GPU”时通信的上限。池化做的事情简单说就是把这四类资源切成不同粒度的小块再根据任务需求动态组合分配。这跟CPU的内存分页很像把物理内存切页虚拟内存按需映射任务看到的是一个“足够大”的抽象资源空间物理上可以用任意空闲页面组合出来。1.3 什么情况下你不该池化池化不是银弹比如一个训练任务需要4张或8张H100做张量并行模型参数本身就跨卡存放在NVLink域内这个时候强行把它塞进池化调度的“共享卡”里性能损耗和通信抖动会让你怀疑人生。后面我会专门讲这个边界。2. 核心原理拆解从PCIe拓扑到MIG、vGPU与时间切片池化从实现路径上看有三个层次一层是物理卡本身怎么被切开一层是调度系统怎么管理这些切片还有一层是跨节点通信怎么做。这一章重点解决第一层。2.1 GPU直通最原始的“伪池化”GPU直通Passthrough是最先成熟起来的方案通过PCIe的VFIO技术把一张物理GPU直接透传给一个虚拟机或容器使用。它的问题是隔离性极好、性能损耗接近零但粒度就是一整张卡没法切分。在池化体系里直通通常作为基础单元存在调度器看它的时候只能决定“这张卡给谁”不能决定“这张卡的多少算力给谁”。2.2 MIG硬件级切分的真正开端NVIDIA从A100开始引入MIGMulti-Instance GPU这是池化历史上很重要的一步。MIG直接把GPU切成多个硬件级隔离的实例每个实例有独立的SM、独立L2缓存、独立显存控制器和显存切片。隔离性做到硬件级意味着一个实例的崩溃、显存耗尽、CUDA错误几乎不会影响其他实例。MIG常见切法是按计算和显存组合比如A100 40GB可以切成1g.5gb、2g.10gb、3g.20gb、7g.40gb这几种profile。注意看命名规律前面的数字代表计算切片比例比如1g代表大约1/7的计算资源后面是显存大小。H100上还有更好的切分粒度。但MIG也有明显限制必须开启MIG Mode需要重启GPU同一张卡上MIG实例之间的NVLink带宽受限profile粒度固定不像软件方案那样可以任意取显存和算力。也就是说MIG适合“需要干净隔离”的调度场景但它不是万能的。2.3 vGPU可分可调的软件虚拟化NVIDIA vGPU以前叫GRID是另一条路线。它通过GPU虚拟化驱动把一张物理GPU切成多个虚拟GPU每个vGPU可以单独指定显存大小、计算份额、编码单元数量。跟MIG比vGPU的好处是粒度和组合更灵活可以给一个任务开15GB显存加30%算力MIG做不到这么细致的任意组合。坏处是隔离性在软件层性能损耗比MIG略高且vGPU有License费用还要考虑并发数的限制。vGPU特别适合图形类负载比如云桌面、云游戏的渲染和编码需要因为它的驱动栈原生支持图形API和视频编解码的切片。2.4 时间切片最轻量也最需要警惕的共享方式时间切片是纯软件层面的共享运行层面是任务们轮流占用执行单元。时间分片、MPS等同类的共享机制在单任务独占卡时性能损失几乎为零多任务并发后算力按时间片分配每个任务都变慢。最要命的是时间切片没有显存隔离所有共享同一张卡的进程都能看到整卡显存。这不是理论风险我后面会讲一个因为时间切片显存不隔离导致的实际事故。2.5 四种方式对比共享方式隔离级别典型性能损耗分配粒度适用场景整卡直通物理隔离0-2%1卡固定大模型训练、对性能极其敏感的任务MIG硬件级隔离3-8%固定profile多租户AI推理、需要强隔离的场景vGPU软件级隔离5-15%任意可调图形渲染、云桌面、灵活切分的推理时间切片几乎无隔离并发时线性下降任意内部共享、轻量级模型、试验环境3. 调度层资源切得开不代表分得好池化的价值最终要靠调度系统体现。如果只把卡切开调度配不上整个池子还是一团乱麻。3.1 资源抽象与配额把GPU变成可计量的单位做池化第一步是把GPU抽象成能被系统识别和计算的资源描述。常见做法是把“一张物理GPU”描述成两个维度计算份额比如0.3卡、1g的MIG profile和显存大小比如15GB。对外只看这两个参数对内由调度器映射到具体物理卡和实例上。配额系统同样重要。没有配额一个团队把池子里所有资源领走其他团队只能干瞪眼。我见过很多平台把配额做成“组织→项目→用户”三级结构每个层级限制累计申请上限。配额不是用来限制业务而是为了防止某个团队“先占坑再找活干”。3.2 Kubernetes生态下的GPU调度方案现在开源场里最主流的底座还是Kubernetes。官方提供的NVIDIA Device Plugin负责把GPU作为扩展资源上报给kubelet它能做最基本的“一张卡给一个Pod”的调度。但如果要切分和共享就必须扩展调度器。NVIDIA MIG Manager可以在K8s里管MIG profilevGPU方案则会有自己的管理组件。更大规模的场景通常会引入Volcano或Kueue这类批量调度器它们支持队列、优先级、抢占、依赖关系这些复杂的调度语义。单纯用默认的K8s调度器做GPU池化很快就会碰到排序策略和配额策略都跟不上业务需求的问题。3.3 Binpack还是Spread调度策略的取舍调度策略里有个很实际的选择把任务尽量堆到少数几张卡上Binpack还是尽量分散到不同卡上Spread。Binpack能最大程度减少被占用的物理卡数量让空闲卡保持完整便于分配给需要多卡的任务Spread则能降低单卡故障或热点带来的影响但容易把卡切得很碎导致后面调度困难甚至碎片化。很多调度器默认Binpack但我在实际中更建议按负载特征混合调度推理任务可以用Binpack因为单个推理Pod占的资源小碎片影响有限训练任务尽量保持整卡避免被碎片化卡点卡住。3.4 优先级与抢占高优任务来了怎么办池化就避不开抢占。系统里随时会有高优先级的紧急任务插队低优先级的长任务正在跑的算力可能被收回。此时最怕的是凶残的硬杀直接kill进程任务不仅白跑还可能导致集群里出现一堆半写状态文件。合理做法是配合任务本身的checkpoint来设计“优雅退让”高优任务进来时调度器先通知低优任务保存状态、释放显存再调度高优任务。这是个工程活儿得训练框架、存储、调度器三方配合但值得做。很多平台的第1版都是硬杀运行一周后就会收到大量投诉然后乖乖回头补优雅退出。4. 应用场景全景AI推理是最大赢家大模型训练要小心池化对不同负载的收益差异很大。我用一个原则来判断跨节点通信越频繁、对单卡算力要求越满的任务池化收益越低任务数量多、单任务需求小、QPS波动大的场景池化收益最大。4.1 AI推理弹性扩缩容的黄金组合AI推理服务是典型的池化受益者。线上QPS有明显波峰波谷白天用户访问多夜间回落。用独占卡部署高峰要预留大量GPU低谷全部闲置用池化部署调度器可以根据QPS自动扩缩容波谷时释放出来的资源自动分配给离线任务或者其他团队。多模型还可以共享同一张物理卡Triton Inference Server配合MIG一个H100可以同时跑好几个模型实例互不干扰吞吐率拉满。推理任务单个Pod占的资源小非常契合池化的“小块可调度”逻辑。我见过一个生产环境6张A100之前只部署一个在线推荐模型高峰期勉强够、低谷全闲着后来改成池化管理同一批卡同时承载在线推理、定时批量推理和几组离线数据预处理任务整体利用率从不到30%提上到60%以上。4.2 大模型训练池化不等于把卡混在一起用大模型训练尤其数据并行、张量并行、流水线并行混合的场景跨GPU通信极其密集。NCCL的allreduce操作对网络时延和带宽极其敏感跨节点走RoCE跟本地NVLink相比性能差距可以达到数倍。如果调度器把训练任务的两个rank分到不同物理卡、不同网络域里训练性能会惨不忍睹。这条线我建议的训练策略是大模型训练任务不参与细粒度池化直接用整卡直通或整机独占的方式运行池化主要覆盖推理、中小模型微调、数据处理等弹性负载。整卡直通也不是“反池化”它本身就是调度池中一个不可切分的单元只是粒度大、不让别人共享。4.3 云桌面、云游戏和图形渲染虚拟化的老本行图形负载是GPU虚拟化的传统战场。一个用户的桌面不可能独占一张专业卡成本上完全扛不住。通过vGPU切分一张物理GPU可以同时服务多个桌面用户每个用户按规格获得对应的显存和计算份额。这类场景里视频编码单元也需要被切分因为云游戏本质上是“一边渲染一边编码推流”编码器资源的切片和GPU核心一样重要。这块要注意的是License成本。vGPU的每个实例都是按License收费的用户并发规模一大这部分的成本会非常可观。不是否定vGPU而是说做成本预算时要把许可证费用算进去别只盯着硬件采购费。4.4 科学计算和视频批处理看任务对“联想”的需求科学计算里很多MPI程序对网络同样敏感但这个领域的任务通常已经写死了通信模式不像深度学习框架有那么多自动混合并行策略所以通过池化做整机调度、按节点分配资源是可行的。视频渲染和转码则是对故障容忍度高的批处理任务中断可以重跑非常适合池化的低优先级队列把白天浪费的零散时间片全部利用起来。4.5 企业内部共享与成本分摊很多公司采购GPU后业务部门是按“我申请了X张卡”的口径做预算的但真正利用率没人统计。GPU池化落地后会天然产生一份“资源账单”DCGM采集的利用率指标加上调度器的分配记录可以按项目、部门、用户维度生成成本报表。有了这个数据后续的扩容决策就不再靠拍脑袋而是看真实负载趋势。这也是池化除了技术收益之外很多人容易忽略的管理收益。4.6 场景与方案匹配速查场景推荐方案理由大模型预训练/重训练整卡直通、整机独占通信密集不能接受共享带来的抖动在线推理多模型MIG/vGPU隔离共享弹性扩缩容多模型共存微调、中小规模训练时间切片/MIG可接受稍低性能换取资源利用率云桌面/云游戏vGPU图形API和编码器需要驱动支持视频转码/渲染时间切片批处理队列任务可重试对故障容忍内部科学计算整机级调度尽量保通信域完整5. 踩坑实录性能损耗、显存安全与“邻居干扰”池化方案选型时大家通常关注性能损耗真正上线后最折磨人的反而是隔离问题和调度策略的副作用。这里把典型的坑按排查路径展开讲。5.1 性能损耗到底多大实测数字和建议我们做过一组对比测试用同一套ResNet训练脚本分别在直通、MIG、vGPU、时间切片模式下跑。直通的性能损耗几乎为0MIG模式单实例跑损耗大概在3%到8%主要是L2和显存带宽被切片后的带宽下降导致vGPU单实例跑损耗在5%到15%时间切片在只有一个任务时基本没有损耗两个任务并发后各自吞吐量腰斩这是正常的算力均分。所以选型的时候别只看基准测试要看业务的“形态”一个推理服务本身QPS波动就大10%的损耗几乎无感知一个训练任务如果真的是满载运行5%的损耗放大到整周训练周期影响就被放大了。5.2 那个显存不隔离事故时间切片的真实风险说回时间切片。公司内部有套K8s集群通过Time Slicing把A100共享给多个Pod。排查一次GPU错误时发现某个Pod的CUDA上下文崩了之后同一物理卡上所有Pod的kernel都开始报错连其他Pod的显存数据都能被异常访问到。原因就是时间切片没有显存隔离所有Pod共享同一份物理显存一个Pod越过边界整卡都遭殃。从那之后我们的内部规范明确为时间切片只用于单租户内部或者完全可信的测试环境凡是多租户共享物理卡至少用MIG或者走vGPU。显存隔离是硬底线没有商量空间。5.3 MIG的毛病粒度不匹配和NVLink限制MIG虽然隔离性好但profile粒度固定很头疼。比如有个算法团队需要20GB显存但算力只用了1/4A100 40GB的MIG profile要么给1g.10gb显存不够要么给3g.20gb算力浪费一半。资源配额上能应对但物理卡分出来之后没法再动态调整切碎了的卡不重建MIG实例就改不了规格。还有一点MIG实例之间的NVLink带宽被阉割得很厉害。多卡训练想跨MIG实例通信得绕PCIe或者走网络性能下降明显。这个在规划调度时就要提前设计MIG实例主要用于单卡推理不用于需要多卡高速互联的训练。5.4 调度器抢占任务被杀的修复思路有个平台第1版上线时紧急高优先级任务到达后直接抢占低优先级的训练任务。运维群里当天就炸了好几个跑了一天的长训练任务进程被强杀checkpoint只存到几个小时前白算了一大半。后来我们改成两层机制第一调度器抢占前先向运行中的任务发送优雅退出信号任务收到信号后会先存checkpoint再退出第二K8s层面配合使用PodDisruptionBudget普通任务最多同时被打断20%关键任务干脆禁止抢占。虽然还是会被打断但至少能恢复到最新checkpoint损失小很多。这个排序是保护关键任务 优雅退出 尽量少中断。5.5 监控与成本报表没有数据就别谈优化GPU池化做得再好没有监控数据证明它的价值推动起来很困难。建议从第一天起采集这些指标GPU利用率、显存使用、显存带宽、NVLink带宽、温度功耗还有任务维度的“资源申请量vs实际使用量”。NVIDIA DCGM是标准工具自带Prometheus exporter配合Grafana就能出一套基础的GPU观测大盘。更重要的是一张“成本分摊表”每个任务的实际GPU使用量按小时计费折算到项目预算。有了这张表业务团队会主动考虑优化自己任务的资源占用因为省下来的钱很直观。这比任何宣传话术都有说服力也避免池化变成“谁都能来蹭一张卡”的公共资源灾难。6. 选型建议与落地路径别一上来就想做全公司池化综合前面的原理、场景和坑最后给一套偏向实操的落地路径按集群规模和业务阶段来划分。6.1 按规模选型集群规模建议方案关键顾虑8卡以内不用池化做简单资源排队即可池化带来的人力和复杂度可能大于收益8-50卡K8s Device Plugin Time Slicing/MIG隔离策略要清晰显存安全是底线50-500卡引入Volcano/Kueue等调度器 vGPU或MIG DCGM监控需队列、优先级、配额和成本报表500卡以上平台级池化系统可能需要自研调度与网络规划网络拓扑、故障域、多租户策略都要做专6.2 落地第一步从推理场景开始建议按“小步快跑”顺序推进。先从在线推理场景切入把一部分业务迁移到MIG或vGPU的池化方案里因为推理任务天然适应资源弹性和共享。跑通之后再把离线批处理任务挂进低优先级队列。最后才考虑把训练任务纳入池化而且只纳入中小规模微调任务大模型预训练保持整卡独占。这样每走一步都有数据验证出问题也容易回滚。6.3 扩容采购时先看池化报表很多团队在采购GPU时只看峰值需求忽略“当前集群到底用满没有”。上了池化之后第二年做扩容规划我会习惯性先看成本分摊表如果某几个业务长期使用率低于20%先优化这些业务再谈扩容如果多团队都达到60%以上利用率还在排队那才真正需要加卡。这个逻辑听起来很朴素但做决策时特别管用。我在实际落地中的体会是GPU资源池化从来不是一个“安装一个产品就完事”的功能它更像一层跟业务负载深度耦合的调度策略。先从监控、配额、成本数据这些地基做起再把推理、批处理这些场景逐步迁进去整个池子才能稳定转起来。等技术沉淀够了再回头处理训练任务的资源编排你会觉得轻松很多。 GPU资源池化完全指南：原理、调度、场景与踩坑
半年前有个朋友让我去帮他分析GPU集群的利用率问题他的第一句话就是“卡不够用训练排期排到一个月后了”。我打开监控面板一看32张A100平均利用率不到40%很多卡凌晨到早上都是空的。这就是典型的“卡不够用又卡闲着”的矛盾。GPU资源池化要解决的根本问题就是这个把物理GPU的计算能力和显存抽象成逻辑资源统一管理、按需分配打破一张卡只能服务一个任务的传统模式让每一块卡都尽量被用满让真正需要算力的任务不用天天排队。这篇文章不打算写概念堆砌我会把池化的底层原理、不同切分方式的本质区别、调度层真正难在哪里、哪些应用场景适合池化、哪些场景硬上反而吃亏这些事一次性讲透。同时会穿插一些我实际落地时踩过、见过、补救过的坑。适合手里有GPU集群、正在做算力规划或者准备上池化的工程师和管理者阅读。1. 为什么GPU资源池化会成为基础设施标配从一个矛盾说起GPU独占模式在资源少、任务单一的时候没什么问题可一旦集群规模上到几十张卡冲突立刻出现。问题从来不是“单卡算力不够”而是“大规模的算力无法被灵活拼装”。1.1 独占模式下GPU利用率为什么这么低训练任务并不是全程把GPU打满的。数据加载、预处理、checkpoint写入、模型评估、跨卡同步等待这些阶段GPU都在空转。我见过很多PyTorch训练脚本data loader写得不好GPU利用率在20%到80%之间剧烈波动。另一个原因是团队之间的忙闲不均做CV的团队在疯狂跑实验做NLP的团队任务没排上但他们的卡已经提前预定了别人根本不能碰。这种“预设资源不动”的分配方式让全局利用率天然上不去。1.2 池化到底在“池”什么东西很多人以为池化就是把几张卡放一起这样理解太粗略。真正被池化的是四类资源第一个是计算单元也就是SM/CUDA核心控制的是并行算力第二个是显存控制的是任务能不能装得下也直接影响瓶颈第三个是显存带宽很多模型瓶颈根本不在算力而在访存第四个是GPU间互联带宽也就是NVLink/NVSwitch和PCIe通路这决定了多个GPU被组合成一个“逻辑大GPU”时通信的上限。池化做的事情简单说就是把这四类资源切成不同粒度的小块再根据任务需求动态组合分配。这跟CPU的内存分页很像把物理内存切页虚拟内存按需映射任务看到的是一个“足够大”的抽象资源空间物理上可以用任意空闲页面组合出来。1.3 什么情况下你不该池化池化不是银弹比如一个训练任务需要4张或8张H100做张量并行模型参数本身就跨卡存放在NVLink域内这个时候强行把它塞进池化调度的“共享卡”里性能损耗和通信抖动会让你怀疑人生。后面我会专门讲这个边界。2. 核心原理拆解从PCIe拓扑到MIG、vGPU与时间切片池化从实现路径上看有三个层次一层是物理卡本身怎么被切开一层是调度系统怎么管理这些切片还有一层是跨节点通信怎么做。这一章重点解决第一层。2.1 GPU直通最原始的“伪池化”GPU直通Passthrough是最先成熟起来的方案通过PCIe的VFIO技术把一张物理GPU直接透传给一个虚拟机或容器使用。它的问题是隔离性极好、性能损耗接近零但粒度就是一整张卡没法切分。在池化体系里直通通常作为基础单元存在调度器看它的时候只能决定“这张卡给谁”不能决定“这张卡的多少算力给谁”。2.2 MIG硬件级切分的真正开端NVIDIA从A100开始引入MIGMulti-Instance GPU这是池化历史上很重要的一步。MIG直接把GPU切成多个硬件级隔离的实例每个实例有独立的SM、独立L2缓存、独立显存控制器和显存切片。隔离性做到硬件级意味着一个实例的崩溃、显存耗尽、CUDA错误几乎不会影响其他实例。MIG常见切法是按计算和显存组合比如A100 40GB可以切成1g.5gb、2g.10gb、3g.20gb、7g.40gb这几种profile。注意看命名规律前面的数字代表计算切片比例比如1g代表大约1/7的计算资源后面是显存大小。H100上还有更好的切分粒度。但MIG也有明显限制必须开启MIG Mode需要重启GPU同一张卡上MIG实例之间的NVLink带宽受限profile粒度固定不像软件方案那样可以任意取显存和算力。也就是说MIG适合“需要干净隔离”的调度场景但它不是万能的。2.3 vGPU可分可调的软件虚拟化NVIDIA vGPU以前叫GRID是另一条路线。它通过GPU虚拟化驱动把一张物理GPU切成多个虚拟GPU每个vGPU可以单独指定显存大小、计算份额、编码单元数量。跟MIG比vGPU的好处是粒度和组合更灵活可以给一个任务开15GB显存加30%算力MIG做不到这么细致的任意组合。坏处是隔离性在软件层性能损耗比MIG略高且vGPU有License费用还要考虑并发数的限制。vGPU特别适合图形类负载比如云桌面、云游戏的渲染和编码需要因为它的驱动栈原生支持图形API和视频编解码的切片。2.4 时间切片最轻量也最需要警惕的共享方式时间切片是纯软件层面的共享运行层面是任务们轮流占用执行单元。时间分片、MPS等同类的共享机制在单任务独占卡时性能损失几乎为零多任务并发后算力按时间片分配每个任务都变慢。最要命的是时间切片没有显存隔离所有共享同一张卡的进程都能看到整卡显存。这不是理论风险我后面会讲一个因为时间切片显存不隔离导致的实际事故。2.5 四种方式对比共享方式隔离级别典型性能损耗分配粒度适用场景整卡直通物理隔离0-2%1卡固定大模型训练、对性能极其敏感的任务MIG硬件级隔离3-8%固定profile多租户AI推理、需要强隔离的场景vGPU软件级隔离5-15%任意可调图形渲染、云桌面、灵活切分的推理时间切片几乎无隔离并发时线性下降任意内部共享、轻量级模型、试验环境3. 调度层资源切得开不代表分得好池化的价值最终要靠调度系统体现。如果只把卡切开调度配不上整个池子还是一团乱麻。3.1 资源抽象与配额把GPU变成可计量的单位做池化第一步是把GPU抽象成能被系统识别和计算的资源描述。常见做法是把“一张物理GPU”描述成两个维度计算份额比如0.3卡、1g的MIG profile和显存大小比如15GB。对外只看这两个参数对内由调度器映射到具体物理卡和实例上。配额系统同样重要。没有配额一个团队把池子里所有资源领走其他团队只能干瞪眼。我见过很多平台把配额做成“组织→项目→用户”三级结构每个层级限制累计申请上限。配额不是用来限制业务而是为了防止某个团队“先占坑再找活干”。3.2 Kubernetes生态下的GPU调度方案现在开源场里最主流的底座还是Kubernetes。官方提供的NVIDIA Device Plugin负责把GPU作为扩展资源上报给kubelet它能做最基本的“一张卡给一个Pod”的调度。但如果要切分和共享就必须扩展调度器。NVIDIA MIG Manager可以在K8s里管MIG profilevGPU方案则会有自己的管理组件。更大规模的场景通常会引入Volcano或Kueue这类批量调度器它们支持队列、优先级、抢占、依赖关系这些复杂的调度语义。单纯用默认的K8s调度器做GPU池化很快就会碰到排序策略和配额策略都跟不上业务需求的问题。3.3 Binpack还是Spread调度策略的取舍调度策略里有个很实际的选择把任务尽量堆到少数几张卡上Binpack还是尽量分散到不同卡上Spread。Binpack能最大程度减少被占用的物理卡数量让空闲卡保持完整便于分配给需要多卡的任务Spread则能降低单卡故障或热点带来的影响但容易把卡切得很碎导致后面调度困难甚至碎片化。很多调度器默认Binpack但我在实际中更建议按负载特征混合调度推理任务可以用Binpack因为单个推理Pod占的资源小碎片影响有限训练任务尽量保持整卡避免被碎片化卡点卡住。3.4 优先级与抢占高优任务来了怎么办池化就避不开抢占。系统里随时会有高优先级的紧急任务插队低优先级的长任务正在跑的算力可能被收回。此时最怕的是凶残的硬杀直接kill进程任务不仅白跑还可能导致集群里出现一堆半写状态文件。合理做法是配合任务本身的checkpoint来设计“优雅退让”高优任务进来时调度器先通知低优任务保存状态、释放显存再调度高优任务。这是个工程活儿得训练框架、存储、调度器三方配合但值得做。很多平台的第1版都是硬杀运行一周后就会收到大量投诉然后乖乖回头补优雅退出。4. 应用场景全景AI推理是最大赢家大模型训练要小心池化对不同负载的收益差异很大。我用一个原则来判断跨节点通信越频繁、对单卡算力要求越满的任务池化收益越低任务数量多、单任务需求小、QPS波动大的场景池化收益最大。4.1 AI推理弹性扩缩容的黄金组合AI推理服务是典型的池化受益者。线上QPS有明显波峰波谷白天用户访问多夜间回落。用独占卡部署高峰要预留大量GPU低谷全部闲置用池化部署调度器可以根据QPS自动扩缩容波谷时释放出来的资源自动分配给离线任务或者其他团队。多模型还可以共享同一张物理卡Triton Inference Server配合MIG一个H100可以同时跑好几个模型实例互不干扰吞吐率拉满。推理任务单个Pod占的资源小非常契合池化的“小块可调度”逻辑。我见过一个生产环境6张A100之前只部署一个在线推荐模型高峰期勉强够、低谷全闲着后来改成池化管理同一批卡同时承载在线推理、定时批量推理和几组离线数据预处理任务整体利用率从不到30%提上到60%以上。4.2 大模型训练池化不等于把卡混在一起用大模型训练尤其数据并行、张量并行、流水线并行混合的场景跨GPU通信极其密集。NCCL的allreduce操作对网络时延和带宽极其敏感跨节点走RoCE跟本地NVLink相比性能差距可以达到数倍。如果调度器把训练任务的两个rank分到不同物理卡、不同网络域里训练性能会惨不忍睹。这条线我建议的训练策略是大模型训练任务不参与细粒度池化直接用整卡直通或整机独占的方式运行池化主要覆盖推理、中小模型微调、数据处理等弹性负载。整卡直通也不是“反池化”它本身就是调度池中一个不可切分的单元只是粒度大、不让别人共享。4.3 云桌面、云游戏和图形渲染虚拟化的老本行图形负载是GPU虚拟化的传统战场。一个用户的桌面不可能独占一张专业卡成本上完全扛不住。通过vGPU切分一张物理GPU可以同时服务多个桌面用户每个用户按规格获得对应的显存和计算份额。这类场景里视频编码单元也需要被切分因为云游戏本质上是“一边渲染一边编码推流”编码器资源的切片和GPU核心一样重要。这块要注意的是License成本。vGPU的每个实例都是按License收费的用户并发规模一大这部分的成本会非常可观。不是否定vGPU而是说做成本预算时要把许可证费用算进去别只盯着硬件采购费。4.4 科学计算和视频批处理看任务对“联想”的需求科学计算里很多MPI程序对网络同样敏感但这个领域的任务通常已经写死了通信模式不像深度学习框架有那么多自动混合并行策略所以通过池化做整机调度、按节点分配资源是可行的。视频渲染和转码则是对故障容忍度高的批处理任务中断可以重跑非常适合池化的低优先级队列把白天浪费的零散时间片全部利用起来。4.5 企业内部共享与成本分摊很多公司采购GPU后业务部门是按“我申请了X张卡”的口径做预算的但真正利用率没人统计。GPU池化落地后会天然产生一份“资源账单”DCGM采集的利用率指标加上调度器的分配记录可以按项目、部门、用户维度生成成本报表。有了这个数据后续的扩容决策就不再靠拍脑袋而是看真实负载趋势。这也是池化除了技术收益之外很多人容易忽略的管理收益。4.6 场景与方案匹配速查场景推荐方案理由大模型预训练/重训练整卡直通、整机独占通信密集不能接受共享带来的抖动在线推理多模型MIG/vGPU隔离共享弹性扩缩容多模型共存微调、中小规模训练时间切片/MIG可接受稍低性能换取资源利用率云桌面/云游戏vGPU图形API和编码器需要驱动支持视频转码/渲染时间切片批处理队列任务可重试对故障容忍内部科学计算整机级调度尽量保通信域完整5. 踩坑实录性能损耗、显存安全与“邻居干扰”池化方案选型时大家通常关注性能损耗真正上线后最折磨人的反而是隔离问题和调度策略的副作用。这里把典型的坑按排查路径展开讲。5.1 性能损耗到底多大实测数字和建议我们做过一组对比测试用同一套ResNet训练脚本分别在直通、MIG、vGPU、时间切片模式下跑。直通的性能损耗几乎为0MIG模式单实例跑损耗大概在3%到8%主要是L2和显存带宽被切片后的带宽下降导致vGPU单实例跑损耗在5%到15%时间切片在只有一个任务时基本没有损耗两个任务并发后各自吞吐量腰斩这是正常的算力均分。所以选型的时候别只看基准测试要看业务的“形态”一个推理服务本身QPS波动就大10%的损耗几乎无感知一个训练任务如果真的是满载运行5%的损耗放大到整周训练周期影响就被放大了。5.2 那个显存不隔离事故时间切片的真实风险说回时间切片。公司内部有套K8s集群通过Time Slicing把A100共享给多个Pod。排查一次GPU错误时发现某个Pod的CUDA上下文崩了之后同一物理卡上所有Pod的kernel都开始报错连其他Pod的显存数据都能被异常访问到。原因就是时间切片没有显存隔离所有Pod共享同一份物理显存一个Pod越过边界整卡都遭殃。从那之后我们的内部规范明确为时间切片只用于单租户内部或者完全可信的测试环境凡是多租户共享物理卡至少用MIG或者走vGPU。显存隔离是硬底线没有商量空间。5.3 MIG的毛病粒度不匹配和NVLink限制MIG虽然隔离性好但profile粒度固定很头疼。比如有个算法团队需要20GB显存但算力只用了1/4A100 40GB的MIG profile要么给1g.10gb显存不够要么给3g.20gb算力浪费一半。资源配额上能应对但物理卡分出来之后没法再动态调整切碎了的卡不重建MIG实例就改不了规格。还有一点MIG实例之间的NVLink带宽被阉割得很厉害。多卡训练想跨MIG实例通信得绕PCIe或者走网络性能下降明显。这个在规划调度时就要提前设计MIG实例主要用于单卡推理不用于需要多卡高速互联的训练。5.4 调度器抢占任务被杀的修复思路有个平台第1版上线时紧急高优先级任务到达后直接抢占低优先级的训练任务。运维群里当天就炸了好几个跑了一天的长训练任务进程被强杀checkpoint只存到几个小时前白算了一大半。后来我们改成两层机制第一调度器抢占前先向运行中的任务发送优雅退出信号任务收到信号后会先存checkpoint再退出第二K8s层面配合使用PodDisruptionBudget普通任务最多同时被打断20%关键任务干脆禁止抢占。虽然还是会被打断但至少能恢复到最新checkpoint损失小很多。这个排序是保护关键任务 优雅退出 尽量少中断。5.5 监控与成本报表没有数据就别谈优化GPU池化做得再好没有监控数据证明它的价值推动起来很困难。建议从第一天起采集这些指标GPU利用率、显存使用、显存带宽、NVLink带宽、温度功耗还有任务维度的“资源申请量vs实际使用量”。NVIDIA DCGM是标准工具自带Prometheus exporter配合Grafana就能出一套基础的GPU观测大盘。更重要的是一张“成本分摊表”每个任务的实际GPU使用量按小时计费折算到项目预算。有了这张表业务团队会主动考虑优化自己任务的资源占用因为省下来的钱很直观。这比任何宣传话术都有说服力也避免池化变成“谁都能来蹭一张卡”的公共资源灾难。6. 选型建议与落地路径别一上来就想做全公司池化综合前面的原理、场景和坑最后给一套偏向实操的落地路径按集群规模和业务阶段来划分。6.1 按规模选型集群规模建议方案关键顾虑8卡以内不用池化做简单资源排队即可池化带来的人力和复杂度可能大于收益8-50卡K8s Device Plugin Time Slicing/MIG隔离策略要清晰显存安全是底线50-500卡引入Volcano/Kueue等调度器 vGPU或MIG DCGM监控需队列、优先级、配额和成本报表500卡以上平台级池化系统可能需要自研调度与网络规划网络拓扑、故障域、多租户策略都要做专6.2 落地第一步从推理场景开始建议按“小步快跑”顺序推进。先从在线推理场景切入把一部分业务迁移到MIG或vGPU的池化方案里因为推理任务天然适应资源弹性和共享。跑通之后再把离线批处理任务挂进低优先级队列。最后才考虑把训练任务纳入池化而且只纳入中小规模微调任务大模型预训练保持整卡独占。这样每走一步都有数据验证出问题也容易回滚。6.3 扩容采购时先看池化报表很多团队在采购GPU时只看峰值需求忽略“当前集群到底用满没有”。上了池化之后第二年做扩容规划我会习惯性先看成本分摊表如果某几个业务长期使用率低于20%先优化这些业务再谈扩容如果多团队都达到60%以上利用率还在排队那才真正需要加卡。这个逻辑听起来很朴素但做决策时特别管用。我在实际落地中的体会是GPU资源池化从来不是一个“安装一个产品就完事”的功能它更像一层跟业务负载深度耦合的调度策略。先从监控、配额、成本数据这些地基做起再把推理、批处理这些场景逐步迁进去整个池子才能稳定转起来。等技术沉淀够了再回头处理训练任务的资源编排你会觉得轻松很多。