Feature Extraction
Transformers
Safetensors
sentence-transformers
multilingual
embedding_gemma2
embedding
multimodal-embedding
multimodal
vision
audio
video
image-feature-extraction
audio-feature-extraction
video-feature-extraction
sentence-similarity
Instructions to use google/embeddinggemma-2 with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use google/embeddinggemma-2 with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("feature-extraction", model="google/embeddinggemma-2")# pip install -U transformers accelerate # Load model directly from transformers import AutoProcessor, AutoModel processor = AutoProcessor.from_pretrained("google/embeddinggemma-2") model = AutoModel.from_pretrained("google/embeddinggemma-2", device_map="auto") - sentence-transformers
How to use google/embeddinggemma-2 with sentence-transformers:
from sentence_transformers import SentenceTransformer model = SentenceTransformer("google/embeddinggemma-2") sentences = [ "The weather is lovely today.", "It's so sunny outside!", "He drove to the stadium." ] embeddings = model.encode(sentences) similarities = model.similarity(embeddings, embeddings) print(similarities.shape) # [3, 3] - Notebooks
- Google Colab
- Kaggle
Built a local knowledge layer for macOS with EmbeddingGemma 2 + MCP
#6
by robyroy - opened
I built a local semantic search layer for macOS using EmbeddingGemma 2, with an MCP interface so tools like ChatGPT and Codex can query local knowledge directly.
The goal is simple: make local files searchable by meaning, not just by filename or exact keywords.
https://github.com/Podcast72/local-knowledge-layer
Wouldn't this double the requirement for storage bruh
hi bro... Not really. The system does not duplicate the original files.
The source documents stay exactly where they are on disk. The local knowledge layer only stores an index containing:
- embedding vectors
- file paths / document IDs
- chunk offsets and small metadata
So the additional storage is proportional to the number of chunks Γ embedding dimension, not to the size of the original corpus.
For example, a 768-dimensional vector stored as float16 is about 1.5 KB per chunk. Even 100,000 chunks would be roughly 150 MB of raw vectors, plus index/metadata overhead β nowhere near another full copy of a multi-GB document collection.
The EmbeddingGemma model itself is a fixed local dependency, so that's a one-time storage cost, not something that grows with the corpus.
You could store extracted text/chunks as a cache, but that's optional. In the minimal design, the index can simply point back to the original file and retrieve the relevant section when needed.
So architecturally it's:
original files β embeddings/index β references back to original files
not:
original files β duplicate copy β embeddings
That's one of the reasons I wanted to keep it as a lightweight local knowledge layer rather than a full duplicated document store.
ohh yeah fair enough. then well... lemme say bye to spotlight rq