本地跑 VeriLoop E2 变慢时，先别急着压上下文长度。更稳的顺序是：用同一个固定输入连续跑三次，把总耗时、首段输出出现时间、显存峰值记下来；如果这三次里显存已经贴着上限，慢的原因大概率不在上下文长度这一项参数上，而在显存不够引发的换入换出或被迫降级路径。等基线稳定后，再单独改上下文长度、单独改生成长度上限，一次只动一个变量，才能判断该先压哪一项。

判断顺序：先用固定输入建基线并记录显存峰值，再看显存是否贴近上限。显存已满时，优先降量化档或减少并发，其次才压上下文长度；显存仍有明显余量时，才用三档上下文长度对照判断耗时是否随长度明显上升。每次只改一个参数，改完重新记录三次基线。所有耗时只做本机相对比较，不作为绝对性能指标。

固定输入跑三次，建立耗时与显存基线

先准备一份固定 prompt 文本文件，固定量化档与生成长度上限，并暂时关掉其他占显存的进程，让三次运行的输入完全一致。跑之前先起一个显存采样，跑完记下三项：总耗时、首段输出出现的时间点、整段运行期间的显存峰值。首段输出出现时间可以从终端第一次打印内容时手动记，也可以看日志里首个 token 的时间戳。

# 显存采样（设备编号按本机情况调整）
nvidia-smi `--query-gpu`=memory.used,memory.total `--format`=csv -l 1

# 端到端耗时（把命令替换成本机实际启动方式）
time ./veriloop-e2 `--config` ./e2-local.yaml `--prompt-file` ./fixed-prompt.txt

三次结果差异明显，通常说明存在预热、缓存或后台负载干扰，这时任何“快慢”的感受都不可比，建议先把干扰项排掉再重跑。三次接近，才说明这个基线可以用来做后续对照。显存峰值这一列尤其不要省，后面判断优先级全靠它。

只改上下文长度，看耗时怎么变

基线稳定后，固定量化档、生成长度上限和 prompt 文本，只调整上下文长度一项，取本机支持的偏小、居中、偏大三档依次跑（具体档位以模型窗口和配置文件为准）。注意 prompt 本身的内容和 token 数不能再变，否则等于同时改了两个变量，对照就不成立。

如果总耗时随档位上升而明显拉长、且首段输出出现时间也一起变晚，说明耗时增长与上下文长度强相关，这一项就有压缩空间。如果档位调大后耗时变化不大，但显存峰值已经顶到上限，那问题不在上下文长度本身，而在显存余量，压上下文只是被动缓解，不是对症处理。

只改生成长度上限，看逐字速度

这一节要区分两种慢：读得慢（prompt 处理阶段就慢）和写得慢（逐字生成阶段慢）。做法是固定上下文长度与量化档，只改生成长度上限，观察输出阶段的节奏。如果日志里有类似“prompt 处理耗时”和“生成耗时”的分项，直接读这两项即可；没有分项时，用输出字数除以从首段输出出现到结束的时间，得到本机自测的逐字速度，只能横向比较，不当绝对指标。

• 首段输出出现时间基本不变、只有后半段越拖越长：偏“写得慢”，通常与生成长度上限直接相关，试着把上限调小观察输出节奏是否变均匀。
• 首段输出出现时间本身就很长、之后逐字速度还算正常：偏“读得慢”，方向应回到上下文长度和显存余量，而不是继续压生成长度。
• 两种现象同时出现：先按显存一项排除换入换出，再分别做上面两组对照。

判断逐字速度时建议连续多跑两三次取相对趋势，单次节奏容易被采样窗口和系统负载干扰。

检查是否发生了显存换入换出

把卡顿从参数问题里摘出来，关键是看“显存占满”和“速度骤降”是否同时出现。典型特征是：运行开始后显存占用很快贴到设备上限并长时间保持，随后输出节奏突然变慢，同一请求内部前后速度不一致；同时系统层面可能出现内存换页活动上升，日志里可能出现显存不足、卸载到主机内存、降级到 CPU 之类的关键词（关键字随本机版本而异，以实际日志为准）。

# 系统层面看换页活动
vmstat 1
free -h

# 看日志里的显存、卸载、降级相关行
grep -Ei "oom|out of memory|offload|fallback|cpu" ./veriloop-e2.log

观察位置建议固定在两处：一是周期性采样的显存占用曲线，二是推理日志的前若干行（加载与初始化阶段最容易暴露卸载和降级）。只要换入换出成立，先调上下文长度或生成长度都是隔靴搔痒，应当先解决显存容量问题，比如降一个量化档、减少并发请求或批大小。

给出先压哪一项的取舍结论

按下面的条件判断，不要凭感觉选：

1. 显存峰值贴近设备上限，或日志出现卸载、降级关键词：先降量化档，或减少并发与批大小；这一步不解决，压上下文长度只是被迫缩小可用空间。
2. 显存有明显余量，且耗时随上下文长度档位上升明显变长：先压上下文长度，同时确认 prompt 文本没有跟着变。
3. 显存有余量、上下文长度影响不大，但首段输出出现时间很长：回到上下文长度与预填充阶段继续排查，而不是继续调生成长度上限。
4. 首段输出很快、逐字阶段拖长：先调生成长度上限，再评估是否换更低的量化档。

每做完一次调整，都要按第 1 节的方式重新跑三次固定输入，重建总耗时、首段输出出现时间和显存峰值基线。没有重建基线就对比新旧配置，很容易把系统负载波动误判成参数效果。