K2-Horizon-36B-A4B · file← K2-Horizon-36B-A4B
BF16 GGUF
IFM's full-size original. Too big to run here; we made the others from it. Downloaded from IFM, rev c8dde8bc.
- Size
- 74.9 GB
- Status
- Deleted 10 Sep 2026
- Scored runs
- 0
This file never completed a scored run. Its record below says why.
Rebuilt from the lab's records by Claude, an AI model. The results above come straight from the automated runs. How these pages are made.
| File | K2-Horizon-36B-BF16.gguf |
| Format | BF16 GGUF, 74,924,627,296 B |
| Where from | downloaded 2026-09-09 from IFM/K2-Horizon-MoVA-36B-A4B-GGUF @ c8dde8bc |
| Status | deleted 2026-09-10 23:48Z |
| Hugging Face | https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B-GGUF |
Where it came from
| field | value |
|---|---|
| repo | IFM/K2-Horizon-MoVA-36B-A4B-GGUF |
| file | K2-Horizon-36B-BF16.gguf (the only GGUF in the repo at that revision; the tree lists .gitattributes, the GGUF, README.md and two PNGs) |
| revision | c8dde8bc6afe5b28e75c7d78db4fbd65d5fcf679 |
| size | 74,924,627,296 B |
| sha256 | 6289baf9e00cfad7584c20fed17eaa34b46336adaf0e1a108145eab024f27bd0 (HF LFS sha256 recorded by the downloader; the local file was never hashed) |
| completed | 2026-09-09 16:00:37Z (metadata epoch 1788969637) |
Command (relaunched at 15:21Z):
export HF_XET_HIGH_PERFORMANCE=1
mlx-venv/bin/python -c "from huggingface_hub import snapshot_download
snapshot_download('IFM/K2-Horizon-MoVA-36B-A4B-GGUF', local_dir='models/k2-horizon-36b-a4b',
allow_patterns=['*BF16*.gguf','*.json','*.jinja'], max_workers=8)"
The first plan (a one-off script, 14:54Z) was to download the 74.9 GB safetensors and convert them with the fork's conversion/k2_horizon.py. It died at the download step: "ModuleNotFoundError: No module named 'huggingface_hub'". It was replaced by the published BF16 GGUF, so no local conversion was ever run.
Who asked / why: Alan's "we could quantize q8 and run it". The BF16 was the only GGUF IFM published. The assistant confirmed the download was "byte-for-byte IFM's official release".
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
| — (no run-log label) | — | — | — | — | never served: 69.8 GiB of BF16 cannot load on a 64 GB box; it existed only as the quantisation source |
Seats held: none.
Decisions
- Downloaded as the quantisation source: Q4_K_M and Q8_0 were made from it the same day (K2-Horizon-36B-A4B Q4_K_M (quantised here from IFM's BF16), K2-Horizon-36B-A4B Q8_0 (quantised here from IFM's BF16)).
- Not served: too large for 64 GB, and the precision ladder used Q8_0 as the 36B's top rung.
- Deleted 2026-09-10 23:48Z on Alan's "Yeah", in a batch with the 7B and 3.7B BF16s. The reasons given: "measured 2026-09-10: Q8_0 and BF16 differ on 0 of 72 nullschema cases" on the 3.7B, and "the 36B BF16 (69.78 GB) cannot even load on a 64 GB box" (Q8_0 and BF16 are behaviourally identical; full precision buys nothing). Disk was at 92%.
- Not re-downloaded on 2026-09-11. Alan asked "should we get the base model and requant to q4_0". The assistant requantised from the Q8_0 on disk instead ("one rounding pass, free" vs "~75 GB download").
What went wrong
- The first download attempt used an interpreter without
huggingface_hub. - The 36B download was cancelled at 15:12Z after Alan's "the 36b not worth it" and restarted at 15:21Z after "oh hang on that's the moe keep the download".
What happened to it
Downloaded 2026-09-09 → source for two quants 2026-09-09 → deleted 2026-09-10 23:48Z. No RESTORE-deleted-*.sh entry. HF cache metadata (revision and sha256) survives in models/k2-horizon-36b-a4b/.cache/huggingface/. Re-downloadable from IFM/K2-Horizon-MoVA-36B-A4B-GGUF at revision c8dde8bc6afe5b28e75c7d78db4fbd65d5fcf679, verified against the sha256 above.