模型训练并发上来先守住哪条线训练或推理负载增加时先问清楚任务类型。在线推理受尾延迟和队列等待约束离线训练更关心吞吐、检查点和数据管道。把两者都归结为“多开 worker、多攒 batch”很容易让 GPU、主机内存或数据服务先失去控制。先给请求和队列设边界在线系统应限制单个请求的输入长度、输出上限、并发数和等待时间。动态批处理不能只按请求个数攒批变长输入会让同样数量的请求消耗完全不同的显存应使用模型实际的 token、图像尺寸或序列长度估算并为运行时开销留余量。队列满时返回明确的拒绝或延迟状态而不是无限堆积。def admit(tokens: int, used: int, limit: int) - bool: return 0 tokens limit and used tokens limit这个检查只是准入条件。真正的显存占用还取决于模型、精度、KV cache、并行方式和框架版本因此限额必须通过压测校准并持续观察 OOM、排队时间、批大小和请求取消率。模型服务异常时要让等待中的请求得到失败结果不能留下永远不会完成的 future。数据管道要保护训练进程训练侧的数据读取、解码和增强常常比 GPU 更先成为瓶颈。增加 DataLoader worker 前先测磁盘、网络、CPU、文件描述符和共享内存的实际余量。worker 太多会增加上下文切换和内存压力pin_memory、预取数量也不该成为无条件的默认设置。检查点、日志和样本缓存应写入有容量监控的存储训练中断后要能从一致的状态恢复。用降级和隔离应对高峰将训练作业与在线推理隔离资源池避免批量任务抢走实时服务的 GPU。对于推理可在压力上升时缩短上下文、关闭可选功能或只接受较小请求但要把降级状态展示给调用方。不要依赖某个固定的显存碎片化参数或某种注意力实现作为通用解法这些优化需结合具体模型、驱动和工作负载验证。发布前演练超长输入、突发并发、GPU 重置、数据源变慢和队列恢复。容量治理的目标不是宣称一个漂亮吞吐值而是在资源接近边界时仍能保护任务、解释状态并安全恢复。指标要按模型版本、硬件类型和请求类别分开看。平均延迟常会掩盖少量大请求造成的排队单一 GPU 利用率也无法解释 CPU 解码或网络读取问题。对训练任务记录数据版本、随机种子和资源配置对推理任务记录限额命中与撤销原因。这样当容量变化时团队能从数据判断该调整模型、队列还是基础设施而不是只靠提高并发来掩盖问题。每次调整都应保留回退条件与负责人。持续复盘。