Fix: staging crash on VRAM-tight cards (fresh rigs)
Root cause, reproduced and fixed: during first-time staging the serveability pass asked llama.cpp to load models that could never fit the card (e.g. the 12B lineup model's 9.3 GiB weights on an 8–10 GB GPU). The failed multi-GiB load isn't harmless — its teardown races the next engine load/generate on the same card, which then dies with a sticky CUDA illegal-memory-access at its first sync. In the field this shows up as the miner aborting right as cards begin hashing, or as a CUBLAS_STATUS_NOT_INITIALIZED restart loop when a wrapper keeps relaunching it. The crash is intermittent on well-provisioned hosts and near-certain on low-RAM rigs, which is why fresh multi-card 8–10 GB setups were hit hardest.
The fix: the engine now checks the model's size against the card's free VRAM before attempting any load. A model that cannot fit is skipped instantly with a clear log line — the outcome is identical to the failed load (that tier is unavailable on that card and is withdrawn from OPoI), minus the doomed allocation and its poisoned window. Cards where the model fits are unaffected (verified: the 12B model still loads and serves normally on 16 GB cards). KERYX_LLAMA_VRAM_CHECK=0 restores the old behavior for diagnosis.
Also worth knowing for low-RAM rigs: first-ever staging of a model peaks at ~10 GB of system RAM (it drops to ~2 GB once the possession tree is cached on disk). With 8 GB of system RAM, staging cannot complete — 16 GB is the practical minimum. Combine --low-ram --wait-ready (v0.11.18) on constrained multi-card rigs.
Validated: the previously-deterministic crash repro (8 GB card, fresh model dir, 6.8 GB memory cgroup) now stages, passes the self-test, and mines with accepted shares.
Includes v0.11.18 (--wait-ready) and v0.11.17 (chaseless PoM solver, +8–14% on GDDR cards).