显存碎片化导致CUDA out of memory，需在import torch前设置PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb:64"；盲目调用torch.cuda.empty_cache()反而加剧碎片。
显存还有空闲却报 CUDA out of memory，基本就是显存碎片化在作祟——不是显存不够，而是找不到连续大块。解决它不靠“清缓存”，而要从分配器行为入手。
确认是不是显存碎片化问题
别急着调参，先用三行代码验证：
import torch
print(f"已分配:{torch.cuda.memory_allocated()/1024**3:.2f}GB")
print(f"已保留:{torch.cuda.memory_reserved()/1024**3:.2f}GB")
如果“已保留”比“已分配”高出 5GB 以上（比如分配 7.2GB、保留 14.6GB），且 nvidia-smi 显示仍有大量空闲，就坐实了是碎片化。这时降低 batch size 或删变量都没用，因为问题出在分配器找不到连续空间。
必须在 import torch 前设置 PYTORCH_CUDA_ALLOC_CONF
这个环境变量是 PyTorch CUDA 分配器的“行为开关”，设晚了等于没设。常见错误是写在 import torch 后面，完全无效。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- Linux/macOS 终端启动前：执行
export PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb:64" - Windows 命令行：执行
set PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:64 - Python 脚本最开头（注意：必须在任何 torch 相关 import 之前）：
import os; os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "max_split_size_mb:64"
64 不是随便选的：Grok 类模型推理常需 3–5GB 连续块，设成 128MB 仍可能 OOM；设成 16MB 则小块太多，memory_reserved 会虚高。实测 64MB 是多数大模型的平衡点。
慎用 torch.cuda.empty_cache()
它不是“万能清道夫”。盲目调用反而加重碎片——每次调用都会触发分配器整理内存池，打断复用节奏。
- 只在明确需要腾出大块连续显存时才用，比如：刚完成一段长序列推理，下一步要加载新模型权重
- 或批量处理中，每处理完 10 个样本后统一释放一批临时张量
- 绝对不要在自回归解码循环里每步都调用
torch.cuda.empty_cache()，这是典型反模式
调用前建议先看一眼现状：torch.cuda.memory_summary()，避免“为清而清”。
别忽略内存池本身的默认行为
PyTorch 2.0+ 默认启用 CUDA Memory Pool，它本身就在做延迟释放 + 池内合并。你不需要手动开，但得理解它在干什么：张量释放后不立刻还给驱动，而是留在池里等复用；不同 stream 释放的内存也能跨流共享。
这意味着，频繁创建/销毁大小差异大的张量（比如交替加载 1GB 和 50MB 的模块）才是碎片温床。真正要优化的，是你的张量生命周期管理逻辑，而不是反复敲 empty_cache。
