存在显存泄漏，需分步排查：先通过nvidia-smi对比30分钟前后显存变化确认泄漏；再隔离open-webui与vllm定位源头；接着移除--enforce-eager、限制批处理量并校准张量并行数；然后在open-webui中启用上下文长度限制；最后用pkill和gpu-reset强制清理残留。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您运行Llama 3模型服务（如vLLM或Open-WebUI）一段时间后出现响应延迟、CUDA out of memory错误或nvidia-smi显示显存持续攀升，则很可能是显存泄漏引发的资源未释放问题。以下是针对该现象的系统性排查步骤：
一、验证显存泄漏是否存在
该步骤用于确认问题是否真实由显存泄漏引起，排除临时性高负载干扰。需在服务稳定运行至少30分钟后执行对比观测。
1、启动服务前，记录初始显存状态：nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits
2、执行连续10轮相同长度的推理请求（例如每轮输入512 token），间隔30秒，避免缓存抖动干扰。
3、第10轮结束后立即再次执行相同nvidia-smi命令，若两次读数差值超过800 MB且未回落，则判定存在显存泄漏。
二、定位泄漏源组件
显存泄漏可能发生在模型加载层、推理引擎或前端交互层，需分层隔离验证。
1、关闭Open-WebUI，仅保留vLLM API服务运行，重复步骤一中的测试流程。
2、若显存增量显著下降（≤100 MB），则泄漏源大概率位于Open-WebUI的会话管理或缓存逻辑中。
3、若显存仍持续增长，则问题集中在vLLM内部——重点检查是否启用了--enforce-eager参数（该参数禁用CUDA Graph优化，已知在Ray调度下诱发显存滞留）。
三、vLLM层显存泄漏修复
vLLM的PagedAttention机制本身抗泄漏能力强，但特定配置组合会绕过其内存回收路径。
1、检查当前启动命令中是否包含--enforce-eager：若有，立即移除并重启服务。
2、强制启用显存自动回收策略：在启动命令中添加参数--disable-log-stats --max-num-batched-tokens 4096，限制批处理上限以触发更频繁的KV Cache清理。
3、若使用tensor parallelism，确认--tensor-parallel-size值与物理GPU数量严格一致（例如双卡必须为2，不可设为1或3）。
四、Open-WebUI层缓存清理
Open-WebUI默认持久化保存全部会话上下文至内存，长时间多轮对话将导致GPU显存中残留大量未释放的KV Cache引用。
1、编辑Open-WebUI配置文件./webui.env，添加或修改行：ENABLE_CONTEXT_LENGTH_LIMIT=true
2、设置单次会话最大上下文长度：在同文件中追加CONTEXT_LENGTH_LIMIT=2048
3、重启Open-WebUI服务，新会话将自动截断超出部分，旧会话需手动清除浏览器本地存储（Application → Local Storage → 删除对应域名条目）。
五、进程级强制清理兜底方案
当上述方法均无法即时恢复时，需通过操作系统级手段切断泄漏链路，确保两张GPU显存彻底归零。
1、终止所有疑似相关Python进程：pkill -f "vllm\|open-webui\|streamlit"
2、清除CUDA上下文残留：nvidia-smi --gpu-reset -i 0,1（需root权限，适用于NVIDIA驱动版本≥535.129.03）
3、验证显存清空结果：watch -n 1 'nvidia-smi --query-compute-apps=pid,used_memory --format=csv'，确认输出中无任何PID行且used_memory稳定为0 MiB。
