PyTorch模型加载慢、内存暴涨主因是DataLoader和Dataset配置不当：Dataset应在__getitem__中按需加载图像，避免__init__中预加载；num_workers需匹配CPU核心数（SSD建议4，HDD≤4），并启用pin_memory=True；慎用重载transforms，优先使用torchvision.transforms.v2或离线增强；警惕persistent_workers导致的内存泄漏及/dev/shm空间不足。
PyTorch模型加载慢、系统内存暴涨，大概率不是模型本身的问题，而是DataLoader配置和Dataset实现方式踩了坑——数据没“懒加载”，全塞进内存了，CPU还在拼命解码，GPU却在干等。
Dataset里一次性读完所有数据，内存直接爆掉
常见错误是把整个数据集在__init__里就用open()或cv2.imread()全加载进RAM。ImageNet子集（5万张图）用PIL逐张decode后存list，轻松吃掉8–12GB内存，还拖慢启动速度。
- 只在
__init__中保存文件路径列表，别碰内容 -
__getitem__里才用torchvision.io.read_image()或PIL.Image.open()按需读取 - 避免在
__getitem__里做耗时预处理（如cv2.warpPerspective），优先用torchvision.transforms的C++后端实现
num_workers设错，CPU忙成陀螺，GPU闲得发烫
num_workers=0时，所有IO和transforms都挤在主进程跑，GPU一算完就空转；但num_workers设太高（比如16），又可能因调度开销、/dev/shm空间不足或HDD随机IO争抢，反而更慢。
- 先查物理核心数：
lscpu | grep "Core(s) per socket"（Linux）或任务管理器“性能→逻辑处理器”看标注“核心”数量 - SSD环境从
num_workers=4起步，HDD建议≤4；超过8基本没必要 - 必须配
pin_memory=True，否则worker传数据到GPU要经过CPU memcpy中转，白费力气 - Docker里跑务必加
--shm-size=2g，否则Bus error不是报错，是直接崩
transforms太重，单个worker就把CPU核占满
像RandomResizedCrop(224) + ColorJitter + GaussianBlur连用，在OpenCV后端下单次调用就可能吃满一个CPU核。这时加更多worker只是排队等CPU，不提速。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 用
torchvision.transforms.v2（PyTorch 2.0+）替代老版transforms，支持lazy执行和jit编译 - 把可离线做的增强（如灰度化、归一化）提前存成LMDB或RecordIO格式，加载时跳过CPU计算
- 实测发现：对JPEG图像，
torchvision.io.decode_jpeg()比PIL快2–3倍，且支持batch decode
内存泄漏藏在persistent_workers和全局缓存里
PyTorch ≥1.7默认persistent_workers=True，worker进程跨epoch复用。如果__getitem__里用了cv2.Canny之类带静态状态的函数，或自己写了全局LRU cache，内存会越跑越高。
- 禁用持久化：
persistent_workers=False（适合调试，但启动略慢） - 检查预处理函数是否引用了模块级变量（如
_cache = {}），改用实例属性或参数传递 - 用
watch -n 1 free -mh盯住available列，如果每epoch掉500MB以上，大概率有泄漏
真正卡顿的地方，往往不在GPU显存，而在/dev/shm大小、HDD寻道延迟、或者那个被你忽略的__getitem__里的json.load()调用——它每次都在反序列化同一个大字典。
