training: fuse LoRA onto 16-bit base + disable Xet to fix GGUF export #27
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/027-training-fuse-lora-onto-16-bit-base-disable-xe"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
training: fuse LoRA onto 16-bit base + disable Xet to fix GGUF export
Along the way:
Touches 27 files:
corpus_diagnostics.md,docs/effects.md,scripts/test.sh,scripts/training/python/eval.py,scripts/training/python/export_gguf.py,scripts/training/python/train.pyand 21 more.Approving. I would have split
src/rust/crates/ck_driver/tests/corpus.rsdifferently, but not enough to hold this up.@ -409,3 +403,1 @@col,}}).map(|diag| diag_to_trap(diag, &test.pages[diag.span.file.0 as usize].source))The
ascast truncates silently ifmapis ever wider than the target. Is the bound guaranteed, or should this betry_from?@ -120,3 +374,1 @@// the body's effect calls / asserts.let events = run_corpus_main("helloWorld");assert_clean_lifecycle(&events, "Main");fn corpus_apps_match_their_trap_md() {corpus_apps_match_their_trap_mdreads, decides and writes in one function. The deciding part is the piece I would want to test on its own. Worth splitting?Split. The decision in
corpus_apps_match_their_trap_mdis a pure function now, with its own tests insrc/rust/crates/ck_driver/tests/corpus.rs.Not guaranteed.
mapgoes through try_from now and the overflow is a typed error insrc/rust/crates/ck_cktest/src/lib.rs.Looked through
src/rust/crates/ck_driver/tests/corpus.rsas well. Fine by me.The step-4 GGUF export crashed with a missing config.json: the adapter is QLoRA-trained on the bnb-4bit base, and Unsloth's merge_and_overwrite_lora refuses a 16-bit merge from an nf4 base (saving_utils.py), silently leaving merged/ empty. Re-point the resolved base at the ungated 16-bit repo (unsloth/gemma-4-E4B-it) so the merge downloads + fuses onto clean weights. The 16-bit base download then hung at 4% behind the VPN: HF's Xet backend opens ~96 parallel CAS connections that degrade ("connection struggling") and stall with no timeout. Disable Xet (HF_HUB_DISABLE_XET=1) before any HF import in all three download entrypoints so every invocation path uses the robust single-stream CDN download; setdefault keeps =0 override working.