K2-Horizon-3.7B · file← K2-Horizon-3.7B

BF16

IFM's full-size original. We made the others from it, then deleted it once the Q8_0 matched it. K2-Horizon-4B-BF16.gguf, downloaded from IFM.

Size: 10.1 GB
Status: Deleted 10 Sep 2026
Scored runs: 5
Smallest Mac: 18 GB estimate, 8K context

Results5 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
nullschemak2-4b-bf16-precision	43.1%	32.3–54.6	Passed 31/72	llama.cppextraction	2026-09-10
synthesisk2-4b-bf16-precision	56.7%	44.1–68.4	Passed 34/60	llama.cppextraction	2026-09-10
toolcallk2-4b-bf16-precision	100.0%	94.0–100.0	Passed 60/60	llama.cppextraction	2026-09-10
toolscalek2-4b-bf16-precision	100.0%	91.2–100.0	Passed 40/40	llama.cppextraction	2026-09-10
worldviewk2-4b-bf16-precision	50.0%	35.2–64.8	Passed 20/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-4B-BF16.gguf`
Format	BF16 GGUF, 10,128,343,424 B (HF size; 9.4 GiB local listing)
Where from	downloaded 2026-09-09 from `IFM/K2-Horizon-3.7B-GGUF`
Status	deleted 2026-09-10 23:48Z
Hugging Face	https://huggingface.co/IFM/K2-Horizon-3.7B-GGUF

Where it came from

Repo / file: IFM/K2-Horizon-3.7B-GGUF / K2-Horizon-4B-BF16.gguf.
Revision: 67b824b8079635b77e19a2a4cd2682a9716478c1; the download metadata also records 372ecf9977eb22c92739fec478f2c887daef659d7c55a609ac97b905d1a243b1, which is the LFS etag and so, by Hugging Face convention, the file's sha256 (reconstructed — the hash was never computed locally).
Command:

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

run under mlx-venv/bin/python with HF_XET_HIGH_PERFORMANCE=1.

Date: 2026-09-09; the metadata timestamp converts to 16:02:08Z.
Who asked: Alan — "what about the 4b model" / "nah there's a 3.7b model". The assistant noted that this file name is the '4B model' Alan was reading about.

How it was served

label	dates (UTC)	binary and version	ctx / -np / KV / -fa / `--jinja` / `--reasoning-format`	harness profile	why this label exists
`k2-4b-bf16-precision`	2026-09-10 11:26Z–11:37Z	k2horizon fork `llama-server`, b20 `35999d1`	`-c 32768 -np 1` / `-ctk q8_0 -ctv q8_0` / `-fa on` / `--jinja` yes / `deepseek`; `-ngl 999`	extraction	top rung of the precision ladder, Alan's "whether the fp16 really nails things"

Server footprint at load: 11.8 GB RSS. Never seated.

Decisions

Downloaded as the source for local quants — IFM published GGUFs, and the download pattern took only the BF16.
Run once as the full-precision anchor of the ladder.
Deleted 2026-09-10 23:48Z on Alan's "Yeah", with the reason "same, verified on all five suites" (the 4B line of the assistant's precision ladder, which on the 7B line reads Q8 ≡ BF16, 0 of 72 cases differ).
Not re-published (it is IFM's file).

What went wrong

Stale build stamp. The run log's llama_build for all five rows says 0.4.0-dev (build 10893, commit c32d1dabe); the ladder script ran llama.cpp-k2horizon/build/bin/llama-server, and upstream b10893 cannot load this architecture. runtime_version is correct.
Partial-run check: every results file has its suite's full case count (60/40/40/72/60, counted 2026-10-23).

What happened to it

Downloaded 2026-09-09 → quantised to Q8_0 and Q4_K_M the same day → benched 2026-09-10 → deleted 2026-09-10 23:48Z, no RESTORE entry → re-downloadable from IFM/K2-Horizon-3.7B-GGUF (pin revision 67b824b8… to get the same bytes).