GPU 任务排队前，先把容量账算明白

云原生 AI 平台最容易出现的误区，是把“有多少张卡”直接等同于“能接多少任务”。调度器真正面对的是显存、执行时间、队列等待和租户配额。任意一项没有边界，扩容都可能只是把积压移到别处。

容量单位要落到任务

先给任务补齐模型版本、资源请求、预估运行方式和优先级。资源请求不能只写 GPU 数量，还要区分整卡、切分实例以及是否允许共享。调度记录里同时保留提交、入队、绑定节点、开始执行和结束时间，排队慢还是执行慢才能分开判断。

背压应从入口生效

队列需要长度或等待时限，达到边界后明确拒绝、延后或转入低优先级池。继续接收而不反馈，只会让调用方误以为任务正在正常推进。取消请求也要能沿着调度器传到执行端，避免用户已经放弃，GPU 还在跑无用任务。

压测记录什么

使用构造任务验证时，记录模型、输入规模、资源配置、到达方式和观察窗口。至少同时看队列深度、等待时间、调度失败、GPU 利用与显存余量。没有这些条件，单独一个吞吐数字没有复用价值。

容量不是一张静态表。任务结构或模型版本变化后，原来的估算就要重做。把边界写进配置和告警，比在故障后临时加副本可靠。