cuPyNumeric 分片并行加载

问题背景

cuPyNumeric 对单个 .npy 有 cupynumeric.load，HDF5 单文件可走 legate.io.hdf5；分片多文件、Parquet/Arrow、固定布局原始二进制、自定义目录结构 则没有「一条 API 读完整个逻辑数组」的内置路径。常见写法是 np.concatenate([read(f) for f in files])，数据一大就卡在单进程顺序 I/O 上，也进不了 Legate 的分布式执行模型。

技能在做什么

本技能给出 手动分区 + 手动启动 Legate Python 任务 的规范写法：在 @task 里用 h5py、pyarrow、np.memmap 等第三方读取器做按行范围的切片读，Legate 把各 tile 调度到可用 GPU/CPU 上。核心约定是：仅轴 0 分片，尾部维 shape[1:] 与 dtype 全分片一致；各文件行数可以不同，靠累积行偏移表在 leaf 任务里二分定位重叠分片并拷贝到输出 tile。

典型五步（示例为 shard_NNNN.npy 目录布局）：

• 发现元数据：mmap 读 .npy 头或格式自带的 shape/dtype，校验连续分片与尾部维一致
• 分配输出：cn.empty(total_rows, *trailing_shape)，避免无意义的零初始化
• 按处理器分 tile：tile_rows = ceil(total_rows / num_processors)，与文件个数解耦
• leaf 任务：用 cupy/numpy 通过 DLPack 或 __array_interface__ 写 PhysicalStore，不要在 task 内调用 cn.asarray
• 屏障：驱动侧做一致性检查

同一任务体可换「每文件一 tile」均匀分片快速路径，或通过更小 tile_rows 做过度分解以均衡负载。

边界与坑

• 数据须已在共享文件系统上可被各 rank 按路径打开；本技能只谈加载，不负责生成分片文件。
• leaf 内写入前对切片用 np.ascontiguousarray；mmap 视图未必 C 连续。
• create_manual_task 的 launch_shape 与 partition_by_tiling 的 task 数须从同一 (total_rows, tile_rows) 推导，不能简单等于 num_processors。
• 格式切换时主要改发现逻辑和 load_tile 内的每文件读取器；读取器须支持 [file_lo, file_hi) 范围读，不能只「整文件读一次」。