批次从 1 调到 8，吞吐量未必就提高 8 倍；如果显存被权重和缓存占满，服务可能先出现延迟抖动或显存溢出。做好AI模型部署时GPU显存分配与批次大小调优，关键是区分固定占用与随批次变化的占用，再用实际请求验证，而不是只看显卡标称容量。
先弄清显存都被谁占用
推理服务的显存通常包括模型权重、输入与中间张量、KV缓存、框架和推理引擎开销，以及显存分配器预留的空间。权重主要取决于参数量和精度：以常见存储方式粗略估算，FP16或BF16权重约占每个参数 2 字节，INT8约占 1 字节，量化还会有比例因子等额外开销。这只是权重估算，不是整卡需求。
对逐 token 生成的 Transformer，KV缓存会随并发序列数和上下文长度增加。其规模还受层数、注意力头配置和缓存精度影响；采用分组查询注意力的模型，缓存需求可能不同于普通多头注意力。因此，同一模型在短输入、长上下文和多路并发下，显存峰值不能简单视为相同。
四个容易踩的分配误区
把空闲显存当成可全部使用
显卡显示尚有余量，不代表这些空间都能留给模型：CUDA上下文、推理框架、临时张量及其他进程也会占用显存。硬把容量用满，容易在请求长度变化时触发 OOM。应在目标并发和较长输入下测峰值，并保留余量；预留约 10%–20% 可作为初始经验值，具体比例要按框架、负载波动和卡上其他进程调整。
只按权重大小计算批次
权重装载成功不等于批次有空间。生成服务的KV缓存可能随并发与上下文增长；图像或音频模型也会因输入尺寸、切片数等改变中间张量规模。调参时要把输入形状和输出长度纳入测试，不能只用短样例估算。
把批次越大等同于吞吐越高
批次增大通常能提高硬件利用率，但会增加排队时间和显存压力；批次太小则可能让计算资源利用不足。动态批处理能合并不同时间到达的请求，但等待凑批也会影响延迟。面向交互请求时，应同时关注首 token 延迟、生成速度和高分位延迟；离线任务则可更偏重总吞吐。
忽略显存碎片与并发进程
多轮分配、不同长度请求或其他进程占用，可能让可用空间变得零散。即使监控显示尚有显存，连续的大块申请也可能失败。排查时检查同卡进程、分配器统计和服务日志；不要仅凭单次显存读数判断容量足够。
用递增测试找到可用批次
- 固定测试条件：记录模型版本、精度、输入长度、最大生成长度、并发方式和是否启用KV缓存。不同条件的结果不要直接比较。
- 从小批次开始：先用批次 1 确认服务稳定，再逐级增加，例如每轮翻倍；接近显存上限后改为较小步进。每档都覆盖预期的长短请求组合。
- 同步记录指标：观察峰值显存、tokens/s、请求延迟、队列等待和错误率。吞吐不再明显增加，或延迟、溢出风险开始恶化时，不要继续盲目加批次。
- 验证真实并发：让多路请求同时进入，覆盖长上下文与输出上限附近的情况；至少重复多轮，确认峰值和服务稳定性，而非只看一次成功结果。
- 再做资源取舍：比较降低精度、缩短最大上下文、限制并发或调整批次上限的效果。每种方法都有代价：量化可能影响数值表现，限制上下文会约束请求，减小批次则可能降低吞吐。
例如在 NVIDIA L4 这类推理卡上部署文本生成服务，也应按实际模型、精度和输入长度测量，而不能仅凭显存容量推断“能跑几个请求”。卡型只能提供边界条件，最终批次仍取决于模型结构、引擎实现与业务请求分布。
常见问题
显存没满，为什么仍然会 OOM？
峰值申请可能高于监控采样读数，也可能受到碎片、临时张量或其他进程影响。结合错误日志和峰值监控排查更可靠。
应该优先加批次还是加显存余量？
先满足目标负载下的稳定性，再逐步提高批次。若长输入或并发变化明显，应优先保留余量，避免以偶尔跑通作为容量标准。
服务批次和离线批次要用同一设置吗？
不一定。服务通常更关注延迟与并发波动；离线处理可接受等待，更适合在稳定输入条件下测试较大批次。
归根结底，AI模型部署时GPU显存分配与批次大小调优不是找一个脱离场景的最大数字，而是用目标请求测出吞吐、延迟和显存风险都可接受的范围，并给运行波动留出空间。
