gputaskman：给 GPU 装一个 htop，逐进程看清显存都被谁占了

当你看到任务管理器里显示“已用 15 GB 显存”，通常无法回答一个更实际的问题：这 15 GB 到底被什么占用了？是模型权重、KV cache、浏览器，还是桌面合成器？为什么还有那么多显存在系统内存里？gputaskman 就是为回答这些问题而生的终端工具。它把自己定位为“GPU 内部的 htop”：不只告诉你显存多满，还试图把逐进程显存、GPU 引擎活动与已加载的运行时、模型文件、LLM 缓冲区拆解关联起来。

项目使用 Python 编写，采用 MIT 许可证，在 GitHub 上已获得约 3301 个 Star 和 160 个 Fork。需要说明的是，这是一个早期实验性软件：设备与进程计数器属于实测数据，而分类结果和基于 GGUF 的拆解属于估算。作者也明确表示，它不会 dump VRAM，也不会枚举游戏纹理。

它解决什么问题

常规 GPU 监控工具通常只给出设备级的总量，例如“显存已用 X GB”。gputaskman 想做的是把这些总量拆到进程层面，并进一步回答“是模型权重还是 KV cache”“这个进程加载了什么运行时”“有多少显存实际落在系统内存里”。

项目范围限定在本地 GPU 负载，不包括云服务。它面向决策模型、视觉、语音、LLM 推理、训练与微调（包括 Unsloth）、图形和视频等场景。不过作者也强调了可见性的边界：进程内存和引擎活动是测量出来的；识别具体模型及其工作状态则需要佐证。仅凭一个 PyTorch/CUDA DLL 无法识别模型，也无法证明正在训练；一个被映射的文件也不代表该模型已驻留 GPU 或正在被执行。纯 CPU、纯 NPU 和云端负载不在范围内。

功能与平台覆盖

从 README 看，gputaskman 的跨平台覆盖是其重点：

• Windows：支持 NVIDIA、AMD 遥测，以及 Intel WDDM 活动。CUDA 负载在 ARM64 上也可用（需要兼容的 NVIDIA 驱动和 ARM64 CUDA 运行时）。
• Linux 与 WSL：NVIDIA 在各处可用；AMD 和 Intel 在原生 Linux 上可用。
• macOS：支持 Apple Silicon（README 中提到，但本次资料未展开细节）。
• 原生 Linux 上的 AMD GPU：使用 amdgpu 驱动，无需 ROCm、AMD SMI 或额外软件包，内核已暴露所需信息。
• 华为昇腾：原生 Linux 上可通过 npu-smi 列出 Ascend 芯片，读取设备内存和逐进程内存，AI 核心与内存带宽活动来自其 watch 流，而非逐进程引擎计数器。

终端界面会明确显示当前处于哪种运行模式，因为“能测量什么”取决于运行位置。例如在 WSL 中，Linux 进程的逐进程 GPU 负载会显示为 n/a；原生 Linux 没有 WDDM 那样的共享内存或 commit 计数器，因此 Spill 和 Paged 列保持空白，而不是显示 0。JSON 输出中用 null 表示不可用的计数器，而不是实测的零。

LLM 与模型洞察

这是 gputaskman 区别于普通 GPU 监控工具的地方。它尝试把进程与已加载的运行时、模型文件以及 LLM 缓冲区拆解关联起来。README 中给出的实测例子包括：在裸机 Linux 上，一个使用 Qwen2.5-1.5B Q4_K_M、以 -ngl 99 -c 4096 运行的 llama-server 被识别出来，证据类型为 api+mapped+cmdline；配合 -lv 4 --log-file 时，CUDA0 的精确缓冲区大小（935 MB 权重、112 MB KV cache）与基于 GGUF 的估算相符。生成期间，TUI 显示该服务器 GPU 占用 96%，而 nvidia-smi pmon 显示 95%。

在 Vast.ai 的 Docker 容器实测中，启动时已有两个 PyTorch 任务运行，观看期间又启动第三个、终止一个，它们都被匹配到正确的容器 PID，并显示了对应的 NVML 显存大小（1.12、2.52 和 1.59 GB）与实时 GPU 占用。一个 Ollama 的 qwen3:0.6b runner 也被检测到并根据 Ollama 存储命名，展示了权重、KV cache 与计算部分的拆分。

安装与运行方式

gputaskman 已发布到 PyPI，无需克隆仓库。可以使用 uv 或 pipx 安装，两者都会把应用放在隔离环境中；也提供更短的 gtm 命令。运行环境要求 Python 3.11+，以及下文所述的受支持 GPU/驱动配置。

对于没有 Python 的 Windows 用户，Releases 页面提供两个便携 ZIP：gputaskman-VERSION-windows-x64.zip 面向 Intel/AMD Windows PC，gputaskman-VERSION-windows-arm64.zip 面向原生 Windows ARM64。这是两个独立的原生构建，不是通用可执行文件。使用时需要解压整个 ZIP，保持 _internal 与 gputaskman.exe 相邻，然后在解压目录中打开 Windows Terminal 或 PowerShell 运行。无需 Python、uv、CUDA Toolkit、模型下载或安装，但需要受支持的 GPU 和较新的 Windows WDDM 驱动。当前构建未签名，代码签名和安装程序不包含在初始分发中。

从源码克隆运行的方式需要 64 位 Windows 10/11、较新的 WDDM 驱动和终端（推荐 Windows Terminal）。使用 uv 时会自动获取固定版本的 Python、创建 .venv 并安装锁定依赖，首次运行需要联网。监控 GPU 本身不需要 CUDA Toolkit、Visual Studio、管理员会话、API key 或模型下载；NVML 随 NVIDIA 驱动提供，AMD ADL 由受支持的 AMD Windows 驱动提供。

Linux 和 WSL 的标记版本提供便携构建：gputaskman-VERSION-linux-x64.tar.gz 和 gputaskman-VERSION-linux-arm64.tar.gz，需要 glibc 2.35 或更新版本（Ubuntu 22.04、Debian 12 或更新），以及 NVIDIA 驱动；在原生 Linux 上也可以是 amdgpu 驱动下的 AMD GPU、i915 下的 Intel GPU，或带 npu-smi 的华为昇腾 310P。NVIDIA 在原生、容器和 WSL 中均可用。

容器与权限的注意事项

在 Docker、Kubernetes 或租用的 GPU 机器等容器环境中，需要额外一步：NVML 报告的是宿主机 PID，这些 PID 在容器的 /proc 中没有意义，而容器也看不到自己进程的宿主机 PID。gputaskman 会把 NVML 中未解析的 PID 与容器内映射了 libcuda.so 的进程配对（像 nvidia-smi 这类仅用 NVML 的工具会打开相同设备文件，但从不加载 libcuda）。两个 PID 命名空间都按创建顺序编号，因此配对按顺序进行：计数匹配时标记为 *，NVML 列出的计算进程多于容器内进程时标记为 ?。剩余项显示为 H:，表示容器之外，不会在本地查找。

在原生 Linux 上，只能列出你有权限检查的进程；其他用户的进程需要 sudo。头部的 JSON（process_status）会说明有多少进程无法查看。

原生 Linux 的 AMD 路径还有一个值得注意的设计：VRAM 和 Shared 只有在没有其他东西能持有这些字节时才会计入某个进程——它的每个 DRM client 都恰好有一个可见持有者、通过 render node 打开，并且在所有 drm-shared-* 区域报告零字节。否则该进程的 VRAM 和 Shared 显示为 n/a（JSON 中为 null，并带 vram_unattributed_reason），其字节留在未归属类别。README 列出了共享 client、共享缓冲区、primary node、旧内核、读取不完整、部分扫描等具体情况。

另外，ROCm/HIP 进程的 VRAM 会像其他进程一样出现在 fdinfo 中，但它的 GPU% 不是：HIP 通过 /dev/kfd 上的用户态队列提交计算，内核不会按进程计时，因此持有 /dev/kfd 的进程引擎显示为 n/a，而不是看起来像实测的 0。设备的 AMD gfx 负载仍然包含这部分工作。

适用人群

gputaskman 更适合需要在终端里快速定位 GPU 显存去向的开发者和运维人员，尤其是运行本地 LLM 推理、微调、视觉或视频负载，并且希望把进程、模型文件和缓冲区拆解对应起来的人。它也适合在 Windows、Linux、WSL 多环境之间切换、需要统一观察视角的用户。

但需要清楚它的定位：这是早期实验性软件，分类和 GGUF 拆解是估算而非官方测量；部分平台和硬件路径（如 Intel Arc B580、昇腾容器与 PID namespace 行为）尚未在真实硬件上独立验证。如果你需要的是稳定、经过广泛认证的生产级监控方案，应谨慎评估。

项目主页

https://github.com/shanselman/gputaskman

项目地址：gputaskman