Loading
Vous avez un workflow ComfyUI ? Obtenez une documentation lisible directement dans votre navigateur.Rendre un workflow lisible.Essayer maintenant ↗
> [!WARNING] > Fork compatibility (2026-07-07): the llama-cpp-turboquant fork is currently based on a llama.cpp revision that predates gemma4 architecture support — it fails with unknown model architecture: 'gemma4'...
Source du modèle
Description de la source
[!WARNING] Fork compatibility (2026-07-07): the
llama-cpp-turboquantfork is currently based on a llama.cpp revision that predatesgemma4architecture support — it fails with and cannot run this model at all. Until the fork rebases, use (which loads this GGUF fine with standard KV-cache types); the RotorQuant/TurboQuant KV-cache options are not usable with gemma-4 yet.
Sources
1 sourceVérifié 18 sept.
Artefacts du modèle
1 artefactgemma-4-E4B-RotorQuant-Q8_0.gguf
gguf · 7,48 GB · SHA-256 6ce4efb80568…5b07 · Hugging Face
TéléchargerExtraits de sources
2 extraits
unknown model architecture: 'gemma4'[!TIP] KV-cache quantization without any fork (recommended, 2026): upstream llama.cpp/Ollama now cover this natively — use
-ctk q8_0 -ctv q8_0(~half KV memory, negligible quality loss: perplexity +0.002–0.05) or-ctk q4_0 -ctv q4_0(~quarter memory, ≈7.6% perplexity increase). In Ollama:OLLAMA_KV_CACHE_TYPE=q8_0withOLLAMA_FLASH_ATTENTION=1. Keep K and V types symmetric to stay on the fast fused Flash-Attention path. Since April 2026, mainline llama.cpp also applies Hadamard rotation to KV activations (PR #21038), which greatly improves low-bit KV quality (opt-out:LLAMA_ATTN_ROT_DISABLE=1).The RotorQuant/TurboQuant fork flow below is experimental/legacy: the TurboQuant llama.cpp PR was closed without merging (June 2026) and the fork is unmaintained relative to mainline. It is NOT required to use this model.
GGUF Q8_0 weight-quantized variant of google/gemma-4-E4B optimised for use with RotorQuant KV cache compression via a dedicated llama.cpp fork.
Important: RotorQuant KV cache types (
planar3,iso3) are not available in upstream llama.cpp, standard Ollama, or LM Studio. They require a specific llama.cpp fork. The GGUF file itself is a standard GGUF and works with any llama.cpp-compatible runtime using normal KV cache types (f16, q8_0, q4_0, etc.).
| Device | VRAM / RAM | Recommendation |
|---|---|---|
| CPU host with ≥8 GB RAM | ~4.4 GB | works via llama.cpp; slower than GPU but no accelerator required |
| Apple Silicon (Metal) | ~4.8 GB | llama.cpp Metal backend; fast on M-series unified memory |
| NVIDIA GPU (partial offload) | split between GPU + RAM | offload as many layers as VRAM allows; rest on CPU |
This model combines two independent compression techniques:
| Technique | What it does | Requirement |
|---|---|---|
| GGUF Q8_0 weight quantization | Reduces model size from ~8 GB (BF16) to ~4.0 GB | Any llama.cpp-compatible runtime |
RotorQuant KV cache compression — block-diagonal Clifford-algebra rotors for 3-bit KV cache (--cache-type-k iso3 --cache-type-v iso3) | Block-diagonal rotations / random rotation for compressed KV cache | llama-cpp-turboquant fork only |
You must build from the RotorQuant-enabled llama.cpp fork:
# Clone and build the fork
git clone https://github.com/johndpope/llama-cpp-turboquant.git
cd llama-cpp-turboquant && git checkout feature/planarquant-kv-cache
# CUDA (Windows/Linux)
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release && cmake --build build -j
# Metal (Apple Silicon)
cmake -B build -DGGML_METAL=ON -DGGML_METAL_EMBED_LIBRARY=ON -DCMAKE_BUILD_TYPE=Release && cmake --build build -j
# Run with RotorQuant KV cache
./build/bin/llama-cli -m gemma-4-E4B-RotorQuant-GGUF-Q8_0.gguf \
--cache-type-k iso3 --cache-type-v iso3 \
-ngl 99 -fa \
-p "Explain quantum computing"
# Or run as a server
./build/bin/llama-server -m gemma-4-E4B-RotorQuant-GGUF-Q8_0.gguf \
--cache-type-k iso3 --cache-type-v iso3 \
-ngl 99 -fa --jinja
The GGUF works as a normal quantised model. You won't get RotorQuant-specific KV cache benefits, but standard KV cache quantization (q8_0, q4_0) still reduces VRAM significantly.
llama.cpp (upstream)
llama-cli -m gemma-4-E4B-RotorQuant-GGUF-Q8_0.gguf \
--cache-type-k q8_0 --cache-type-v q8_0 \
-ngl 99 -fa \
-p "Explain quantum computing"
LM Studio
q8_0 (or q4_0 for more aggressive VRAM savings).iso3 cache types. Track this feature request for updates.Ollama
# Standard Ollama does not support RotorQuant cache types.
# Use with default or q8_0 KV cache via OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_FLASH_ATTENTION=1 ollama run majentik/gemma-4-E4B-RotorQuant-GGUF-Q8_0
| Property | Value |
|---|---|
| Base Model | google/gemma-4-E4B |
| Architecture | Dense transformer (Edge optimised) |
| Parameters | ~4B |
| Context Length | 128K |
| Weight Quantization | GGUF Q8_0 (near-lossless 8-bit, reference quality) |
| Original Size (BF16) | ~8 GB |
| Quantized File Size | ~4.0 GB |
| KV Cache (RotorQuant) | 3-bit via --cache-type-k iso3 --cache-type-v iso3 (fork only) |
| KV Cache (standard) | q8_0, q4_0, f16, etc. (any llama.cpp runtime) |
| License | apache-2.0 |
| Modalities | Text + Image + Audio |
| Compatible Runtimes |
RotorQuant is a KV cache compression method based on Clifford algebra (Cl(3,0)) rotors. It was developed as a faster, more parameter-efficient alternative to Google's TurboQuant (ICLR 2026).
Instead of applying a dense d×d random orthogonal rotation matrix (as TurboQuant does), RotorQuant uses lightweight block-diagonal rotations — independent 2D/4D rotations per pair/quartet — achieving O(d) complexity instead of O(d log d), fully parallelisable with no inter-element dependencies.
Benchmarks from the RotorQuant repository (Llama 3.1 8B, RTX 5090 — results will vary by model and hardware):
| Metric | RotorQuant (iso3) | TurboQuant | Standard q4_0 |
|---|---|---|---|
| Prefill Speed | 3,822 tok/s | 722 tok/s | — |
| Decode Speed | 119 tok/s | 93 tok/s | — |
| Perplexity (PPL) | 6.91 | 7.07 | — |
| KV Compression | ~5× vs FP16 | ~5× vs FP16 | ~4× vs FP16 |
| Rotation Parameters | 4 per rotor | 16,384 per matrix | N/A |
Note: These benchmarks are from the RotorQuant repository using Llama 3.1 8B on an RTX 5090. Performance on gemma-4-E4B will differ. Independent benchmarks for this specific model are welcome — please open a discussion if you have results to share.
| Runtime | RotorQuant Support | Standard KV Quant |
|---|---|---|
| llama.cpp (upstream) | ❌ Not merged | ✅ q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1 |
| llama-cpp-turboquant fork | ✅ planar3, iso3 | ✅ All standard types |
| LM Studio | ❌ Requested | ✅ Via advanced settings |
| Ollama | ❌ Not supported | ✅ Via OLLAMA_KV_CACHE_TYPE |
| koboldcpp | ❌ Not supported | ✅ Standard types |
For VRAM-constrained setups, standard q8_0 KV cache quantization already halves KV cache memory with negligible quality impact. Flash Attention should always be enabled — it is required for V cache quantization and improves memory efficiency regardless.
| VRAM | Suggested Configuration |
|---|---|
| 24 GB (RTX 4090) | Q8_0 + q8_0 KV cache + Flash Attention, 8K–16K context |
| 16 GB | Q8_0 + q4_0 KV cache + Flash Attention, 4K–8K context |
| 48+ GB | Q8_0 + f16 KV cache, full 32K+ context |
| Quant | Approx size | Use case | Recommendation |
|---|---|---|---|
| Q2_K | ~2.2 GB | Lossy, low-RAM CPU/edge | Resource-constrained inference |
| Q3_K_M | ~2.4 GB | Smaller-than-Q4, modest quality drop | Edge devices with ~16 GB RAM |
| IQ4_XS | ~2.1 GB | Importance-quant 4-bit, smaller than Q4_K_M | Best size/quality at 4-bit |
| Q4_K_M | ~3.0 GB | Balanced default | Recommended for most users |
| Q5_K_M | ~3.1 GB | Higher fidelity than Q4 | Quality-sensitive applications |
| Q6_K | ~3.6 GB | Approaching FP16 quality | High-fidelity CPU/edge |
| Q8_0 | ~4.1 GB | Near-lossless reference |
(Current variant — Q8_0 — is bolded.)
(Showing 14 sibling variants under majentik/gemma-4-e4b-*. The current variant — RotorQuant-GGUF-Q8_0 — is bolded.)
| Variant | Runtime | Approx size | Use case |
|---|---|---|---|
| RotorQuant | runtime modifier | n/a | KV-cache root (weight-agnostic) |
| RotorQuant-GGUF-IQ4_XS | llama.cpp | ~3.4 GB | Lossy 4-bit, low-RAM CPU/edge |
| RotorQuant-GGUF-Q2_K | llama.cpp | ~2.4 GB | Lossy, low-RAM CPU/edge |
| RotorQuant-GGUF-Q3_K_M | llama.cpp | ~3.1 GB | Smaller 3-bit, CPU-friendly |
| RotorQuant-GGUF-Q4_K_M | llama.cpp |
--- license: apache-2.0 base_model: google/gemma-4-E4B tags: - gguf - rotorquant - kv-cache-quantization - gemma - gemma4 - edge - llama-cpp - quantized library_name: gguf pipeline_tag: image-text-to-text --- > [!WARNING] > **Fork compatibility (2026-07-07):** the `llama-cpp-turboquant` fork is currently based on a llama.cpp revision that **predates `gemma4` architecture support** — it fails with `unknown model architecture: 'gemma4'` and cannot run this model at all. Until the fork rebases, use **mainline llama.cpp** (which loads this GGUF fine with standard KV-cache types); the RotorQuant/TurboQuant KV-cache options are not usable with gemma-4 yet. <!-- gemma4-fork-note --> > [!TIP] > **KV-cache quantization without any fork (recommended, 2026):** upstream > llama.cpp/Ollama now cover this natively — use `-ctk q8_0 -ctv q8_0` > (~half KV memory, negligible quality loss: perplexity +0.002–0.05) or > `-ctk q4_0 -ctv q4_0` (~quarter memory, ≈7.6% perplexity increase). In > Ollama: `OLLAMA_KV_CACHE_TYPE=q8_0` with `OLLAMA_FLASH_ATTENTION=1`. Keep > K and V types symmetric to stay on the fast fused Flash-Attention path. > Since April 2026, mainline llama.cpp also applies Hadamard rotation to > KV activations ([PR #21038](https://github.com/ggml-org/llama.cpp/pull/21038)), > which greatly improves low-bit KV quality (opt-out: > `LLAMA_ATTN_ROT_DISABLE=1`). > > The RotorQuant/TurboQuant fork flow below is **experimental/legacy**: the > TurboQuant llama.cpp PR was closed without merging (June 2026) and the fork > is unmaintained relative to mainline. It is NOT required to use this model. <!-- kv-upstream-note --> # gemma-4-E4B-RotorQuant-GGUF-Q8_0 GGUF Q8_0 weight-quantized variant of [google/gemma-4-E4B](https://huggingface.co/google/gemma-4-E4B) optimised for use with **RotorQuant** KV cache compression via a dedicated llama.cpp fork. > **Important:** RotorQuant KV cache types (`planar3`, `iso3`) are **not** available in upstream llama.cpp, standard Ollama, or LM Studio. > They require a [specific llama.cpp fork](https://github.com/johndpope/llama-cpp-turboquant/tree/feature/planarquant-kv-cache). > The GGUF file itself is a standard GGUF and works with any llama.cpp-compatible runtime using normal KV cache types (f16, q8_0, q4_0, etc.). ## Hardware compatibility | Device | VRAM / RAM | Recommendation | | --- | --- | --- | | CPU host with ≥8 GB...
Source context: 136 downloads · 0 likes · Pipeline image-text-to-text · Library gguf · Repo majentik/gemma-4-E4B-RotorQuant-GGUF-Q8_0
| llama.cpp, LM Studio, Ollama, koboldcpp |
| Fidelity-critical work |
| MXFP4_MOE | ~2.2 GB | Microscaling FP4 (MoE-aware) | vLLM / transformers users |
| ~4.4 GB |
| Balanced default |
| RotorQuant-GGUF-Q5_K_M | llama.cpp | ~5.3 GB | Higher fidelity, more RAM |
| RotorQuant-GGUF-Q8_0 | llama.cpp | ~8.4 GB | Near-lossless reference |
| RotorQuant-MLX-2bit | mlx-lm | ~1.3 GB | Apple Silicon, smallest |
| RotorQuant-MLX-4bit | mlx-lm | ~2.5 GB | Apple Silicon balanced |
| RotorQuant-MLX-8bit | mlx-lm | ~4.7 GB | Apple Silicon reference |
| TurboQuant | runtime modifier | n/a | KV-cache root (weight-agnostic) |
| TurboQuant-MLX-2bit | mlx-lm | ~1.3 GB | Apple Silicon, smallest |
| TurboQuant-MLX-4bit | mlx-lm | ~2.5 GB | Apple Silicon balanced |
| TurboQuant-MLX-8bit | mlx-lm | ~4.7 GB | Apple Silicon reference |