New workflow step exercises the same code path Studio's setup.sh
takes on macOS: studio/install_llama_prebuilt.py with
--published-repo ggml-org/llama.cpp and --published-release-tag
b9049 (latest llama.cpp release at time of writing). The installer
fetches llama-b9049-bin-macos-arm64.tar.gz -- universal Apple
Silicon arm64 build (M1/M2/M3/M4 all OK).
After install, downloads unsloth/gemma-3-270m-it-GGUF Q4_K_M (~241
MB) from HuggingFace and runs the prebuilt llama-cli on it with a
fixed seed + greedy sampling. Asserts the prompt echo "Hello"
appears in stdout. If the install or inference fails, that's an
Unsloth/Studio-side bug.
The b9049 release publishes four macOS-related assets:
* macos-arm64 -- universal Apple Silicon, M1/M2/M3/M4 OK.
Studio picks this asset by default.
* macos-arm64-kleidiai -- KleidiAI dispatches at runtime, falls
back where ISA features are missing on
older Apple Silicon (e.g. M1 lacks I8MM),
so it ALSO runs on M1 -- Studio just
doesn't pick this variant by default.
* macos-x64 -- Intel-only, would require Rosetta 2 on
M1; we deliberately avoid this.
* iOS XCFramework -- iOS-app artifact, not a macOS desktop
build.
Step uses a separate install dir (~/.unsloth-studio-prebuilt-test/
llama.cpp) so it does not collide with the existing MLX export
round-trip's save_pretrained_gguf path that clones+builds llama.cpp
from source under ~/.unsloth/llama.cpp.
4526641cf4