fc09d8f343* Studio: defer the Windows CUDA Toolkit check so prebuilt users are not blocked setup.ps1 section 1e validated the installed CUDA Toolkit against the driver in Phase 1 and hard-exited when the toolkit was newer than the driver supports. That ran before the prebuilt llama.cpp install (Phase 3.4), which is self-contained and needs no local toolkit. A Blackwell host (sm_120) on a driver that advertises CUDA 13.2 with CUDA Toolkit 13.3 installed was blocked entirely, even though the prebuilt selector would have given it a working GPU build. The toolkit (nvcc) is only consumed by the Phase 4 source build. Move section 1e into a Resolve-CudaToolkit function and call it lazily at the source-compile branch, gated on $HasNvidiaSmi. The prebuilt path no longer touches the toolkit; forced/source builds keep the identical requirement, winget auto-install, and error text via -RequireOrExit. Add a pwsh unit test that extracts the real function and runs it against a spoofed Blackwell sm_120 / driver 13.2 / toolkit 13.3 host: the prebuilt path defers, the forced build still fails fast. Refs #5879. * Studio: correct a stale Phase-1 prerequisites comment (CUDA Toolkit is now resolved lazily) * Studio: retrigger Windows GGUF CI (artifact upload flake) |
||
|---|---|---|
| .. | ||
| backend | ||
| frontend | ||
| src-tauri | ||
| __init__.py | ||
| install_llama_prebuilt.py | ||
| install_python_stack.py | ||
| LICENSE.AGPL-3.0 | ||
| package-lock.json | ||
| package.json | ||
| setup.bat | ||
| setup.ps1 | ||
| setup.sh | ||
| Unsloth_Studio_Colab.ipynb | ||