AI 3D模型推理任务在生成网格、点云或神经辐射场时，经常出现进程跑到一半突然退出、日志里只留下一条CUDA out of memory的情况。这类中断不一定意味着显存容量绝对不足，也可能是显存碎片、临时张量未释放、数据加载方式不合理，或者系统层内存交换影响了GPU上下文稳定性。要准确排查，需要同时关注GPU显存和系统资源两个层面。下面先给出整体排查逻辑，再展开具体监控方法。
先定位显存峰值：从报错信息反推分配场景
当CUDA报错显示无法分配一块特定大小的显存时，第一件事不是盲目减小batch size，而是把这条错误拆开看。模型推理阶段的显存占用大致包括权重参数、输入张量、中间激活、临时缓冲和输出结果。3D模型与普通图像模型最大的区别在于，体素、点云和多尺度网格特征会把中间激活放大很多倍。比如一个256乘256乘256的体素特征图，使用float32保存时仅单层就接近256MB，如果网络里同时存在多个不同分辨率的特征图，峰值很容易超过预期。
在PyTorch环境中，不能只靠nvidia-smi来判断显存是否被释放。PyTorch的缓存分配器会预留一块显存池，即使张量已经删除，预留空间也可能不会立即归还给驱动。更准确的方法是记录推理循环内的显存峰值变化，下面这段代码可以在每个关键步骤前后输出当前占用和最大值。
import torch
def log_memory(tag):
allocated = torch.cuda.memory_allocated() / 1024**3
reserved = torch.cuda.memory_reserved() / 1024**3
peak = torch.cuda.max_memory_allocated() / 1024**3
print(f"{tag} | allocated={allocated:.2f}GB reserved={reserved:.2f}GB peak={peak:.2f}GB")
log_memory("before model")
with torch.inference_mode():
output = model(input_data)
log_memory("after model")
这里有两个指标经常被混淆：memory_allocated表示实际被张量占用的显存，memory_reserved表示分配器从驱动预留的显存总量。排查重点应放在memory_allocated上，因为它更贴近真实计算压力。如果峰值出现在某个算子之后，可以使用torch.profiler进一步定位到具体模块，尤其是上采样、多尺度融合和注意力计算这类在3D任务中容易产生临时大张量的步骤。
系统资源监控：GPU、CPU、内存与交换分区不能割裂看待
显存不足导致的推理中断有时只是表象。系统内存吃紧、交换分区频繁读写，同样会让GPU等不到数据，推理进程被系统OOM Killer终止，或者CUDA上下文被破坏后直接退出。因此排查时至少需要同时观察GPU利用率、显存占用、CPU各核心负载、系统内存和Swap使用情况。nvidia-smi是基础工具，可以用下面命令连续输出关键指标。
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu,temperature.gpu --format=csv watch -n 1 nvidia-smi
GPU利用率的含义需要结合场景判断。如果显存占用很高但利用率长期低于50%，可能不是模型计算量太大，而是数据加载线程成为瓶颈，GPU在等待点云或网格数据从CPU内存搬运到显存。此时继续降低batch size并不能解决问题，反而可能让数据加载次数更多。可以用htop或glances查看CPU核心是否被数据预处理任务打满，同时关注swap是否持续增长。
系统内存不足时，Linux会尝试将匿名页写入交换分区，这会让数据加载路径变得非常缓慢。更严重的是，部分深度学习框架在分配主机内存失败时，会直接抛出异常或触发CUDA错误，看起来就像GPU显存不够。下面这段Python脚本通过psutil采集系统内存和交换分区，适合嵌入到推理服务的健康检查里。
import psutil
def system_status():
vm = psutil.virtual_memory()
sw = psutil.swap_memory()
cpu = psutil.cpu_percent(interval=1, percpu=True)
print(f"memory total={vm.total/1024**3:.1f}GB used={vm.used/1024**3:.1f}GB percent={vm.percent}%")
print(f"swap total={sw.total/1024**3:.1f}GB used={sw.used/1024**3:.1f}GB percent={sw.percent}%")
print(f"cpu_percent={cpu}")
system_status()
实践中比较稳妥的做法是，在推理服务启动前设置资源上限和监控日志，例如每5秒记录一次GPU显存和系统内存，并保留最近30分钟的采样。一旦出现异常峰值，就能对照日志判断是某个请求触发的临时分配，还是系统内存被其他进程挤占。
降低显存占用的几种实用手段
确认是显存峰值过高后，可以先从推理模式入手。PyTorch的torch.no_grad()只是关闭梯度记录，而torch.inference_mode()在此基础上还会改变部分算子的行为，进一步减少临时张量的创建。对于纯推理的3D模型，建议优先使用torch.inference_mode()，并配合自动混合精度将部分激活和权重转为float16或bfloat16。不过要注意，3D坐标计算对数值精度较敏感，尤其是点云配准和体素边界处理，混合精度需要先在验证集上对比输出误差。
from torch.cuda.amp import autocast
with torch.inference_mode():
with autocast(device_type="cuda", dtype=torch.float16):
output = model(input_data)
分块推理也是处理大体量3D数据的常用方法。将一个大的体素场拆成多个小块，逐块计算并在每次处理完立即删除中间结果，可以显著降低显存峰值。下面给出一个基本框架，其中chunks来自输入切分逻辑，每次迭代后主动调用empty_cache释放预留显存。
outputs = []
with torch.inference_mode():
for chunk in chunks:
result = model(chunk)
outputs.append(result)
del chunk, result
torch.cuda.empty_cache()
如果模型本身很大，还可以考虑模型权重不常驻显存，或者将编码器与解码器分开加载。对于已经固定结构的模型，使用TensorRT或ONNX Runtime进行推理优化，也能够合并部分中间层并降低显存占用。但这些方案需要额外的导出与验证工作，在应急排查阶段不一定能立刻落地。
构建可落地的监控与预警脚本
与其每次等到推理中断后再登录服务器查看日志，不如为长期运行的3D推理服务增加一个轻量监控脚本。思路并不复杂：周期性采集GPU显存使用率，超过阈值时输出时间戳和当前进程信息，必要时保存最近一段时间的日志以辅助分析。下面这段脚本使用nvidia-smi获取显存使用量，并与总量比较。
while true; do
USED=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | awk '{print $1}')
TOTAL=$(nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits | awk '{print $1}')
PERCENT=$((USED * 100 / TOTAL))
echo "$(date '+%Y-%m-%d %H:%M:%S') memory ${PERCENT}% ${USED}/${TOTAL} MB"
sleep 5
done
这个脚本可以重定向到文件长期运行，也可以进一步扩展为当显存使用率超过80%时，通过调用ps查看当前GPU进程列表，或者发送告警消息。需要注意的是，如果显存使用率长期稳定在90%以上，但推理并未中断，说明系统已经处于临界状态，应立即调整输入尺寸或增加硬件资源，而不是等待下一次OOM发生。
在服务端部署中，建议把监控数据和推理请求日志放在同一时间线上。这样一旦某次请求导致显存尖峰，可以迅速定位到具体输入数据。很多显存问题不是稳态问题，而是单个异常样本触发的瞬时高占用，只有连续监控才能捕捉到这类特征。
