turintech/embeddinggemma-2-Artemis-GGUF

TurinTech models, built with Artemis

EmbeddingGemma 2 for search and retrieval on a CPU, compressed with Artemis

Download	Peak CPU memory	Recall@10, BEIR test
156.935 MB	0.339 GiB	0.6588 (Unsloth UD-Q4_K_XL 0.6427)

Run it

An embedding model: it turns a query or a document into a 768-dimensional vector for search and retrieval, served on llama-server's /v1/embeddings endpoint. It does not chat.

hf download turintech/embeddinggemma-2-Artemis-GGUF embeddinggemma-2-Artemis-Q4_K_S.gguf --local-dir .
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

Ollama: turintech/embeddinggemma-2-artemis on /api/embed, as in Run it  ·  LM Studio: turintech/embeddinggemma-2-artemis

llama-server here is llama.cpp at commit f3363593, built for the CPU as in the folded section below. Other llama.cpp builds and GPUs have not been checked with these files; Ollama and LM Studio were checked as described there. Queries take the prefix task: search result | query: and documents the form title: ... | text: ...; every result below was measured with them, mean pooling and inputs of at most 512 tokens.

Build the runtime, embed with Python, check the download, Ollama and LM Studio

On Linux x86-64, install Git, CMake, a C/C++ compiler and OpenMP development support with the system package manager (upstream build instructions at this commit). These are the source commit and CMake options of our CPU build; another compiler or CPU can give different binaries, and other platforms have not been checked. Run it in a directory without a llama-cpp-embeddinggemma2 folder:

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 CPU of the build machine, so the binaries may not run on another CPU.

Check the download against its checksum:

printf '%s  %s\n' f76351ba13988274750620577c88911b195a15321c37fc991bed485ed8f81f45 embeddinggemma-2-Artemis-Q4_K_S.gguf | sha256sum -c -

For the larger file, download embeddinggemma-2-Artemis-Q5_K_S.gguf by its exact name with the same hf download command; automatic Hugging Face imports have not been checked. With the server running, embed a query and a document from 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 files passed this two-input check on the CPU build above. The snippet keeps the first 512 tokens of a long text; the test run kept the first 511 and the end token, as sentence-transformers does.

Ollama (0.40.4 tested) serves the package on /api/embed. latest and q4_k_s hold the default file, q5_k_s the 182.04 MB file; both files passed a public pull, a full checksum and a two-input CPU embedding check. The retrieval numbers on this card come from llama.cpp, not Ollama.

ollama pull turintech/embeddinggemma-2-artemis:q4_k_s
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}
}'

This request runs on the CPU and rejects an input longer than the context instead of cutting it. Ollama lists both tags as Q4_K_M, a label the files inherit from their headers; the tags and checksums identify the files.

LM Studio (0.4.26 tested, CPU engine 2.64.0) loaded the Hub entry turintech/embeddinggemma-2-artemis with the default file on 25 October 2026, and its /v1/embeddings on port 1234 returned 768-dimensional vectors:

lms get turintech/embeddinggemma-2-artemis@q4_k_s --gguf

Results

File	Size	nDCG@10	Recall@10
TurinTech Q4_K_S	156.935 MB	0.5754	0.6588
TurinTech Q5_K_S	182.036 MB	0.5790	0.6538
Unsloth UD-Q4_K_XL	175.674 MB	0.5738	0.6427
FP32 original	n/a	0.5833	0.6541

Equal-weight means of SciFact (300 queries, 5,183 documents) and FiQA (648 queries, 57,638 documents): BEIR test queries, each ranked against its dataset's full corpus. The records of how the files were chosen do not mention these queries (How it was tested); bold marks the best in each column, not a tested difference. One gap holds after correcting for four planned tests: Recall@10 of our Q4_K_S over Unsloth's UD-Q4_K_XL (0.6588 against 0.6427, Bonferroni p 0.043). The default's nDCG@10 did not separate from Unsloth's file (0.5754 against 0.5738) or from the original (0.5833), and the plan did not test our Q5_K_S. Full results, memory and method.

Files

File	Size	Peak CPU memory	Use it for
embeddinggemma-2-Artemis-Q4_K_S.gguf	157 MB	0.339 GiB	Default: the smaller download, Ollama tag q4_k_s (latest)
embeddinggemma-2-Artemis-Q5_K_S.gguf	182 MB	0.359 GiB	Larger file with higher measured nDCG@10 than the default, Ollama tag q5_k_s

Text only. Smaller weights do not shrink the embedding index, which stores 768 values per text. The memory figures come from a 2,048-token context and batch; the 512-token settings in Run it were not measured. Peak CPU memory measured on AMD Ryzen 9 5900X, CPU only, 12 threads, llama.cpp f3363593 CPU build, -c 2048 -b 2048 -ub 2048 -np 1 --flash-attn off --no-warmup, peak resident memory over the 300 SciFact test queries in requests of up to 16, the memory-mapped file included.

Pick this model

• Good for search and retrieval on a CPU in a 156.935 MB download. On 948 test queries its Recall@10 was higher than that of Unsloth's 175.674 MB UD-Q4_K_XL (0.6588 against 0.6427), and its nDCG@10 did not separate from that file or the original.
• Pick another file when nDCG@10 matters more than download size: our Q5_K_S (182.036 MB) scored nDCG@10 0.5790 against the default's 0.5754 but Recall@10 0.6538 against 0.6588, and no planned test covers either gap.

How it was made

Built with Artemis, TurinTech's optimisation platform, from Google's EmbeddingGemma 2 at revision 914f7f8. Each file is a per-tensor mix of standard llama.cpp quant types, so the llama.cpp build above, Ollama and LM Studio load it as it is. Its label is a size class: the Q4_K_S file is smaller than a stock Q4_K_S file of this model, the Q5_K_S file smaller than a stock Q5_K_S. The tensor types and bits per weight are on the results page. Text only.

How it was tested

Every file in the Results table ran on one AMD Ryzen 9 5900X with no GPU (12 threads) on 27 and 28 October 2026: the GGUF files through llama-server at llama.cpp f3363593, the FP32 original through sentence-transformers, with the same prompts, 512-token cap, mean pooling and normalisation. The queries are all 948 BEIR test queries of SciFact and FiQA that have a relevance judgment, each ranked against the full corpus of its dataset. Before scoring, a BF16 conversion of the original on the same llama-server gave the same vectors as the FP32 original on 128 of the queries, to a worst cosine error of 8.3e-06.

Measured retrieval trade-offs

The files were chosen on a development panel of 96 queries from the train and dev relevance judgments of the same two datasets, with 1,024 of their documents. The records of how the files were chosen mention only that panel; they do not mention the test queries. On the development panel the default had a little lower Recall@10 than Unsloth's file (0.914856 against 0.920933); on the test queries it was higher (0.6588 against 0.6427), the one gap that holds after a Bonferroni correction over the four tests the run planned. nDCG@10 did not separate from Unsloth's file or from the original. The results page has the method, the scores per dataset, the paired tests, peak memory and the development panel.

Retrieval quality

The retrieval numbers from the tables on the results page, 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-beir-test-512-20261027

AMD Ryzen 9 5900X, CPU only, 27 and 28 October 2026.

• Reference: the original google/embeddinggemma-2 FP32 checkpoint (revision 914f7f89142e33e77833254d9c9b90c3cef7303b) through sentence-transformers 6.2.0 and PyTorch 2.14.1 on the same CPU, mean pooling, L2-normalised; it is not a GGUF. A BF16 GGUF conversion served by the same llama-server matched its vectors on 128 test queries (mean cosine error 2.9e-06, worst 8.3e-06)
• Panel test: BEIR SciFact and FiQA test queries, full corpora, equal-domain average; dataset: BEIR SciFact (BeIR/scifact at b3b5335604bf5ee3c4447671af975ea25143d4f5, judgments BeIR/scifact-qrels at 2938d17dc3b09882fdb8c12bbbe2e2dc0e75a029) and FiQA (BeIR/fiqa at 979c07a7cb5ccc6ca009792241fa1250b98055dd, judgments BeIR/fiqa-qrels at 252958f2d646e22cab6d0c72dd3f0d5de6d0655a); split: test relevance judgments (test.tsv); every query with at least one positive judgment; queries: 948 (SciFact 300, FiQA 648); documents: 62,821, the full corpora (SciFact 5,183, FiQA 57,638); text SHA-256: 37688fe561f82a27b54e556d1e3b41b5d340df3ead021039d7c9681cb052c41f (SHA-256 of the panel file; content digest 904fd90350ab83bcd1edc11aa893353f3352bbbc59583b24385d0ab32f54e4eb)
• Tool: llama-server /v1/embeddings for the GGUF files, each text sent as the server's own token ids; cosine ranking within each dataset (ties by ascending document id), linear-gain nDCG@10 and Recall@10, averaged equally over SciFact and FiQA
• llama.cpp build: commit f3363593f457169cdfbdfe22ea399b1cc139ba18, CPU build from source (its version line reads build 1, commit f336359)
• Command: llama-server -m <file.gguf> --embeddings --pooling mean --embd-normalize 2 -ngl 0 -t 12 (the flags the run record lists), 16 texts per request
• Hardware: AMD Ryzen 9 5900X 12-Core Processor, 12 threads, no GPU
• Settings: 512-token cap (a longer text keeps its first 511 tokens and the end token, as sentence-transformers cuts it; 2,890 of the 63,769 texts reached the cap), mean pooling including prompts, query prefix task: search result | query: , documents as title: <title, or none> | text: <text>
• Measured by: TurinTech measured every GGUF file in this table, including Unsloth's UD-Q4_K_XL, the same way on the same machine, each once, and the original through sentence-transformers on that machine; the GGUF files measured are the published ones
• Selection: the records of how the files were chosen do not mention these test queries; the files were chosen on the development panel of protocol cpu-dev-panel-512-20261016, whose documents come from the same two corpora
• Source, on the results page: 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-beir-test-512-20261027, panel test (BEIR SciFact and FiQA test queries, full corpora, equal-domain average):

File	Repository	Measured by	Size (MB)	Size (bytes)	nDCG@10	Recall@10
FP32 original	google/embeddinggemma-2 at 914f7f89142e	reference	n/a	n/a	0.5833	0.6541
embeddinggemma-2-Artemis-Q4_K_S.gguf	turintech/embeddinggemma-2-Artemis-GGUF at 8748160053b5	TurinTech	156.935	156935264	0.5754	0.6588
embeddinggemma-2-Artemis-Q5_K_S.gguf	turintech/embeddinggemma-2-Artemis-GGUF at 8748160053b5	TurinTech	182.036	182035552	0.5790	0.6538
embeddinggemma-2-UD-Q4_K_XL.gguf	unsloth/embeddinggemma-2-GGUF at 031f0d4b3553	TurinTech	175.674	175673856	0.5738	0.6427

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
• 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 GGUF 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, so it favours them; it is not an independent test or a full MTEB evaluation
• Source, on the results page: the table columns "nDCG@10, development panel", "Recall@10, development panel"
• 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):

File	Repository	Measured by	Size (MB)	Size (bytes)	nDCG@10	Recall@10
FP32 original	google/embeddinggemma-2 at 914f7f89142e	reference	n/a	n/a	0.856404	0.928224
embeddinggemma-2-Artemis-Q4_K_S.gguf	turintech/embeddinggemma-2-Artemis-GGUF at 2f1be8eeab0f	TurinTech	156.935	156935264	0.859481	0.914856
embeddinggemma-2-Artemis-Q5_K_S.gguf	turintech/embeddinggemma-2-Artemis-GGUF at 2f1be8eeab0f	TurinTech	182.036	182035552	0.872079	0.928224
embeddinggemma-2-UD-Q4_K_XL.gguf	unsloth/embeddinggemma-2-GGUF at 031f0d4b3553	TurinTech	175.674	175673856	0.857125	0.920933

File checksums

File	Bytes	sha256
embeddinggemma-2-Artemis-Q4_K_S.gguf	156,935,264	f76351ba13988274750620577c88911b195a15321c37fc991bed485ed8f81f45
embeddinggemma-2-Artemis-Q5_K_S.gguf	182,035,552	476a432281b3c9c8f16b5286bbe1aa482357e4b15fe69c3f8008ade36fd8f381

---

Artemis is TurinTech's optimisation platform: teams use it to make their own models smaller and faster, or to optimise their code.

All our models · LinkedIn · Questions and requests

_{Apache 2.0, as released by Google (licence); see LICENSE and NOTICE. An independent TurinTech release, not affiliated with or endorsed by Google. When serving these files to others, for example through an API, an inference provider or OpenRouter, we'd appreciate a mention of TurinTech (turintech.ai) as the source of the quantization.}

These files keep improving.