TensorFlow双输入Generator读取多文件触发Kernel崩溃问题排查

1. 核心诱因：内存耗尽触发进程强制终止 #

Kernel无报错直接崩溃，本质是Python进程被操作系统强制杀掉，绝大多数场景是内存占满。按数据规模可以直接算账单：

• 单样本张量形状为(5,416,416,3)，如果是float32精度，单样本内存占用约10MB。
• 单个npz包含20个样本，拆成前景、背景双输入后，单文件对应的批次张量总大小约400MB，还没算YOLO推理时的临时内存开销——每个416尺寸的图像经过YOLO做前向推理，单张图就需要数百MB的临时内存空间，单文件的预处理总内存很容易破GB。
• batch_size=1时，只处理1个文件，内存还能扛住；提到2的时候，要同时在内存里跑两个文件的预处理流程，总占用直接翻倍，很容易直接吃满物理内存。
  这是这类自定义生成器换batch_size就崩的最常见原因

2. 生成器的批次定义和预期完全错位 #

当前实现的生成器，batch_size参数的实际作用是“一次加载几个npz文件”，完全不是“一个批次包含多少个训练样本”：

• batch_size=1时，代码读1个npz，把里面20个样本全部拼到一个批次里返回，实际单批次样本数是20，和常规理解的“1个样本/批次”完全不是一回事。
• batch_size=2时，代码读2个npz，把两个文件的40个样本全部拼到一个批次里返回，单批次大小直接翻倍，内存压力陡增。

3. 其他会引发崩溃的隐藏问题 #

• 代码片段里的模型定义存在明显的变量未对齐问题：先定义了input1/input2，但后续构建模型时却引用了从未定义的x1/x2和out变量，虽然这类变量引用错误一般会抛Python异常，不会直接崩内核，但如果实际运行的代码和贴出的版本存在差异，很容易出现内存访问错误。
• 共享的file_list是可变对象，当tf.data启动多个并行worker跑生成器时，多个线程会同时执行np.random.shuffle(file_list)的原地修改操作，触发内存访问竞态，严重时会直接导致内核崩溃。

• 先做内存验证：把batch_size设为2后，打开系统资源管理器监控Python进程的内存占用，观察崩溃前的内存占比。如果确实是内存耗尽，优先做内存优化：
  • 用np.load(fil, mmap_mode='r')以内存映射方式读取npz文件，避免把整个文件一次性加载到物理内存。
  • 每处理完一个文件的预处理流程，主动用del删除临时数组，配合垃圾回收及时释放内存，避免numpy数组的冗余拷贝占用额外空间。
  • 调整tf.data的预取策略，仅保留1个预取批次，不要因为预取机制额外占用内存。
• 修正生成器的批次逻辑：不要按npz文件数切批次，改成攒够预设的训练样本数再yield。比如需要单批次8个样本，就遍历选中文件里的所有样本，凑够8个处理好的张量再返回，不要把整个文件的全部样本都塞进同一个批次。
• 单独排查预处理函数的内存泄漏：在独立的Python循环里连续跑两次文件的get_sub_images流程，观察进程内存是否持续上涨不回落。如果存在上涨，说明YOLO推理产生的临时张量没有被及时释放，需要在每次推理后清理对应的缓存。
• 关闭tf.data的多worker并行，避免多个生成器实例同时跑预处理把内存占满。

内容的提问来源于stack exchange，提问作者gastastrophe