Granite Guardian 3.1 2B · file← Granite Guardian 3.1 2B

Granite Guardian 3.1 2B Q4_K_M

The only file we held, a community conversion rather than IBM's own. Run once through our checking test, then deleted in an October clear-out. DevQuasar community GGUF.

Size: 1.5 GB
Status: deleted by 2026-10-11 (Tiers A & B sweep); no re-download command
Scored runs: 1
Smallest Mac: 8 GB estimate, 8K context

Results1 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
screeninggranite-guardian-3.1-2b	0.0%	-0.0–6.0	Passed 0/60	llama.cppextraction	2026-09-07

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	`guardian-3.1-2b-Q4_K_M.gguf`
Format	Q4_K_M GGUF, 1,545,303,040 B (HF size)
Where from	downloaded 2026-09-07 ~17:07Z from DevQuasar-11's community GGUF repo, saved under a shortened local name
Status	deleted by 2026-10-11 (Tiers A & B sweep); no re-download command
Hugging Face	https://huggingface.co/DevQuasar-11/ibm-granite.granite-guardian-3.1-2b-GGUF

Where it came from

Repo / file: DevQuasar-11/ibm-granite.granite-guardian-3.1-2b-GGUF / ibm-granite.granite-guardian-3.1-2b.Q4_K_M.gguf. A community conversion of IBM's ibm-granite/granite-guardian-3.1-2b. The local file was renamed from the HF basename.
Command:

curl -sL --retry 20 --retry-delay 4 --retry-all-errors --no-progress-meter \
-o models/granite-guardian-3.1-2b/guardian-3.1-2b-Q4_K_M.gguf \
"https://huggingface.co/DevQuasar-11/ibm-granite.granite-guardian-3.1-2b-GGUF/resolve/main/ibm-granite.granite-guardian-3.1-2b.Q4_K_M.gguf"

Run with nohup at 17:07Z; 0.25 of 1.44 GB at 17:07:29Z.

Size: 1,545,303,040 B. This is the HF API size (the API listed "1.44 GB"); the local listing of 2026-09-12 shows "1.55 GB" decimal, consistent. The local file was never measured to the byte. Revision and sha256: not on record.
Who asked: Alan, "Is there a smaller granite model..." and "Sure".
Not an IBM file. It is third-party. Whether DevQuasar's conversion matches IBM's weights was not checked. The GGUF loaded and produced coherent Yes/No answers on llama.cpp b10618.

How it was served

label	dates (UTC)	binary and version	ctx / -np / KV / -fa / --jinja / --reasoning-format	harness profile	why this label exists
`granite-guardian-3.1-2b`	2026-09-07 17:10Z	`llama.cpp/build/bin/llama-server`, b10618 `eb25b7263`	`--ctx-size 16384 --n-gpu-layers 99 --jinja`; -np, KV type and -fa left at defaults (not on the line); no `--reasoning-format`	extraction, `--no-resume`	the one screening run: does a 1.4 GB judge match the 4.1-8b's 100%? Label is the server alias `$N` passed as `--model-id`
— (probe, no label)	2026-09-08 14:01Z	Hypura (`hypura/target/release/hypura serve`)	—	none	used as the smallest GGUF to test whether Hypura serves `/v1/chat/completions`
— (llama-bench, no label)	2026-09-11 13:13Z	`llama.cpp/build/bin/llama-bench`	`-p 0 -n 64 -ngl 99 -r 2`	none	"what is the actual fastest model on this box"

Seats held: none. It ran beside a resident 80B (total RSS 46.22 GB at the time), the assistant's stated reason for running it there: "small enough to co-reside, so nothing gets evicted".

Stale-stamp check: the run-log llama_build "build 10618, commit eb25b7263" matches the evidence (the 2026-08-25 rebuild, the next rebuild was 2026-09-10). Missing-flag check: --jinja present.

Decisions

Downloaded to size the judge seat.
Not adopted: "The judge seat doesn't shrink to 1.4 GB" (assistant).
Kept on disk through the 2026-09-09, 09-12 (listed DO NOT DELETE) and 09-16 cleanups. The 2026-09-16 inventory marked it KEEP.
Deleted 2026-10-11 as "Superseded by 4.1-8b (live seat)" (RESTORE-deleted-20261011-tiersAB.sh).
Not published (a community file).

What went wrong

0.0% in the run log is a format failure. The grader needs verdict JSON; the model answers Yes/No. All 60 rows malformed. It cost nothing at the time, since the assistant read the raw answers within a minute, but the 0.0 stayed in the run log and the published table (see the family doc).
Promised cleanup not done. "I'll delete the misleading 0% artifact"; result file and manifest are still in benchmarks/results/.
Directory listings disagree about the deletion. The sweep note lists the file as removed (a lab note, Tier B), but the review that morning's "Never-benched leftovers" line still named granite-guardian-3.1-2b as remaining even though it has one benched run. The directory is absent on disk now (ls models, 2026-10-23), so the sweep note is right.
Fuzzy-match false duplicate (2026-09-16): the 4.1-8b's HF cache was tagged "DUP of granite-guardian-3.1-2b"; nothing was acted on.
Partial-run check: 60 rows, complete. Stale-build and missing-flag checks: clean.

What happened to it

Downloaded 2026-09-07 17:07Z → benched 2026-09-07 17:10Z (0/60 as scored; 71.7% by hand) → Hypura probe 2026-09-08 → llama-bench 2026-09-11 → KEEP in the 2026-09-16 inventory → deleted by 2026-10-11 (Tiers A & B sweep; RESTORE-deleted-20261011-tiersAB.sh holds only a comment line, no re-download command). Re-downloadable from DevQuasar-11/ibm-granite.granite-guardian-3.1-2b-GGUF (expect 1,545,303,040 B) or re-convertible from ibm-granite/granite-guardian-3.1-2b. The exact deletion time is not on record.