不能，千万级节点必须放弃全图一次性加载，转向子图采样或图分区；NeighborLoader通过分层采样动态构建微型子图，实现内存可控、训练加速与强扩展性。
PyTorch Geometric 能否直接加载千万级节点的完整图？
不能。直接用 torch_geometric.data.Data 构造含数百万节点的全图（比如把全部 edge_index 和 x 加载进内存）通常会 OOM——哪怕 GPU 显存够，CPU 内存也大概率撑不住。这不是 PyG 的 bug，而是邻接矩阵/边索引张量本身在稠密或中等稀疏度下就占几 GB 到几十 GB。
关键判断：**千万级节点必须放弃全图一次性加载，转向子图采样或图分区**。
-
torch_geometric.loader.NeighborLoader是最常用起点，按 batch 采样节点及其 k-hop 邻居，内存和显存消耗可控 - 若节点特征极宽（如 1024 维 embedding），即使采样也要注意
num_neighbors别设太大，否则子图爆炸 - 原始图文件（如 CSV 或 .pt）建议用 memory-mapped 方式读取节点特征，避免一次性
torch.load()整个 tensor
NeighborLoader 的 num_neighbors 参数怎么设才不崩？
这个参数不是“越大越好”，而是要根据你的硬件和任务平衡。设高了子图变大，batch size 被迫压小；设低了感受野太浅，模型学不到长程依赖。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 从
[10, 5, 2]这类递减序列开始（对应 3 层 GNN），比全设成[20, 20, 20]更稳 - 用
loader = NeighborLoader(..., shuffle=True)避免某几个 batch 特别大（某些中心节点度极高） - 加
drop_last=True，防止最后一个 batch 因节点度分布尾部而超限 - 运行时监控
len(batch.edge_index[0])和batch.num_nodes，如果单 batch 边数 > 2M，说明采样过猛，得调低num_neighbors
训练时卡在 dataloader worker 上，是不是 num_workers 太高？
是。PyG 的 NeighborLoader 在多进程下容易因共享内存或图结构序列化出问题，尤其当原始图对象包含非 tensor 成员（如自定义 dict、networkx 图）时。
常见现象：BrokenPipeError、worker 进程 silent hang、CPU 占满但 GPU 利用率 0%。
- 先试
num_workers=0—— 虽慢但最稳，能确认是否是 worker 问题 - 若必须用多进程，确保
Data对象只含 tensor、int、float 等可 pickle 类型；删掉data.graph_metadata这类自定义字段 - Linux 下可尝试
pin_memory=False+prefetch_factor=1减少内存压力 - PyTorch 2.0+ 用户注意：
torch.compile和NeighborLoader当前不兼容，会触发RuntimeError: DataLoader worker exited unexpectedly
节点 ID 超过 int32 范围（比如 3e9），PyG 会出错吗？
会。PyG 默认用 torch.int64 存 edge_index，但部分底层算子（尤其是旧版 CUDA kernel）可能隐式转成 int32，导致负值或截断。
典型错误：IndexError: index -2147483648 is out of bounds for dimension 0 with size 2147483647。
- 检查
data.edge_index.dtype == torch.int64，强制转换：data.edge_index = data.edge_index.to(torch.long) - 避免用 numpy array 初始化
edge_index（numpy 默认 int32），改用torch.tensor(..., dtype=torch.long) - 如果用
torch_sparse相关操作（如sparse_matmul），确认其版本支持 int64 —— 1.6.0+ 才稳定
千万级节点本身不致命，但 ID 编号方式、采样策略、数据加载路径任何一个环节松动，都会让整个 pipeline 在某个 batch 突然失败。最常被忽略的是节点特征文件的 mmap 加载逻辑和 edge_index 的 dtype 一致性。
