What Granite Vision 3.3 2B Embedding is
Granite Vision 3.3 2B Embedding is an open-weight multimodal embedding model provided by IBM through the Granite model family. Its specific role is to find relevant visual documents or document pages in response to a text query. It is not intended to write answers, hold conversations, generate images, or act as a general-purpose assistant.
The model is designed for pages such as reports, presentation slides, manuals, invoices, scanned documents, charts, tables, and infographics. These documents often contain meaning in both their words and their visual arrangement. A table's row and column relationships, the location of a chart legend, or the structure of a slide can be important to retrieval even when the raw text is available.
IBM distributes the model as an open-weight model under the Apache 2.0 license. The canonical model repository is ibm-granite/granite-vision-3.3-2b-embedding on Hugging Face. It is based on Granite Vision 3.3 2B and occupies a specialized position within the Granite Vision family: it is an embedding extractor for retrieval rather than a prose-producing version of the model.
How its multi-vector retrieval works
Many embedding systems compress an entire document or query into one vector. Granite Vision 3.3 2B Embedding instead produces a collection of vectors for an image or page. This is commonly described as a ColBERT-style or ColPali-style late-interaction design.
The model projects its hidden representations into 128-dimensional document and query embeddings. A page can produce up to 729 embedding vectors. Each vector can represent a different token-level or visual region, allowing a query to match specific parts of a page rather than depending only on one global summary.
During retrieval, a system compares the query and page vectors using a MaxSim-based scoring method. In simple terms, the system looks for strong matches between individual query representations and the most relevant page representations, then combines those matches into a document score. This approach can preserve more fine-grained information about mixed text-and-image pages than a single pooled embedding.
The model card describes the embeddings as L2-normalized. Applications still need to build the surrounding retrieval system: image preprocessing, index storage, candidate search, late-interaction scoring, and any reranking or answer-generation stage. The embedding model supplies representations; it does not by itself return a natural-language answer.
Supported inputs and outputs
The documented inputs are English text instructions or queries and PNG or JPEG images. In a typical workflow, a user query is encoded as text and each document page is rendered or supplied as an image. The resulting representations can then be compared in a multimodal search index.
| Capability | Documented behavior |
|---|---|
| Text input | English text queries or instructions |
| Image input | PNG and JPEG document images |
| Embedding output | Normalized, token-level multi-vector representations |
| Embedding dimensions | 128 dimensions for document and query projections |
| Vectors per image | Up to 729 embedding vectors |
| Text generation | Not supported as the model's intended output |
| Image, audio, and video generation | Not supported |
The model has a listed language context configuration of 131,072 tokens. That is a configuration value for the underlying language component, not a promise that every document image or retrieval workflow can use that many tokens effectively. The supplied research does not specify a separate maximum generated-output limit because the model is an embedding extractor rather than a text-generation model.
Where the model is most useful
Granite Vision 3.3 2B Embedding is a good fit when document relevance depends on visual structure as well as readable text. Suitable applications include:
- Searching enterprise reports, presentations, manuals, invoices, and scanned pages.
- Retrieving charts, tables, diagrams, or infographics in response to natural-language questions.
- Building multimodal retrieval-augmented generation systems over visual document collections.
- Combining visual retrieval with a conventional text-based retriever.
- Creating ColBERT-style indexes that preserve multiple matching regions per page.
For example, a query about quarterly revenue could retrieve a page because it contains a relevant chart and legend, even if the page's extracted text does not express the relationship as a simple sentence. Similarly, a query about a maintenance procedure may benefit from matching both instructions and the associated diagram.
Technical profile and reported evaluations
The underlying architecture uses a SigLIP-based vision component together with a Granite language backbone. The configuration describes a 384-pixel patch size and variable image grids for image processing. These details support the model's visual-document focus, although the practical resource requirements will depend on the serving environment and the way images are prepared.
IBM's model card reports average NDCG@5 scores of 57.7 on ViDoRe V2 and 83 on REAL-MM-RAG in published comparisons. These are provider-reported benchmark results, not guarantees for a particular collection. Retrieval quality can vary with document types, image resolution, query wording, indexing choices, and the scoring pipeline used around the model.
Limitations and deployment considerations
The most important limitation is that this is not an answer-generation model. It will not directly explain why a page was retrieved or produce a final response for a user. A complete application normally needs a retrieval index and a separate generation or extraction component after retrieval.
Its multi-vector output also creates more demanding infrastructure requirements than a conventional single-vector embedding. An index must store multiple vectors per page and support late-interaction scoring. With up to 729 vectors per image, storage, memory use, indexing time, and query-time computation should be measured against the size of the intended collection.
The repository requires Transformers custom code, and the supplied research identifies local deployment through feature-extraction workflows rather than a first-party managed inference service. There is no verified hosted API price or per-token pricing for this exact model. Consequently, the total cost depends on selected hardware, image-processing throughput, storage, and serving infrastructure. The editorial speed score of 7 and cost score of 9 describe an assessment of a locally deployable open-weight model; they are not IBM-published benchmarks or prices.
The model supports English text queries according to the supplied documentation. The research does not verify broader language coverage, audio input, video input, function calling, tool use, streaming, fine-tuning, caching, or structured JSON output. Those capabilities should not be assumed from its multimodal input support.
When to choose this model
Choose Granite Vision 3.3 2B Embedding when visual document retrieval is the central requirement and you can operate the indexing and scoring infrastructure yourself. It is especially appropriate when OCR-only search misses tables, page layout, charts, diagrams, or other visual signals, and when an open-weight Apache 2.0 model is preferable to a managed retrieval service.
It may be a better option than a single-vector text embedding model when page-level detail matters. It can also complement a conventional text retriever: text search can provide inexpensive broad candidate retrieval, while this model can supply visual matching for pages where layout and graphics are important.
Another option may be more appropriate when the application needs a hosted per-token API, direct natural-language answers, conversational behavior, coding assistance, function calling, or very simple low-storage vector search. A conventional text embedding model may be easier to deploy when documents are already cleanly represented as text and visual layout adds little retrieval value. Likewise, a general vision-language generation model is more suitable when the system must inspect a page and produce a written answer rather than only rank relevant pages.
Position in the Granite Vision catalog
This model belongs to the Granite Vision line but should be evaluated as a dedicated retrieval component, not as a replacement for every other Granite Vision use case. Its relationship to Granite Vision 3.3 2B is explicit: the embedding model is based on that model and adds a projection layer for retrieval-oriented representations. The supplied catalog information also indicates that newer Granite Vision family members exist, while this exact embedding model remains separately identifiable and downloadable.
That positioning makes the model's trade-off clear. It focuses its output format and architecture on detailed visual search, accepting the operational complexity of multi-vector indexing in exchange for retrieval that can account for page regions and document structure.