GPU 资源配额：多租户平台先防止一个团队吃光集群

GPU 资源配额：多租户平台先防止一个团队吃光集群

一、GPU 比 CPU 更需要配额

云原生 AI 平台里，GPU 是最昂贵也最容易被争抢的资源。一个团队提交几个长时间训练任务，或者一个租户发起大量推理请求，就可能吃光集群。没有配额，多租户只是名义上的隔离。

GPU 资源配额不仅是成本控制，也是稳定性保护。平台要明确谁能用多少、什么时候能借用、超额时怎么排队。

二、配额要分层

flowchart TD A[集群 GPU] --> B[组织配额] B --> C[项目配额] C --> D[任务配额] D --> E[Pod 调度]

组织配额控制总量，项目配额控制场景，任务配额控制单个工作负载。只设 namespace limit 不够，因为不同任务类型的优先级和生命周期不同。

还要区分训练、批推理、在线推理。在线推理需要稳定保留，批任务可以排队，训练任务可以设置时间窗口。

三、配额对象要可查询

type GpuQuota = { tenantId: string guaranteed: number burstable: number used: number queueDepth: number }

guaranteed是保底资源，burstable是可借用资源。这样平台既能保证核心团队资源，也能提高空闲 GPU 利用率。

gpu_quota_policy: enforce_namespace_quota: true support_borrow_idle_gpu: true preempt_low_priority_jobs: true show_quota_to_user: true

配额要对用户可见。看不到剩余额度，用户就会以为平台调度不稳定。

四、超额要有明确反馈

资源不足时，不要只让 Pod Pending。平台应该告诉用户：当前配额不足、前面有多少任务、预计何时可运行、是否可以降低规格。

还要记录配额使用。长期满额说明需要扩容或优化；长期空闲说明配额分配不合理。

配额系统还要支持排队策略。资源不足时，任务是等待、降级、抢占还是失败，要根据优先级决定。训练任务可以等待，在线推理通常不能长期排队。

gpu_queue_policy: online_inference: max_wait_seconds: 5 priority: high batch_inference: max_wait_minutes: 30 priority: medium training: max_wait_hours: 12 priority: low

抢占也要有边界。低优先级任务被抢占前，应保存检查点或输出当前进度。否则抢占只是把成本浪费转移到任务失败上。

平台还要给用户容量建议。比如“当前任务请求 4 张 GPU，预计等待 40 分钟；改为 2 张 GPU 可立即运行但耗时更长”。这种反馈比单纯 Pending 更有帮助。

从运营角度看，配额使用率能反映平台健康。长期借用资源很多，说明保底配额太低；长期抢占很多，说明批任务和在线任务混得太近。

配额变更也要治理。线上平台最怕临时把某个团队配额调高，结果忘记调回，后续容量计划全部失真。每次变更都应该有申请人、原因、生效时间、过期时间和影响范围。

quota_change_policy: require_reason: true require_expire_at: true notify_tenant_owner: true audit_all_changes: true

如果平台支持临时突发配额，最好单独计量，不要把它混进保底配额。保底资源代表长期承诺，突发资源代表短期借用，两者混在一起会让用户误判自己的真实容量。

五、总结

GPU 资源配额要按组织、项目和任务分层，支持保底、借用、抢占和可见反馈。

多租户平台先防止一个团队吃光集群，才能谈资源效率。