On-device AI RAM requirements cannot be read from a model download size. Peak memory also includes the in-memory weight representation, runtime buffers, KV cache, input tensors, operating-system headroom, and allocator behavior. The only reliable compatibility verdict comes from measuring the exact model artifact, runtime configuration, task, and target device together.
Disk size and RAM answer different questions
A download size tells you how much data must be transferred and stored. It does not tell you how much memory an inference session will request after the runtime opens the file. A deployment package may contain compressed or quantized weights, metadata, tokenizer data, and runtime-specific structures. The runtime may map some regions, allocate others, and create temporary buffers while processing input.
Cove provides a useful concrete example without turning it into a universal rule. Its currently pinned Gemma 4 E2B LiteRT-LM artifact has an expectedSizeBytes value of 2,583,085,056 in the Android model configuration. That number describes one exact artifact used for download and storage checks. It is not a claim about peak RAM and is not the size of every Gemma 4 E2B package.
The same configuration currently has an empty SHA-256 field. That means Cove can describe the expected file length, but it must not describe the current artifact as hash-verified until a real digest is recorded. File integrity and memory suitability are separate release checks.
Start with the weight-storage lower bound
A useful first estimate is:
weight bytes ≈ parameter count × stored bits per weight ÷ 8This is a lower bound, not a deployment forecast. Real artifacts may use mixed precision, additional tables, alignment, tokenizer assets, or architecture-specific structures. A format name such as INT4 also does not prove that every stored value occupies exactly four bits in the final file.
Use the formula to reject obviously impossible combinations, then switch to artifact inspection. Record the actual file, its source revision, conversion settings, quantization settings, and runtime version. Without those fields, two people saying they tested “the same model” may be testing different packages.
What else consumes memory
The weight representation is only one part of peak memory. A complete measurement plan should account for the following components.
Runtime and execution buffers
The runtime needs memory for its own objects, execution plan, kernels, tensor arenas, and temporary results. The amount and lifetime of those allocations depend on the model graph and backend. A CPU path, GPU path, and NPU path may allocate memory differently even when they load the same artifact.
KV cache and context
Autoregressive language models preserve intermediate attention state so they do not recompute the entire prompt for every generated token. That state grows with the active context. A model that loads successfully for a short prompt can fail later when a long conversation, retrieved documents, or a large output increases the working set.
Image and audio tensors
Multimodal tasks add decoded images, resized tensors, audio buffers, spectrograms, and modality encoders. Measuring a text-only prompt does not validate a camera or voice workflow. Use representative image dimensions and audio durations from the real product.
Application memory
The model does not run in an empty process. Camera frames, UI bitmaps, database pages, navigation state, caches, and background work compete for the same process and system resources. A model-only command-line test can be valuable, but it is not the final mobile compatibility test.
Operating-system headroom
Android and iOS need memory for the operating system and other processes. The amount available to an app changes over time. A robust app must handle memory pressure, process recreation, and failed allocations rather than assuming the amount reported at launch remains available.
Why device-RAM tables are often misleading
A table that says “this model needs this much RAM” hides the variables that determine the result:
- artifact and quantization;
- context configuration;
- enabled modalities;
- runtime and backend;
- model concurrency;
- application workload;
- system version and memory pressure;
- continuous use rather than a single successful request.
Without that metadata, the table is not reproducible. It may still be a useful anecdote, but it should not be presented as a compatibility guarantee.
For Cove, this means a public device matrix must be generated from stored benchmark records, not written from model size intuition. Until those records exist, the correct wording is “requires testing on this device tier,” not “supported” or “unsupported.”
A measurement procedure that produces usable evidence
Android Studio Memory Profiler and Android system memory diagnostics can observe an app’s real memory behavior. The important part is not the tool name but the test discipline: use the exact release artifact and keep the scenario repeatable.
Run at least these phases separately:
- Baseline: launch the app without loading the model.
- Artifact load: load the model but do not generate.
- Short request: run the smallest supported input.
- Representative request: run a real product input.
- Maximum promised context: exercise the limit the UI advertises.
- Repeated work: run multiple requests without restarting the process.
- Multimodal work: include camera or audio inputs if the product supports them.
- Lifecycle: background, restore, rotate, and recreate the process.
- Pressure: repeat with other normal applications present.
- Fallback: force the non-preferred execution backend if the product allows it.
Record model revision, file hash when available, file length, runtime version, backend, device model, chipset, OS build, scenario input, and peak observed memory. A result without this context cannot be compared safely with a later release.
A practical compatibility worksheet
| Question | Evidence to collect |
|---|---|
| Does the artifact fit storage? | Exact file length plus temporary download/update space |
| Does the model load? | Clean-start load result on the minimum target device |
| Does the real task complete? | Representative input and output, not a hello-world prompt |
| Does context growth remain stable? | Peak memory across the maximum promised context |
| Do images or audio change the result? | Separate multimodal measurements |
| Does repeated use leak memory? | Multiple runs in one process with allocation tracking |
| Does fallback work? | Result from each supported execution path |
| Can the app recover? | Behavior after cancellation, pressure, and process recreation |
What to publish on a trustworthy model page
Publish artifact facts separately from measured runtime facts. The model page may state which artifact was tested and its exact file length. A benchmark page should state the device, runtime, backend, scenario, and measured peak. A requirements page should link to those records and explain the acceptance rule.
Do not compress all three into a single “minimum RAM” badge. Readers need to know whether a number came from a formula, a file, or a real device measurement.
For an architecture-level comparison, read on-device AI vs cloud AI. For the underlying execution concepts, see how on-device AI works. Chinese readers can continue with 本地 AI 部署怎么选.
Last reviewed: 2026-09-16.