Patch release. pip install falcata now resolves to 1.0.3.
Multi-GPU works from the prebuilt wheel
num_gpu > 1 used to require building from source with USE_NCCL=ON, and a wheel install silently fell back to a single GPU. (--config-settings has no effect on a wheel install — pip only passes it to source builds, so the flag looked like it worked and didn't.)
NCCL is now loaded at runtime rather than linked at build time, so the stock wheel can do multi-GPU:
pip install 'falcata[multigpu]' # pulls nvidia-nccl-cu12
then pass num_gpu=2. Without NCCL present you get a warning naming the fix instead of a silent single-GPU fallback. The base install is unchanged in size and gains no hard dependency.
What two GPUs buy you, measured on 2×T4 with Numerai v5.3 (30k trees, depth 10, 1024 leaves; hours extrapolated from 300-round runs):
| 1×T4 | 2×T4 | |
|---|---|---|
train split (2.75M × 3555) |
3.0 h | 2.8 h |
| full data (6.86M × 3555) | out of memory | 9.2 h |
Two effects, and which one you get depends on the card. Rows are split across ranks, so VRAM pools: datasets that don't fit on one card train on two. Speed is the smaller story — histogram building parallelizes but the all-reduce doesn't, so multi-GPU wins only where compute dominates communication. On slower cards like the T4 it does. On fast cards (A100/H100/5090) a single GPU is still the faster choice, and 2 GPUs land at roughly 0.65× of one; use multi-GPU there for capacity, not throughput.
Thanks to the user who reported this from a Kaggle 2×T4 notebook.
Fixed
gpu_device_idno longer reports its own default as invalid. The default is-1, documented as "the default device", but multi-GPU startup warnedInvalid gpu_device_id = -1before doing the right thing anyway.-1now selects the master silently; an explicitly chosen device that is out of range still warns.