VeriLoop E2 出现“加载得进、一推理就断”时，先判断主因再调参，比同时把批大小和量化档各降一档有效得多。这类报错通常不是显存真的少一大截，而是峰值出现在生成中途或某一批请求里，把本来就不厚的余量吃掉了。可操作的做法是单变量隔离：固定输入与上下文长度，先只改批大小，再只改量化数值精度档，各自记录峰值显存和是否跑完，最后对照看谁的影响更大。

先别同时拧两个旋钮。把输入长度、上下文、并发固定住，只改批大小，记录峰值显存与是否跑完；再只改量化精度档，记录同一份输入的峰值显存和输出变化。若最小批仍失败、换低精度档能跑通且峰值显存明显下降，主因偏向量化档；若最小批能跑通、批大小一升就断，主因偏向批大小。结论只在你这套硬件与框架版本下成立，换更长输入要重新核对。

先复现一次「差一点」的失败

目标是把“偶尔崩”变成可重复的失败记录。做法：准备一个固定长度的输入文件，固定 max_new_tokens，并发固定为 1，反复跑同一段输入，直到稳定复现。记录四件事：报错原文、失败发生的时间点、当时的输入长度、显存峰值的来源。

# 失败记录模板
复现次数: 第 3/5 次
失败时间点: 生成到约第 N 个 token 时
报错原文: <粘贴完整 traceback 或服务端返回体，不要只写 OOM>
输入长度: prompt 约 X token, max_new_tokens = Y
批大小: 1
量化档: <当前档位名称>
显存峰值: 采样到的最大值 Z MiB
采样方式: 命令行轮询 / 框架内峰值统计

显存峰值必须注明来源，否则后面的对比没有意义。命令行轮询可以这样起一个后台采样：

nvidia-smi `--query-gpu`=timestamp,memory.used,memory.total `--format`=csv -l 1 > mem.log

轮询间隔较粗，可能错过瞬时峰值。如果框架自身提供峰值统计，优先用框架读数，例如在 PyTorch 里推理前后各取一次峰值：

torch.cuda.reset_peak_memory_stats()
run_inference(...)
print(torch.cuda.max_memory_allocated() / 1024**2)

命令行轮询和框架峰值统计都记也可以，只要同一组对比始终用同一种来源。失败时间点很关键：如果模型刚加载完就没跑起来，问题多半在显存基线本身；如果是跑到中途才断，通常和 KV 缓存随序列增长、或批内某条长输入有关。

只动批大小，观察峰值显存的变化斜率

保持输入、上下文长度、量化档完全不变，只改批大小，取三个值即可，比如 1、2、4，或者按你的服务实际支持的区间取三档。每档至少跑两次，记录是否跑完和峰值显存读数。

看两件事：批大小翻倍时峰值显存是否近似阶梯上升，以及上升的斜率是否还在你的余量之内。如果批大小 1 就已经贴着上限，说明余量本来就不够；如果批大小 1 很宽裕、4 直接断，说明批大小是敏感变量，要重点压。批大小对显存的影响通常不是纯线性，attention 相关开销和运行时缓冲会让斜率在某个点突然变陡，所以只取两档容易误判，三档更稳。这里只需要观察趋势，不必套用别人的数值对照表。

只动量化的数值精度档位

把批大小固定回能跑通的那一档（通常是 1），只切换量化数值精度档，同一份输入、同一 max_new_tokens，逐档记录峰值显存，同时把输出文本落盘做对照。

输出差异只写能直接观察到的现象：结构格式是否还稳定、是否出现重复或提前截断、关键信息是否漏掉、长文本里是否开始跑题。不要写“精度下降多少”这类没有对照标准的结论；不同量化实现在同一档位下的表现也不完全一样，需要结合你实际使用的加载方式和后端确认。这一步的目标只是分离精度档带来的显存差异，不是给精度打分。

两个变量一起动，和单变量结果对照

把前两步的记录并排放，再做一组组合验证，用来确认不是两个效应的叠加在误导你。

判定规则：如果最小批大小（通常是 1）仍然失败，而换更低量化档后能跑通、且峰值显存下降明显，主因偏向量化档。如果最小批大小能稳定跑通、批大小一升就断或峰值显存阶梯抬升很快，主因偏向批大小。如果两者都动才有明显改善、单动任何一项都不够，说明是叠加效应，余量本身已经很小，此时更该回头检查上下文长度和 KV 缓存增长，而不是继续在批大小上抠。

用一组合适参数跑通并留档

诊断完就固定下来，别继续靠试。收尾记录写清最终参数、当时的峰值显存和采样方式。

最终参数组合:
  批大小: <能稳定跑通的最小值>
  量化数值精度档: <选定的档位>
  输入长度上限: <X token>
  max_new_tokens: <Y>
  峰值显存: <Z MiB，注明采样方式>
  跑通次数: <连续 N 次无中断>

换更长输入时需要重新核对的项：输入长度上限、KV 缓存随序列增长带来的峰值抬升、批大小是否还能维持、量化档是否仍然够用，以及采样方式是否和上次一致。只要其中一项变了，这组参数就不算已验证，建议重新跑一遍批大小与量化档的单变量对比再确认。留档的价值在于下次出问题时，你能立刻分清是配置漂移，还是输入真的变长了。