Direct answer
Memory mapping describes a way for a process to access file-backed regions through virtual memory; it is not a statement that a model consumes no RAM or that a particular inference runtime uses the technique. Android memory documentation explains that mappings, object heaps, shared pages, and resident physical memory are different views of process memory. Unmodified mapped pages can be reclaimed when the system needs memory, while pages that are touched or modified may remain resident. Therefore, model file size, virtual mapped length, resident set, and peak inference working set are separate measurements. Start by verifying the actual loading mechanism from the selected runtime's official documentation, source, or a supported diagnostic. Do not infer mmap from a large file, a fast load, or the absence of a full byte-array allocation in application code: a native dependency may own the loading path. If the runtime does not expose whether or how it maps the artifact, record the implementation as unknown and measure observable process behavior instead. Keep model artifact revision, runtime package/version, app build, device, OS, backend, and exact task together in the record. Use a staged measurement timeline: before model access, after engine initialization, after a representative task touches model data, after repeated tasks, after cancellation, and after engine close. Collect a named process metric from Android Studio Memory Profiler or a documented system tool. Preserve whether a value is Java/Kotlin heap, native heap, PSS, RSS, virtual size, or another metric. Do not add unlike metrics or call virtual address space resident RAM. A mapped buffer's lifetime may also extend until references are released and collection occurs; closing a higher-level engine does not prove every mapping immediately disappears unless the runtime documents that behavior. Design controls that distinguish file mapping from model working memory. Compare a file inventory with process measurements; record whether the task touches different regions; separate cold process and warm runs; and include a task that exercises the same input each time. Mapped pages may be faulted in progressively, so a low initial reading can rise after a workload. Runtime buffers, KV cache, input tensors, decoded media, and allocator behavior also contribute. Model download size alone cannot predict peak inference memory. The conclusion should answer only what was measured: whether mapping was directly observed, which memory metric changed, at what task phase, and how the process behaved after cleanup. If no official or runtime evidence confirms mmap, do not title a finding as proof that LiteRT-LM uses mmap. The project has no complete device benchmark dataset, so this article defines a measurement protocol and does not publish a memory requirement, startup result, or device-compatibility claim. Distinguish a mapping implementation fact from a measured memory result; the former requires implementation evidence, while the latter requires a named metric and reproducible run. Report tool, units, sampling points, artifact/runtime identifiers, device state, and task fixture. Android process metrics can include shared pages and non-model work, so do not attribute the entire reading to weights. If the runtime hides its internal allocator or mapping strategy, keep that limitation explicit. The most useful result is an auditable timeline showing what changed after each task stage and what remains unknown, not a single unqualified number.
A model file is large, but the Java heap looks smaller than the file
An Android engineer sees a model on disk and a managed heap below the artifact length. The team suspects memory mapping but has no evidence that the selected native runtime uses it, and wants to explain why later inference could still increase memory.
Decision
Verify mapping from authoritative runtime evidence if possible, then measure mapping, process metrics, and task allocations as distinct values.
Expected outcome
The report states what the profiler actually observed and what remains unknown, without treating file length or a virtual mapping as a RAM requirement.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Mapping method
- Resident-memory metric
- Representative task peak
A device badge must come from an exact device, OS, artifact, runtime, backend, and workload record, not parameter-count intuition.
Implementation workflow
- Verify whether mapping is documented or observable. Inspect the exact runtime revision and supported diagnostics for its loading strategy. If the runtime does not expose this, mark mmap unknown; do not infer it from load timing, file size, or a missing app-level byte array.
- Pin artifact and execution identity. Record artifact source/revision/format, runtime and app build, device and OS, backend request/evidence, task fixture, and cold or warm process state. Different artifacts or backends require separate rows.
- Name each memory metric. Capture virtual mapping length only if directly available, and separately identify PSS, RSS, Java/Kotlin heap, native heap, or profiler allocation values. Preserve tool, sampling point, and units; never label virtual bytes resident RAM.
- Measure lifecycle checkpoints and page touching. Collect before access, after initialization, after a fixed task, repeated task, cancellation, and close. Keep input constant and note workload phases that may access more model regions or create cache and input buffers.
- Report cleanup and limits. Observe memory after release with the same tool and wait procedure. Do not promise immediate unmapping without a documented contract; references, allocator retention, shared pages, and OS reclaim affect readings.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The report distinguishes file length, virtual mapping, resident/process metrics, and inference working memory.
- Mmap is called observed only when exact runtime evidence supports it; otherwise the implementation is explicitly unknown.
- Cold/warm state, artifact, runtime, backend, task, metric definition, units, and cleanup checkpoint are recorded.
- No minimum-RAM, load-speed, or device-compatibility claim is derived from mapping length or file size.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Model file length | Storage inventory in bytes | Describes disk content, not mapped resident pages or runtime working set. |
| Virtual mapped length | Address-space region, if directly observable | Shows a mapping reservation; it is not the same as physical pages resident in RAM. |
| Process/task peak metric | Profiler or system measurement at named lifecycle points | Useful for the tested task and device; includes more than file mapping and remains scope-limited. |
Failure patterns to prevent
- Calling mapped bytes free memory
- Equating file length and RAM
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does mmap mean the model is not using RAM?
No. Mapping provides file-backed access through virtual memory. Pages accessed by the process may become resident, and inference also needs runtime buffers, cache, tensors, and other allocations.
Can a model file larger than the Java heap prove mmap is used?
No. A native runtime may load or stream data another way. Verify the selected implementation or mark mapping unknown; the managed heap size alone does not reveal the mechanism.
Should mapped pages disappear immediately after engine close?
Do not assume that without a documented contract. References, native allocator behavior, shared pages, and OS reclaim can affect memory after close; measure with a named tool and wait procedure.