litetune fine-tunes a small language model, converts it into a file that runs through LiteRT-LM on supported native devices — phone, desktop, embedded board, robot — and checks that the converted model still does the job.
Converting a model so it fits on a device changes it. The file still loads, the tools still report success, and the model can still be worse at your task than it was before. litetune runs the converted model on data it was never trained on, compares it with the version it came from, and tells you the difference.
Across the twelve headline runs, every converted candidate ran on LiteRT-LM's CPU backend; some float references ran on CUDA. The eight-bit gap was small on all twelve and often unresolved. Four of the fine-tuned models also have blockwise four-bit results with the candidates on LiteRT-LM's CPU backend, where the gap was larger. A separate Qwen3 phone run shows that the backend can change the answer. The numbers, and what they do not establish
270M parameters, text only. Google built it for tool calls: given a list of functions it picks one and fills in its arguments, which is the job an app needs done on the phone rather than in a round trip to a server. Small enough that the whole model ships inside the app.
270M parameters, text only — the smallest checkpoint measured here. In the banking77 run it was fine-tuned on 2,400 examples and evaluated as a 77-way intent classifier, rather than as a conversational model.
1B parameters, text only. It was measured on the same banking77 split and through the same export rule as the 270M, providing a second size in one family without assuming that size predicts the conversion cost.
0.6B parameters, text only. A reasonable first try when the task is labels, and the first family measured here that litetune had no per-model rule for — it exported with no flag from litetune; since 0.4.3 its rule hands the base model, and a checkpoint litetune trained on rendered prompts, LiteRT-LM's own Qwen 3 template.
1.7B parameters, text only, and the same chat template as the 0.6B byte for byte, so its rule hands it LiteRT-LM's own Qwen 3 template on the same terms. Measured on litert-lm 0.18.0, with neither eight-bit conversion cost resolved.
0.5B parameters, text only. It is the one checkpoint here on which channelwise four bits produced a score at all, where the others either refused or came apart, and those scores cost it +0.2683 and +0.2500 against its float 0.7700 on litert-lm 0.17.1.
1.5B parameters, text only, and the same chat template as the 0.5B Instruct byte for byte, composed behind the same text-parts block. Measured on litert-lm 0.18.0 with eight bits only, neither conversion cost resolved.
0.8B parameters, text only, and most of its layers are not attention: 18 of its 24 are linear attention. It takes LiteRT-LM's own Qwen 3.5 template, edited to render a single turn as the checkpoint does, and verify gives every prompt an Engine of its own.
2B parameters, text only, under the same rule as the 0.8B: its bundle carries the same edited template, byte for byte. Measured on litert-lm 0.18.0, where its eight-bit dynamic conversion cost resolved.
1B parameters, text only. It takes LiteRT-LM's own MiniCPM5 template, edited for the start token its checkpoint template prints itself: the runtime puts that token in front of what it renders, and the first export of it could not check that.
3.4B parameters, text only, and the largest text-only model measured here. Its own chat template, composed behind litetune's text-parts block. Measured on litert-lm 0.18.0 with eight bits only, neither conversion cost resolved.
About 5B parameters, and multimodal — a text tower with vision and audio towers beside it. For an assistant that has to see or hear as well as read. A LoRA run on it is scoped to the text tower, because all three use the same projection names and a run scoped by name alone reaches every one of them.