LiteRT is Google's on-device runtime, the new name for TensorFlow Lite (Android: com.google.ai.edge.litert:litert), and litert-torch, the renamed ai-edge-torch, is its PyTorch converter: a PyTorch model converted unmodified with litert_torch.convert matched the original to 4e-7 on a Galaxy S26 (measured, LiteRT 2.2.0, Android 16, 2026-09-05).

LiquidAI/LFM2.5-VL-3B converted to the LiteRT-LM (.litertlm) format for on-device inference with Google's LiteRT-LM runtime.

Text + image work end-to-end on the released litert-lm 0.16.0 pip runtime — the bundle carries the vision encoder, the vision adapter and the LFM2 image-placeholder metadata, so litert-lm run … --attachment photo.png just works. To our knowledge this is the first LFM2.5-VL in LiteRT form.

On litert-lm 0.16.0 — and on current main — only the top quarter of the image reaches the model. Captioning, colour questions and OCR of a large dominant subject still work. Anything positional — locate, count, enumerate, "which one is at the bottom" — comes back wrong, with no error and well-formed output.

The cause is a shrink-factor assumption in the runtime's vision path, reported upstream as LiteRT-LM#3246. It affects every LFM2.5-VL bundle, not just this one: the family performs its 2×2 pixel-unshuffle in the vision adapter rather than the encoder, and the runtime assumes the opposite.

Quick check — a 512×512 image with 16 numbered horizontal bands, asked to list every number from top to bottom:

A repaired build exists (the pooling moved into the exported encoder, which makes the runtime's forwarded rows the correct pooled tokens). We have not replaced the files here, because the upstream fix may make the change unnecessary or incompatible — open a discussion on this repo if you need it now.

LFM2.5-VL-3B pairs Liquid AI's hybrid text backbone (22 gated short-convolution blocks + 8 grouped-query attention layers, 128k vocab) with a SigLIP2 vision tower (27 layers, hidden 1152) and a pixel-unshuffle projector. On this runtime an image is processed at 512×512 into 256 soft tokens (single image per prompt; the runtime resizes for you) — but see the known issue above: on 0.16.0 those 256 tokens carry only the top quarter of the picture.

Sanity gates on the 0.16.0 pip CLI (greedy, fresh engine per question, --cache no). Vision: five deterministic synthetic fixtures (dominant color, large-text OCR, shape, counting three squares, largest word). Text: the 8-question gate used across our LiteRT conversions.

All five image answers from both LiteRT variants are verbatim identical to the bf16 reference on both backends ("Red." / "Hello." / "Circle." / "Three." / "CAT."). The single text miss (rhyme completion answered "Purple.") is shared with the source model's behavior at greedy decoding, not a conversion artifact. Zero degenerate outputs across all runs.

What the image gate does not show. All five vision fixtures place their subject in the middle of the frame, below the cut described in the known issue above. They therefore cannot separate "the model resolved the image" from "the model answered from priors" — a bundle that sees only the top quarter still scores 5/5 on them. The band ruler above is the check that does separate the two. Concretely: circle.png puts its circle at y 128–384 of 512, entirely below the cut, and the 3B still answers "Circle." The 450M answers "Square." on the same fixture and flips to "Circle." once the bundle is repaired, with nothing else changed.

Text-only prompts work the same way without --attachment. --vision-backend cpu|gpu selects the vision encoder backend independently of the text backend.

litert-lm benchmark … --cache no, litert-lm 0.16.0 pip, Apple M4 Max (128 GB), text path (prefill/decode; image encoding is a separate one-shot vision-encoder call at prompt time):

CPU backend:

GPU backend (--backend gpu; both variants verified to generate correct text and answer the image gate on GPU before quoting):

On Android the same bundle runs GPU-accelerated. Pixel 8a (Tensor G3), litert_lm_main built from the v0.16.0 release tag, 292-token prompt, decode run to EOS (≈1.1k tokens sustained), --disable_cache (worst-case load; default caching makes subsequent loads much faster), int4 file:

The text graph delegates fully on Android OpenCL (937/937 nodes, zero rejected ops). One operational note: the GPU path writes multi-GB compile caches next to the model by default — on a nearly-full device the cache write can fail mid-initialization; run with --disable_cache or free storage first.

Both published bundles run on the Android GPU backend and generate.

Measured on a Samsung Galaxy S26 (SM-S942Q / SM8850, Android 16) with litert_lm_advanced_main from litert-lm 0.16.0, --backend=gpu --sampler_backend=cpu, prompt What is the capital of France?. Peak is the process high-water mark (VmHWM) sampled during that same run. Gated 2026-08-25.

The op counts above are the LiteRT GPU partitions. XNNPACK additionally takes 1 of the 4 nodes in main; the runtime accepts that split.

The gate prompt carries no image, so this covers engine creation and the text path. The vision path on the GPU is not measured here.

No speed rows, on purpose. On this handset the GPU backend wins prefill and does not win decode, so a GPU throughput figure only means something beside a CPU row from the same handset, and no S26 CPU row exists for this model yet.

GPU wiring, including the Gallery import toggle: GPU guide.

Converted with the open pipeline in hf-to-litertlm (lfm_work/convert_lfm25_vl.py, litert-torch 0.9.3 --task image_text_to_text): the exact recipe, the int4 post-processing (OCTAV int4-b32 + int8 embedder + zero-scale repair + executor metadata, all vision sections preserved) and the text/image gate harnesses are in the repo's REPRODUCE.md.