LOCAL AI · INDEPENDENT EXPERIMENTS
What can the hardware on my desk actually do?
Experiments in file paths, memory, and compatibility.
Tested conditions. Commands you can repeat.
The layers behind a local AI experiment.
01 / THE NOTEBOOK
Changing HF_DATASETS_CACHE changed the destination of newly prepared Arrow files—not the downloaded CSVs.
HF_HOME/hubHF_DATASETS_CACHEChanging a variable does not move existing files.
Explore the cache map ARCHIFY ↗The same mixed KV cache took different execution paths with one build flag changed.
RTX 5060 Ti · Qwen3 1.7B Q4_K_M · q8_0/q4_0
llama.cpp f280b2698 · median of 3 selected samples
Three PyTorch wheels detected the GPU. Actual operations told a different story.
| Wheel | Detected | fill_ |
|---|---|---|
| cu126 | 3/3 | 0/3 |
| cu130 | 3/3 | 3/3 |
| cu132 | 3/3 | 3/3 |
Completed probes / 3 fresh processes. Not a general compatibility score.
02 / THE METHOD
Each report keeps the environment, commands, evidence, and limits together.
Find your starting pointHardware, versions, revisions, and the question being tested.
Real operations and output. Keep failure paths visible.
Trace file locations and execution—not just status flags.
Explain what this setup does and does not establish.
03 / ON THE DESK
A small workbench.
Not a GPU leaderboard.
Windows + WSL2
macOS · system memory
04 / FIELD NOTES
Qwen3-8B on a 16GB M4: nine Metal runs measure first response, RSS, KV memory, compression and swap. A separate 16K scout hit a 120-second cutoff.
Measured Hub downloads, Arrow files, import order, saved datasets, and cleanup on WSL2. Why HF_DATASETS_CACHE and cache_dir leave other files behind.
On an RTX 5060 Ti, llama.cpp's default CUDA build sent mixed q8_0/q4_0 Flash Attention to CPU; one build flag restored CUDA and an 86x PP gap.
All three PyTorch 2.13 wheels saw my RTX 5060 Ti, but cu126 mixed working dot/GEMM paths with missing native CUDA kernels.
I tested four reasons torch.cuda.is_available() returns False on WSL2: a CUDA 13 driver mismatch, CPU-only wheel, hidden GPU, and wrong Python.
On WSL 2.7.3, compressed and sparse VHDX files booted but --resize failed with 0xc03a001a; clearing the attribute restored 9/9 retries.
I tested HF_HOME, HF_HUB_CACHE, symlinks, and /mnt/c on WSL2, then measured cleanup behavior with the current hf cache commands.
Deleted 20 GB inside WSL but ext4.vhdx stayed huge? Measured on WSL 2.7.3: fstrim no longer needed, sparse VHD gated as unsafe, diskpart rejects sparse files.