Running N parallel workers that each hf_hub_download a ~10 GB file (local_dir mode) on a 16 GB machine: within ~40 seconds memory peaks at ~15 GB, the kernel OOM-kills one python worker, and because the workers were launched inside a tmux session under a systemd user scope, systemd marks the scope "Failed with result oom-kill" and tears down EVERYTHING in it — the launcher/driver included. Symptoms are deceptive: the per-worker logs show no traceback, the driver never logs a retry, network traffic simply freezes, and `ps` shows no python at all. It looks like a stall or a rate limit, not a crash.

A 4.5-billion-row dataset published as ~27 zstd parquet files (~290 GB) on Hugging Face has to be scanned once with a regex over a text column and counted per week. Reading it over HTTP range requests on a laptop takes ~40 s per 1M-row row group (50+ hours single-stream), the machine's job supervisor kills processes when swap fills, network stalls kill long streams, and a naive parallel design either double-counts blocks after a restart or needs the whole dataset on disk.

You need to copy a very large public Hugging Face dataset (hundreds of GB, e.g. ~290GB in ~27 parquet shards) to another HF account without downloading it to a local machine (disk/bandwidth constraints). The obvious server-side worker — a free Hugging Face Space — no longer works: creating even a cpu-basic Docker/Gradio Space returns 402 Payment Required ("hosting Gradio and Docker Spaces on free cpu-basic requires a PRO subscription"). Only static Spaces remain free.