What is Gemma 4 E2B?
Gemma 4 is Google DeepMind’s open-weight model family. E2B is one of its smaller variants, and Google’s model card places that size in mobile and edge deployment scenarios. The name can be misleading if read as a complete count of every parameter stored in a checkpoint: Google reports 2.3 billion effective parameters for E2B and 5.1 billion when embeddings are included. Those are two related counts with different definitions; neither tells you how many bytes a particular downloaded package occupies.
The same card lists a 128,000-token context window, text and image input, audio input for E2B, and text generation. It lists Apache 2.0 as the license. These are useful model-level facts for building a shortlist. They are not proof that a converted package preserves each capability, that a specific Android runtime exposes it, or that a particular phone can complete a task within its memory and thermal limits.
The distinction matters because a model name is not a deployment manifest. An application needs an exact artifact, a tokenizer and conversation format, a runtime build, a backend choice, and input/output limits. Google’s official Gemma 4 model card describes the family; Google’s Gemma 4 page provides its broader positioning. Neither is a phone-by-phone compatibility database.
Core specifications and what they mean
The specification card above presents fields that are supportable at model level. “Not disclosed” for package size and minimum RAM is intentional. The model card does not establish a universal quantized download size or a minimum handset-memory requirement. A specific community conversion may publish its own file metadata, but that metadata belongs to that repository revision, not to every E2B package.
Context length also needs careful wording. The 128K value describes the model-card limit; it does not guarantee a mobile application can use all 128K tokens. A request includes system instructions, conversation history, task text, formatting tokens, and possibly image or audio representations. The runtime may impose a lower configured limit, and the device must hold the model, working buffers, cache, application state, and operating system processes at once. A prompt that is accepted but truncated or terminated before the task finishes is not a successful 128K workflow.
Similarly, “audio input” does not mean that E2B is an end-to-end speech product. A speech workflow can require capture permissions, speech preprocessing, an audio representation the model accepts, output formatting, and possibly playback or translation components. Each stage needs separate evidence. The feature list should say exactly which artifact and runtime were verified rather than turning a model-card modality into an app capability claim.
Which devices can run it?
Google describes smaller Gemma 4 models as designed for mobile and edge use. That is a deployment target, not a compatibility verdict. This page therefore does not publish a brand-specific supported-device list. It also does not set a 4 GB or 8 GB minimum. Those conclusions require measurements for a precise model file, runtime version, operating-system build, backend, task, and device configuration.
For an Android evaluation, keep the word “supported” tied to a reproducible test record. Record the SoC and memory configuration, OS build, app build, runtime coordinate and version, model repository and immutable revision, file name, digest where available, selected backend, input shape, context configuration, and output limits. Measure both the cold path (first process launch and model load) and repeat use. A benchmark on one phone is evidence for that test setup; it is not evidence for every device sharing a brand name.
Google AI Edge’s official LiteRT-LM Kotlin guide documents an Android/JVM engine API, advises initializing the engine away from the UI thread, and shows that callers should close the engine to release resources. It also documents backend configuration and the extra setup that may be needed for GPU or NPU execution. The guide does not certify all combinations of Gemma artifact, runtime release, accelerator driver, or handset. Treat backend availability as something to establish in logs and tests, not infer from a device specification sheet.
Strengths and limitations
The official evidence makes E2B a credible candidate for experiments where local inference, small-model deployment, text/image/audio inputs, and a clearly stated open-weight license matter. E2B’s effective parameter count is lower than its total count including embeddings, and the official family documentation explicitly targets smaller models at mobile and edge use. This provides a reason to test it—not a reason to skip testing.
The same evidence leaves meaningful questions unanswered for an app team. It does not give a supported minimum RAM for your converted artifact, a universal file size, an Android device matrix, sustained battery or thermal results, or an application-specific quality score. Published benchmark tables are tied to named tasks and evaluation setups; they should not be presented as predictions for a private field-note prompt, a translation pair, or a phone session. The model’s broad multilingual training description is not a guarantee of equal quality across languages or tasks.
There is also a practical distinction between a capable model and a complete user feature. E2B does not by itself provide a microphone flow, reliable speech segmentation, language selection, model downloading, cancellation, user-visible failure recovery, or a privacy explanation. Those are application and runtime responsibilities. See our guides to Android model memory requirements and thermal behavior for the measurements an application team should plan before making device claims.
A concrete evaluation scenario: private field-note summaries
Consider a team building an Android field-notes feature for workers who sometimes have no signal. A note may include a person’s name, a date, a negation (“do not reopen the valve”), and one action that must remain attached to its owner. The decision is not “Is E2B good?” It is whether one pinned E2B artifact, used through a stated runtime on a target device class, can complete this task with acceptable fidelity, usable latency, and safe recovery when it cannot.
Treat this as a proposed evaluation, not as a result already achieved by Cove or by a named phone. Build a small, privacy-safe fixture set with synthetic notes and reviewed expected summaries. Include different lengths and writing styles, but freeze the cases before comparing configurations. Decide what counts as a critical omission, contradiction, or invented detail. Do not send personal field records to an external evaluator unless your privacy review explicitly approves the transfer.
Reproducible Android test procedure
- Pin the candidate. Record the upstream model family and exact repository, immutable revision, artifact filename, file length, available digest, tokenizer/template, and license. Record whether the artifact is original or converted, who published the conversion, and what modality files it includes. A display name such as “Gemma 4 E2B” is not enough to reproduce a run.
- Freeze the runtime and task. Log the Android app build, LiteRT-LM artifact/version, device and OS build, backend request and actual initialization result. Write down the prompt, input cap, expected output format, sampling settings, and cancellation policy. Initialize long-running model work off the UI thread and verify that lifecycle cleanup closes resources.
- Run the fixed fixture set. Start with short notes, then increase input length in planned steps. Score whether names, dates, negations, owners, and requested actions are preserved. Log malformed output, truncation, load failure, process termination, and retries as first-class outcomes. Do not silently remove failed cases or combine scores from different prompts.
- Test resource and lifecycle behavior. Measure model-load and request stages at consistent boundaries. Capture process memory and device state, then repeat the same workload after warm-up and through background/foreground transitions. If comparing CPU, GPU, or NPU, confirm the actual backend from runtime output; requested acceleration is not proof that the delegate initialized.
- Verify offline operation separately. After model setup has completed, block network access and cold-start the app. Run the same fixture and inspect failure handling. Then restore connectivity and review whether the app tried remote inference, analytics, account validation, or model-update services. Local generation and an app making no network requests are separate claims.
- Publish a narrow result. Preserve the raw run manifest, fixtures or privacy-safe fixture identifiers, scoring rubric, failed cases, and measurement boundaries. State the exact artifact, runtime, device, OS, and task. Do not extrapolate one successful run into “works on Android,” “runs on all flagship phones,” or a universal speed or memory statement.
Acceptance criteria to set before running
- Task fidelity: every fixture is scored against the same prewritten rubric; critical names, negations, dates, and action ownership meet a threshold chosen by the product team before results are seen.
- Runtime reliability: model load, first response, repeated response, cancellation, background/foreground, and close are recorded; a crash, hidden fallback, or unreported truncation counts as a failed case.
- Resource and offline boundary: memory and timing checkpoints are reproducible, the intended backend is verified, and the airplane-mode run completes without an undisclosed remote-inference path.
Do not invent universal numeric thresholds for those checks. Product owners should choose them based on the user task and device class, then publish the threshold and the raw evidence together. If a build cannot capture a required signal, record that gap rather than describing it as a pass.
| Choice | What official evidence says | What still needs testing |
|---|---|---|
| Gemma 4 E2B | 2.3B effective parameters (5.1B including embeddings), 128K context, text/image/audio inputs, text output; Apache 2.0. | Exact Android artifact, load success, memory, task quality, latency, battery, thermal behavior, and offline lifecycle. |
| Gemma 4 E4B | 4.5B effective parameters (8B including embeddings), 128K context, text/image/audio inputs, text output. | Whether its larger footprint or quality trade-off fits the target workload and device; do not infer RAM from parameter count. |
| Hosted inference endpoint | Inference runs on remote infrastructure rather than the user’s endpoint device. | Whether connectivity, privacy review, cost, service terms, and failure behavior fit the task. |
For another model family, compare specifications only after checking the primary model cards. The Qwen 3.5 2B page demonstrates the same separation between a documented model limit and a tested mobile configuration. The model leaderboard is a catalog, not a device benchmark.
When to choose it—and when not to
Put E2B on a shortlist when your team can pin and distribute an exact artifact, owns Android runtime integration, has a task-specific quality rubric, and can test memory, failure recovery, and offline behavior on representative devices. Its documented mobile/edge positioning and text/image/audio inputs are relevant when those capabilities match the feature. Apache 2.0 is a useful license signal, but legal review should still retain the exact license and notices for the artifact actually used.
Do not choose it solely because “2.3B” sounds small, because a model card shows 128K context, or because a sample runs on someone else’s phone. If the product cannot accept a larger or versioned artifact, cannot tolerate model-load delays, depends on a modality the selected conversion may omit, or needs a device guarantee you have not measured, the evidence is not ready for a compatibility promise. Consider a different model/runtime or defer that claim until you have the required tests.
What is known about Cove’s implementation?
The Cove Android repository contains a model configuration pinned to a Hugging Face revision and records an expected file length of 2,583,085,056 bytes for one E2B LiteRT-LM artifact. Its SHA-256 configuration field is empty. That number is a development-time storage precheck value, not a measured download result or a universal Gemma package size. These source-code facts do not establish a verified download, a successful run across consumer devices, a signed public release, or a current distribution date. Cove’s public status and device-performance evidence are tracked separately, so this page makes no APK availability or phone-compatibility promise. The Cove app status page currently offers release notifications rather than a verified APK link.
Frequently asked questions
The concise questions at the top of this page are intentionally scoped to model-card and deployment evidence. In particular, “mobile model,” “mobile-compatible package,” and “available in an app store” are three different statements. A future update should only strengthen a claim when the relevant artifact, runtime, device run, or release record is available for review.
Editorial status: rewritten against Google DeepMind and Google AI Edge primary documentation plus the Cove Android source configuration on 2026-09-25. The Chinese edition is published for the site owner’s native-language review; that review is pending.