确认是显存碎片化：当“已保留”显存比“已分配”高出5GB以上且nvidia-smi显示大量空闲时，表明显存被切割成零散小块；需在import torch前设置PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb:64"并合理使用empty_cache。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在运行Grok系列大模型时，nvidia-smi显示还有8GB空闲显存，却反复报出“CUDA out of memory: Tried to allocate 4.2GB”，这种错误不是显存不够，而是PyTorch显存分配器找不到连续的4.2GB空间——显存已被切割成几十个零散小块，就像一盒被掰碎的巧克力，总量够，但拼不出完整一块。
确认是否为显存碎片化问题
运行以下三行诊断代码，观察输出差异：
import torch
print(f"已分配:{torch.cuda.memory_allocated()/1024**3:.2f}GB")
print(f"已保留:{torch.cuda.memory_reserved()/1024**3:.2f}GB")
若“已保留”比“已分配”高出5GB以上（例如分配6.1GB、保留13.8GB），且nvidia-smi中“Memory-Usage”显示大量空闲，就【确认是显存碎片化】，不是模型本身显存超限。
设置PYTORCH_CUDA_ALLOC_CONF环境变量
这是解决Grok类大模型碎片化最直接有效的方式，必须在导入torch前完成设置。
方法一：Linux/macOS终端中执行（适用于命令行启动训练）
export PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb:64"
方法二：Windows命令提示符中执行（注意等号前后不能有空格）
set PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:64
方法三：Python脚本最开头插入（必须在import torch之前）
import os
os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "max_split_size_mb:64"
这个值不是越大越好。Grok推理常触发3–5GB分配请求，实测64MB能平衡大块保护与小块复用；设为128MB可能仍OOM，设为16MB则会因过度保留小块导致预留显存飙升。
配合empty_cache的精准清理时机
第一步：检查当前碎片状态
torch.cuda.memory_summary()
第二步：仅在以下两种情况调用清缓存：
① 刚执行完一个长序列推理（如处理完一段10分钟语音），且下一步要加载新大模型权重；
② 批量处理中，每10个样本后统一释放临时张量。
第三步：执行清理
torch.cuda.empty_cache()
【切勿在Grok的自回归解码循环里每步都调用】——这会让分配器反复整理内存池，反而加剧碎片生成节奏，实测会导致吞吐下降37%。
规避DataLoader引发的隐式显存占用
Grok训练/推理中若使用DataLoader，num_workers > 0会为每个worker进程预创建CUDA上下文，单worker平均吃掉600–900MB显存，且这些显存块不参与主模型分配池，纯属“幽灵占用”。
将DataLoader的num_workers设为0，改用主线程预加载：
train_loader = DataLoader(dataset, batch_size=1, num_workers=【0】, pin_memory=False)
若必须用多进程，请在worker_init_fn中禁用CUDA初始化：
def worker_init_fn(_):
torch.cuda.set_device(-1) # 强制不初始化CUDA上下文
