先看现象。vLLM 0.6.4 启动时加了 --swap-space 0，长请求一多日志就出现 preemption，随后接口返回 500，而 nvidia-smi 显示显存还有 3GB 空闲。
排查方向其实有限，先把可能性排一排。swap_space 为 0 时被抢占的序列无处换出，只能丢弃。也可能是gpu_memory_utilization 留得太紧，没有余量给新序列。
另外，max_num_seqs 设得比 KV 能容纳的数量大。
少数情况下是长请求集中在同一批，KV 峰值超过预算。
第一件事是把 swap_space 给回默认的 4GB
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct --swap-space 4下调并发上限观察是否还抢占
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct --max-num-seqs 16随后用长请求压一轮复现
python bench.py --url http://127.0.0.1:8000 --long-context --requests 50等前面都确认过，再看日志里的抢占计数是否归零
grep -c preemption vllm.log同一份数据我导出了两份，一份留底，一份拿来试。
怎么算真的好了，看的是同一批现象。长请求连续五十次都返回 200，日志里 preemption 计数不再增长，显存峰值仍在卡容量以内。
容易忽略的是，swap_space 走的是内存到显存的搬运，设太大反而把延迟拉高，四到八 GB 够用，别拿它当显存扩容。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。