A model that sees and runs on a phone: 460 million parameters, Apache 2.0 licence
7 min read
On 29 July 2026 Tether Data released VisionPsy-Nano as open weights: a family of vision-language models of roughly 460 million parameters, under the Apache 2.0 licence, designed to run on the device itself. The company’s press release is dated 30 July, with a San Salvador dateline. The weights sit on Hugging Face in two variants — qvac/VisionPsy-Nano-460M and qvac/VisionPsy-Nano-460M-Flash — alongside quantised GGUF builds of each.
For anyone running a business or a public body, the news is not the leaderboard. It is that a model able to read an image and a document can now live inside a company phone or a field terminal: if inference happens there, the photograph of the switchboard, the delivery note or the inspection tag crosses no network at all. This is the use case manufacturing asks about most often, and until now it required either a connection or a cabinet. Before it goes into a specification, though, it is worth reading what the producer actually declares — and with what caveats, which are written on the model card rather than in the press release.
What was released
- Declared architecture: a SigLIP2 base vision encoder, patch16, at 512×512; SmolLM2-360M as the language backbone; a pixel-shuffle connector. The starting point is named on the card:
lusxvr/nanoVLM-460M-8k. Context window 8,192 tokens. - Licence: Apache 2.0. The card’s own wording is that the model “is licensed by Tether Data, S.A. de C.V. under the Apache 2.0 license”. No revenue threshold, no separate agreement.
- Two variants, not one: the full model uses 1,088 visual tokens per image, the Flash variant 64. On the declared overall normalised score the gap is 62.3 against 61.4.
- Runtimes:
transformerswithtrust_remote_code, vLLM, SGLang, Docker Model Runner, plus GGUF builds for local execution.
The headline number, and the three underneath it
The figure doing the rounds is “first token in 0.3 seconds on an iPhone 15”. It is accurate, and it needs three qualifications that appear in the producer’s own post but not in the headline.
First: that timing belongs to the Flash variant, not the full model. Second: it is the best of four measurements. The same table reports time-to-first-token of 0.3s on iPhone 15, 2.6s on Galaxy S25 Ultra, 5.9s on Galaxy S23 and 6.1s on Pixel 9 — a twentyfold spread between first and last. Third: the conditions are stated and they are narrow, “measured on real phones with quantized GGUF builds at 512×512”. If your device fleet is not made of recent iPhones, the number that should inform your decision is the last one in that row, not the first.
The same reading applies to leading “16 of 17 benchmarks”. The comparison set is models of the same size — LFM2.5-VL-450M, SmolVLM2-500M and nanoVLM-460M-8k — and it is the producer itself that names the third as the checkpoint VisionPsy-Nano was built from. A fine-tuned model beating its own starting point is the expected outcome, not a surprise. The seventeenth test, the one it does not lead, is never named. The evaluations were run by the producer: the post states that every model was scored under a single harness, VLMEvalKit, with eval configs and judge setup published, “so the benchmark numbers are reproducible”. True — and distinct from “already reproduced by someone else”: as of 29 July, support for these two models inside VLMEvalKit was an open pull request on the public repository, number 1613, not merged code.
This holds as a general rule, well beyond this release. A declared number is unusable until you know four things: who ran the measurement, against which competitors, under what conditions, and what the worst case was among those measured. If one is missing, the figure is not a measurement but a sales argument — the same test we applied when writing about how you check whether a system actually worked.
The lines that matter more than the scores
The limitations section on the card is short and should be read in full, because it decides more than the benchmarks do.
“Primarily English; other languages are not officially supported yet.” For anyone who has to read delivery notes, inspection records, clinical reports or maintenance sheets in Italian, that line comes before any score: a trial on your own real documents is the only test that counts.
“Single-image by design”: one image per query, multi-image prompts fall outside the intended use. Then the admission about behaviour: the model “may occasionally hallucinate or miscount and is best suited to focused tasks rather than very dense documents or long multi-step math”. And finally the line to copy straight into the file: “Not intended for safety-critical or high-stakes automated decisions”.
That last one is not boilerplate. If your use case falls among high-risk systems, you hold a supplier document stating the model is not intended for that purpose: either the use changes, or the statement has to be explained and offset by documented human controls. On what to demand from a model’s documentation before installing it, we wrote a separate note.
Apache 2.0 on the weights does not cover everything behind them
The card lists the fine-tuning datasets with their respective licences: FineVision (CC BY 4.0), NVIDIA Nemotron-Image-Training-v3 (CC BY 4.0), mPLUG TinyChartData (Apache 2.0), TabMWP (CC BY-NC-SA 4.0), PopVQA (MIT), InfoSeek (Apache 2.0), MMKU-Bench (Apache 2.0), VisionFoundry-10K (Apache 2.0), PKU-SafeRLHF-V (CC BY-NC 4.0).
Two carry the NC clause: non-commercial. Whether, and how far, a licence on training data reaches the weights derived from it is an open question, and no ruling appears to settle it: the weights themselves are published under Apache 2.0. The operational point is not having the answer: it is that the question exists, it is written on the supplier’s own card, and whoever misses it today will be asked about it in a due diligence. We have already set out how to read an open-weight licence; this adds one step, which is to read the declared data list as well. And to archive the card as it stood on the day you downloaded, with the exact revision and the file hashes: a card can be rewritten, your copy cannot.
What to do now
- Test the model on your own Italian-language documents before any other assessment: the card declares English as the primary supported language, and that alone may close the use case.
- Do not carry the producer’s figure into the business case: measure time-to-first-token again on the terminal you will actually deploy, at the same quantisation and the same resolution.
- Write down which variant you are adopting. Full and Flash do not share timings or scores, and in the repositories they look alike.
- Have the two non-commercial licences assessed before production, not after. The answer may well be “acceptable risk”: it has to be a written decision, not an oversight.
- Treat the line about high-stakes decisions as a design requirement: set out where the model does not decide, who decides instead, and where the record is kept.
A 460-million-parameter model running on a phone is not a system: it is the part that sees. Around it you still need the rest — document indexing, domain rules, human review, evidence retention, controlled updating of the weights — and that rest runs where you decide: on-premise in the environment you already administer, or on a dedicated cloud, an environment reserved to the single client, reached over a dedicated VPN, in a data centre resident in Italy, in premises we staff directly. Those are the two delivery modes we work in, and the choice stays yours after signature too. The full reasoning on where the compute runs, whose the weights are and what leaves the perimeter sits on the page about hardware and open-weight models.
Assessing an on-device model for field inspection or for reading confidential documents? Let us talk it through in a thirty-minute session: we put the declared numbers to the test on your documents, before you do it in production.