在大模型与 AI 应用全面落地的当下，GPU 已成为企业算力基建中最昂贵的核心资产。然而绝大多数企业在生产环境中都面临着同一个尴尬的现实：采购成本居高不下，但实际 GPU 平均利用率长期徘徊在 30% 以下，大量算力在闲置中被浪费。尤其是在广州、深圳等珠三角科创企业密集的区域，随着 AI 创业公司与传统制造业数字化转型的加速，算力供需矛盾与成本压力愈发凸显。

我们团队基于 Kubernetes 搭建了统一的 GPU 算力资源池，通过硬件分区、软件共享与智能调度三层优化，将集群整体 GPU 利用率从不足 32% 提升至 80% 以上，等效实现算力翻倍。本文从工程落地视角，完整复盘整个方案的技术选型、架构设计、实施步骤与踩坑经验。

一、传统 GPU 调度模式的核心痛点

在未做池化改造之前，我们的 K8s 集群采用原生 NVIDIA Device Plugin 方案，GPU 以整卡为单位进行调度。这种模式在训练场景下尚且合理，但在推理、开发测试、小模型微调等混合负载场景下，暴露出了严重的资源浪费问题。

首先是资源粒度粗放。默认调度模式下，一个 Pod 申请nvidia.com/gpu: 1就会独占整张物理卡。对于 ASR 语音识别、OCR 文字提取、向量检索这类轻量推理服务，单副本显存占用往往不足 10GB，却要占着一张 80GB 显存的 A100 跑一整天，计算核心利用率常年低于 20%。更棘手的是，不同业务线各自申请 GPU 资源，部门之间形成资源孤岛，A 部门卡闲置、B 部门排队等资源的情况时有发生。

其次是资源碎片化严重。不同型号 GPU 混部时，调度器只能按整卡匹配，小模型无法塞进大卡的剩余空间，大模型又凑不齐足够的整卡节点。随着业务迭代，集群里逐渐出现大量 "半空闲"GPU 节点，整体吞吐上不去，扩容又觉得亏，陷入两难境地。

最后是运维成本高企。每上线一个新的 AI 服务，都要单独评估 GPU 规格、找空闲节点、手动调配，交付周期长。尤其是在多租户场景下，配额管控粗放，无法做到细粒度的算力计量与成本分摊，部门结算全靠估算。

二、GPU 资源池化的技术方案选型

针对上述痛点，我们调研了业界主流的四种 GPU 共享技术路线，各自的适用场景与隔离能力差异显著。

MIG 即多实例 GPU，是 NVIDIA 从 Ampere 架构开始引入的硬件级分区技术。它可以将一张物理 GPU 在硬件层面切分为多个完全隔离的实例，每个实例拥有独立的计算核心、显存与缓存，故障互不影响。以 A100-40GB 为例，最多可切分为 7 个 1g.5gb 实例。这种方案的隔离性最强、性能最稳定，是生产环境多租户场景的首选。缺点是只支持特定型号 GPU，且分区规格固定，灵活性不足。

时间分片是驱动层的软件共享方案，通过快速上下文切换让多个任务轮流使用 GPU，类似 CPU 的时间片调度。它的优势是兼容几乎所有 NVIDIA 显卡，无需特殊硬件支持，配置简单。但缺点也很明显：没有真正的并行，任务交替执行会带来上下文切换开销；显存是共享池，没有硬件隔离，容易出现 "邻居噪声" 干扰，极端情况下一个任务显存溢出会影响整张卡。适合开发测试环境或内部可信 workload 使用。

vGPU 虚拟化方案以 HAMi 等开源项目为代表，在 K8s 调度层做 GPU 资源虚拟化，支持算力与显存的细粒度切分，算力最小可切到百分之几的粒度，显存可精确到 1GB 级别。它对上层应用透明，业务代码无需修改即可接入，灵活性很高。隔离性介于时间分片与 MIG 之间，通过内核驱动做资源限制，适合企业内部多业务混部场景。

DRA 即动态资源分配，是 Kubernetes 1.32 后正式 GA 的原生特性，用 ResourceClaim 替代传统的设备插件计数模式，可以表达更复杂的资源诉求，比如 "4 张 80GB 以上、同 NVLink 域的 Hopper 架构 GPU"。它代表了未来的演进方向，但目前生态还在完善中。

我们最终采用的是 "MIG 为主、vGPU 为辅、时间分片补位" 的混合策略。生产推理业务优先用 MIG 保证隔离性与稳定性，内部开发与轻量任务走 vGPU 提高灵活性，少量旧型号显卡则开启时间分片充分利旧。

三、基于 K8s 的 GPU 算力池化架构设计

整个算力池化架构自上而下分为四层，依托 Kubernetes 原生能力做扩展，不侵入业务代码。

最上层是接入与配额管理层，负责统一的资源入口、多租户配额管控与计费计量。所有业务方通过统一平台提交算力申请，系统根据部门配额自动审批与调度，支持按算力使用量、显存占用、运行时长等多维度计费，解决了以往成本分摊不清的问题。

第二层是统一调度层，在原生 K8s 调度器基础上做扩展。核心是自定义调度插件，实现负载感知调度、拓扑感知调度与碎片整理三大能力。调度时不仅看节点剩余资源量，还会参考实时 GPU 利用率、显存占用率与算力碎片率，优先把任务打到负载低、碎片少的节点，避免越调度碎片越多。

第三层是资源抽象层，通过 NVIDIA GPU Operator 与自定义设备插件，将物理 GPU 抽象为 MIG 实例、vGPU 配额、时间分片副本等多种可调度资源，统一注册到 K8s 资源模型中。业务 Pod 只需在 YAML 里声明对应资源类型，无需关心底层具体是哪张卡、哪个节点，真正实现算力池化。

最底层是基础设施层，包括 GPU 计算节点、高速 RDMA 网络与并行存储。节点按 GPU 型号、显存规格、是否支持 MIG 等维度打标签，通过污点与亲和性实现不同等级业务的物理隔离。高速网络是跨节点池化的基础，尤其是多卡并行训练场景，RDMA 网络能大幅降低通信开销。

这套架构的核心设计思想是 "池化而不僵化"。既打破了单卡单节点的资源边界，形成统一算力池子；又保留了足够的分级与隔离能力，不同 SLA 等级的业务跑在不同资源池里，互不干扰。

四、落地实施步骤与配置实战

整个落地过程分四个阶段推进，我们在广州机房的生产集群上用了两周时间完成全量切换，业务无感知。

第一步是基础环境准备与 GPU Operator 部署。先确认集群版本在 1.26 以上，容器运行时用 containerd，网络插件选 Calico。然后通过 Helm 部署 NVIDIA GPU Operator，它会自动管理驱动、容器运行时、设备插件等全套组件，比手动安装省心很多。部署时注意开启 MIG 管理器与节点标签自动发现，方便后续统一纳管。

第二步是 MIG 资源划分与注册。我们对所有 A100 节点统一启用 MIG，采用 mixed 混合策略，支持同一节点上存在不同规格的 MIG 实例。具体配置通过 ConfigMap 下发，MIG Manager 会自动应用到节点上。比如针对主流的 7B-13B 级推理模型，我们主要划分 2g.10gb 与 3g.20gb 两种规格；轻量的 Embedding 与 OCR 服务则用 1g.5gb 规格。划分完成后，节点上会注册出对应数量的nvidia.com/mig-1g.5gb这类可调度资源。

第三步是 vGPU 扩展部署。对于不支持 MIG 的 RTX 系列与旧型号 T4 卡，我们部署了 HAMi vGPU 调度器。它以扩展调度器的形式接入 K8s，不会替换原生调度器。安装完成后，每张 GPU 会被虚拟化成多个 vGPU 实例，业务 Pod 申请nvidia.com/vgpu资源即可使用。我们设置了单卡最大超配比为 1:4，兼顾利用率与服务稳定性。

第四步是统一标签体系与资源池划分。我们给所有 GPU 节点打上 gpu 型号、显存大小、MIG 能力、算力等级等标签，然后通过节点亲和性与污点将集群划分为生产推理池、训练池、开发测试池三个逻辑池。生产池只跑 MIG 实例，稳定性最高；开发池用 vGPU 超配，性价比最高。业务方根据自身 SLA 等级选择对应池子提交任务。

五、调度策略深度优化

资源池化只是第一步，要真正把利用率提上去，调度策略才是关键。我们在原生调度基础上做了三项核心优化。

第一项是负载感知调度。默认调度器只看资源申请量，不看实际使用量，很容易出现 "申请很多但用得很少" 的节点堆积。我们在调度插件里接入了 Prometheus 的实时监控数据，打分时综合考虑剩余可分配资源、当前实际利用率、显存占用率三个维度。对于同样剩余配额的两个节点，优先把新任务调度到当前实际负载更低的节点上，让全集群负载更均衡。

第二项是拓扑感知调度。针对多卡推理与训练任务，调度时会感知 GPU 之间的拓扑关系，优先把需要通信的副本调度到同一 NVLink 域或同一 PCIe 交换机下的 GPU 上，减少跨节点通信延迟。对于大模型张量并行场景，这个优化能带来 20% 以上的端到端推理速度提升。

第三项是碎片整理与动态重构。集群运行一段时间后，MIG 分区会出现碎片化，比如一张卡上剩两个不连续的小分区，放不下一个中等规格的任务。我们开发了碎片检测控制器，定期扫描全集群的碎片率，当某节点碎片率超过阈值且空闲资源充足时，自动触发低峰期 MIG 重构，调整分区规格，把碎片拼成大块可用资源。这个机制让集群长期保持较高的资源调度成功率。

除此之外，我们还引入了优先级与抢占机制。高优生产业务拥有抢占权限，低优先级的测试任务在资源紧张时会被自动驱逐，保证核心业务的算力供给。被驱逐的任务进入排队队列，等资源释放后自动恢复运行，整体体验接近批量调度系统。

六、实测效果与收益分析

改造完成后，我们对集群运行了一个月的持续观测，各项指标提升非常显著。

资源利用率方面，改造前集群 GPU 平均计算利用率约 32%，高峰期也不到 50%；改造后日常平均利用率稳定在 78% 到 83% 之间，高峰期可达 90% 以上。相当于同样的硬件投入，现在能承载两倍以上的业务负载。单节点推理副本承载量从平均 8 个提升到 48 个，集群密度翻了数倍。

业务交付效率方面，以前新业务上线申请 GPU 资源，走流程加找节点调试至少要半天；现在通过算力池自助申请，分钟级即可交付容器环境。弹性伸缩也更灵活，流量高峰自动扩容副本，低谷自动释放，真正做到按用量付费。

成本收益上，我们广州机房现有二十多张 A100，按利用率翻倍计算，等效于省出了二十多张卡的算力。按当前市场算力租赁价格折算，每年仅算力成本就能节省数百万元。而且随着业务量增长，池子越大、负载越杂，池化的摊薄效应就越明显。

稳定性方面，MIG 硬件级隔离保证了租户之间几乎零干扰，业务推理延迟波动控制在 5% 以内，服务可用性保持在 99.9% 以上。vGPU 池由于做了超配比控制，也未出现明显的性能互相影响。

七、踩坑经验与优化建议

整个落地过程也踩了不少坑，这里分享几条最有价值的经验。

第一，MIG 分区规划要提前做足功课。MIG 不是分得越细越好，分区太小会导致大任务调度不进去，分区太大又浪费。建议先梳理业务的显存与算力需求画像，再反推分区规格，尽量用两到三种主力规格覆盖 80% 以上的业务，规格太多反而加剧碎片化。

第二，不要盲目追求高超配比。vGPU 与时间分片的超配比不是越高越赚，超过临界点后上下文切换开销陡增，整体吞吐反而下降。不同业务类型的耐受度不同，推理业务可以高一些，训练业务建议保守。我们的经验是推理场景 1:3 到 1:4 比较均衡，训练场景不建议超过 1:2。

第三，监控体系必须先行。池化之后资源关系变复杂，如果没有细粒度监控，出了问题根本定位不到是哪块卡、哪个实例、哪个容器的问题。建议从 GPU 硬件级、MIG 实例级、容器级、业务级四层做监控指标采集，显存、算力、温度、功耗都要覆盖。

第四，网络是容易被忽略的瓶颈。GPU 池化后单节点跑的容器数量大增，东西向流量也随之增长，如果网络带宽跟不上，很容易出现 GPU 在等数据的情况。高速网卡与 RDMA 在大规模集群里是必选项，不要省这部分成本。

第五，循序渐进，不要一上来全量切。建议先从非核心的测试与开发环境试点，跑通流程、验证稳定性后再逐步迁移推理业务，最后再考虑训练业务接入。我们就是先在测试集群跑了两周，没问题再切生产流量，整个过程业务零中断。