# LFM2.5-VL-3B: visual processors as release artifacts

LFM2.5-VL-3B's visual processor is part of the effective release artifact, because the same source image can become different evidence before model execution.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-12
Original announcement: https://www.liquid.ai/blog/lfm2-5-vl-3b
Canonical URL: https://retrivium.ai/retrospectives/retro-liquid-vl3b-vision-processor/

LFM2.5-VL-3B's visual processor is part of the effective release artifact, because the same source image can become different evidence before model execution.

## The image is not the tensor

An uploaded file is a source artifact. The model consumes a prepared representation with particular dimensions, ordering and transformation choices. Preserving the file while changing those choices does not preserve the effective input, even if the application still displays the original image beside the answer.

## The August model boundary

The [visual release](https://www.liquid.ai/blog/lfm2-5-vl-3b) combines a text backbone with a visual path. The earlier [hybrid model](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact model](https://www.liquid.ai/blog/lfm2-5-230m) establish preceding family context, not a universal image processor. A text-family relationship cannot determine the correct preprocessing of a separately introduced visual artifact.

The relevant configuration therefore includes both weights and input preparation. Treating the processor as an incidental library detail makes a historical evaluation incomplete: a later reader can obtain the same image and model while still executing a different task representation.

## A small-label example

Consider a photograph containing a small serial label. A resize or crop can remove characters before the visual encoder receives the image. An incorrect extracted code then does not immediately establish a failure of the language backbone or an inability to follow the question.

| Recorded artifact | Diagnostic question |
| --- | --- |
| Original image | Was the relevant detail present in the supplied source? |
| Prepared image representation | Did the transformation preserve that detail for inference? |
| Final response | Did the answer remain grounded in the effective evidence? |

## Comparing implementations

If two runtimes return different answers, first identify whether their visual preparation matches. A difference can be intentional, such as a different supported path, or accidental, such as using a processor revision that does not belong with the selected artifact. Neither explanation follows from the output alone.

Retain enough preparation metadata to reproduce the effective input. If the implementation does not expose it, state that limitation. An unknown preprocessing path should remain unknown rather than being treated as identical merely because both systems accept the same image file type.

## The retrospective consequence

The release's practical meaning includes a new route from pixels to a generated answer. That route cannot be reduced to the text checkpoint or inferred from a generic visual-model label.

The conclusion is to version the processor with the model. Doing so makes visual comparisons interpretable and prevents a preprocessing change from being misreported as an unexplained change in model quality. It also gives the operator a concrete place to investigate before changing the prompt or replacing the entire model.

Further analysis: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/); [GPU hosting for multimodal models: count more than text](/journal/multimodal-gpu-hosting/).