在AI/ML模型训练与推理的日常运维中，一个令人头疼的高频问题是：进程被强制终止（如Ctrl+C或kill -9）后，其占用的GPU显存资源并未随之释放。此时，nvidia-smi可能显示显存被占用却无对应PID，或残留着“僵尸进程”（Zombie/Defunct），常规手段束手无策，最终往往只能诉诸重启服务器——这在生产环境中代价高昂。本文将构建一套纯用户态的工具链方案，无需修改内核或驱动，即可主动检测并安全释放这些“失控”的GPU资源，让宝贵的算力回归可用状态。
这套工具链的核心思路是分层排查与精准打击。第一层，优先使用深度学习框架自带的缓存清理机制。对于PyTorch用户，在Python脚本末尾或交互式环境中执行import torch; torch.cuda.empty_cache()，可显式清空当前进程的未使用缓存。TensorFlow用户则可调用from tensorflow.keras import backend as K; K.clear_session()来重置会话状态。这一步是“温柔”的首选，它只影响调用者自身，不会波及其他进程，但前提是原进程仍可访问且未完全僵死。
当框架级清理失效，或面对完全失控的僵尸进程时，我们需要深入到操作系统层面。第二层工具是nvidia-smi，这是NVIDIA官方提供的状态监控工具。运行nvidia-smi可列出所有GPU及其占用进程的PID。若能看到明确的PID，直接使用kill -9 <PID>即可干净利落地终止进程并释放资源。这是最直接有效的方法，但其局限性在于，许多资源泄露场景下，nvidia-smi根本不会显示任何占用进程，仿佛显存被“幽灵”占据。
此时，我们必须祭出第三层，也是最强大的武器：fuser命令。fuser用于显示哪些进程正在使用指定的文件或文件系统。NVIDIA GPU设备在Linux中以/dev/nvidia*（如/dev/nvidia0, /dev/nvidiactl, /dev/nvidia-uvm等）的形式存在。运行sudo fuser -v /dev/nvidia*，可以强制列出所有正在访问这些设备文件的进程ID，即使它们在nvidia-smi中“隐身”。这一步是揭开“幽灵”真面目的关键。得到PID列表后，即可通过sudo kill -9 <PID>逐个或批量清除。为方便操作，可以将这两步合并为一条命令：sudo fuser -k /dev/nvidia*，其中-k选项会直接向查找到的进程发送SIGKILL信号。
为了将上述步骤工程化、产品化，我们可以构建一个简单的Bash脚本或Python工具，封装成用户友好的命令行工具。例如，一个名为gpu-reclaim的脚本可以提供如下功能：--card 0指定只清理0号GPU；--dry-run先模拟运行，只输出将被清理的PID而不执行kill，供用户确认；--keyword "debug"只清理命令行中包含特定关键字（如实验代号）的进程，避免误伤其他正在运行的重要任务。核心逻辑是先尝试框架清理（如果环境允许），再用fuser扫描，最后在用户确认后执行清理。这样的工具链将零散的命令行操作整合为一个可靠、可复用的工作流。
当然，这套方案也存在风险与局限。最大的风险是误杀：fuser -k /dev/nvidia*是无差别攻击，会杀死所有访问GPU的进程，包括那些正常运行的任务。因此，生产环境中强烈建议先使用--dry-run模式审查，或结合ps命令根据进程名、启动时间等二次过滤。其次，对于某些特定的硬件或驱动组合（如搜索结果中提到的AMD CPU + NVIDIA GPU），可能存在内核级死锁，导致kill -9也无法终止进程，最终仍需重启。此外，fuser命令本身可能不在所有系统中默认安装，通常需要通过sudo apt-get install psmisc（Ubuntu/Debian）或sudo yum install psmisc（CentOS/RHEL）来获取。
总而言之，通过组合nvidia-smi、fuser和框架API，我们可以在用户态构建一套强大的GPU资源回收工具链。它虽然不能解决所有极端情况，但足以应对绝大多数因进程异常退出导致的显存泄露问题，显著减少不必要的服务器重启，提升AI基础设施的稳定性和运维效率。将这些命令封装成脚本，加入到你的运维工具箱中，下一次再遇到“幽灵显存”，你将不再手足无措。