dask_cudf加载数据创建BlazingSQL表时触发cudaErrorMemoryAllocation显存溢出报错

• 触发CUDA显存溢出的直接原因是复现代码的逻辑错误：dask_cudf完成分布式parquet读取后，执行了ddf.compute()操作，该操作会将分散存储在所有GPU worker上的数据集分片，全部拉取到单个节点的单块GPU显存中，远超单卡16GB显存的承载上限。
• 空表异常的关联诱因：OOM触发了cudf内部的数据初始化异常，最终传入bc.create_table()的cudf DataFrame实际为空，表现为表创建流程正常但查询时记录数为0。
• 资源调度层面的问题：硬件配置共6块V100，但当前LocalCUDACluster仅占用4块GPU，剩余2块的算力和显存未被纳入调度池；且worker初始化时默认将单卡16GB显存全量预占，没有给临时计算预留冗余空间，进一步放大了OOM风险。
• BlazingSQL原生read_parquet可正常运行的原因：该方法会自动将数据拆分成分片、分布式存储到集群的各个GPU上，单卡仅承接部分数据，不会出现全量数据堆积到单卡的问题。

• 调整BlazingSQL建表逻辑，移除不必要的compute()操作：BlazingContext支持直接传入dask_cudf分布式DataFrame创建表，无需先将全量数据归集到单卡。修正对应代码为：

  # 原错误代码
  # bc.create_table('table', ddf.compute())
  # 修正后
  bc.create_table('table', ddf)
  

  *注意：大规模分布式数据集场景下，直接执行全局compute操作完全丧失多卡分布式的资源优势，是GPU显存溢出的最常见诱因。
• 优化dask_cudf读取参数，控制单分片大小：读取parquet时增加split_row_groups=True参数，将大的parquet行组拆分为更细的分片，让单分片的显存占用适配单卡16GB的承载能力，示例：

  ddf = dask_cudf.read_parquet(
      '/home/ubuntu/126M_dataset/',
      split_row_groups=True
  )
  

• 修正LocalCUDACluster的资源配置，充分利用全部GPU资源：
  • 显式指定可调度的GPU设备，覆盖全部6块V100：cluster = LocalCUDACluster(CUDA_VISIBLE_DEVICES="0,1,2,3,4,5")
  • 限制单worker的显存分配阈值，预留临时计算空间：初始化时设置device_memory_limit="14GB"，避免单卡16GB显存被全量预占，给RMM临时分配留2GB余量。
• 针对CSV格式读取的OOM问题，显式指定分片大小：读取时通过chunksize参数控制单分片的显存占用，比如设置dask_cudf.read_csv(..., chunksize=100_000_000)，避免一次性加载过大的CSV分片到显存。

• 通过Dask状态监控面板查看各GPU worker的显存占用，确认移除compute()操作后，单分片的平均显存占用低于单卡14GB的阈值。
• 建表完成后执行bc.sql('SELECT COUNT(*) FROM table').compute()，验证返回的总记录数是否和数据集实际规模（1.26亿）一致，排除空表异常。
• 若仍存在OOM，可在初始化BlazingContext时开启RMM池化内存分配，减少显存碎片带来的额外开销，对应参数为rmm_pool_size="12GB"。

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