Runtime and integration

Validate a LiteRT GPU Backend on Android

Prove which backend executed the exact model and task on a target device.

Last reviewed: 2026-09-16 · Fact IDs: LITERT-01, BENCHMARK-01

Direct answer

The runtime owns model loading and native execution. The application owns lifecycle, concurrency, validation, user-visible state, and the release promise.

This page does not publish benchmark or compatibility results. It shows the evidence required to answer LiteRT GPU Android without turning an assumption into a product claim.

Evidence to collect

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

  • Backend initialization evidence
  • Representative task result
  • Fallback outcome

A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.

Implementation workflow

  1. Freeze the product task and minimum device tier.
  2. Choose the runtime and supported artifact format.
  3. Pin artifact and runtime revisions.
  4. Wrap native state behind an application-owned interface.
  5. Test load, representative work, cancellation, close, and fallback.
  6. Publish only the behavior reproduced by the recorded configuration.

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

Failure patterns to prevent

  • Assuming GPU use from a setting
  • Publishing one-device compatibility

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 端侧专题.