Gemma 4 E2B 128K Context: Verify the Real Android Limit

Direct answer

Google’s Gemma 4 model card lists a context length of 128K tokens for E2B and E4B. That is an official model-family specification; it is not an assurance that a specific Android application can accept and complete a 128K request. The delivered artifact, quantization, tokenizer, runtime configuration, prompt construction, multimodal inputs, output budget, and available memory all affect the usable boundary. An app may configure a lower maximum or fail before the model-card limit. To answer the device question, pin the artifact and runtime, measure token counts, increase a fixed task in stages, preserve memory and completion records, and retain failures such as truncation, timeout, or out-of-memory. Do not derive a RAM minimum or response speed from the context value. This guide documents a validation method, not a Gemma performance result or device-compatibility list. It also combines the overlapping validation and boundary-test themes into one canonical guide; the separate context-boundary seed remains noindex so the two pages do not compete for the same query.

Scenario: deciding whether a long document fits an Android summarization task

A product team wants an Android app to summarize a long, user-selected document with Gemma 4 E2B. The official model card says 128K, but the app uses a converted artifact and a particular runtime. The team needs to know what the full task can complete under its own prompt, output, and memory constraints before describing the feature to users.

Decision

Treat 128K as the published model-card limit. Test the exact app artifact and runtime at increasing, token-counted input sizes, and define “complete” to require an intact input, useful summary, acceptable memory behavior, and no hidden fallback. Record a smaller app limit if that is what the evidence supports.

Expected outcome

The team publishes the largest tested task boundary for that exact configuration, along with setup and limitations. It does not claim that every Android phone can use the full model-card window.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Google’s Gemma 4 model card lists 128K context for E2B/E4B
• A runtime may configure a smaller limit than the model card
• Actual completion and peak memory require a pinned device-specific record

A device badge must come from an exact device, OS, artifact, runtime, backend, and workload record, not parameter-count intuition.

Implementation workflow

1. Pin the model artifact and preprocessing path. Record the official source, immutable model revision, conversion or quantization, tokenizer files, and any vision or audio components involved. Capture the application build and preprocessing code that turns a selected document into model input. A different artifact or tokenizer can change token counts, memory needs, and failure behavior, so do not mix runs across revisions.
2. Inspect the runtime’s configured maximum. Record the runtime version, backend configuration, context allocation, and any application-side input cap. The model card describes a model property; runtime settings determine what the app asks the engine to allocate or accept. Keep the actual configuration file or build setting with the test record, and distinguish a requested maximum from an observed successful request.
3. Create an ordered, representative fixture set. Use privacy-safe documents with reviewed expected facts and summaries. Begin with a short control, then increase input length in planned steps while keeping the prompt structure and output budget stable. Include paragraphs, names, dates, negation, and section boundaries. Count tokens with the exact tokenizer for the tested artifact rather than estimating from characters or pages.
4. Run each fixture from a clean task state. Use the same app and device state for each attempt. Record cold load separately from an already-loaded model, then submit one fixture at a time. Capture accepted input count, generated output, whether the entire source was included, duration boundaries if measured, and the completion status. A prompt that begins generating after input truncation is not a successful long-context pass.
5. Observe memory and operating-system behavior. Use Android Studio Memory Profiler or another documented tool to capture consistent checkpoints around model load, input preparation, inference, and release. Record process peak and any system pressure, background interruption, or process death. Do not convert the downloaded file size into a RAM requirement; weights, runtime buffers, cache, tensors, and other app allocations all contribute.
6. Repeat around the first boundary and preserve failures. When a fixture fails or becomes incomplete, repeat nearby lengths with the same configuration to determine whether the result is reproducible. Keep out-of-memory, truncation, timeout, malformed output, and recovery outcomes in the dataset. Do not select only the longest successful sample or average away failures. If the runtime cannot expose the failure reason, record that evidence gap.
7. Test the actual product task and report a scoped result. Evaluate whether the summary preserves required facts and user intent, not merely whether the engine returned text. Define acceptance criteria before testing and have a reviewer inspect outputs against the reference. Report the artifact revision, runtime, device and OS, configured context, measured input length, output budget, memory method, completed tasks, and failures. State that the result applies only to this configuration.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The 128K figure is attributed to Google’s official model card, not described as a universal Android limit.
• Artifact revision, tokenizer, runtime, context setting, prompt, and measured input tokens are recorded together.
• At least one representative task is checked for full-input inclusion, useful output, memory behavior, and release/recovery.
• Truncation, out-of-memory, timeout, and incomplete outputs remain in the result record; any conclusion is bounded to the tested configuration.

Decision table

Failure patterns to prevent

• Calling the published context an Android-supported limit
• Confusing token count, context allocation, and output budget
• Reporting only the longest successful run and discarding failures

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Gemma run guide
• Android Memory Profiler
• Cove benchmark method
• Google AI for Developers — Gemma 4 model card
• Google AI Edge — LiteRT-LM repository
• Android Studio — Memory Profiler

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions