原帖在 Colab 的 Linear 运算处失败；相同代码以前能跑，batch 从 128 降到 64 仍未解决：
RuntimeError: CUDA error: CUBLAS_STATUS_ALLOC_FAILED when calling `cublasCreate(handle)`
降低 batch 仍失败，说明还需要做区分检查
原题只有 cuBLAS 创建句柄失败的堆栈，没有标签、网络和显存时间序列，因此不能套用别人的“类别数写错”或“batch 太大”结论。先在干净进程确认最小计算，再恢复同一模型与首批数据，能够把环境问题和训练资源问题分开。
cuBLAS 初始化需要设备资源，但这条错误不能单独证明是 batch 过大。Notebook 残留模型、其他进程占用和此前 CUDA 失败也应区分。
在尚未失败的干净运行时、模型前向之前检查：
import torch
print("josh050608")
print("torch/CUDA:", torch.__version__, torch.version.cuda)
print("available:", torch.cuda.is_available())
if torch.cuda.is_available():
print(torch.cuda.memory_summary(abbreviated=True))
在 Colab 终端或单独命令单元运行 nvidia-smi，查看设备总占用。PyTorch 的 memory_summary 主要统计本进程分配器，两者应结合看。如果此前发生设备断言，先重启运行时，不能继续用已经出错的上下文判断显存。
若干净进程显存充足，先运行很小的矩阵乘法 torch.ones(2,2,device='cuda') @ torch.ones(2,2,device='cuda')。若连它都失败，继续核对驱动与 torch 构建；若能成功，恢复模型到首个失败层，检查该层输入形状、权重形状和实际峰值。
若确认为显存压力，清理已不用的模型引用，降低 batch/输入大小，推理加 torch.no_grad()，日志只存 loss.item()。empty_cache() 不会释放仍被活跃张量占用的显存，不能代替删除无用引用或缩小计算。
最后在干净会话跑完整一个训练 step，再观察多批次内存是否稳定。只有这一条 cuBLAS 消息，没有足够依据断定是哪一项造成资源分配失败。
在模型加载前后分别记录资源
下列脚本需要可用的 NVIDIA CUDA 环境，可在重启后的独立进程运行。它只创建小矩阵；若这里失败，应保留完整错误，暂不加载大模型：
import torch
if not torch.cuda.is_available():
raise RuntimeError("当前进程 CUDA 不可用，请先核对驱动和 torch 构建")
device = torch.device("cuda:0")
print("before:", torch.cuda.memory_allocated(device), torch.cuda.memory_reserved(device))
a = torch.ones(2, 2, device=device)
b = a @ a
torch.cuda.synchronize()
assert torch.equal(b.cpu(), torch.full((2, 2), 2.0))
print("after:", torch.cuda.memory_allocated(device), torch.cuda.memory_reserved(device))
然后把同样的统计放在真实模型加载后、前向后、backward 后，观察第一次显著增长的位置。nvidia-smi 显示的是设备层面的占用，可能包含其他进程；PyTorch 统计不能直接等同于整张卡剩余空间。
若每批都增加，检查列表里是否保存了 GPU 输出或带图 loss：用于记录时保存 loss.item()，用于后续 CPU 分析时明确 detach 并迁到 CPU。若是一次性峰值过大，再减小 batch、输入尺寸或按任务采用精度优化；不要为了省内存改变类别数或丢失目标含义。
若此前已有 device-side assert，先重启运行时，继续 empty_cache 无法恢复坏掉的上下文。新进程小矩阵通过、真实首批通过、连续多批峰值稳定，才构成这类问题比较可靠的验证；原题缺少资源记录，文章只能提供分支判断，不能补造唯一根因。
参考：原始求助帖；技术依据：PyTorch CUDA 语义（2.5）、CUDA 内存统计（2.5）、PyTorch CUDA 环境变量（2.5）。
