QAT Q4_0 GGUF

Where it came from

• Repo / file: google/gemma-4-E4B-it-qat-q4_0-gguf, gemma-4-E4B_q4_0-it.gguf, no revision pinned.
• Command: models/gemma4-e4b/get.sh, written and run 2026-08-23 10:19Z with the parallel-range helper pget.sh at 6 ranges. The same script fetched gemma-4-E4B-it-mmproj.gguf; see Gemma 4 E4B mmproj (Google QAT).
• Size: 5,154,941,280 B. sha256 not on record. The file's local mtime is "23 Aug 11:43" (BST), i.e. 10:43Z; the download completed by 10:44Z when .dl_complete was written.
• Who asked: Alan, "also want to try gemma4 smaller models at full context".
• Made here: no. Never requantised or modified.

How it was served

All rows are the same file. Flags are from the scripts that launched each server; --jinja was always present; -fa and KV type were not on the line (defaults: KV f16) except where stated; --reasoning-format was never set. Run-log runtime for every row except worldview is llama.cpp b10369 (6e62ba538) stamped from evidence, not from the server.

Seats held: none. Not in fleet-models.ini, fleetview or any launchd plist.

Times of the nullschema/screening/grounding servers are derived from the run-log finish times (BST minus one hour) and the script start times; the servers were not time-stamped in their logs.

Decisions

• Downloaded for the context question.
• Benched across the 2026-08-23/24 grid at Alan's request.
• Kept through the 2026-10-11 model sweeps: ls models/gemma4-e4b shows the file present on 2026-10-23. Why it survived is not on record (the sweep notes were not read for an E4B line).
• Not seated. The assistant recommended it as the agentic model but the DISPATCH seat later went to K2-3.7B and the TAG seat to the 12B. No decision against E4B is on record.
• Not published to HF: it is Google's own redistributable QAT file (nothing to publish).

What went wrong

• Tagger/2 run-log row read 240 measured of 480 attempted, coverage 50.0. The first grid pass (2026-08-23 22:34Z) launched the harness against a server that was still loading: llama.cpp returns 200 on /health while loading and 503 on every completion. Each of the 240 cases was recorded as ERROR: HTTP Error 503: Service Unavailable. The results file was then opened in append mode by the successful re-run (22:44Z), so tagger__gemma4-e4b__study-nothink.jsonl holds 240 ERROR rows followed by 240 MEASURED rows; 240 distinct case ids (verified 2026-10-23). The run log counted coverage against the rows present, so a complete run looked half-finished. Cost: counted that way, the run read as 45.4% (218/480) where the measured figure is 90.8 (218/240). Fixed in the harness readiness check for later runs; the E4B row itself had not been corrected at the source.
• epistemics/3 → /4. A grader/output-format wording change moved E4B 83.3 → 97.9 with the same model and cases; the old run is kept as .superseded.
• Toolery timeouts scored as failures inflated the apparent gap between E-series and larger models; corrected 2026-08-24 15:43Z.
• Stale build stamps / missing flags / partial runs: build stamps are "evidence" (inferred from the scripts), not read from the servers, for all b10369 rows; the worldview row's b10893 comes from the server's props. All launches carried --jinja; none set --reasoning-format, so reasoning-capable behaviour was governed by the study-nothink / extraction profiles. No other partial runs.

What happened to it

Downloaded 2026-08-23 10:19Z–10:44Z → smoke test and context ladder 11:27Z → benched across 2026-08-23 to 2026-10-05 (nine suites) → on disk, unseated, 2026-10-23. Not deleted. Re-downloadable from google/gemma-4-E4B-it-qat-q4_0-gguf (current main may differ from what was fetched).