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).

Jan-nano — LiteRT-LM (blockwise int4)

Menlo/Jan-nano converted to the LiteRT-LM (.litertlm) format for on-device inference with Google's LiteRT-LM runtime (the engine behind the official litert-community/* models).

Jan-nano is a 4B deep-research agent fine-tuned from Qwen3-4B (Qwen3ForCausalLM) with a multi-stage RLVR recipe, optimized for tool use via the Model Context Protocol (MCP). It is a reasoning model — it emits a <think>…</think> chain before its answer — so it rides the existing Qwen3 converter and runtime directly.


Files	`model.litertlm` — int4 block 128 (recommended, on-device) · `model_block32.litertlm` — int4 block 32 (finer-grain, desktop/Android)
Quantization	int4 weights (symmetric) + OCTAV optimal-clipping; embeddings INT8 (externalized section)
Compute	integer
Context (KV cache)	4096
Base model	Menlo/Jan-nano (Qwen3-4B)

⚠️ It's a reasoning model — give it room to think

Jan-nano generates a <think>…</think> reasoning chain, then the answer. Run it with max_tokens ≥ 2048 — at a short limit it gets cut off mid-thought and never reaches the answer. (All quality numbers below were measured at 2048.)

Which file?

File	int4 granularity	GSM8K (max_tokens 2048)	iPhone 17 Pro	Mac (M-series, GPU)
`model.litertlm`	block 128	88.0%	~14 tok/s, loads	~67 tok/s
`model_block32.litertlm`	block 32	85.0%	2.11 GiB section — near the iOS memory ceiling, may not load	~67 tok/s

Use model.litertlm (block 128) — for a reasoning model that emits long <think> chains, faster decode matters, and block 128 (¼ the scales → lighter GPU dequant) is ~40% faster while matching block 32 on accuracy here. It is also the build that loads reliably on iPhone (the block-32 build's larger section sits at the device memory edge). block 32 is provided for desktop/Android where the extra granularity is free.

Performance

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.

Device	Backend	Prefill (256)	Decode	TTFT	Load	Peak footprint
Apple M4 Max (macOS)	CPU	111 tok/s	18.0 tok/s	2.49 s	—	—
Apple M4 Max (macOS)	GPU (Metal)	1003 tok/s	69.0 tok/s	0.28 s	—	—
iPhone 17 Pro	GPU (Metal)	—	~14 tok/s	—	—	—

Reproducibility: the GPU rows repeat to within about 1% across invocations; the CPU rows are noisier — re-running the 1B control six times spread its CPU decode over 29.0–33.3 tok/s, so treat the CPU column as accurate to roughly ±7%.

The desktop rows are the shipped model.litertlm (block 128); the block-32 build was not re-measured, so the figures for it in “Which file?” above are the older ship-gate numbers. The iPhone row is carried over from this repository's own earlier on-device note for the block-128 build; its run log is not retained here, so the run count and prompt are not known.

Accuracy note

Measured on GSM8K (n=100, greedy, 0-shot chain-of-thought, max_tokens 2048, identical prompt and answer-extraction for every row).

Configuration	GSM8K
bf16 (reference)	92.0%
LiteRT int4 — block 128	88.0% (−4 pt)
LiteRT int4 — block 32	85.0% (−7 pt)

int4 is at parity (−4 pt for the recommended block-128 build). Note: evaluating a reasoning model at a short token budget badly understates int4 — at max_tokens 1024 the same block-32 build scored only 63% purely because the longer int4 reasoning chains were truncated before the answer; at 2048 it recovers to 85%. Always benchmark reasoning models with enough headroom.

Galaxy S26 — GPU backend

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

file	GPU backend	delegation	peak
`model.litertlm`	runs	3270 / 3270 ops across 2 subgraphs on `LiteRT GPU`	1021 MB
`model_block32.litertlm`	runs	3270 / 3270 ops across 2 subgraphs on `LiteRT GPU`	1364 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-24.

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

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.

Usage

bash

# build litert-lm from https://github.com/google-ai-edge/litert-lm, then:
litert_lm_main \
  --model_path model.litertlm \
  --backend gpu \
  --input_prompt "Plan how to find where HTTP retries are configured in a Python repo."

Run on Android

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 adb needed. The manual steps below are only required on older builds or for sideloading a local file.

The official Google AI Edge Gallery app runs .litertlm models on-device:

Install a recent Gallery (package com.google.ai.edge.gallery, 1.0.15+ supports .litertlm).
Download model.litertlm and push it: adb push model.litertlm /sdcard/Download/
In the app tap +, pick the file, choose the GPU backend, and raise the max-tokens setting.
Chat — the bundle already carries the tokenizer and Qwen3 chat template.

A 4B int4 build needs ~2.5 GB free RAM; reboot the phone first if memory is tight.

Run on desktop (LiteRT-LM CLI)

The same .litertlm bundle runs on macOS / Linux / Windows with the official LiteRT-LM CLI — including as a local OpenAI-compatible API server:

bash

pip install litert-lm
litert-lm import --from-huggingface-repo litert-community/Jan-nano model.litertlm jan-nano
litert-lm run jan-nano     # interactive chat in the terminal
litert-lm serve           # local OpenAI-compatible API server

Run on iPhone

Verified on iPhone 17 Pro (LiteRT-LM Swift runtime): model.litertlm (block 128, 1.94 GiB section) loads and generates at ~14 tok/s. The block-32 build's section (2.11 GiB) sits at the device memory ceiling and may fail to load — prefer block 128 on iPhone.

Conversion

Converted with the official litert-torch converter — Jan-nano is a standard Qwen3ForCausalLM, so it uses the existing Qwen3 path with no custom graph code. Recipe: blockwise int4 + OCTAV (INT4 weights, block 128 or 32, symmetric, OCTAV optimal-clipping), embeddings INT8, KV cache 4096.

python

from litert_torch.generative.export_hf.export import export
export(
    model="Menlo/Jan-nano",
    output_dir="out",
    quantization_recipe="qwen3_int4_block128_octav.json",  # blockwise-128 int4 + OCTAV, int8 embeddings
    cache_length=4096,
    externalize_embedder=True,
)

Raspberry Pi 5 (CPU)

Measured on a Raspberry Pi 5 Model B Rev 1.1 (8 GB, Raspberry Pi OS 64-bit) with litert-lm benchmark 0.16.1: CPU backend, 4 threads, 256 prefill + 256 decode tokens, --cache memory (the compile cache lives and dies with the process, so every invocation compiles the model from scratch; nothing is reused between runs), one warm-up plus one timed iteration per invocation, 3 invocations per file with cooldown in between. Values are the median across invocations (min–max in parentheses). No thermal throttling occurred during these runs (vcgencmd get_throttled stayed 0x0). Every file listed produced coherent text in a real generation on this backend before its numbers were recorded.

File	Prefill (tok/s)	Decode (tok/s)	TTFT	Peak RSS
`model.litertlm`	10.6 (10.4–10.7)	1.5 (1.5–1.5)	25.5 s	3.9 GB
`model_block32.litertlm`	10.4 (10.4–10.4)	1.4 (1.4–1.4)	28.0 s	4.3 GB

License

Apache-2.0, inherited from the base model Menlo/Jan-nano (itself fine-tuned from Qwen/Qwen3-4B, also Apache-2.0).