FreshContextA context lab · Fife
Drawing
02 · Benchmarks
Sheet
2 of 3
Rev
A · 2026-10-01

Gemma 4 E4B · file← Gemma 4 E4B

QAT unquantized safetensors

Google's half-precision copy of the same trained weights, fetched to see whether 4-bit rounding explained its behaviour. Deleted two days later. Google.

Size
15.9 GB
Status
Deleted 26 Aug 2026
Scored runs
0
ResultsNever scored

This file never completed a scored run. Its record below says why.

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.

Filegemma4-e4b-bf16/model.safetensors (directory name says bf16; the card says half precision)
Formatsafetensors, QAT checkpoint with the quantisation removed, 14.8 GiB
Where fromdownloaded 2026-08-24 ~13:00Z
Statusdeleted 2026-08-26 10:23Z
Hugging Facehttps://huggingface.co/google/gemma-4-E4B-it-qat-q4_0-unquantized

Where it came from

  • Repo: google/gemma-4-E4B-it-qat-q4_0-unquantized, one model.safetensors plus configs (HF API listing 2026-08-24 12:56Z: "files: 1 ['model.safetensors']"). The repo holds the QAT-trained weights at half precision, "same QAT weights at half precision, so only precision differs". The exact dtype (bf16 or f16) was not read; the local directory is called gemma4-e4b-bf16.
  • Command: a one-off script: snapshot_download('google/gemma-4-E4B-it-qat-q4_0-unquantized', local_dir=models/gemma4-e4b-bf16, allow_patterns=['*.safetensors','*.json','*.model','*.txt']) through uv run --with huggingface_hub[hf_transfer]; it logged "Fetching 6 files". Files on disk afterwards: config.json, generation_config.json, model.safetensors, processor_config.json, tokenizer_config.json, tokenizer.json. The script also converted to f16 GGUF; see Gemma 4 E4B f16 GGUF (converted here from the QAT unquantized checkpoint).
  • Size: model.safetensors 14.8 (GiB, from an awk division by 1,073,741,824; exact bytes not on record), directory 29 G including the f16 GGUF. Download complete before 15:41Z. sha256 and revision not on record.
  • Missing from the download: a chat template. tokenizer_config.json had no chat_template. This is what invalidated the control run.
  • Who asked: Alan's question "are we running fp16 on the e models?" and "yes, do research on our specific issues and see what you can find"; the assistant chose this repo as the control.

How it was served

labeldates (UTC)binary and versionctx / -np / KV / -fa / --jinja / --reasoning-formatharness profilewhy this label exists
nonenever served (source for the f16 GGUF)nonenonenonesource file only; the served artefact was the GGUF made from it (Gemma 4 E4B f16 GGUF (converted here from the QAT unquantized checkpoint))

Seats held: none.

Decisions

  • Downloaded 2026-08-24 as the "ideal control" for the QAT-versus-full-precision question.
  • Deleted 2026-08-26 10:23Z. Assistant: "The experiment it was for is superseded"; Alan: "Yeah nuke the f16". The check run before deletion found no references in fleet-models.ini, harness code or suites.
  • Not published. Google's own repo.

What went wrong

  • No chat template in the repo. The downstream f16 run scored 24.5 and made no tool calls (see Gemma 4 E4B f16 GGUF (converted here from the QAT unquantized checkpoint)).
  • Directory name gemma4-e4b-bf16 asserts a dtype that was never checked; the only dtype statement on record is the HF card's "half-precision".
  • HF_HUB_ENABLE_HF_TRANSFER is deprecated in the installed huggingface-hub 1.16.1, and the hf_transfer extra does not exist; the download used the default Xet path, which the assistant noted at 12:57Z.

What happened to it

Downloaded 2026-08-24 12:57Z → converted to f16 GGUF → Toolery run invalid 15:41Z → deleted 2026-08-26 10:23Z (rm -rf models/gemma4-e4b-bf16, 29 G; no RESTORE entry) → re-downloadable from google/gemma-4-E4B-it-qat-q4_0-unquantized.