Llama 3.2 split its ambitions between vision and small devices

The Llama 3.2 family arrived with different models for different jobs. The announcement covered 11B and 90B vision variants alongside 1B and 3B text-only variants. It also introduced related safeguard models and Hugging Face integrations for inference and fine-tuning.

The useful distinction is between adding a new input modality and reducing a deployment footprint. The small text models do not inherit all the capabilities of the vision models. Choosing a family name alone is not enough; the exact checkpoint determines what an application can do.

Follow the original guide to the relevant model card, then confirm input support, memory requirements, and license terms for that checkpoint. A local text assistant and an image-question-answering service should not start from the same default assumption.

Small text models and visual models serve different constraints

A model family can contain variants aimed at different deployment settings. A compact text model may be attractive for a narrow local task, while a visual model introduces a different input pipeline and resource budget. Treating the family as one interchangeable object makes model selection unnecessarily vague.

Begin with the application’s required inputs and outputs. A device-side command classifier, a writing helper and an image-questioning tool should each have their own success criteria and test collection.

Verify the exact checkpoint contract

Use the tokenizer, processor and message format expected by the selected model. A familiar family name does not guarantee that every variant takes the same inputs or supports the same task. Keep the checkpoint revision and preprocessing configuration attached to the application.

Run a small set of known examples before integrating additional tools or retrieval. This establishes what the base model can do and helps locate failures introduced by the surrounding system.

Evaluate narrow tasks honestly

For a small text model, a focused task with a clear output contract can be more useful than an open-ended assistant interface. Test ambiguous requests and missing information as well as ordinary cases. A model that always produces an answer may be less reliable than one that can signal a limitation.

For visual tasks, compare the answer with visible evidence. Include images where the requested detail is absent or unclear, and avoid accepting plausible guesses as correct observations.

Measure the complete device experience

Record download size, load time, memory and latency under realistic inputs. Weight size alone does not include context-related memory or application overhead. Repeated use and concurrent requests can expose constraints that a one-shot demonstration misses.

Provide clear limits and a cancellation path. A user should not have to close an entire application because a model request is taking too long or has become irrelevant.

Keep deployment choices reversible

Compare the candidate with the current system using the same task examples. Preserve a known-good configuration while evaluating the change, and keep model-specific usage terms in the selection process. Access to weights is not a substitute for reviewing the conditions of the intended use.

The useful opportunity in a varied model family is flexibility. A team can choose a task-sized configuration rather than adopting the largest available model by default. The reliable choice is the one whose input contract, quality and operating requirements are understood well enough to support a real feature, including the cases where the model should not pretend to know the answer.