记录一下那天晚上的排查过程。一台 4090 24GB 的机器白天跑推理服务，晚上跑 LoRA 微调，两者同时开着，nvidia-smi 显示显存用到 23.4GB，推理的 P99 从 1.2 秒涨到 9 秒，偶尔直接 CUDA out of memory。
刚开始盯着「vLLM 的 gpu_memory_utilization 按整卡算，没给训练留余量」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。训练进程按需增长显存，把推理预留的 KV cache 挤掉。少数情况下是两个进程争抢 SM 与显存带宽，推理的算力被摊薄。
不容易想到的是，训练 dataloader 的 pin memory 也占用了锁页内存。
第一件事是看两个进程各自占了多少显存
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv给训练进程设一个显存上限
python -c "import torch;torch.cuda.set_per_process_memory_fraction(0.45, 0);print(torch.cuda.memory_allocated())"然后把推理的显存比例压到一半以下
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct-AWQ --gpu-memory-utilization 0.45 --max-model-len 4096剩下的就是观察推理延迟是否回到基线
curl -s localhost:8000/metrics | grep -E 'time_to_first_token|e2e_request_latency' | head别只看报错消失，验证要多做一步。两个进程共存时推理 P99 回到 1.5 秒以内，显存峰值不超过 22GB，连续跑两小时不再出现 OOM。
容易忽略的是，同卡混跑本质是资源争抢，靠调参数只能缓解，真要稳定还是分开机器，或者用 MPS 做算力隔离。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。