Observed facts: Google’s Hugging Face card lists an instruction-tuned Gemma 4 E4B QAT checkpoint in GGUF Q4_0 format. It gives the file size as 5.15 GB and says QAT is intended to reduce memory needs while preserving quality similar to bfloat16. The same card describes E4B as supporting text, image, and audio input, with a 128K-token context window.
Mechanism: QAT incorporates quantization into training so that lower-precision weights are not simply an after-the-fact conversion. The checkpoint is distributed in GGUF, which Google describes as a ready-to-deploy format for broad ecosystem compatibility. This packages a reduced-memory artifact that local-runtime builders can try without first producing their own quantized export.
Why now: The release turns the Gemma 4 E4B option into a specific downloadable local artifact; the model card’s 5.15 GB figure gives builders a concrete starting point for hardware-fit testing.
First implication: Builders can test whether a QAT GGUF checkpoint makes multimodal Gemma 4 E4B viable within their local memory budget.
Evidence boundary: The evidence is the vendor-published model card: its claim of quality similar to bfloat16 is not independent validation, and file size does not establish runtime memory use, speed, or task-level quality on any particular device.
First watch condition: Compare this checkpoint with the bfloat16 baseline on representative tasks and devices, measuring peak memory, latency, and output quality.