动态GPU渲染负载扩缩：MIG与Kubernetes选型及KEDA咨询

直接对应你的三个核心疑问：

• 你提到的MIG如果是指GCP托管实例组（Managed Instance Group），它原生不支持按作业队列长度直接计算扩缩数量的能力，仅支持基于CPU、内存、自定义监控指标的扩缩规则，自定义配置成本很高；如果你指的是NVIDIA MIG（多实例GPU），首先你当前使用的Tesla T4显卡为图灵架构，不支持该特性，且MIG本身只是GPU硬件分区技术，完全不具备扩缩容调度能力。
• 你的渲染作业场景非常适合用Kubernetes实现，是目前落地成本最低、最贴近无服务器使用体验的方案。
• 你对KEDA的理解完全正确，KEDA就是实现你需求的核心组件，不需要额外做定制开发就能完全匹配你要的扩缩逻辑。

为什么原生MIG方案不推荐 #

你目前了解到的基于CPU使用率的扩缩，是GCP托管实例组的原生能力，它的核心逻辑是围绕节点资源使用率调整实例数。如果硬要用它实现按作业数扩缩，需要自己开发适配器把队列积压的作业数同步到Cloud Monitoring，再配置单实例承载16个作业的指标阈值，不仅开发维护成本高，还缺少作业调度、故障自动重试、缩容到0、GPU细粒度共享这些渲染场景必备的能力，整体性价比很低。

补充说明：NVIDIA MIG是安培及更新架构GPU（A100、L4、H100等）才支持的硬件分区功能，作用是把单块物理GPU切分成多个硬件隔离的小GPU实例，本身和扩缩容调度没有任何关系。就算你后续更换支持MIG的显卡，也还是需要单独的调度组件实现按作业数扩缩的逻辑。

K8s + KEDA的适配逻辑 #

整套方案完全贴合你要的无服务器体验，不需要人工干预实例数量：

• 所有渲染作业统一提交到消息队列（SQS、GCP Pub/Sub、RabbitMQ、Redis流等KEDA均原生支持）
• KEDA直接监听队列的待处理消息数，按照你配置的「单副本承载作业数」自动计算需要的Pod副本数：比如配置单副本承载16个作业，100个待处理作业时会自动做向上取整计算，最终启动7个副本，完全匹配你提到的实例数计算逻辑
• K8s集群搭配自带的Cluster Autoscaler（GKE、EKS等托管K8s服务均默认支持），当现有节点资源跑不下新增的Pod时，会自动创建对应数量的n1-standard-16 + T4规格节点；当队列为空后，会自动把Pod副本缩到0，再自动删除空闲节点，全程没有闲置资源浪费。

配置调整说明 #

你提供的两份示例配置只需要修改两处即可直接使用：

1. 调整KEDA ScaledObject的队列长度阈值，把queueLength从1000改成16，代表每16个待处理作业对应1个服务副本，刚好匹配你单实例并行16个作业的理论上限：

# 其余配置保持不变
    metadata:
      queueURL: myQueue
      queueLength: "16" # 修改为单副本可承载的作业数
      awsRegion: "eu-west-1"

2. 调整Deployment的GPU资源配置：你当前配置的nvidia.com/gpu: 1代表每个Pod独占1块T4显卡，会导致单台n1-standard-16节点只能跑1个作业，资源严重浪费。如果你的渲染作业不需要强GPU硬件隔离，直接开启GPU时间分片共享能力（托管K8s的GPU插件、NVIDIA GPU Operator均自带该功能），给每个作业Pod分配1/16块GPU的资源配额，就能让单台节点刚好并行跑16个作业，资源利用率拉满。如果后续压测发现单节点实际稳定并行上限低于16（比如只能跑12个），只需要把KEDA里的queueLength改成对应压测值即可，不需要改动其他逻辑。

正式上线前先做一轮基准测试，确认单台n1-standard-16 + T4实例实际能稳定并行的作业数，不要直接使用理论值16，避免单节点负载过高导致渲染超时、失败。如果后续需要更强的GPU隔离能力，再考虑更换支持MIG的显卡，把单块GPU切分成对应数量的MIG实例，每个作业Pod绑定1个MIG实例即可，上层KEDA的扩缩逻辑完全不需要改动。

内容的提问来源于stack exchange，提问作者Michael Joseph Aubry