v0.6.11.1 — critical fix for light-tier (Gemma) cards
Fixes a regression in v0.6.10.0 / v0.6.11.0 that left all light-tier (Gemma-3-4B) cards unable to mine — every 6–8 GB GPU, which is why Pascal miners (P106-100 / P104 / GTX 1060 6 GB / 1070 / 1080) reported "the latest version, even legacy, does not work."
Cause: v0.6.10 made in-process llama.cpp the default engine, with the PoM walk gathering zero-dup over llama's resident VRAM. llama.cpp repacks the Gemma-3 architecture on load (it materialises a separate output.weight from Gemma's tied embeddings), so its resident weight layout no longer matches the canonical GGUF the walk must gather. The N-guard correctly refused to mine (it never produced bad shares) — but the card just sat idle. Dolphin-8B and Llama-70B tiers were unaffected (llama loads them byte-identically), so this only hit cards that auto-select the Gemma tier.
Fix: a byte-compatibility gate now checks llama's resident layout against the possession index before using it for the walk. On a repacked architecture (Gemma), the miner frees llama's VRAM and falls back to candle for both the walk and inference on that card — exactly the pre-v0.6.10 behavior. Byte-clean tiers (Dolphin, Llama-70B) keep the llama zero-dup path.
Verified on real Pascal hardware (1080 Ti, light tier): mining, shares accepted, 2.55 GB VRAM. No consensus change; the N-guard remains as the final safety net.
If you were affected: update to v0.6.11.1 (any line — for Pascal use the pascal tarball, driver R550+). Package versions: CUSTOM_VERSION 0.6.11.1 / BUILD 30.
NVIDIA Linux assets
12 tarballs (modern sm_75+ / legacy sm_70+ / pascal sm_60-61) + SHA256SUMS. Windows zips + macOS attached by CI. AMD packages follow separately.