Gaussian Splatting 项目中的 CUDA 内存溢出问题分析与解决

问题背景

在使用 Gaussian Splatting 项目进行 3D 场景重建时，开发者 MazzARQ 遇到了一个典型的 CUDA 内存溢出问题。当尝试从已训练的模型（30000 次迭代）继续训练时，系统在调用 rasterizer 进行渲染时出现了内存不足的错误。有趣的是，这个问题只在训练过程中出现，而在直接使用 render.py 进行渲染时却能正常工作。

问题现象

错误信息显示系统尝试分配 52.32GB 的显存，而 GPU 的总容量只有 23.68GB。这种显存需求与实际情况明显不符，表明存在某种内存管理或数据处理上的异常。

根本原因分析

经过深入排查，发现问题出在模型参数的获取方式上：

1. 正常工作的 render.py 调用方式：

scales = pc._scaling
rotations = pc._rotation
opacity = pc.get_opacity

2. 导致内存溢出的 train.py 调用方式：

scales = pc.get_scaling
rotations = pc.get_rotation
opacity = pc.get_opacity

关键区别在于 get_scaling 和 _scaling 的不同行为。get_scaling 方法可能包含了额外的激活函数处理，导致显存需求异常增长。

解决方案

MazzARQ 最终发现自己在保存模型参数时，错误地将 scales 和 rotations 的值与激活状态一起保存。当这些参数被重新加载并再次应用激活函数时，导致了显存需求的爆炸性增长。

正确的做法应该是：

1. 确保在保存模型参数时，只保存必要的原始数据，不包含冗余的中间状态
2. 在加载模型时，直接访问原始参数而非通过可能包含额外处理的 getter 方法
3. 对于 Gaussian Splatting 项目，优先使用 _scaling 和 _rotation 这样的直接属性访问方式

经验总结

这个案例提供了几个有价值的经验教训：

1. 显存管理：在深度学习项目中，显存使用情况是性能调优的重要指标。异常的高显存需求往往表明数据处理流程存在问题。

2. 属性访问与方法调用：理解 Python 中属性访问与方法调用的区别至关重要。前者通常直接返回值，后者可能包含额外的计算逻辑。

3. 模型序列化：在保存和加载模型状态时，需要明确区分哪些数据需要持久化，哪些是运行时计算的中间结果。

4. 调试技巧：通过对比工作场景和失败场景的差异，可以快速定位问题根源。

对于 Gaussian Splatting 这类计算密集型项目，合理的内存管理和参数处理是保证训练稳定性的关键因素。开发者需要特别注意模型参数的存储和加载方式，避免不必要的计算和内存消耗。