granite-embedding-small-english-r2

Name: granite-embedding-small-english-r2
Author: ibm-granite

by ibm-granite

384-dimensional vectors from a 48M-parameter encoder that still reads 8,192 tokens

260Kdl/month

82likes

48Mparams

HuggingFace Run it on your own data, free

Identifiers

Model ID

ibm-granite/granite-embedding-small-english-r2

Feature URI

mixpeek://text_extractor@v1/ibm_granite_embed_small_english_r2

Deploy granite-embedding-small-english-r2

Single-tenant

Mixpeek has no managed extractor for this model. On a single-tenant deployment you upload the weights and a custom plugin serves them next to the rest of your pipeline.

Read the customer-hosted guide Talk to us about single-tenant

Overview

Most of what an embedding costs you is not the forward pass, it is the index. Storage, memory and query time all scale with the dimension, so a 384-d vector is a quarter of the footprint of a 1,536-d one over the same corpus. Granite Embedding R2 small pairs that small output with a ModernBERT backbone and an 8,192-token position limit, which is the combination that is usually unavailable: long-context encoders are normally large and wide. If your documents are long and your index is the line item you care about, this is the shape to look at first.

Architecture

ModernBERT encoder, 12 layers, 384-dimensional hidden state, 47,662,464 parameters in safetensors. CLS pooling rather than mean pooling, and an 8,192-token maximum position. English only, which is the trade that buys the size.

Mixpeek SDK Integration

# 384-d vectors, so the index is small. Declare the dimension when you
# create the collection: a vector index cannot be resized afterwards.
from sentence_transformers import SentenceTransformer
from mixpeek import Mixpeek

enc = SentenceTransformer("ibm-granite/granite-embedding-small-english-r2")
mx = Mixpeek(api_key="API_KEY")

vec = enc.encode(document_text, normalize_embeddings=True)

mx.documents.upsert(
    collection_id="col_your_collection",
    documents=[{
        "document_id": "policy-2026-h2",
        "payload": {"text": document_text, "source_key": "policies/2026-h2.pdf"},
        "vectors": {"text_embedding": vec.tolist()},
    }],
)

Capabilities

384-dimensional output, so the index is a quarter the size of a 1,536-d one
8,192-token context on a 48M-parameter model
Runs on CPU at a usable speed because of the parameter count
Apache-2.0, so commercial use is unambiguous

Use Cases on Mixpeek

Text retrieval over a corpus large enough that vector storage is the budget

Long documents you do not want to chunk aggressively, since the window absorbs them

A CPU-only retrieval tier where a GPU embedding service is not worth standing up

Frequently Asked Questions

Is a 384-dimensional vector worse than a 1,536-dimensional one?

Often, and not always, and the gap is smaller than the ratio suggests. Dimension buys capacity to separate near-identical meanings, which matters most on large and semantically dense corpora. Measure it on your own queries before paying for it, because a fourfold index saving is a real number and a recall difference of a point or two may not change any answer you serve.

Does the 8,192-token window mean I can stop chunking?

It means you can chunk less aggressively. A single vector still averages everything it read, so a long document embedded whole retrieves as a blur and cannot tell you where in itself the answer lives. Use the window to keep a section intact rather than to swallow a whole report.

Does Mixpeek run this model?

Not as a managed extractor. Embed with it yourself and upsert the vectors, or point a collection's text index at whichever encoder you already run. The dimension is the only thing the collection needs to agree with.