On Windows-on-ARM + NVIDIA (DGX Spark / N1X "RTX Spark"), install.ps1 routes the
install through WSL2 and, after setup finishes, launches provision_llama_cuda.sh
in the BACKGROUND to install the CUDA toolkit + gcc-14 and build the real sm_121
CUDA llama-server, replacing whatever section 9 produced.
On a fresh WSL distro there is no nvcc yet, so section 9 could only ever build a
CPU-only server ("building (CPU, CUDA driver found but nvcc missing)") that the
background CUDA build immediately throws away -- slow and wasteful.
Skip the section-9 source build entirely on this exact path. Introduce a distinct
_LLAMA_CPP_DEFERRED state (NOT _LLAMA_CPP_DEGRADED) so:
- the footer reports "GGUF engine: CUDA build running in background" (success),
not "limited: llama.cpp unavailable";
- the arm64 CPU-prebuilt last-resort does NOT fire (it gates on DEGRADED=true);
- the install-failure exit 1 does NOT fire (it gates on DEGRADED=true).
Strictly gated -- defers only when ALL hold: WSL (grep microsoft /proc/version),
aarch64/arm64, an NVIDIA GPU is listed by nvidia-smi, nvcc is missing (PATH and
/usr/local/cuda*/bin), UNSLOTH_NO_LLAMA_CUDA != 1, no forced compile, no pinned
PR. Every other host (x86_64, native-Linux aarch64, nvcc-present, opt-out,
ROCm, macOS, non-NVIDIA) is byte-for-byte unaffected and still builds via
section 9 as before. install.ps1 is unchanged; it still builds CUDA in the
background, but now with no wasted CPU build first.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
9e26277cb8