区块一：顶栏（系统时间与驱动版本）
Tue Jul 07 15:29:03 2026|NVITOP 1.3.2|Driver: 595.71.05|CUDA Driver: 13.2
- 含义：当前系统时间、nvitop 工具版本、NVIDIA 显卡驱动版本，以及驱动支持的最高 CUDA 版本（13.2）。注意，这不等于我们实际运行的 CUDA 运行时版本，只是驱动能兼容的最高版本。
区块二：系统整体资源（CPU + 内存 + 交换分区）
位于 GPU 表格的上方：
- Load Average:
12.51 11.69 8.06：系统过去 1、5、15 分钟的平均负载。我们的 CPU 是16核32 线程（下方gmx用了-ntomp 16是为了配倍数，当然可以绑定cpu核心，-pin on）。负载 12.5 意味着有 12.5 个进程在“抢”CPU，虽然没有满载（16），但已经相当繁忙。 - CPU:
35.1%：整体 CPU 占用率（所有核心平均）。虽然负载高，但占用率只有 35%，说明大量进程在等待 I/O 或内存读写（而非纯计算）。 - MEM:
20.66GiB (18.6%)：物理内存已用 20.66 GB，总内存约 111 GB（20.66/0.186），剩余充足。 - SWP:
1.05GiB (52.4%)：交换分区用了 1.05 GB，占比一半，说明物理内存虽够，但系统仍换出了部分冷数据。
区块三：GPU 基础属性（第一行表格）
GPU 0 | GeForce RTX 4080 | Off | 00000000:01:00.0 | Off | 100% | N/A | MEM: 63.9%
- GPU 0：第一张显卡（我们只有一张）。
- Persistence-M (Off)：持久模式未开启（不影响性能，仅影响驱动加载速度）。
- Bus-Id：硬件在 PCIe 总线上的物理地址。
- Disp.A (Off)：未连接显示器（无图形输出）。
- Volatile Uncorr. ECC (100% / N/A)：显存错误检测状态，RTX 4080 不支持 ECC，所以显示 N/A，前面的 100% 只是软件占位符。
- MEM: 63.9%：显存总占用比例（即下方
10469MiB / 16376MiB）。
区块四：GPU 实时运行状态（第二行传感器）
56% | 76°C | P2 | 314W / 320W | 10469MiB / 16376MiB | GPU-Util 100% | Compute M. (默认)
这是最关键的性能诊断区：
- Fan
56%：风扇转速为 56%。 - Temp
76°C：核心温度 76 摄氏度。对于 4080 满载来说非常正常（安全阈值约 85°C）。 - Perf
P2：性能状态级别。P0 是最高（满血），P2 是次顶级（通常是由于功耗墙限制或非官方超频模式，P2 对于 RTX 40 系跑计算任务是正常的）。 - Pwr
314W / 320W：当前功耗314W，离功耗墙上限 320W只差 6W。这是系统当前最大的瓶颈——撞功耗墙了（Performance capped by Power）。这意味着 GPU 核心频率无法再往上 boost。 - Memory-Usage
10469MiB / 16376MiB：已用显存10.47 GB，剩余约 5.9 GB。虽然占用了 63.9%，但显存带宽和容量尚未爆满。 - GPU-Util
100.0%：GPU 核心计算单元满载（说明计算任务没有在偷懒，一直在跑 Kernel）。
区块五：进程列表（谁在占用 GPU）
GPU | PID | USER | GPU-MEM | %SM | %CPU | %MEM | TIME | COMMAND
这是排查“谁在干活、谁在捣乱”的核心。针对我们的列表，我标注如下：
| PID | 用户 | GPU显存 | %SM (流处理器占用) | %CPU | 运行时间 | 指令 | 解读 |
|---|---|---|---|---|---|---|---|
| 1985589 | csn | 804 MiB | 20% | 395.2% | 16:04 | gmx mdrun -deffnm md50 | GROMACS 模拟 (md50)。占用 395% CPU（约 4 个核心满线程）和 20% SM。这是正常的混合精度计算。 |
| 1993129 | csn | 806 MiB | 20% | 447.1% | 8:00 | gmx mdrun -deffnm md1 | GROMACS 模拟 (md1)。另一个并行跑的模拟任务。两个gmx加起来占用了 40% 的 SM 资源。 |
| 1984096 | csn | 304 MiB | 40% | 99.8% | 23:12 | python3.12 ... localcobold | AlphaFold / localcobold 主进程。单核跑满 CPU，占用 40% 的 SM（可能在运行神经网络推理或特征提取）。 |
| 1991854 | csn | 276 MiB | 0% | 100.0% | 18:59 | python3.12 ... localcobold | 另一个 Python 辅助进程。0% SM 说明它不跑 GPU 计算，只是在干数据预处理或 I/O 读写，但把 1 个 CPU 核心吃满了。 |
| 865813 | root | 754 MiB | 20% | 0.0% | 13:09 | ngrok-cli --host ... | 内网穿透工具 ngrok。注意：一个隧道工具居然占用了754 MB 显存，而且占 20% SM，这极不正常。可能是 ngrok 内部使用了 GPU 加速加密（或存在显存泄露）。 |
| 6785 | csn | 4.46 MiB | 0% | 0.0% | 25天 | /usr/lib/xorg/Xorg | Linux 图形界面服务。基本不占资源，忽略即可。 |
重要的指标其实就两个，
- GPU-MEM 显存占用：显存爆了当然就直接OOM报错、程序闪退
- %SM 流式多处理器利用率（GPU算力使用率）
特别提醒（针对我们当前状况的硬核分析）
为什么
GPU-Util是 100%，但每个进程的%SM加起来只有 80% (40+20+20)？%SM指的是该进程在采样周期内占用 SM 的时间比例（可能会有重叠）。而顶部的GPU-Util是瞬时硬件总线繁忙率。因为两个gmx和 Python 进程在争抢显存带宽，导致硬件始终处于“传输数据”的繁忙状态，但 SM 内部计算单元并未 100% 塞满（受限于内存带宽瓶颈）。
结论：我们的系统目前绝对性能瓶颈是 320W 的功耗墙（已拉满）和显存带宽争抢。如果我们想加速，只能降低 CPU 功耗或优化代码以减少显存读写；如果继续增加任务，功耗墙会导致核心频率急剧下降，速度反而变慢。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
