Apple's LensVLM reads long documents as compressed images and expands only the pages that answer the question

Apple’s LensVLM reads long documents as compressed images and expands only the pages that answer the question

Apple quietly published LensVLM-9B on Hugging Face on September 21. It is a finetune of Qwen3.5-9B with one job: read long documents cheaply. The model never tokenizes the full text. It renders every page as a compressed image, scans those images, and when a page looks relevant to the question, it calls a learned tool to load that page’s actual text at full resolution. Victor Mustar’s tweet about it (1,657 likes) put it well: turn long documents into small page images to save tokens, then pull up the full text of only the pages that matter.

The numbers from Apple’s paper (arXiv 2605.07019, Xie, Friedman, Yu, et al.): at 4.3x effective compression the model holds accuracy comparable to reading the full text, and it beats retrieval-based, text-compression, and visual-compression baselines all the way out to 10.1x compression across seven text QA benchmarks. At higher compression, the margin over those baselines widens, and selective expansion carries more of the accuracy.

How LensVLM compresses pages and expands only relevant ones

The model card describes three compression levels: 5x, 10x, 15x. A document comes in as plain text. LensVLM renders the pages as images at the chosen compression, and the vision encoder maps each page to a fixed number of visual tokens regardless of how much text the page holds. That fixed mapping controls the compression. The model answers with a two-stage trick: it reads the blurry compressed images to figure out which pages could contain the answer, then expands those specific pages back to uncompressed form and reads them properly.

The paper’s own analysis explains why this works better than just squinting at compressed text: characters shrink below the vision encoder’s effective resolution and become indistinguishable, so the model is trained to rely on expanded content rather than trying to read the unreliable fine print. The model learns when to expand.

Run it on an 8 GB laptop

9.41B parameters at 4-bit is roughly 4.7 GB of weights. That fits an 8 GB laptop, and the Qwen3.5 base runs on llama.cpp-class runtimes. For Tokenstead readers, the useful comparison is what the visual-token trick does to memory pressure on long documents. A 400-page document tokenized as text at the usual 1.3 tokens per word is hundreds of thousands of tokens, and the KV cache for that at 9B scale eats several gigabytes on top of the weights. LensVLM’s compressed scan of the same document is a fixed, small token count, with only the few relevant pages expanded.

The numbers above come from Apple’s own paper on its own benchmarks: seven QA suites, no independent replication yet. 233 downloads in two days says nobody has run it broadly at home yet. The GitHub code is there (apple-aiml-research/ml-lensvlm), so the check is runnable.