Model delivery

Report Model Storage Use Accurately

Separate active artifacts, optional variants, partial downloads, caches, and user data.

Review status: Fact and editorial QA complete; owner review pending · 2026-10-05 · Fact IDs: COVE-MODEL-01, COVE-DOWNLOAD-01

Direct answer

A local AI storage report should be an inventory of observed files and app-owned data, not a restatement of model parameter count or configured download length. Group storage by ownership and lifecycle: active model artifacts, optional installed variants, in-progress or recoverable transfers, removable caches, databases and indexes, and user-created content. Show measurements only when the application can identify and measure the underlying data. Keep unknown or inaccessible categories separate from zero, and explain which items can be removed without affecting user work. The report has a different job from a pre-download space check. A precheck predicts whether one operation can start; a report explains what currently occupies a volume. The report should use actual filesystem observations for app-controlled files and platform storage APIs when a system-level value is needed. It should not add an expected remote artifact size to the current installed total if that file has not been downloaded. Nor should a model weight size be presented as memory use or final disk use: package compression, temporary copies, caches, and app data have separate accounting. Assign every storage object an owner and lifecycle state. A model file may be active, staged as a candidate, partially downloaded, quarantined, or obsolete. A cache may be rebuildable. A conversation database, imported document, or exported result may belong to the user and should not be grouped under “model cache” just because it uses the same application sandbox. Record location or volume so the UI can explain when a removable drive is absent. If a file cannot be measured because access was revoked or the volume is unavailable, display “not currently available” rather than counting it as zero or claiming it was deleted. Use careful measurement semantics. Android StorageStatsManager can provide app-scoped or package storage summaries under documented rules, while a file inventory can sum app-owned artifact lengths. Those values may include or exclude cache depending on the API and query; disclose the scope and avoid summing overlapping totals twice. A point-in-time report can become stale as a transfer progresses or a cache is reclaimed. Mark the measurement time, refresh after a completed transfer or cleanup, and distinguish allocated file length from system-reclaimable cache. Cleanup is a separate decision from reporting. Offer actions by category, such as removing a known inactive variant or clearing a rebuildable cache, only when the product implements and tests them. State whether the action affects the active model, partial download, local index, or user content. Prefer a reversible staged deletion or a confirmation that names exact data. Do not let a “clear model storage” control erase conversations or user files. After cleanup, re-scan actual files rather than subtracting a configured size from the previous display. An honest report can also show that some costs are not included. A runtime may allocate in-memory buffers, a download may temporarily use both old and new files, and an installed package may contain native libraries. If the page reports only model-file bytes, label it as such. Do not infer peak RAM, total app footprint, or guaranteed free-space recovery from a single directory. If the app cannot safely attribute files to categories, show a subtotal and an unknown remainder rather than manufacturing a complete total.

Review storage after installing and removing variants

The user installed one active artifact, attempted optional variants, canceled a transfer, and saved local history. They need to distinguish removable bytes from the working model and their own data.

Decision

Inventory current app-owned files, label each category and volume, then offer only tested cleanup actions with explicit scope.

Expected outcome

The report shows measured storage without confusing expected download size, runtime RAM, cache, or user content.

Evidence to collect

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

  • Storage-class inventory
  • Exact file lengths
  • Cleanup verification

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

  1. Inventory owned locations. List active model, candidate and partial files, variant folders, rebuildable caches, databases, indexes, and user media. Record the volume and data owner for every category.
  2. Measure from the right source. Sum observed lengths for app-controlled files and use documented platform APIs for package summaries. State whether cache is included and avoid adding overlapping API totals together.
  3. Classify lifecycle and cleanup. Mark each item active, staged, partial, quarantined, obsolete, rebuildable, or user-owned. Define a tested action for each class rather than labeling every file inside the app sandbox as cache.
  4. Represent unknown measurements. When a file is inaccessible, stored on a missing volume, or cannot be attributed, show unavailable or unknown. Never show zero or deleted without evidence; timestamp and refresh the result.
  5. Keep usage separate from speed. Report model, package, and app data only as measured categories. Do not infer peak RAM, device compatibility, or inference speed from bytes on disk.
  6. Verify cleanup and rescan. Delete one explicitly named class in tests, rescan the filesystem, and confirm the active model and user data remain. Test cancellation or interrupted cleanup when those states are supported.

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

Acceptance criteria

  • Active artifacts, optional variants, partial files, caches, databases/indexes, and user content have distinct categories.
  • Storage is measured or explicitly API-scoped and timestamped; an expected remote size never appears as installed use.
  • Inaccessible or unattributed categories are unknown rather than zero, and overlapping totals are not double-counted.
  • Every cleanup action states its scope and cannot silently remove user content or the only active model.

Decision table

DimensionChoice or evidenceHow to interpret it
Download-size descriptionAnswers expected size of one specified remote artifact.Uses a manifest or configuration value and labels it expected.
Storage precheckAnswers whether one install/update can start safely now.Uses destination allocation state and files that coexist in that operation.
Storage reportAnswers what app-owned bytes occupy the device now.Uses a current file inventory and documented platform summaries.

Failure patterns to prevent

  • Showing weight estimates as disk use
  • Combining user content with model storage

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

Minimum reproducibility record

LayerRecord
DeviceManufacturer, model, chipset, RAM class, operating-system build
SoftwareApplication version and git commit
ModelFamily, variant, revision, format, file length, hash, quantization
RuntimeName, revision, requested backend, observed backend evidence
WorkloadFixture revision, input hash, prompt hash, output policy
OutcomeCompleted, 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

Can model parameter count tell users actual disk usage?

No. Parameter count is not file length, and packaging, metadata, temporary copies, and caches alter storage. Measure the actual artifact and label exactly which categories are included.

Can an inaccessible file category be reported as zero bytes?

No. A revoked grant or absent volume prevents measurement. Show unavailable and refresh if access returns rather than claiming the data was deleted.

Is every model cache safe to remove?

Only if the app can identify it as rebuildable and has tested removal and recovery. Active models, partial files, user indexes, conversations, and exports need separate ownership and confirmation.