Gemma 4 E2B — Structured Output
A QLoRA fine-tune of Google's Gemma 4 E2B, trained to convert natural-language text into valid, schema-conforming JSON. Built for use cases where an LLM needs to reliably hand off structured data to downstream code — agent tool calls, form extraction, data pipelines, and anywhere else "give me clean JSON, not prose" actually matters.
Why this model exists
Most instruction-tuned models can produce JSON when asked, but they tend to wrap it in explanation, second-guess the schema, or take an unnecessarily long reasoning path to get there. This fine-tune trains that overhead away, so the model goes straight from a schema and a block of text to a clean, parseable JSON object.
Training details
| Base model | unsloth/gemma-4-e2b-it-unsloth-bnb-4bit |
| Method | QLoRA |
| Dataset | interstellarninja/json-mode-agentic |
| Task | Schema-guided JSON extraction from natural language |
| License | apache-2.0 |
Evaluation
Tested informally against the base model on a set of hand-written extraction tasks, covering simple schemas, nested/typed schemas, and — most importantly — cases where the input text is missing information the schema asks for.
Speed. On every test, the fine-tuned model produced output immediately, with no visible reasoning phase. The base model consistently reasoned through a multi-step "analyze, map, construct, review" process first, taking 30+ seconds before reaching the same answer.
Accuracy on typed schemas. On a schema mixing strings, numbers, booleans, and arrays
(e.g. price: number, in_stock: boolean, tags: [string]), the fine-tuned model matched
every field type correctly, including nested arrays and decimal numbers. On a separate,
simpler test, it returned one field (age) as a string instead of the integer the schema
specified — the base model got this particular field right. Across the full test set this
looked like an isolated slip rather than a systematic pattern, but it's a real, observed
behavior worth knowing about if your use case depends on strict type fidelity.
Handling missing data. This was the most important test. When a required field wasn't
present anywhere in the input text, the fine-tuned model correctly returned null for that
field instead of inventing a plausible-looking value to fill the schema. This matters more
than it might sound — a structured-output model that fabricates missing fields to "complete"
a schema is a real liability in any pipeline that trusts its output, and this model didn't
do that in testing.
Bottom line: significantly faster and more direct than the base model on structured extraction tasks, with strong type accuracy on complex schemas and correct, honest behavior on missing data. The one observed weak spot — an occasional type mismatch on simpler schemas — is worth validating against your own schema and data before relying on it in production.
This isn't a formal benchmark result, and it's a small test set. If you run it against something more rigorous (JSON-mode-eval, a custom test suite, or your own production data), I'd genuinely like to hear how it does — open an issue or start a discussion on this repo.
How to use
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained(
"agentbyumer/gemma4-e2b-structured-output",
device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("agentbyumer/gemma4-e2b-structured-output")
prompt = """Schema: {"name": "string", "age": "integer", "email": "string"}
Text: "Hi, I'm Sarah Ahmed, I'm 29 years old, you can reach me at sarah.ahmed@email.com"
Task: Extract the information into the given JSON schema."""
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
A GGUF-quantized version for local/CPU inference is planned — check back or watch this repo for updates.
Part of an ongoing series
This is one of several small, task-focused fine-tunes I'm building and evaluating as part of exploring what narrow specialization can (and can't) improve in sub-5B parameter models — covering function-calling, math reasoning, code generation, and structured output so far. More context on the approach and results across the series.