题目重点：MLE 面经中的 60GB GPU serving 追问没有给模型尺寸；本文以权重、激活、工作区、并发和余量推公式并示例验证思路。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版以单实例、固定模型版本和输入形状讨论；60GB 按设备可用显存上限，实际 runtime 报告值可能更低。
- 权重、框架、算子工作区、激活或 KV cache、输入/输出缓存及碎片安全余量均计入；不能只用 60GB 除以权重大小。
解题路线
- 确定模型参数量 P、数值精度 bytes/parameter、是否量化和额外常驻张量，先得权重及运行时常驻内存 M_fixed。
- 按代表性和最长输入测 batch 从 b 到 b+1 的峰值显存增量 M_item；Transformer 序列长度、KV cache 和注意力实现会改变增量，不能固定假设与 b 完全线性。
- 给安全余量 M_margin 和并发实例工作区 M_concurrent，得到初估 b≤floor((60GB−M_fixed−M_concurrent−M_margin)/M_item)。
- 用真实输入长度分布、并发、warmup 和峰值流量压测，逐步提高 b，检查 OOM、p95 延迟、吞吐和 batch 等待时间；最终 batch 可能受时延先于显存限制。
手动走一遍
纯示例：若权重与固定缓存共 30GB、工作区 5GB、余量 7GB、每条样本峰值增量 0.6GB，则显存粗上限 floor((60−30−5−7)/0.6)=30。若等待凑满 30 条使 p95 超标，应选择更小 batch；这些数字都不是题目给的模型。
规模与取舍
模型计算一般随 batch 增大而增大，但 GPU 利用率可先改善后饱和；服务容量要同时看 batch 吞吐、到达率和排队。内存估算是上界筛选，最终由实测峰值与尾延迟决定。
易错点与追问
容易失分的边界
- 直接说 60GB 能放多少样本，不问模型权重和输入 shape。
- 只看平均显存，忽略峰值、碎片与框架工作区。
- 显存刚好放满 batch，任何输入变长就 OOM。
- 吞吐提高但请求排队等 batch，p95 变差。
继续深挖
- 序列长度从 512 增到 2,048，batch 为什么可能大幅下降？
- 量化权重节约的显存是否全能用于 batch？
- 动态 batch 如何在不同请求长度和延迟目标之间调度？
