In v3.1.0 we added Qwen3-VL and made a promise: thanks to the new FAMILY_GROUPS registry, future model families would appear in the notebooks automatically, with no interface edits at all. Version 3.2.0 is that promise kept. InternVL3.5 — the latest generation of OpenGVLab’s InternVL line, released in August 2025 — is now the fourth family in the registry, and neither notebook changed by a single line to display it.

UVLM integrates the six Transformers-native -HF checkpoints, which run through the standard Transformers stack without any custom remote code. None of them is gated: no Hugging Face token required.

The registry now totals 21 checkpoints across 4 families, from 1B to 110B parameters — and the 1B entry replaces Qwen3-VL 2B as the smallest model UVLM has ever supported.

InternVL3.5 is not a variation on the Qwen conventions — it uses the standard Transformers pattern in which the chat template tokenizes directly (apply_chat_template(tokenize=True)), the generated tokens are sliced off after the prompt, and only the generated portion is decoded. That makes it the third distinct inference path in UVLM, alongside LLaVA’s string-based cleaning and Qwen’s separate vision preprocessing with token trimming. As always, all three converge at the same unified response parser — from the user’s side, InternVL3.5 is simply one more family in the dropdown.

Loading follows the same BF16-aware logic introduced in v3.1.0: BF16 automatically on GPUs with native support (RTX 30-series and newer, L4, A100), FP16 fallback otherwise.

While validating the new backend, we caught a fossil from UVLM’s two-backend era: the notebooks used a hardcoded rule that sent every non-Qwen2.5 model’s results to Score_Analysis_LLaVA.csv. With four families, that meant different models could silently append into the same CSV — and resume mode could not tell them apart. As of v3.2.0, output filenames are derived from the loaded checkpoint (e.g. Score_Analysis_InternVL3_5-8B-HF.csv), so each model writes its own file and resume mode and schema upgrades are per-model by construction. If you benchmark several models on the same image folder, this is the release that keeps your results honest.

Nothing changes in the workflow — install (or upgrade) and the new family is there:

pip install --upgrade --force-reinstall --no-deps
git+https://github.com/perezjoan/UVLM.git

Or open the Colab notebook — it always installs the latest version automatically. The three-block workflow (load → configure tasks → run batch), consensus validation, chain-of-thought mode, and truncation detection all work with InternVL3.5 out of the box. No dependency changes since v3.1.0. Tested locally on Windows 11 with an RTX 5060 laptop GPU, where the 1B model loads in about 15 seconds once cached.

One field note from validation, and a nice illustration of why UVLM separates format reliability from accuracy: under temperature sampling, InternVL3.5 1B answered a counting task with “There are two vehicles in the picture” — correct, but unparseable as an integer, so it was recorded as NA by design. Under greedy decoding with a strict format instruction, the same model returned a clean integer. Small models follow instructions best when you ask firmly and decode greedily.

The third family addition promised in v3.1.0 — the Gemma multimodal line — is coming next, and it will be a bigger step than a minor version: Gemma 4 requires the Transformers v5 line, which means UVLM’s next release will be a major version with a documented migration. Same discipline as always: one backend at a time, validated before released.

Full change log in VERSIONS.txt · Source and releases on GitHub · If you use UVLM in research, please cite our Software paper.

UVLM was built around one idea: compare Vision-Language Models across architectures using identical prompts and evaluation protocols, without writing model-specific code. Until now that meant two families: LLaVA-NeXT and Qwen2.5-VL. Version 3.1.0 adds a third: Qwen3-VL, the successor to the Qwen2.5-VL family that anchored our published benchmark.

Qwen3-VL is the latest vision-language generation from Alibaba’s Qwen team, first released in September 2025 with the 235B-A22B flagship, followed shortly after by the compact dense checkpoints that matter for most research budgets. UVLM v3.1.0 integrates the four dense Instruct sizes:

The registry now totals 15 checkpoints across 3 families, from 2B to 110B parameters — and the 2B entry is the smallest model UVLM has ever supported, which makes it an interesting new baseline for large-scale, low-cost batch analysis.

Technically, Qwen3-VL keeps the Qwen inference conventions (chat template → separate vision preprocessing → generation → token trimming), so it plugs into UVLM’s existing Qwen pipeline. What changes under the hood: the model loads through Transformers’ generic AutoModelForImageTextToText class, requires transformers ≥ 4.57 and qwen-vl-utils ≥ 0.0.14, and resizes images to multiples of 32 pixels rather than 28. All of this is handled inside the package — from the user’s side, it is simply one more family in the dropdown.

With three families and fifteen checkpoints, a single flat dropdown was getting crowded. Both notebooks (Colab and local) now use a two-level selector: choose the family first — LLaVA-NeXT, Qwen2.5-VL, or Qwen3-VL — and the model list refreshes automatically.

The selector is built from a new FAMILY_GROUPS mapping in the registry, which means future families will appear in the widgets automatically, with no notebook edits at all.

Qwen3-VL checkpoints are trained in BF16. On GPUs with native BF16 support (RTX 30-series and newer, L4, A100), the loader now selects BF16 automatically, falling back to FP16 on older cards and FP32 on CPU. If you followed our earlier benchmark work, you may remember the FP16 numerical-overflow crashes we documented with BF16-trained checkpoints on T4 hardware — this release is the first step toward closing that class of problem at the loader level.

Local Jupyter users get a long-overdue improvement: the model-loading progress (download bars, device map, timings) is now displayed in a log area under the Load button. Previously, output emitted inside the widget callback was silently swallowed in local Jupyter — Colab was never affected. The release also silences the torch_dtype deprecation warnings from recent Transformers versions and synchronizes the package version metadata.

Nothing changes in the workflow — install (or upgrade) and the new family is there:

pip install --upgrade --force-reinstall --no-deps git+https://github.com/perezjoan/UVLM.git

Or open the Colab notebook — it always installs the latest version automatically. The three-block workflow (load → configure tasks → run batch), consensus validation, chain-of-thought mode, and truncation detection all work with Qwen3-VL out of the box. Tested locally on Windows 11 with an RTX 5060 laptop GPU, where the 2B model loads in well under a minute once cached.

v3.1.0 is the first of a series of family additions. Next on the roadmap: InternVL3.5 (via the Transformers-native -HF checkpoints) and the Gemma multimodal line. Each family will land as its own validated release — same discipline, one backend at a time.

Full change log in VERSIONS.txt · Source and releases on GitHub · If you use UVLM in research, please cite our Software paper.

When we released UVLM in March 2026, it was a Google Colab notebook. You opened it in your browser, picked a model, typed your prompts, and ran your images — all without installing anything. That simplicity was the point: a tool that anyone could use to load and compare Vision-Language Models, regardless of their technical setup.

But we kept hearing the same requests. Can I run this on my own machine? Can I call UVLM from a script? Can I integrate it into an existing pipeline? The answer was always the same: not easily. The entire tool lived inside a single notebook, with all the logic packed into three massive code cells. Moving it anywhere else meant copy-pasting thousands of lines and untangling global variables.

Version 3.0.0 changes that. UVLM is now a proper Python package.

The core logic — model loading, dual-backend inference, response parsing, consensus validation, batch processing — has been extracted from the notebook into eight standalone Python modules. These modules have no dependency on Google Colab, no global variables, and no widget code. They are plain Python functions that accept arguments and return results.

The package is installed from GitHub in one line:

pip install git+https://github.com/perezjoan/UVLM.git

On Google Colab, this happens automatically in the first cell of the Colab notebook. On your local machine, you run it once in a terminal and you are done.

Nothing changed in how UVLM analyses images. The same 11 model checkpoints are supported (LLaVA-NeXT and Qwen2.5-VL, from 3B to 110B parameters). The same parsing logic, the same consensus validation, the same truncation detection. If you had a workflow built on v2.2.2, the outputs will be identical.

Google Colab — Zero Install

This is the same experience as before. Open the Colab notebook, select a GPU runtime, and start working. The notebook installs the UVLM package automatically. Images are loaded from Google Drive. Nothing has changed for Colab users, except that the code running behind the widgets is now cleaner and easier to maintain.

Local Jupyter Notebook — Your GPU, Your Data

If you have an NVIDIA GPU on your workstation (or access to a GPU server), you can now run UVLM locally. The local Jupyter notebook provides the same widget-based interface — model selection dropdown, prompt builder form, batch execution button — but images are read from your local filesystem and results are saved locally. No Google account needed, no data leaves your machine.

This matters for researchers working with sensitive imagery (medical, security, proprietary datasets) or for anyone who wants faster and more reliable model loading than what Colab’s network provides.

Python Script — Full Programmatic Control

For integration into larger pipelines, UVLM now exposes a clean API. Three lines of code replace the entire notebook workflow:

from uvlm import load_model, run_inference, parse_response
ctx = load_model("[Qwen] Qwen2.5-VL 7B Instruct", precision="4bit")
raw, tokens = run_inference("photo.jpg", "Count the cars", ctx)
result = parse_response(raw, "numeric")

The `load_model()` function returns a context dictionary containing the model, processor, backend type, and device information. This dictionary is passed to every subsequent function — no global state, no hidden side effects. You can load multiple models in the same session and switch between them by passing different context objects.

For batch processing, `run_batch()` handles the full pipeline:

from uvlm import load_model
from uvlm.batch import run_batch

ctx = load_model("[Qwen]  Qwen2.5-VL 7B Instruct", precision="4bit")
df = run_batch(
    model_ctx=ctx,
    task_specs=my_tasks,
    image_folder="./images",
    output_path="./results.csv",
)

The monolithic notebook has been split into eight modules, each with a single responsibility:

registry.py holds the model dictionary — 11 checkpoints with their backend type and HuggingFace checkpoint ID. Adding a new model is one line in a dictionary.

loader.py contains the `load_model()` function. It handles quantisation configuration (4-bit, 8-bit, FP16), device placement (single GPU, auto, CPU offload), and the LLaVA vs Qwen branching logic. It returns a dictionary — not a set of global variables.

inference.py contains `run_inference()`, the dual-backend forward pass. It accepts a model context dictionary and returns the raw response plus the exact token count as a tuple. The full LLaVA response cleaning logic and the full Qwen token-trimming pipeline are preserved exactly as they were.

parsers.py holds the four response parsers (numeric, category, boolean, text) and the advanced reasoning parser. These are pure functions with zero dependencies beyond Python’s standard library.

consensus.py contains the majority voting logic. batch.py handles folder iteration, CSV writing, resume mode, and schema upgrading. prompts.py stores the task type definitions and the chain-of-thought templates. utils.py provides seed management, environment detection, and HuggingFace token retrieval.

On Colab: Open the notebook from GitHub and run the three blocks as before. The package installs itself.

Locally: First, install PyTorch with CUDA support matching your GPU driver (check with `nvidia-smi`). For example, with CUDA 12.8+:

pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128
pip install git+https://github.com/perezjoan/UVLM.git

pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128
pip install git+https://github.com/perezjoan/UVLM.git

Then open the local Jupyter notebook.

You get the same dropdown menus, the same prompt builder form, the same batch execution. The only difference is that you type a local path for your image folder instead of a Google Drive path.

For HuggingFace authentication (needed for some gated models like LLaMA3-based checkpoints), either set the `HF_TOKEN` environment variable or run `huggingface-cli login` once in your terminal.

The package architecture makes it much easier to add new VLM families. InternVL, BLIP-2, CogVLM, DeepSeek-VL, and Molmo are planned for future releases — each one requires implementing the backend-specific sections of the inference function and adding entries to the registry, without touching the rest of the codebase.

We are also working on multi-GPU batching for parallel inference across images, video frame analysis support, and integration with the SAGAI workflow for automated streetscape analysis.

Source code: github.com/perezjoan/UVLM

Paper: arXiv preprint — Perez & Fusco (2026)

UVLM page on this site: urbangeoanalytics.com › Software & Algorithms › UVLM

Previous blog post: Introducing UVLM: A Free Tool to Compare AI Models That Understand Images

If you use UVLM in your work, please cite:

Perez, J. & Fusco, G. (2026). UVLM: A Universal Vision-Language Model Loader for Reproducible Multimodal Benchmarking. arXiv:2603.13893