turintech/embeddinggemma-2-Artemis-GGUF

TurinTech models, built with Artemis

Google's EmbeddingGemma 2 for search and retrieval on a CPU: it turns text into 768-dimensional vectors through llama.cpp's /v1/embeddings endpoint.

• 156.935 MB download for the default file, embeddinggemma-2-Artemis-Q4_K_S.gguf.
• Tested on a Linux CPU with four threads and a 512-token input cap.
• nDCG@10 0.859481, against 0.857125 for Unsloth's Q4 (175.674 MB), from a file 10.67% smaller. This development panel also chose the files.

Run it

An embedding model: llama.cpp serves its vectors on /v1/embeddings, not chat. The commands below select the exact compact file. The local files passed the CPU interface checks described below.

set -e
hf download turintech/embeddinggemma-2-Artemis-GGUF \
  embeddinggemma-2-Artemis-Q4_K_S.gguf --local-dir ./embeddinggemma-2-artemis
cd ./embeddinggemma-2-artemis
printf '%s  %s\n' f76351ba13988274750620577c88911b195a15321c37fc991bed485ed8f81f45 embeddinggemma-2-Artemis-Q4_K_S.gguf | sha256sum -c -

Runtime build, server, requests and Ollama Build the pinned CPU runtime

On Linux x86-64, install Git, CMake, a C/C++ compiler and OpenMP development support using your system's package manager. The source commit and CMake options below match our successful CPU build. This is a source-build path, not a prebuilt binary download; your compiler and CPU can produce different binary bytes. Other platforms have not been checked here. See the upstream build instructions at this commit for dependencies.

Run in a directory where llama-cpp-embeddinggemma2 does not already exist:

set -e
mkdir llama-cpp-embeddinggemma2
git -C llama-cpp-embeddinggemma2 init
git -C llama-cpp-embeddinggemma2 remote add origin https://github.com/ggml-org/llama.cpp.git
git -C llama-cpp-embeddinggemma2 fetch --depth 1 --no-tags origin f3363593f457169cdfbdfe22ea399b1cc139ba18
git -C llama-cpp-embeddinggemma2 checkout --detach f3363593f457169cdfbdfe22ea399b1cc139ba18
cmake -S llama-cpp-embeddinggemma2 -B llama-cpp-embeddinggemma2/build \
  -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=OFF -DGGML_NATIVE=ON \
  -DGGML_OPENMP=ON -DGGML_BLAS=OFF -DLLAMA_CURL=OFF
cmake --build llama-cpp-embeddinggemma2/build --target llama-server llama-quantize -j 4
export PATH="$PWD/llama-cpp-embeddinggemma2/build/bin:$PATH"
llama-server --version

Keep the build directory and its libraries together. GGML_NATIVE=ON targets the build machine's CPU; do not assume its binaries run on a different CPU.

With that build on PATH and the current directory containing the downloaded GGUF, run:

llama-server -m embeddinggemma-2-Artemis-Q4_K_S.gguf \
  --embeddings --pooling mean --embd-normalize 2 \
  -ngl 0 -t 4 -tb 4 -c 512 -b 512 -ub 512 -np 1 \
  --flash-attn off --host 127.0.0.1 --port 8080 --no-warmup

Use embeddinggemma-2-Artemis-Q5_K_S.gguf for the larger alternative. Download the larger file explicitly with the same hf download command and its exact filename. Automatic Hugging Face import defaults remain unverified. These commands follow the repository head. Verify the downloaded file against the checksum below.

Embed a query and document with Python

The prefixes, special tokens and 512-token cap match the measured path. Run this in another terminal:

import json
import urllib.request

def post(path, data):
    request = urllib.request.Request(
        "http://127.0.0.1:8080" + path,
        data=json.dumps(data).encode(),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(request, timeout=30) as response:
        return json.load(response)

texts = [
    "task: search result | query: How does photosynthesis work?",
    "title: Photosynthesis | text: Plants use light energy to convert carbon dioxide and water into sugars.",
]
for text in texts:
    tokens = post("/tokenize", {"content": text, "add_special": True})["tokens"][:512]
    vector = post("/v1/embeddings", {
        "input": tokens, "encoding_format": "float", "embd_normalize": 2,
    })["data"][0]["embedding"]
    print(len(vector))  # 768 for each input

Both final files passed this two-input CPU interface check with llama.cpp f3363593f457169cdfbdfe22ea399b1cc139ba18. It is an embedding endpoint, not a chat model. This check does not establish performance or support in other runtimes.

Ollama

Native Ollama packages are available. Pull the exact recommended variant:

ollama pull turintech/embeddinggemma-2-artemis:q4_k_s

Embed a query and document with Ollama

curl http://localhost:11434/api/embed -H 'Content-Type: application/json' -d '{
  "model": "turintech/embeddinggemma-2-artemis:q4_k_s",
  "input": [
    "task: search result | query: How does photosynthesis work?",
    "title: Photosynthesis | text: Plants use light energy to convert carbon dioxide and water into sugars."
  ],
  "truncate": false,
  "options": {"num_ctx": 512, "num_thread": 2, "num_gpu": 0}
}'

Keep the query/document prefixes and replace the text after them. This request uses CPU execution and rejects inputs exceeding the context instead of silently truncating them.

latest and q4_k_s select the compact file; q5_k_s selects the 182.04 MB alternative. Both current files passed public-pull, full-checksum and two-input CPU embedding checks in Ollama 0.40.4. The new larger file was checked after its tag was updated; the compact file and default alias are unchanged. No chat, GPU, speed or retrieval-quality claim through Ollama is made.

The existing Ollama packages display the inherited broad Q4_K_M metadata label, including in Ollama's runtime listing. Their payloads differ: the exact tags and file checksums identify the intended mixed-quantization artifacts.

Choose this model

• Best for search and retrieval where a small download matters.
• Consider another file when you want the best measured retrieval: our Q5_K_S (182.04 MB) has higher nDCG and Recall than Unsloth Q4. The default's Recall@10 is 0.914856, against 0.920933 for Unsloth's Q4.

Files

Every file we publish for this model. Sizes are download sizes, not memory.

• With llama.cpp or a Hugging Face pull, add the file's quant label as the tag: -hf turintech/embeddinggemma-2-Artemis-GGUF:Q4_K_S.
• The Ollama tag pulls our package, which holds the same file: ollama pull turintech/embeddinggemma-2-artemis:<tag>.
• LM Studio's Hub entry turintech/embeddinggemma-2-artemis offers every model file above.

Smaller weights do not shrink the embedding index.

Results

Our two files against Unsloth's Q4 file and the original, on 96 queries and 1,024 documents from SciFact and FiQA. This development panel was used to choose the files.

The default is the smallest file and gives up a little Recall@10 against Unsloth's Q4. Peak RAM and GPU compatibility are not established yet. How it was tested.

Measured retrieval trade-offs

Measured retrieval trade-offs

The recommended compact candidate is 156.94 MB, 10.67% smaller than the measured Unsloth Q4 file. On our exposed development panel, nDCG@10 was 0.236 percentage points higher and Recall@10 was 0.608 points lower. It offers a smaller download with a measured retrieval trade-off.

A 182.04 MB alternative has higher measured nDCG and Recall than Unsloth Q4 on the same panel, at a larger file size. Neither candidate has a confirmed speed or runtime-memory advantage. Both produce 768-dimensional text embeddings; smaller weights do not shrink the embedding index.

96 queries and 1,024 documents across SciFact and FiQA; equal-domain averages, 512-token cap, mean pooling and normalized 768-dimensional vectors. This development panel was used to select candidates. It is not an independent test or full MTEB evaluation.

Bold marks the best displayed value in each column, not statistical significance. The larger candidate's measured gains over Unsloth Q4 are 1.50 percentage points in nDCG and 0.73 points in Recall; it is 3.62% larger. Small sampled-panel differences do not establish broad superiority. The compact candidate had one timing-comparable observation; that does not establish a reliable speed advantage. The larger candidate had one timing-comparable observation: query latency was 6.94% higher than the paired Unsloth control, while document throughput was 1.64% higher. This is not a speedup claim. No independent confirmation has been completed.

Quantization labels and file size

Q4_K_S and Q5_K_S are size classes in a measured standard K-quant ladder made from the same BF16 parent and quantizer build. They do not describe stock tensor recipes or rank quality. The compact file fits below the 178,164,000-byte stock Q4_K_S reference; the larger file fits below the 210,669,856-byte stock Q5_K_S reference. Intermediate K classes were checked; IQ formats were not part of this naming ladder.

The compact file mixes Q3_K, Q4_K, BF16 and F32; the larger file mixes Q4_K, Q5_K, BF16 and F32. Whole-file bits per weight are 4.632730 and 5.373691, respectively; tensor-payload values are 4.166577 and 4.907537. Both files include about 15.79 MB of metadata and alignment. Their inherited general.file_type headers still read Q4_K_M; the exact filenames select the intended files.

Retrieval quality

The retrieval numbers from the tables above, in one fixed layout with the protocol behind each table. nDCG@10 and Recall@10 score the ranking against the panel's relevance labels; higher is better.

Protocols and standard tables

n/a means the card's tables or our run records do not have that value.

Protocol cpu-dev-panel-512-20261016

Four CPU cores, 16 October 2026.

• Reference: the original google/embeddinggemma-2 FP32 checkpoint (revision 914f7f89142e33e77833254d9c9b90c3cef7303b), mean pooling, L2-normalised; it is not a GGUF
• Panel dev: BEIR SciFact and FiQA development panel, equal-domain average; dataset: BEIR SciFact and FiQA; split: development queries from the train and dev relevance judgments; queries: 96 (48 per domain); documents: 1,024 (512 per domain); text SHA-256: 097270111c4e6a70cdf602a8416897bdb393c0bebdddf1ec7c6fcf29b2487cb1 (SHA-256 of the panel file)
• Tool: llama-server /v1/embeddings for the GGUF files; nDCG@10 and Recall@10 from dot-product ranking of the normalised 768-dimensional vectors, averaged equally over the SciFact and FiQA domains
• llama.cpp build: commit f3363593f457169cdfbdfe22ea399b1cc139ba18
• Command: llama-server -m <file.gguf> --embeddings --pooling mean --embd-normalize 2 -ngl 0 -t 4 -c 2048 -b 2048 -ub 2048 -np 1 --flash-attn off, inputs capped at 512 tokens by our harness (the card's 512-token run command is for interface checks, not this measurement)
• Hardware: four CPU cores, no GPU
• Settings: 512-token input cap, mean pooling including prompts, query prefix task: search result | query: , documents as title: ... | text: ...
• Measured by: TurinTech measured every file in this table, including Unsloth's UD-Q4_K_XL, the same way on the same machine. Our numbers were measured on the raw quantizer outputs; the published files change only header metadata, with identical tensors
• Selection: this development panel was used to choose the files; it is not an independent test or a full MTEB evaluation
• Source on this card: the table columns "nDCG@10", "Recall@10"
• Comparison files: Unsloth: unsloth/embeddinggemma-2-GGUF at 031f0d4b3553, embeddinggemma-2-UD-Q4_K_XL.gguf, SHA-256 ea905fd08e8061db77a0031cbb5096d459d7cfd2bdd0ad2ba66e483f16719493

Protocol cpu-dev-panel-512-20261016, panel dev (BEIR SciFact and FiQA development panel, equal-domain average):

Artifact checks and sources

Both raw files rebuilt to their measured SHA-256 identities. Each cleaned copy preserves all 413 tensor payloads and all inference metadata; only the display name and modality tags changed. Both final files returned finite, normalized vectors through the CPU endpoint. No GPU or multimodal result is claimed; the separate Ollama CPU interface checks are described above. MB are decimal file sizes, not memory requirements.

Original: google/embeddinggemma-2 at 914f7f89142e33e77833254d9c9b90c3cef7303b. Comparator: unsloth/embeddinggemma-2-GGUF at 031f0d4b35536f69ab3509d4893c923264fcf253, file embeddinggemma-2-UD-Q4_K_XL.gguf (175,673,856 bytes).

The earlier 151 MB and 154 MB candidates remain in the dated research record. This compact candidate has higher measured nDCG and Recall than both, at a slightly larger file size.

Changes

16 October 2026: updated the larger Q5_K_S file from 201.17 MB to 182.04 MB, with higher observed nDCG and Recall on the same development panel. The compact default is unchanged. The previous larger file and previous card remain available at their original revision.

These files keep improving.

About and licence

Original model by Google; public GGUF comparison by Unsloth. Both candidates use Artemis compression recipes. Apache License 2.0 applies; see LICENSE and NOTICE.