litert-community/LFM3-VL-2B-LiteRT

LFM3-VL-2B — LiteRT-LM

This repository is a conversion of LiquidAI/LFM3-VL-2B to LiteRT-LM, made with litert-torch (release 0.10.0 for the vision encoder, commit f61d0b7 of its main branch for the text decoder) and litert-lm-builder 0.18.1 for LiteRT-LM 0.18.1: on a Galaxy S26 GPU, LFM3-VL-2B_int4.litertlm decodes 37.88 tokens/s after a 1,024-token prompt, against 14.96 tokens/s for the float16 file in the same session (2026-10-31), and on that phone, a Pixel 8a and a Mac it answered correctly every image question with one right answer that we asked it (7, 7 and 18), with thinking off and with thinking on.

LFM3-VL-2B_int4_ctx4096.litertlm is the same int4 file with room for 4,096 tokens instead of 2,048, for answers that think longer: with thinking on, asked where in a photo to put an object, it answered 21 of our 30 requests right and ran out of room on none, where the 2,048-token file answered 17 and ran out before the answer on 7 (Mac GPU, 2026-11-01). On the Galaxy S26 GPU it decodes 34.35 tokens/s after a 1,024-token prompt, against 37.65 tokens/s for the 2,048-token file in the same session (2026-11-01).

LFM3-VL-2B is Liquid AI's vision-language model for on-device visual understanding: 1.92B parameters, a 1.73B LFM3 language model (24 layers: 13 gated short convolutions, 5 sliding-window attention, 6 global attention), a 164M vision encoder (14 layers: 8 gated depthwise 2D convolutions, 6 bidirectional attention) and a 25M projector. It reads text, images and video, and by default it thinks in a <think> block before it answers. The files here take text and images; video is not included.

Files

File	What is inside	Size	sha256
LFM3-VL-2B_int4.litertlm	Text decoder with int4 weights in blocks of 32 and an int8 output projection (no activation type declared), token embedding table in int8, vision encoder with fp32 weights and adapter with fp16 weights (both declared fp32 activations; the same bytes as in the float16 file). One image becomes 256 tokens at 512 × 512. Context 2,048 tokens.	2,071,595,259 B (2.07 GB)	8c208746b7758996c41e27eec8507b3c875a9e3bbde4b6da0e4c145d3e450c41
LFM3-VL-2B_int4_ctx4096.litertlm	LFM3-VL-2B_int4.litertlm with a 4,096-token context: the same weights, token embedding table, vision encoder, adapter, tokenizer and template; only the text decoder's cache length differs (2,048 → 4,096 tokens). One image becomes 256 tokens at 512 × 512. Context 4,096 tokens.	2,071,611,643 B (2.07 GB)	64d89b858df4cea27fea4ebcb3bc468e0bc6af2c2cc87db69ac9776332c451e4
LFM3-VL-2B_f16.litertlm	Text decoder with fp16 weights (no activation type declared), token embedding table in int8, vision encoder with fp32 weights and adapter with fp16 weights (both declared fp32 activations). One image becomes 256 tokens at 512 × 512. Context 2,048 tokens.	4,439,967,995 B (4.44 GB)	e9e15f4da346a8eb7fc5d2dc276dde9a9cecf1424d50193deeb2d098bf664877
LICENSE	The source model's license file, unchanged	10,574 B
litertlm_manifest.json	Machine-readable description of the three .litertlm files	38,860 B
fixtures/	The four 512 × 512 images of the demo below	0.9 MB

Which file: LFM3-VL-2B_int4.litertlm on the Galaxy S26 GPU, the Pixel 8a GPU and the Mac GPU (on the Mac CPU it decodes faster and prefills more slowly than the float16 file). It decodes 2.5 times as fast on the Galaxy S26 GPU, it stays more than 1.4 GB above our test's memory stop line on the Pixel 8a where the float16 file sits at that line (Performance), and on the test questions with a right answer it was right at least as often as the float16 file (Accuracy). LFM3-VL-2B_f16.litertlm keeps closer to the source model's exact wording (Accuracy). Pick LFM3-VL-2B_int4_ctx4096.litertlm when thinking is on and a thought may run past 2,048 tokens: on 7 of our 30 requests to place an object in a photo, the 2,048-token file's thought reached the end of the context and no answer came (Accuracy). It decodes 9 % slower than LFM3-VL-2B_int4.litertlm on the Galaxy S26 GPU and 11 % slower on the Mac GPU (Performance).

The source repository also lists Liquid AI's own GGUF, MLX and ONNX checkpoints.

Usage

Turn the photo upright and resize it to 512 × 512 first. LiteRT-LM 0.18.1 stretches every image to the file's 512 × 512 (it keeps neither the aspect ratio nor the EXIF orientation), and every result on this page was measured on 512 × 512 images made with this line (the NASA photos were first reduced to 1,024 pixels on the long side):

pip install pillow
python -c "from PIL import Image, ImageOps; ImageOps.exif_transpose(Image.open('photo.jpg')).convert('RGB').resize((512, 512), Image.BICUBIC).save('photo_512.png')"

One question about an image with the LiteRT-LM command-line tool (thinking off):

uvx --from litert-lm==0.18.1 litert-lm run LFM3-VL-2B_int4.litertlm --backend gpu --vision-backend gpu --cache no --thinking false --attachment photo_512.png --prompt "What words are written on the yellow sign? Answer with the words only." < /dev/null

Without --thinking false the tool prints the model's thought between [thought] and [/thought] before the answer.

The same from Python (pip install litert-lm==0.18.1):

import litert_lm
from litert_lm import interfaces

engine = litert_lm.Engine("LFM3-VL-2B_int4.litertlm",
                          backend=interfaces.Backend.GPU(),
                          vision_backend=interfaces.Backend.GPU(),
                          cache_dir=":nocache")
conversation = engine.create_conversation(extra_context={"enable_thinking": False})
reply = conversation.send_message(
    {"role": "user", "content": [
        {"type": "image", "path": "photo_512.png"},
        {"type": "text", "text": "What words are written on the yellow sign? Answer with the words only."}]},
    max_output_tokens=64)
print("".join(part["text"] for part in reply["content"] if part.get("type") == "text"))

Use LFM3-VL-2B_f16.litertlm or LFM3-VL-2B_int4_ctx4096.litertlm in the same lines for the other files. Thinking is on by default, as in the source model. Leave out extra_context (or pass {"enable_thinking": True}) to turn it on; the thought then comes back in reply["channels"]["thought"] and the answer in reply["content"]. Give it room (the example above stops at 64 tokens with thinking off; with thinking on use, for example, max_output_tokens=1024): with the int4 file the longest thinking reply in our tests was 541 tokens, and on the placement requests of Accuracy the 4,096-token file's longest was 3,746 tokens (Limitations), so with that file set max_output_tokens to 4,096 minus the prompt's tokens (an image is 256 tokens; our placement prompts were 335–345 tokens), as those runs did. The files carry no sampler settings, so answers are greedy unless you set a sampler; the source model card recommends temperature 0.1, top_k 50 and repetition_penalty 1.1 (LiteRT-LM 0.18.1's sampler settings have no repetition penalty). Pass interfaces.Backend.CPU() for both backends to run on the CPU.

On litert-lm 0.18.x and 0.19.0, a blocking send_message that is still generating after 10 minutes fails with DEADLINE_EXCEEDED (a fixed timeout with no setting), and the generation it leaves running can crash the process. For long replies on a slow backend (long thinking in particular), lower max_output_tokens or use the streaming send_message_async, which has no such limit.

On Android, litert_lm_advanced_main built from the LiteRT-LM v0.18.1 tag reads the image from the prompt: a prompt file holding [image:/data/local/tmp/photo_512.png]What words are written on the yellow sign? Answer with the words only. and --backend=gpu --vision_backend=gpu --model_path=LFM3-VL-2B_int4.litertlm --input_prompt_file=<that file> --max_num_tokens=2048 (--max_num_tokens=4096 for LFM3-VL-2B_int4_ctx4096.litertlm). This command-line tool has no thinking switch: our thinking-off phone runs used a copy of each file whose template defaults to thinking off (12 bytes differ; every other byte is the same), and the thinking-on runs used LFM3-VL-2B_int4.litertlm as published. With a file as published, the tool prints the model's thought before the answer. On the Galaxy S26 the GPU engine started in 4.2–5.1 s with the int4 file and in 26.6–27.2 s with the float16 file in the benchmark runs of the table below (28–39 s in the float16 file's earlier runs), and in 8.2–10.4 s in the int4 file's 15 image-question runs. With LFM3-VL-2B_int4_ctx4096.litertlm on 2026-11-01 it started in 4.2–4.9 s in the benchmark runs and 4.5–4.6 s in the image-question runs (the int4 file in the same session: 4.2–4.3 s in the benchmark runs and 4.4 s in the image-question runs).

Performance

Galaxy S26 (SM-S942Q, Android 16), litert_lm_advanced_main built from the LiteRT-LM v0.18.1 tag.

File	Backend	Prefill, 1,024-token prompt (tok/s)	Decode, 256 tokens (tok/s)	Time to first token, 1,024-token prompt (s)	Image + question (~280 tokens): first token (s)	Peak memory (MB)
int4	GPU, vision encoder on the GPU	1,328 ¹	37.88 ¹	0.79–0.80 ¹	0.855 ²	1,038–1,616
int4, 4,096-token context	GPU, vision encoder on the GPU	1,183 ⁶	34.35 ⁶	0.89 ⁶	0.698 ⁷ (the int4 file in the same session: 0.660)	1,145–1,613
float16	GPU, vision encoder on the GPU	1,262 ¹	14.96 ¹	0.88 ¹	1.12 ³	4,393–4,589
float16	GPU, vision encoder on the CPU				1.53 ⁴	4,557–4,589
float16	CPU, 4 threads	74.31	5.28	13.97	25.4 ⁵	7,642

• NPU: none of the three files is built for the NPU. Builds compiled ahead of time for this phone's NPU (Qualcomm QAIRT 2.47) are not published: with thinking off the faster one answered the 18 image questions with one right answer correctly on the Galaxy S26 NPU, but it decodes 26.25 tokens/s (with a LiteRT-LM build newer than the 0.18.1 release used for the table above), slower than the int4 file on the GPU, and it was run with thinking off only.
• Text rows: --benchmark_prefill_tokens=1024 --benchmark_decode_tokens=256 --max_num_tokens=2048, no vision encoder loaded. ¹ One session on 2026-10-31 that ran the two files in turn (float16, int4, int4, float16), each in a new process, every run starting at thermal status 1 with no limit on the CPU clock; mean of each file's two runs (decode 38.14 and 37.61 against 14.47 and 15.44 tok/s). During the runs the phone held its CPU clock below the maximum in 162 of 175 samples taken every half second for the float16 file and in 38 of 48 for the int4 file. Earlier GPU runs of the float16 file (2026-10-29, median of three processes): prefill 1,236 tok/s, decode 14.72 tok/s (13.63, 14.72 and 15.35), time to first token 0.90 s; in those runs the phone held its CPU clock below the maximum in 69 of 70 samples taken every 2 s, and during decode it lowered the GPU's clock limit from 1,300 MHz to as low as 500 MHz. The CPU row is one process of 2026-10-29, with the CPU clock held below the maximum in every sample. ⁶ --max_num_tokens=4096; one session on 2026-11-01 that ran the 4,096-token file and the int4 file in turn (4,096, int4, int4, 4,096, 4,096, int4), each in a new process, both files as published; median of each file's three runs (decode 34.35 / 34.43 / 34.30 against 37.65 / 37.45 / 37.68 tok/s; the int4 file's medians in that session: prefill 1,314 tok/s, decode 37.65 tok/s, time to first token 0.81 s). The session began at thermal status 0 with the battery at 34.9 °C; every run started at thermal status 0 with no limit on the CPU clock, and during the runs the phone held its CPU clock below the maximum in 58 of 75 samples taken every half second for the 4,096-token file and in 51 of 69 for the int4 file.
• Image rows: a 512 × 512 image and a question, 276–290 prompt tokens (256 for the image). First token = the runtime's vision encoder time plus its time to first token. ² Median of the 8 image questions of the accuracy run below (one process per question, run back to back, 2026-10-31); as medians, vision encoder 291 ms, then 0.555 s. ³ Median of the 23 questions of the float16 file's accuracy run (2026-10-28): vision encoder 375 ms, then 0.74 s. ⁴ The truck photo of the demo below, median of three processes: median of the three per-process sums (vision encoder 971 ms on the CPU and 0.57 s after it, as medians). ⁵ The same photo, one process, the run that wrote the CPU weight cache: vision encoder 559 ms, then 24.81 s. ⁷ The truck photo of the demo below and its question with thinking on (283 prompt tokens; the files as published), median of three processes in the session of ⁶ (int4, 4,096, 4,096, int4, int4, 4,096): vision encoder 298 ms, then 0.40 s; the int4 file in that session: 0.660 s.
• Peak memory is the runtime's own "Peak system ram usage" line: int4 1,038 and 1,136 MB in its two text runs and 1,475–1,616 MB in its question runs (images and text, thinking off and on); float16 4,393 and 4,450 MB in the text runs of 2026-10-31 and 4,431–4,589 MB in the earlier runs; the 4,096-token int4 file 1,145–1,147 MB in its text runs and 1,549–1,613 MB in its image runs (the int4 file in the same session: 1,141–1,145 and 1,539–1,568 MB). On the CPU, XNNPACK unpacks the fp16 decoder into a 6.92 GB float32 weight cache next to the model.

Pixel 8a (Mali-G715, Android 16), the same litert_lm_advanced_main build, GPU with the vision encoder on the CPU. Our test stops a run at the first reading of available memory under 400,000 kB (read every 0.25 s on the phone).

• LFM3-VL-2B_int4.litertlm (2026-10-31): in two timing runs of the truck photo below the first token came 6.83 s and 5.64 s after the request (vision encoder 4.30 s and 3.12 s, then 2.53 s and 2.52 s), prefill ran at 120–121 tok/s and the engine took 7.9–8.4 s to start; during the accuracy run below (8 images, one process per question, run back to back) the median was 5.94 s. The lowest available-memory reading in its 26 runs was 1,805,804 kB, in a thinking answer of 541 tokens.
• LFM3-VL-2B_f16.litertlm: during its accuracy run (2026-10-28, 8 images) the first token came 11.4 s after the request (vision encoder 7.2 s, then 4.15 s), prefill ran at 85 tok/s and the engine took 78 s to start; the lowest reading in those 16 runs was 401,624 kB. On 2026-10-31 our test stopped its first run at a reading of 274,812 kB while the engine was starting (after the decoder's last signature went to the GPU). This file sits at the edge of this phone's memory: use the int4 file here.
• LFM3-VL-2B_int4_ctx4096.litertlm was not run on the Pixel 8a, and none of the files was tried on its CPU (the float16 file's CPU path needs the 6.92 GB weight cache above, and this phone had 4,294,304–4,701,716 kB (4.40–4.81 GB) available before each run of 2026-10-28).

Pixel 11 Pro (Tensor G6, PowerVR GPU, Android 17), the same litert_lm_advanced_main build, LFM3-VL-2B_int4_ctx4096.litertlm as published (thinking on), one process per prompt, 2026-11-01. These single runs check that the file answers on this phone; they are not the 1,024 / 256-token benchmark of the Galaxy S26 table. Each number below is one run; the GPU and CPU runs were not alternated, so the CPU's higher decode number does not say which backend is faster. The first GPU run (the France question) started at thermal status 1, the other three runs at 0.

• GPU, vision encoder on the GPU: asked "What is the capital of France? Answer in one word." it answered "Paris" after a closed thought (57 tokens at 14.97 tok/s; the engine took 13.2 s to start in that first run, which wrote its caches). Asked two of the placement requests of Accuracy, it answered "Put the sugar bowl to the right of the glass shaker." with the Mac's point (561 tokens at 15.75 tok/s; the first token 2.14 s after the request: vision encoder 511 ms, then 1.63 s) and "Put the mug between the lamp and the books." with [350, 820] (347 tokens at 15.51 tok/s), inside the region, as the Mac's [370, 800] is; the engine started in 4.7 s in those two runs.
• CPU, 4 threads: the same text question, "Paris" after a closed thought (57 tokens at 17.11 tok/s, time to first token 1.74 s; the engine took 4.5 s to start in that first run, which wrote the XNNPACK weight cache).
• Peak memory (the runtime's line): 708–1,577 MB on the GPU, 2,033 MB on the CPU.

Mac M4 Max (macOS 27.0), litert-lm 0.18.1 from PyPI (its GPU path is WebGPU), Python API, cache_dir=":nocache", one process per run, median of three. Other jobs ran on the same Mac: the int4 and float16 rows were measured at different hours of 2026-10-28 (load average 38–55 during the int4 rows, 6–17 during the float16 rows), the 4,096-token rows on 2026-11-01 (below).

File	Backend	Prefill 1,024 (tok/s)	Decode 256 (tok/s)	Time to first token (s)	Image + question: first text (s)	Peak footprint text / image (GB)
int4	GPU (vision encoder on the GPU)	4,117	179.0	0.254	0.205
int4, 4,096-token context	GPU (vision encoder on the GPU)	3,679	156.5	0.288	0.222	2.41 / 3.40
float16	GPU (vision encoder on the GPU)	3,932	99.0	0.271	0.220	5.04 / 5.92
int4	CPU (vision encoder on the CPU)	300	57.0	3.44	2.13
int4, 4,096-token context	CPU (vision encoder on the CPU)	285	50.4	3.61	2.30	7.19 / 7.55
float16	CPU (vision encoder on the CPU)	557	17.3	1.90	3.93	43.84 / 44.54

The image column uses the truck photo and question of the demo below; first text = vision encoder + prefill + first decoded token, as streamed. The int4 file's three CPU decode runs gave 61.0, 57.0 and 39.1 tok/s; on the CPU it prefills more slowly than the float16 file. Its peak footprint was not measured in those runs; in one run of the Python lines in Usage (2026-10-31, the truck photo) it was 3.12 GB on the GPU and 7.34 GB on the CPU. The 4,096-token rows are one window of 2026-11-01 that ran the two int4 files in turn (median of three; max_num_tokens 4,096 for the 4,096-token file and 2,048 for the other; load average 29–59): in that window the 2,048-token file gave 4,060 / 176.2 tok/s on the GPU and 300 / 58.0 tok/s on the CPU (prefill / decode), so the 4,096-token file decoded 11 % slower on the GPU and 13 % slower on the CPU. One of its three GPU decode runs gave 49.1 tok/s and one CPU run 28.3 (other jobs on the Mac).

On-device demo

Q: What words are written on the yellow sign? Answer with the words only. A (int4): "Oversize load" A (float16): "Oversize load"	Q: Describe this image in one sentence. A (int4): "Three men wearing orange jumpsuits and hoods are working together in a jungle environment, handling large green palm fronds." A (float16): "Three men wearing orange jumpsuits and hoods are working together in a forest, handling large green fern-like plants."
Q: Which day has the tallest bar in this chart? Answer with the day label only. A (int4): "Wed" A (float16): "Wed"	Q: What text is written on the sign? Answer with the text only. A (int4): "EXIT 12" A (float16): "EXIT 12"

Verbatim answers, thinking off, greedy, litert_lm_advanced_main built from the LiteRT-LM v0.18.1 tag: with the int4 and float16 files the Galaxy S26 (--backend=gpu --vision_backend=gpu) and the Pixel 8a (--backend=gpu --vision_backend=cpu) gave the same four answers as the Mac GPU, word for word, except that the int4 file on the Pixel 8a wrote the sign as "Exit 12". With the vision encoder on the Galaxy S26's CPU the float16 file's sign came back as "OVERSIZE LOAD" (three runs out of three). The two photos are NASA's (public domain): KSC-08pd3809 and S67-34267; the chart and the sign are our own drawings.

Accuracy

The test set is 23 questions about 12 images (8 drawings and 4 NASA photos): 18 with one right answer (counts, colours, text, chart and table values, left or right, yes or no), 3 bounding boxes and 2 one-sentence descriptions; plus 8 short text questions and "What is the capital of France?". The reference is the source model in Transformers on the CPU, given the same 512 × 512 images. All answers here are greedy, one process per question. On the phones we asked the int4 file 8 of the image questions (7 with one right answer) and the text questions; the float16 file was asked all 23 image questions on the Galaxy S26 and the same 8 on the Pixel 8a.

Right answers. With thinking on, the reply had room for 1,024 tokens, and an answer counts only when the thought ended and the answer after it is right.

	LFM3-VL-2B_int4.litertlm	LFM3-VL-2B_f16.litertlm
Image questions with one right answer, thinking off	18 of 18 on the Mac GPU and CPU; 7 of 7 on the Galaxy S26 GPU and the Pixel 8a GPU	18 of 18 on the Mac GPU and CPU and the Galaxy S26 GPU; 7 of 7 on the Pixel 8a GPU
The same, thinking on	18 of 18 on the Mac GPU and CPU; 7 of 7 on the Galaxy S26 GPU and the Pixel 8a GPU; every thought ended (the longest reply 541 tokens)	18 of 18 on the Mac GPU and CPU, measured on a 4,096-token build of the same weights with room up to the end of its cache (Limitations)
Text questions, thinking off	8 of 8 and "Paris" on the Mac GPU and CPU, the Galaxy S26 GPU and the Pixel 8a GPU	7 of 8 and "Paris" on the Mac and the Galaxy S26; the miss is a rhyme the source model misses too (the Pixel 8a: the 7 asked pass, and France)

LFM3-VL-2B_int4_ctx4096.litertlm was not asked these questions; its weights are the int4 file's byte for byte, and on the 23 placement requests below that fit in 2,048 tokens its thoughts and points equal the int4 file's.

The source model itself, in bfloat16 (its released precision), answers 18 of 18 image questions and 7 of 8 text questions (the rhyme) with thinking off.

A closer look at the wording. Against the source model in bfloat16 the first 32 tokens of the answer agree on 22 of 23 image questions thinking off and 20 of 23 thinking on for the float16 file (Mac GPU; Mac CPU 22 and 19), and on 17 of 23 and 9 of 23 for the int4 file (Mac GPU; Mac CPU 17 and 8): the int4 file more often gives the same answer in other words, and with thinking on it thinks in other words. bfloat16 and float32 themselves differ on 1 and 3 of these questions.

• Mac GPU, float16 file: on all 23 image questions the first 32 tokens of the answer equal the source model's in float32, with thinking off and with thinking on (46 of 46), and the text answers equal float32's (8 of 8). Mac CPU: 23 of 23 thinking off, 22 of 23 thinking on, text 8 of 8.
• The phones against the Mac GPU: float16 file, Galaxy S26 GPU 22 of 23 image answers identical (the 23rd is a bounding box with two of its four coordinates one unit off) and the text answers identical (9 of 9); Pixel 8a GPU, the 8 image answers asked are identical, and so are the 7 text questions asked (the eighth was not reached) and France. int4 file, Galaxy S26 GPU 8 of 8 image answers identical; Pixel 8a GPU 7 of 8 (the sign in other letter case); on both phones 7 of 8 text answers identical (the eighth, "Which is larger: 0.9 or 0.11?", right in other words) and France.
• Images at a fixed 512 × 512 instead of the source processor's native resolution (which keeps the aspect ratio; 256–800 image tokens on these images): with the source model in float32, all 18 right answers stay right, and the first 32 tokens stay the same on 16 of 23 questions (boxes move a few units, descriptions are reworded).

Where to put an object, thinking on (what the 4,096-token file is for). 30 requests such as "Put the mug between the lamp and the books." about 10 photos from Wikimedia Commons (CC0 or public domain: desks, tables, a shelf, a kitchen counter, a bedside), each stretched to 512 × 512: 8 to the left or right of something, 6 between two things, 10 in front of or behind something, 6 on a surface. The model answers with a point, and an answer is right when its point lies inside the region we drew for the request before any model was run. Mac GPU, litert-lm 0.19.0, greedy, thinking on, replies allowed up to the end of each file's context (3,751–3,761 new tokens for the 4,096-token file, 1,703–1,713 for the 2,048-token file); the source model was allowed 4,096 new tokens.

	Right	Thought cut off at the end of the context	Longest reply (tokens)
Source model in float32 (Transformers on the Mac GPU), the same 512 × 512 images	21 of 30	0 (allowed 4,096 new tokens)	2,332
LFM3-VL-2B_int4.litertlm	17 of 30	7	1,713
LFM3-VL-2B_int4_ctx4096.litertlm	21 of 30	0	3,746

On the 23 requests the 2,048-token file answered, the two int4 files wrote the same thought and gave the same point. On the 7 where it ran out of room, the 4,096-token file's thought begins with the same words and goes on to an answer, 4 of them right. Its longest reply came within 11 tokens of the end of its context (4,085 of 4,096 tokens with the prompt). The source model and the 4,096-token file are right on different requests: both on 15, each alone on 6. On the Pixel 11 Pro GPU (Performance) the 4,096-token file answered two of these requests: "Put the sugar bowl to the right of the glass shaker." with the Mac's point and "Put the mug between the lamp and the books." with [350, 820], inside the region, as the Mac's [370, 800] is; both replies, thought and answer, were longer than on the Mac (561 and 347 decoded tokens against 326 and 204).

Limitations

• Every image is stretched to 512 × 512 = 256 tokens. Turn photos upright and resize them yourself (Usage).
• Video is not in these files. More than one image per conversation was not tried.
• Context is 2,048 tokens in LFM3-VL-2B_int4.litertlm and LFM3-VL-2B_f16.litertlm and 4,096 in LFM3-VL-2B_int4_ctx4096.litertlm (the source model: 128K). With the int4 file and thinking on, the longest reply to our test questions was 541 tokens, after a prompt of 276–290 tokens. With the float16 weights and thinking on, every answer to the 32 test prompts ended within 634 tokens, prompt included (measured on a 4,096-token build of the same weights, whose replies to all 64 test prompts equal the float16 file's). On the placement requests (Accuracy) 7 of 30 thoughts did not fit in 2,048 tokens, and the 4,096-token file's longest reply came within 11 tokens of its end.
• Create one Engine per conversation: on LiteRT-LM, a conversation started on an Engine that already served another one continues from that conversation's running state (LiteRT-LM issue #3165). This model keeps a running short-convolution state; this was not measured on these files.
• From the second message of a conversation, LiteRT-LM 0.18.1 feeds the previous answer's stop token to the model as a zero embedding (every file with a separate embedding table); not measured on these files. One question per conversation avoids it.
• Pixel 8a: the float16 file sits at the edge of the memory (Performance); use the int4 file.
• The int4 file keeps the answers of our tests but words them differently from the source model more often than the float16 file (Accuracy).
• The Galaxy S26 CPU: the float16 file decodes 5.28 tok/s, with a 6.92 GB weight cache. The int4 files were not run on the Galaxy S26 CPU; use its GPU. LFM3-VL-2B_int4_ctx4096.litertlm answered our text question on the Pixel 11 Pro CPU (Performance).
• Tool calling was not tested with these files.
• The source model card does not recommend the model for coding, multi-turn conversations or complex reasoning.

Conversion notes

• Source: LiquidAI/LFM3-VL-2B at revision f83d2b0a (1,918,181,888 BF16 parameters). The current main (da10385c) changes only README.md.
• Text decoder: exported with litert-torch (commit f61d0b7) and our LFM3 export extension (see REPRODUCE.md in the conversion repository) (torch 2.14.0, transformers 5.20.2) with 7 signatures (prefill 1,024 / 256 / 64 / 16 / 4 / 1 and decode) over a 2,048-token cache (4,096 for LFM3-VL-2B_int4_ctx4096.litertlm: the same export with only that length changed, so its weights are the int4 file's, byte for byte), the token embedding table as its own section in int8. With ai-edge-quantizer-nightly 0.10.0.dev20261023, the float16 file casts every fully connected weight to fp16; the int4 file quantizes every fully connected weight but the output projection to int4 (symmetric, blocks of 32, from each block's largest value; the 3,517 block scales under 2^-14 in 4 weights raised to 2^-14) and the output projection to int8 per channel.
• How the int4 file was chosen: before any converted file was measured, we first required at least 21 of the 23 image answers (thinking off) to equal the bfloat16 source model's first 32 tokens, and int8 and int4 decoder weights, whole or in part, gave 17–20, so the float16 file came first. We then judged the faster builds by the answers an app gets: right answers on the questions that have one, the text questions, and thinking that ends (Accuracy). The int4 file passed on the Mac, the Galaxy S26 GPU and the Pixel 8a GPU, and it was the fastest build we measured on the Galaxy S26 GPU, the Pixel 8a GPU and the Mac GPU.
• Vision encoder and projector: re-written in plain PyTorch for the fixed 512 × 512 grid and exported with litert-torch 0.10.0. The graph takes the runtime's float(u8) / 255 input back to u8 and normalises it as the source processor does. Against the source model's image features the worst per-token cosine over 12 images is 0.9999978 for this fp32 encoder and fp16 adapter; fp16 or int8 encoder weights, or the GPU's fp16 precision, lowered it to 0.20–0.70, so the encoder stays fp32. All three files carry the same vision encoder and adapter, byte for byte.
• Template: the source chat template with the changes LiteRT-LM's template engine needs (no generation tags, no .get() calls), the image placeholder, and earlier assistant turns rendered without their thought wherever they sit (LiteRT-LM keeps a conversation's earlier prompt as a prefix of the next one). On 10 test conversations (images, text, a system message, two turns with a thought, two images in two turns) it renders the token ids of the source processor, and LiteRT-LM 0.18.1's own rendering equals ours on 5 conversations (an image with thinking off, on and unset; a second turn with thinking off and on). The tokenizer is the source repository's tokenizer.json, byte for byte; all three files carry the same template and tokenizer.

License

LFM Open License v1.0, the same license as the source model (LICENSE). The files here are converted from LiquidAI/LFM3-VL-2B: the weights are cast to fp16 (the float16 file's text decoder, the vision adapter), quantized to int4 (the text decoder of the two int4 files, with an int8 output projection) and to int8 (the token embedding table), the vision encoder is re-exported in fp32, and the chat template is changed as described above. Section 5 of the license does not license commercial use by an organization with annual revenue of 10 million US dollars or more (a qualified non-profit's non-commercial and research use is exempt).