GNNのmemory wallをsystems設計で回避しようとする試み

2026年3月15日、r/MachineLearningではGraphZero v0.2のself-postが334 points、27 commentsを集めた。主張はかなり明快で、Papers100Mのようなlarge graph datasetはtrainingを始める前にconsumer machineを落としてしまうことが多い、なぜなら既存libraryがtopologyとfeature matrix全体をRAMへ積もうとするからだ、というものだ。作者はそのload-to-memory modelを捨て、datasetをdisk上に置いたまま扱うC++ engineを作ったと説明している。

Reddit postによれば、GraphZeroはraw CSVを2種類のoptimized binary formatへ変換する。topologyは .gl、featuresは .gd に保存し、その後 mmap で直接memory-mapする。engineは nanobind を使ってraw pointerをNumPyやPyTorchへzero-copy arrayとして渡す。重要なのは、model側からは巨大tensorがRAMにあるように見えても、実際にはbatchが触れた4KB pageだけが必要な瞬間にNVMeから読まれる点だ。さらにOpenMPでneighbor samplingを並列化し、Python GILも解放してdisk I/O、CPU sampling、GPU計算を重ねられるようにしているという。

GitHub READMEでは、より強いbenchmark claimが示されている。例として挙げられる ogbn-papers100M は111 million nodes、1.6 billion edges規模で、GraphZeroは30GBのraw CSVを13GB binaryへ縮めるcompressed CSR風の形式を使うとする。READMEでは16GB RAMのWindows laptop上でpeak RAM usageが約5.1GBのOS cache程度に収まり、同じ条件でPyTorch Geometricは24.1GB超を要求してcrashしたと述べている。加えて、effectively instantなload timeと1,264,000 random-walk steps/sというthroughputも提示している。

このprojectが面白いのは、大規模graph trainingの問題をmodel architectureではなくsystems problemとして捉え直していることだ。より大きなserverを買う代わりに、data layout、file format、memory mapping、sampling pipelineを作り直して対処しようとしている。benchmark numberの外部検証はまだ必要だが、communityが強く反応した理由は分かりやすい。graph MLの実験をconsumer hardwareへ引き戻せる可能性があるからだ。

Primary source: GraphZero GitHub repository. Community discussion: r/MachineLearning.

#graph-neural-networks

r/MachineLearning: GraphZero、mmapとzero-copy tensorで巨大graphをRAMごと読み込まず扱うC++ engine