Direct answer
A useful resource budget is a tested operating envelope for one task and configuration, not a universal phone specification. Model-file storage length is only one input. Process memory may also include runtime allocations, weights or mapped pages, context or KV cache, input/output tensors, decoded image and audio buffers, tokenizer state, UI state, history, and temporary copies. Android distinguishes Java/Kotlin heap, native heap, graphics, and other process memory; a profiler is a measurement tool, not proof that another device has the same headroom. Record exactly what the tool reports rather than adding unlike categories into an unlabeled RAM-required claim. Define an envelope around a user task: exact artifact and runtime, intended maximum input/context, output limit, media dimensions or duration, concurrency, lifecycle, and acceptable failure behavior. A short text prompt cannot establish capacity for long context, image decoding, simultaneous audio capture, or multiple sessions. If the feature accepts images, include decoded image and preprocessing; for speech, include capture buffers and any transcription or speech generation actually used. Name each stage and whether buffers are retained, copied, or released. Measure a baseline before model load, then checkpoints after artifact verification, engine initialization, representative task, cancellation, and cleanup. Repeat a fixed task to find growth that one run misses. Capture process memory with a named Android tool, alongside lifecycle logs and task outcomes. Record OS build, background activity, charge state, and available thermal signal because they can affect observations. Do not turn one profiler snapshot into a minimum-device claim or promise that Android will not reclaim the process. Design concurrency intentionally. If the selected session is not verified for parallel access, serialize it. Bound queued work, media dimensions, context, retained history, and output according to real configuration. Release temporary bitmaps and buffers when ownership ends; cancellation should stop or explicitly classify native work, not merely hide progress. After memory pressure or process death, separate user-authored data from disposable derived state and offer recoverable continuation or a clear restart. Never silently erase history to recover the model. Acceptance means more than surviving one run: the task completes under the recorded envelope, repeated runs show no unexplained retained growth, cancellation and cleanup leave the next run in a known state, and low-memory interruption has a safe user-visible outcome. If a feature is disabled, input reduced, or the user asked to close another task, document and test that behavior and confirm original data remains safe. Cove has no raw device records that support a particular RAM threshold or sustained workload, so the proper public output is a method and tested scope, not a number. Start by describing one task, maximum inputs and output, concurrency, and session lifetime; translate promises into fixtures and pass/fail rules. Map app heap, native runtime, model artifact, cache/context, media decode/preprocessing, UI, persistence, and temporary buffers; mark ownership and release points, not equating file bytes with resident memory. Profile baseline, load, task, repeat, cancellation, cleanup, and recovery on the exact build. Keep raw records, tool, timestamps, artifact/runtime identities, and failures. Change one boundary dimension at a time—context, image, audio, history, or concurrency—and preserve rejected cases instead of searching for an impressive maximum. Define graceful degradation and verify it preserves user data, explains retry or reduced input, and makes no broader device claim. The budget is an engineering aid valid only for the tested artifact, runtime, device, OS state, workload, and method; repeat after material changes.
An image-and-text assistant must recover after memory pressure
A short text test has no immediate failure, but the planned local assistant also accepts large photos, retains conversation history, and allows cancel-and-retry. No complete device benchmark records exist, and the team needs a safe operating boundary rather than a marketing RAM figure.
Decision
Map the complete working set and lifecycle, profile representative stages, serialize unverified native work, and define a reduced-input or restart path that preserves user-authored state.
Expected outcome
The release decision follows reproducible fixtures and recovery behavior; unsupported RAM, thermal, battery, and device claims remain unpublished.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Task and device test matrix
- Lifecycle resource checkpoints
- Limit, cancellation, and recovery records
A device badge must come from an exact device, OS, artifact, runtime, backend, and workload record, not parameter-count intuition.
Implementation workflow
- Write the task envelope. Specify artifact/runtime, maximum prompt or context, output limit, media dimensions or duration, session lifetime, concurrency, history policy, and expected UI behavior on cancellation or memory pressure.
- Map resources by owner. List process heap, native runtime, model pages, cache, tensors, decoded media, preprocessing, UI, persistence, and temporary copies. Identify each owner and release point.
- Capture lifecycle checkpoints. Measure clean baseline, initialization, one task, repeated tasks, cancellation, cleanup, and recovery with the same tool and device build. Preserve all observations and failures, not one peak screenshot.
- Test input and concurrency boundaries. Change one variable—context, image size, audio duration, retained history, or simultaneous work. Keep unsupported and failed cases visible; one success does not establish a universal maximum.
- Verify graceful degradation. Reproduce pressure and confirm the app explains the next action, offers a justified smaller-input or retry path, releases temporary resources, and preserves source and saved history.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The record names task, artifact, runtime, device/OS, profiler, workload, lifecycle checkpoints, and relevant environment state.
- Repeated runs, cancellation, cleanup, and recovery have outcomes; unexplained retained growth remains an open issue.
- Memory pressure produces a user-visible response and never silently deletes user-authored content.
- No minimum-RAM, sustained-performance, thermal, battery, or broad-compatibility claim exceeds raw device evidence.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Artifact storage length | Bytes occupied on disk | Describes the file, not process working set or device RAM requirement. |
| Single-task profile | Observed memory during a named fixture | Useful for that device and stage; misses repeated growth and recovery. |
| Task-envelope study | Lifecycle checkpoints with boundaries and recovery | Supports a scoped budget when raw records and tool definitions are retained. |
| Universal minimum-RAM badge | Generalized device claim | Not supported by one file length or isolated run; it needs validated multi-device evidence. |
Failure patterns to prevent
- Using one universal RAM threshold
- Ignoring background and media allocations
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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
- Android Developers — Memory overview
- Android Developers — Memory Profiler
- Android Developers — Analyze native memory
- Cove benchmark raw-data requirements
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does model download size tell me how much RAM is needed?
No. Runtime memory also depends on native buffers, weights or mapped pages, context cache, tensors, media preprocessing, UI state, and allocator behavior. Measure the exact task and name the profiler metric.
Should sessions run in parallel to reduce waiting?
Only when the chosen runtime and application path are designed and verified for that concurrency. Otherwise serialize access, bound the queue, and measure user-task outcomes rather than assuming parallelism helps.
What should happen after Android reclaims the process?
Restore only intentionally persisted state, distinguish model reload from user-data loss, explain whether work can resume, and keep source content safe. An in-memory singleton is not durable across process death.
Can one profiler capture establish minimum-device requirements?
No. It applies to a named device, OS, build, tool, artifact, and workload. A general requirement needs a defined multi-device matrix and raw outcomes; otherwise publish only the method and scope.