BF16

IFM's published full-size file. We made the other two from it, and scored it once. IFM's published GGUF.

Size: 18.0 GB
Status: Deleted 10 Sep 2026
Scored runs: 2
Smallest Mac: 32 GB estimate, 8K context

Results2 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
nullschemak2-7b-bf16-precision	37.5%	27.2–49.0	Passed 27/72	llama.cppextraction	2026-09-10
worldviewk2-7b-bf16-precision	30.0%	18.1–45.4	Passed 12/40	llama.cppextraction	2026-09-10

Runs marked unenforced were measured on a suite that requires constrained decoding, on a server shown not to apply the schema: mlx_lm accepts it and ignores it, and a few other servers and models break it. Those numbers do not measure what the suite is designed to measure. They are kept and labelled rather than deleted.

The recordHow it was made · how it was served · what went wrong · what happened to it

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-7B-BF16.gguf`
Format	BF16 GGUF, 18,010,413,440 B (16.77 GiB)
Where from	downloaded 2026-09-09 ~15:00–15:11Z from `IFM/K2-Horizon-7B-GGUF`
Status	deleted 2026-09-10 23:48Z
Hugging Face	https://huggingface.co/IFM/K2-Horizon-7B-GGUF

Where it came from

Repo / file: IFM/K2-Horizon-7B-GGUF / K2-Horizon-7B-BF16.gguf, the only GGUF in the repo on 2026-09-09.
Command, with HF_XET_HIGH_PERFORMANCE=1 and mlx-venv/bin/python (the interpreter that had huggingface_hub):

snapshot_download('IFM/K2-Horizon-7B-GGUF', local_dir='models/k2-horizon-7b',
allow_patterns=['*BF16*.gguf','*.json','*.jinja'], max_workers=8)

The first attempt (14:57Z) used hf_hub_download(..., max_workers=8) and died with TypeError:... unexpected keyword argument 'max_workers'. It was switched to snapshot_download so the parallel path applied.

Date: 2026-09-09, started 14:59Z, complete by 15:11Z.
Who asked: Alan, "the 7b model looks more interesting".

How it was served

label	dates (UTC)	binary	ctx / -np / KV / -fa / --jinja / --reasoning-format	profile	why this label exists
`k2-7b-bf16-precision`	2026-09-10 11:48Z–11:56Z	`llama.cpp-k2horizon/build/bin/llama-server` (fork b20, 35999d1)	`-c 32768 -np 1 -fa on -ctk q8_0 -ctv q8_0 -ngl 999 --jinja --reasoning-format deepseek`, alias k2-7b-bf16	extraction (temp 0, seed 42, thinking off)	top rung of the same-weights precision ladder

Footprint at load: 16.1 GB RSS. Never seated. Its main use was as the input to the two quants (variant docs K2-Horizon-7B Q8_0 (quantised here from IFM's BF16), K2-Horizon-7B Q4_K_M (quantised here from IFM's BF16)).

Decisions

Downloaded only as the quantisation source: "quantise locally rather than convert".
Scored once, for the precision question.
Deleted 2026-09-10 23:48Z with the 36B and 4B BF16s as "dead weight the precision ladder identified", on Alan's "Yeah". The stated basis was "Q8 ≡ BF16, 0 of 72 cases differ". On this model the two differ by one nullschema case (27 vs 26), and the 0-of-72 identity is the 3.7B's.
Not published (IFM's own file).

What went wrong

Download failure: hf_hub_download takes no max_workers. Fixed in four minutes.
Run-log build stamp: both entries carry llama_build: 0.4.0-dev (build 10893, commit c32d1dabe), the upstream binary. The server was the fork's. runtime_version (b20, 35999d1) is correct.
No partial runs and no missing flags. The label's intent (precision only, thinking off) matches --reasoning-format deepseek with the extraction profile.

What happened to it

Downloaded 2026-09-09 → quantised to Q8_0 and Q4_K_M 2026-09-09 → benched 2026-09-10 (2 suites) → deleted 2026-09-10 23:48Z. No RESTORE-deleted-*.sh entry (it predates the RESTORE pattern for this family; the 2026-10-11 tiersAB entry covers only the Q4_K_M folder). Re-downloadable from IFM/K2-Horizon-7B-GGUF (revision not pinned). The run-log rows survive.