Google built Gemma 4 E2B and E4B to run on the devices people carry: phones, tablets and laptops. At full precision they are still large files: 9.3 GB for E2B and 14.9 GB for E4B. We compressed both with techniques discovered by Artemis. Our E2B files are 2.1 to 2.3 GB and our E4B files 3.6 to 4.2 GB, and they run on stock llama.cpp.
This article starts with what two of the E2B files do on ordinary tasks, then gives the measurements. The rest of Artemis Edge is decision models; these two are general chat models.
Why file size matters on a small device
On a phone the model file has to be downloaded, stored and loaded into memory next to everything else the phone is running. A 9.3 GB file is a big download over mobile data and is larger than the whole memory of an 8 GB phone. A 2.3 GB file is about a quarter of that size.
File size is not the same as memory in use, so here is what was measured. On the E4B card, llama.cpp running on CPU only with an 8,192-token context peaked at 4.3 to 5.1 GiB of system memory for our three E4B files (measured on the host of an NVIDIA A100 while answering 10 short chat prompts). That is less than the 8 GB of RAM many recent phones have. We have not tested any of these files on a phone, and the E2B card has no memory measurement yet.
Six everyday prompts
We gave the original E2B (the 9.3 GB BF16 conversion of Google's QAT checkpoint) and our default and smallest E2B files, gemma-4-E2B-it-Artemis-2.3GB.gguf and gemma-4-E2B-it-Artemis-2.1GB.gguf, the same six prompts: the kind of thing someone might ask a model on their phone. All three ran on a desktop CPU (AMD Ryzen 9 9950X) with llama.cpp 1e6f04a, greedy decoding and thinking off, so each file gives its single most likely answer every time. Each prompt was run once per file and every answer is kept.
On three prompts all three files gave the same answer, word for word.
An invoice
The prompt was a short supplier invoice (total due GBP 237.00, issued 2 October 2026, payable within 30 days) and a request for JSON. All three returned:
{
"amount_due": 237.00,
"currency": "GBP",
"due_date": "2026-11-01"
}
That is correct: 30 days from 2 October is 1 November.
A word problem
"A shop sells apples in bags of 6. I need 50 apples for a school event. How many bags do I need to buy, and how many apples will be left over?" All three answered: "You need to buy 9 bags, which will give you 54 apples. You will have 4 apples left over."
A two-line summary
The message was a staff note about an office move, with new key and return dates, what to bring, parking and lockers. All three wrote: "The office move is delayed until Monday, November 3rd, due to electrical inspection issues. Please work from home until November 10th, bringing your laptop and charger."
A calendar reply
The prompt asked for a reply declining a Thursday 2 pm budget review in favour of Friday before 11. The 2.1 GB file's answer matched the original word for word: three draft replies, the first being "Hi Dan, thanks for the invite! Unfortunately, I'm tied up at a client site all afternoon on Thursday. Would Friday morning work for you? I'm free anytime before 11 am. Let me know what time suits!" The 2.3 GB file kept that first draft (ending "Let me know what time suits you best!") and wrote different second and third drafts. They are still correct, polite replies.
Where the small files slip
A translation
Asked to translate "The pharmacy is closed on Sunday, but you can collect your prescription on Monday after 9 in the morning" into French, all three opened with the same main translation: "La pharmacie est fermée le dimanche, mais vous pouvez récupérer votre ordonnance lundi après 9 heures." The extras differ. The original offered "retirer votre ordonnance" as a more formal option, which is what a French pharmacy would say. The 2.3 GB file offered "collecter votre ordonnance" instead, which is not natural French. The 2.1 GB file kept "retirer" but labelled that option with the wrong verb. In both cases the small file's answer is a little worse than the original's.
A scheduling question all three get wrong
"I have three 45-minute meetings starting at 10:30, with a 15-minute break between each one. What time does the last meeting end?" The right answer is 1:15 pm. All three files, the original included, answered "12:45 PM" and then wrote working that ends at 1:15. The mistake comes from the original model, and the compressed files repeat it. They only lay out the working differently.
Six prompts are not a benchmark. The measurements below cover 640 scored token positions, 50 greedy continuations and a 310-item task sample, and they show how often the files drift.
The originals
Google DeepMind released Gemma 4 in five sizes, from E2B to 31B, under Apache 2.0 (model card). The two smallest are built for phones and laptops. The "E" stands for effective parameters: E4B has about 4.5 billion and E2B about 2.3 billion, and per-layer embedding tables that are only used for lookups bring the totals to about 8 and 5.1 billion. Both take text, images and audio, have an optional thinking mode, can call tools, and read up to 128K tokens of context.
In June 2026 Google added quantisation-aware training (QAT) checkpoints. QAT simulates low precision while the model trains, so it loses less quality when it is compressed later. Our files are made from those QAT checkpoints (E4B, E2B) and are text only. Every comparison uses the BF16 conversion of the same checkpoint as the reference.
Why a chat model is tested differently
A chat model has no fixed list of answers to compare, so we measured three other things. "Same next token" is how often a file predicts the same next token as the original, over 640 scored positions. "Matching tokens" is the share of the first 32 tokens a file writes with greedy decoding that match the original's token at the same position. A 310-item task sample from ARC-Challenge, WinoGrande, HellaSwag, MMLU-Pro, GSM8K, BFCL and IFEval checks whether answers change; on a sample this size, differences under about 4 points are noise.
None of these is decision agreement, and a high next-token figure does not mean the replies are identical. What they show is how soon a compressed file starts to drift from the original.
Gemma 4 E2B in 2.3 GB
The original QAT checkpoint is 9.3 GB. The Gemma 4 E2B Artemis GGUF repository has three files from 2.1 to 2.3 GB, 75 to 78% smaller. The card's first choice, gemma-4-E2B-it-Artemis-2.3GB.gguf, predicts the original's next token 95.8% of the time on CPU (an AMD Ryzen 9 9950X), and 74.7% of the first 32 tokens it writes match the original's. The 2.1 GB file scores 91.6% and 67.1%. Both are lower than the E4B figures below, which fits what the six prompts showed: the answers mostly hold, while longer text drifts from the original's wording sooner.
On the task sample none of the three files shows a change larger than noise. The 2.3 GB file is 1.6 points lower (the 95% range runs from -5.6 to +2.4), and it loses 3 of the 16 maths questions in the sample.
Unsloth's UD-Q4_K_XL, at 2.62 GB, is closer to the original than ours, with 98.3% next-token agreement. Ours are for when the download has to be smaller than that. Below 2.6 GB, the public files we tested from the same checkpoint predict a different next token 45 to 55% of the time and lose 23 to 34 points on the tasks.
Gemma 4 E4B in 4.2 GB
The original QAT checkpoint is 14.9 GB at BF16. The Gemma 4 E4B Artemis GGUF repository has three files from 3.6 to 4.2 GB, 72 to 76% smaller. The card's first choice is the 4.2 GB file, gemma-4-E4B-it-Artemis-4.2GB.gguf. On CPU (an AMD Ryzen 9 9950X) it predicts the original's next token 98.4% of the time, 93.9% of the first 32 tokens it writes match the original's, and its task score moves by +0.3 points.
At this size the main public alternative is Unsloth's UD-Q4_K_XL, and the two test about the same. Unsloth's file predicts the original's next token slightly more often (98.8%); ours matches more of the first 32 generated tokens (93.9% against 90.2%). A second check on an RTX 5090, over 51,200 positions of WikiText-2, gave 98.5% for ours and 98.6% for Unsloth's.
Under 4 GB
The table leaves out Unsloth's UD-Q2_K_XL and six mradermacher files from 3.29 to 3.79 GB; all of them are in the chart.
| File | Size | Same next token | Matching tokens (first 32) | Task accuracy change (points) |
|---|---|---|---|---|
| Unsloth UD-Q4_K_XL | 4.22 GB | 98.8% | 90.2% | -0.6 |
gemma-4-E4B-it-Artemis-4.2GB | 4.22 GB | 98.4% | 93.9% | +0.3 |
| TheStageAI M | 4.03 GB | 83.6% | 38.9% | -1.3 |
| mradermacher i1-IQ3_XXS | 3.98 GB | 73.1% | 28.3% | -6.8 |
gemma-4-E4B-it-Artemis-3.8GB | 3.84 GB | 94.7% | 85.6% | 0.0 |
gemma-4-E4B-it-Artemis-3.6GB | 3.56 GB | 93.6% | 65.2% | +1.6 |
Our 3.8 GB file predicts the original's next token 94.7% of the time and scores the same as the original on the task sample. The public files we tested below 4 GB predict a different next token 27 to 74% of the time and lose 7 to 40 points on the same tasks. Our 3.6 GB file also holds its task score, but its longer text drifts from the original sooner, with 65.2% matching tokens.
How it was tested
Every file, ours and public, was compared with the BF16 conversion of the same QAT original at identical llama.cpp settings (commit 0504396, context 8192, greedy decoding, thinking off) on an AMD Ryzen 9 9950X, CPU only. The checks were next-token agreement and KL divergence over 640 positions from 20 fixed documents, greedy 32-token continuations on 50 prompts (code repair, maths, chat, multilingual text and report excerpts), and the 310-item task sample. The task sample is there to compare files and is not a benchmark score.
Unsloth's UD-Q2_K_XL may come from a different checkpoint. The cards list it, but it is not a like-for-like comparison.
Run it
hf download turintech/gemma-4-E2B-it-Artemis-GGUF gemma-4-E2B-it-Artemis-2.3GB.gguf --local-dir .
llama-server -m gemma-4-E2B-it-Artemis-2.3GB.gguf --port 8080 -c 8192 --jinja
The chat template turns thinking on by default, so allow about 1,500 output tokens or turn thinking off in the request. For E4B, download gemma-4-E4B-it-Artemis-4.2GB.gguf, or gemma-4-E4B-it-Artemis-3.8GB.gguf to stay under 4 GB, and run the same command. The model cards for E4B and E2B have every file, the full tables and checksums, and both are in the Artemis Edge compressed LLMs collection.
These are independent conversions, not affiliated with or endorsed by Google, and the credit for Gemma belongs to Google DeepMind. The files were compressed by TurinTech with techniques discovered by Artemis. For a version tuned on your own data, built for your hardware or compressed from a private model, book a call.
