Downloads · 30 days
1.4K
47% of all-time downloads
litert-community/SmolVLM2-500M
SmolVLM2-500M is a image-text-to-text model from litert-community. Use it for the image-text-to-text task on the model card, and read the license before you ship it in a product. It is set up for litert-lm. The card lists the license as apache-2.0.
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 unmo…
Downloads · 30 days
1.4K
47% of all-time downloads
All-time downloads
2.9K
Public
Repo size
1.1 GB
Likes
4
Public
Click a slice to open those files.
.litertlm361 MB · 100%
From the Hugging Face model README
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).
HuggingFaceTB/SmolVLM2-500M-Video-Instruct
(image path) converted to the LiteRT-LM (.litertlm) format for on-device image+text inference
with Google's LiteRT-LM runtime.
SmolVLM2-500M is a tiny vision-language model from Hugging Face: a SigLIP vision encoder + pixel-shuffle connector feeding a SmolLM2 (Llama-architecture) 360M decoder. At just 361 MB it is one of the smallest on-device VLMs — give it an image and a question, get a grounded answer, fully offline.
| File | SmolVLM2-500M.litertlm (~361 MB) |
| Vision | SigLIP encoder (512×512, 1024 patches, no CLS) + pixel-shuffle ×4 + Linear connector, int8 → 64 image tokens |
| Decoder | SmolLM2-360M (Llama, 960-dim, 32 layers, GQA 15/5), int4 weights (blockwise-32 + OCTAV); tied embedding INT8 (externalized) |
| Compute | integer |
| Context (KV cache) | 2048 |
| Image input | resized to 512×512 ((x−0.5)/0.5 normalization baked into the vision encoder) |
| Base model | HuggingFaceTB/SmolVLM2-500M-Video-Instruct |
1. Install the runtime
pip install litert-lm
2. Run it in one command — this downloads the bundle, encodes your image and answers:
litert-lm run --from-huggingface-repo litert-community/SmolVLM2-500M SmolVLM2-500M.litertlm \
--attachment photo.jpg \
--prompt "Describe this image in one sentence."
On the COCO sample image huggingface/documentation-images/coco_sample.png (two tabby cats on a pink blanket, remote controls beside them) this prints:
Two tabby cats are sprawled on a pink blanket, one of them is holding a remote control.
Drop --prompt for an interactive chat, and pass --attachment more than once for several images. litert-lm serve exposes the same bundle as a local OpenAI-compatible API. The same file runs on macOS, Linux and Windows.
litert-lm benchmark (litert-lm 0.15.0) on an Apple M4 Max, -p 256 -d 256 --runs 3 (the tool averages three iterations), max-num-tokens 4096, warm-up run discarded, otherwise idle machine. These figures cover the text path; the vision encoder runs once per image and is not included.
| Device | Backend | Prefill (256) | Decode | TTFT |
|---|---|---|---|---|
| Apple M4 Max (macOS) | CPU | 409 tok/s | 63.9 tok/s | 0.64 s |
Every desktop backend listed above was checked by actually generating a caption on it, not just by reading the benchmark tool's output.
The macOS GPU backend is not usable for this bundle on litert-lm 0.15.0. Asked to describe an image with --backend gpu, it returns a stream of <|endoftext|> tokens instead of a caption. litert-lm benchmark still reports GPU numbers for it — 104,040 tok/s prefill and 862 tok/s decode for a 0.36 GB bundle — but they measure a path that produces no usable text, so no GPU row is quoted here. Use the CPU backend on the desktop. This is a desktop-runtime observation and says nothing about the iPhone or Android GPU paths described elsewhere on this card.
Single-image VQA produces coherent, image-grounded answers (CPU-verified; the SigLIP vision tower
converts bit-faithfully, float CPU-parity corr ≈ 1.0). It is a very small (500M) model — keep a
sensible max_tokens and use sampling (e.g. top-p); at pure greedy it can be repetitive/verbose.
The published bundle runs on the Android GPU backend and generates.
| file | GPU backend | delegation | peak |
|---|---|---|---|
SmolVLM2-500M.litertlm | runs | 4138 / 4138 ops across 3 subgraphs on LiteRT GPU | 404 MB |
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.
Ask about one image per chat (start a new conversation for a different image). Single-image VQA is
the primary use case. (On the GPU backend, a second image in the same conversation may degrade — a
GPU-delegate trait shared across fast_vlm models; CPU handles multi-image.)
Use the LiteRT-LM Swift runtime (swift-litert-lm /
the LiteRTDemo sample). Load SmolVLM2-500M.litertlm with the vision tower enabled
(modalities Modality.textImage / [.vision] — vision-only bundle, no audio tower), attach a photo,
ask a question.
Update (July 2026): Google AI Edge Gallery v1.0.16+ can import litert-lm models directly from Hugging Face inside the app (tap +) — no computer or
adbneeded. The manual steps below are only required on older builds or for sideloading a local file.
Run this model with image input in the official Google AI Edge Gallery app — no custom app needed (the bundle carries the tokenizer, chat template, and image preprocessing config):
adb push SmolVLM2-500M.litertlm /sdcard/Download/SmolVLM2-500M.litertlm in the file picker.Tip: ask about one image per conversation. It's a tiny 500M model — keep max-tokens modest so it doesn't ramble.
The same .litertlm bundle runs on macOS / Linux / Windows with the official
LiteRT-LM CLI — including as a
local OpenAI-compatible API server:
pip install litert-lm
litert-lm import --from-huggingface-repo litert-community/SmolVLM2-500M SmolVLM2-500M.litertlm smolvlm2-500m
litert-lm run smolvlm2-500m # interactive chat in the terminal
litert-lm serve # local OpenAI-compatible API server
fast_vlm bundle: VISION_ENCODER ([1,512,512,3]→[1,1024,768], SigLIP) + VISION_ADAPTER
([1,1024,768]→[1,64,960], pixel-shuffle ×4 + Linear) + single-token EMBEDDER + PREFILL_DECODE.arange(1024) position-embedding path (the model's dynamic
bucketize position logic is bypassed — numerically identical for a full 512×512 frame) and bakes the
(x−0.5)/0.5 normalization + NCHW transpose into the graph.The LiteRT-LM engine prepends the metadata start_token to every prompt, and this model's chat template already renders <|im_start|> itself — so the model was reading <|im_start|><|im_start|>…, a stream it was never trained on. The start token has been removed.
Metadata-only change: every section of the bundle except the LlmMetadata block is byte-identical to the previous file (verified by sha256 per section), so the weights, the graph and the tokenizer are unchanged and the speed and memory numbers on this card still describe exactly this file — only the file's own sha256 differs. What changed is the input: the token stream the model reads for a given conversation can differ from the previous file's, and it now matches this model's own reference chat stream. Greedy decoding can turn on a single token, so an individual answer can differ from the previous file in either direction. Unless a row says otherwise, the accuracy figures on this card were measured on the previous file and have not been re-measured on this one. If you downloaded before 2026-08-28, re-download.
The tokenizer in SmolVLM2-500M.litertlm was a SentencePiece conversion of the model's BPE tokenizer, and the conversion lost the byte-level semantics: a standalone accented letter or symbol (é, ñ, ü, °, ·, …) was encoded to the id of a single-byte token instead of the token the upstream tokenizer uses, and any character without a whole-character vocabulary entry (emoji, most of Latin Extended-A) became the token the conversion had reused as UNK — the end-of-text token for this vocabulary. SmolVLM2-500M.litertlm now embeds the upstream tokenizer.json (the same HF tokenizer path most bundles in this collection use).
Tokenizer-only change: every section of the bundle except the tokenizer is byte-identical to the previous file (verified by sha256 per section), so the weights, the graph and the chat template are unchanged and the speed and memory numbers on this card still describe this file per token — only the file's own sha256 differs. Verified on the LiteRT-LM runtime: the default turn, 7 probe strings, the 223 standalone characters U+00A1–U+017F and every special token now tokenize identically to the upstream tokenizer, and the four ASCII-only test questions answer byte-identically to the previous file (same ids in, same tokens out). Prompts containing accented letters, symbols or emoji reach the model differently from before, so individual answers to such prompts can change. Unless a row says otherwise, the accuracy figures on this card were measured on the previous file, and any on-device rows were measured on the previous file too — the on-device gate has not been re-run on this one (the runtime's tokenizer code is the same on macOS and on device; the weights and graph are byte-identical). If you downloaded before 2026-08-30, re-download.