先把显存算清楚再决定要不要本地跑——Matrix-Game 4.0 的显卡门槛

判断 Matrix-Game 4.0 能不能本地跑，起点不是显卡包装盒上的显存数字，而是「启动前空闲显存 − 运行增量 − 安全余量」这个减法还剩多少。显卡标称显存里有相当一部分在系统启动、桌面环境和驱动常驻之后就已经不可用了，这部分和你后面要跑的游戏运行时占用是两笔账，必须分开量。下面按“先读数、再拆占用、再测增量、最后留余量并用峰值回验”的顺序走一遍，每一步都能用命令或日志复现，不依赖任何估算经验值。

先把空闲显存、常驻占用、运行增量三件事分开测，再决定是否本地跑 Matrix-Game 4.0。做法是：启动前用 nvidia-smi 记录总量、已用、空闲三个字段；用进程级查询找出桌面环境与常驻进程吃掉的显存；启动 Matrix-Game 4.0 待加载稳定后再读一次，差值即运行本身的下限；把这个增量加上安全余量去和空闲显存比。适用场景是单机自测、显存报错排查。边界在于：增量随分辨率、精度、上下文长度变化，必须按你实际要用的配置测，换配置要重测。

读出显卡标称显存与当前空闲显存

第一步只做一件事：让“总量”和“空闲”同时出现在屏幕上，很多显存不足的误判就出在把前者当后者。NVIDIA 卡建议直接用查询模式，输出稳定、便于抄进记录表，也不受表格排版影响。

nvidia-smi `--query-gpu`=name,memory.total,memory.used,memory.free `--format`=csv

需要记录的字段只有四个：卡型号、memory.total、memory.used、memory.free。判读时注意三点：memory.free 才是你现在能拿来跑的额度；memory.total 与 memory.free 之间的差距，通常是驱动、显示输出、ECC 或虚拟化预留等开销，这部分不会因为你关掉游戏就还回来；如果机器有桌面环境正在跑，memory.used 里已经含了显示相关占用。想持续看变化可以用 nvidia-smi `--query-gpu`=memory.used `--format`=csv -l 1，一秒钟刷一行，比盯着表格找数字可靠。

如果是多卡机器，先确认 CUDA_VISIBLE_DEVICES 或程序自身指定的卡号，别对着 0 号卡的空闲值去判断 1 号卡能不能跑。查询单卡可以加 -i 1。

列出常驻占用显存的进程

空闲和总量之间的差额不是玄学，基本都能落到具体进程上。分两类看：一类是计算型进程，nvidia-smi 能直接列出；另一类是图形型进程（桌面合成器、浏览器硬件加速、远程桌面等），它们占显存但常常不出现在计算进程列表里。

# 计算型进程，按占用显存从大到小排
nvidia-smi `--query-compute-apps`=pid,process_name,used_memory `--format`=csv,noheader | sort -t, -k3 -hr

# 图形上下文与整体视图
nvidia-smi pmon -c 1

查到 PID 后回到系统侧确认：ps -p <pid> -o pid,user,comm,args。常见的常驻占用包括桌面环境与窗口合成器、常开的浏览器标签页、视频播放或转码进程、别的推理服务残留。处理原则是先判断“能不能关”，比如关掉不用的浏览器硬件加速、退出闲置的推理进程，而不是一上来就改系统配置。关闭后再跑一次总量/已用/空闲查询，确认空闲值确实回升，回升多少记下来，这就是可回收的部分。

如果计算进程列表是空的，但已用显存明显高于桌面环境的合理水平，多半是图形上下文占用，可以先注销或重启显示服务后再测，判断这是不是干扰项。

启动 Matrix-Game 4.0 并记录加载阶段增量

这一步要的是“运行本身占多少”的下限，而不是估计值。做法很简单：启动前读一次，等程序进入可交互状态、加载动画结束、显存读数连续若干秒不再上涨之后，再读一次，两次相减。

# 启动前
nvidia-smi `--query-gpu`=memory.free,memory.used `--format`=csv,noheader

# 启动 Matrix-Game 4.0（按你实际的启动方式），等待加载完成进入稳定状态

# 加载稳定后
nvidia-smi `--query-gpu`=memory.free,memory.used `--format`=csv,noheader

读数时机的选择影响结论：在加载进度条刚走完时读数，往往偏低，因为纹理、缓存、编译产物可能还在后台准备；建议等到界面可以正常操作、显存读数在一分钟量级内不再变化再取值。记录内容建议写成一行：配置（分辨率、精度、上下文或场景规模）+ 启动前空闲 + 加载后已用 + 差值。差值就是这一档配置下的运行增量下限，后续所有判断都基于它，换配置必须重测一次。

用增量加安全余量判断能否运行

不能拿标称显存直接和“需求”对比，原因有两个：标称显存本身就包含了驱动与系统开销，这部分不是你能用的；运行增量也不是恒定值，加载阶段的增量通常不是峰值，长序列生成、场景切换、缓存增长都会把已用显存往上推一截。所以判断式应该是：

启动前空闲显存 − 运行增量 − 安全余量 > 0 且留有可操作空间

安全余量的取值建议结合观察到的波动幅度来定：如果加载稳定后读数上下浮动明显，余量就取大一些；如果长时间平稳，可以取小一些。下面是一条示例计算，数值仅为占位写法，请替换成你自己测到的数：

启动前 memory.free        21.4 GB
加载稳定后运行增量         9.6 GB
安全余量                   2.0 GB
剩余额度 = 21.4 - 9.6 - 2.0 = 9.8 GB  → 有富余，可以先按该配置试跑

结论建议按三档表述，写清楚适用条件，方便以后复查：剩余额度明显为正，属于“该配置下可运行”；剩余额度接近零或只有零点几 GB，属于“临界，先降分辨率、降精度或缩短上下文再试”；结果为负，属于“当前配置不建议本地跑”，需要换卡或改配置，而不是靠反复重试。表述时把配置和数值一起写出来，例如“在 1080p、某精度档下，空闲扣除增量与余量后剩余约若干 GB”，比一句“能跑”有用得多。

记录一次完整运行的显存峰值

估算只有被峰值验证过才算数。运行期间做轮询采样，把时间戳和已用显存写进日志，跑完取最大值，与加载阶段的增量对照。

# 运行 Matrix-Game 4.0 的同时，另开一个终端轮询
while true; do
  nvidia-smi `--query-gpu`=timestamp,memory.used `--format`=csv,noheader >> mem.log
  sleep 2
done

# 取峰值
awk -F', ' '{gsub(/ MiB/,"",$2); if ($2+0 > m) m=$2+0} END {print m " MiB"}' mem.log

把峰值减去启动前的已用显存，得到实际峰值增量，再和估算的“运行增量 + 安全余量”对照，回填成一张简单的对照表：

配置档位：填入分辨率与精度等实际参数
估算增量：加载阶段测得的差值
实测峰值增量：轮询取到的最大值减启动前已用
差额与判定：实测是否落在余量之内，是偏宽松还是偏紧

如果实测峰值明显高于加载增量，说明此前把余量留小了，应把该配置标为“临界”，或者把余量按新的峰值重新定；如果峰值始终低于估算，说明当前配置还有空间，可以尝试提高一档参数，但调整后要重新做第 3、5 两步。峰值出现的时机也值得记一笔，例如是否集中在场景切换或长时间生成之后，这决定了你后续在什么时刻盯显存读数。