Instructions to use unsloth/gemma-4-31B-it-GGUF with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use unsloth/gemma-4-31B-it-GGUF with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL # Run inference directly in the terminal: llama cli -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL # Run inference directly in the terminal: llama cli -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL # Run inference directly in the terminal: ./llama-cli -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL # Run inference directly in the terminal: ./build/bin/llama-cli -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Use Docker
docker model run hf.co/unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
- LM Studio
- Jan
- vLLM
How to use unsloth/gemma-4-31B-it-GGUF with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "unsloth/gemma-4-31B-it-GGUF" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "unsloth/gemma-4-31B-it-GGUF", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }'Use Docker
docker model run hf.co/unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
- Ollama
How to use unsloth/gemma-4-31B-it-GGUF with Ollama:
ollama run hf.co/unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
- Unsloth Desktop
- Pi
How to use unsloth/gemma-4-31B-it-GGUF with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Configure the model in Pi
# Install Pi: npm install -g @earendil-works/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL" } ] } } }Run Pi
# Start Pi in your project directory: pi
- Docker Model Runner
How to use unsloth/gemma-4-31B-it-GGUF with Docker Model Runner:
docker model run hf.co/unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
- Lemonade
How to use unsloth/gemma-4-31B-it-GGUF with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Run and chat with the model
lemonade run user.gemma-4-31B-it-GGUF-UD-Q4_K_XL
List all available models
lemonade list
- Hermes Agent
How to use unsloth/gemma-4-31B-it-GGUF with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Run Hermes
hermes
- Atomic Chat
- OpenClaw
How to use unsloth/gemma-4-31B-it-GGUF with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
Gemma 4 31B's Context VRAM is insane. Seems like an unusable model to me.
I did the numbers crunching with Claude and here's how much VRAM you'd need to run this model at full context.
Model used: UD-Q4_K_XL (18.8 GB)
Model Size in VRAM without Cache: 21.07 GB
β No KV Quantization (0.85 MB/token) β
8K: ~7 GB
32K: ~27 GB (48GB of VRAM required)
64K: ~54 GB
128K: ~109 GB
256K: ~218 GB
β Q8_0 (0.25 MB/token) β
8K: ~2 GB (Might fit in 24GB of VRAM)
32K: ~8 GB
64K: ~16 GB (37GB of VRAM required)
128K: ~32 GB
256K: ~64 GB
β Q4_0 (0.038 MB/token) β
8K: ~0.3 GB
32K: ~1.2 GB
64K: ~2.4 GB (Might fit in 24GB of VRAM)
128K: ~4.9 GB
256K: ~9.7 GB
These numbers are rough and were gained using a setting of 100, 2048, and 8192 empty context with the KV Cache settings. Tests were done on LM Studio on Windows 11. They aren't perfect but plenty to get the point across. Q4_0 is the only one that looks remotely usable if you ask me. For reference Qwen3.5 27B is somewhere around 0.003MB per token at Q8_0.
The model has a fixed 3.6GB SWA KV cache that you need to account for.
With --fit and 32GB of VRAM the UD-Q4_K_XL model with f16/f16 (no KV quantization) leaves me with over 100,000 context.
The model has a fixed 3.6GB SWA KV cache that you need to account for.
With --fit and 32GB of VRAM the UD-Q4_K_XL model with f16/f16 (no KV quantization) leaves me with over 100,000 context.
I switched to llama.cpp to test it further when I had more time on my hands and it appears that my above post was just an LM Studio bug. In llama.cpp I'm seeing 22.3GB of VRAM usage at 16384 context at FP16.
If you are the only user add the
-np 1
option to your llama.cpp config. I will reserve space for a single SWA KV instead of the default 4.
Ollama Gemma 4 26B A4B KV-Cache Measurement
i did some investigating about your convo and hope this helps.
This note summarizes a local measurement of Ollama memory allocation for gemma4:26b while varying num_ctx from 8k to 256k tokens.
System
- Machine: MacBook Pro
Mac16,7 - Chip: Apple M4 Pro, 14-core CPU (10 performance, 4 efficiency)
- Memory: 48 GB unified memory
- Architecture: arm64
- OS: macOS 15.6 (build 24G84)
- Measurement time: 05/02/2026, 21:04:11 CDT; raw report timestamp 2026-05-03T02:04:11.646Z
Model
- Ollama model:
gemma4:26b - Family:
gemma4 - Parameter size reported by Ollama: 25.8B
- Quantization reported by Ollama:
Q4_K_M - Installed model file size reported by Ollama: 17,987,581,215 bytes (~16.75 GiB)
Script And Method
Script path in the Gary repo:
scripts/diagnostics/measure-ollama-kv-cache.mjs
Command run:
npm run diagnose:ollama-kv -- --max-tokens 262144 --step-tokens 8192 --no-manage-ollama --output output/ollama-kv-measurement-256k.json
The script ran in context mode, which is designed for runtimes that preallocate KV cache from num_ctx rather than growing only with actual prompt tokens. For each 8k-token step it:
- unloaded the currently loaded Ollama model;
- waited briefly;
- started a tiny one-token prompt with
options.num_ctxset to the target context size; - sampled Ollama process RSS and Ollama
/api/psreported size; - wrote partial JSON after every probe;
- fit memory as
fixed model allocation + per-token allocation.
Gary-managed services were stopped before the run. The command used --no-manage-ollama because an existing Ollama server was already reachable on 127.0.0.1:11434; attempting to start a new sandbox-managed Ollama process could not bind that local port from this shell.
Results
The run completed 32 samples from 8,192 tokens through 262,144 tokens.
The script's RSS-based fit reported:
- Fixed/model memory: 18.487 GiB
- KV/cache slope: 0.02267 MiB/token
- KV/cache slope: 0.18132 GiB per 8,192 tokens
Ollama's own API-reported model size produced a slightly cleaner fit:
- Fixed/model memory: 18.270 GiB
- KV/cache slope: 0.02232 MiB/token
- KV/cache slope: 0.17855 GiB per 8,192 tokens
Selected API-reported allocation points:
| Context | Ollama API size | Peak RSS delta |
|---|---|---|
| 8,192 | 18.51 GiB | 18.64 GiB |
| 65,536 | 19.68 GiB | 19.95 GiB |
| 131,072 | 21.12 GiB | 21.45 GiB |
| 196,608 | 22.56 GiB | 22.81 GiB |
| 262,144 | 23.99 GiB | 24.42 GiB |
Interpretation
For this hardware, model, Ollama build, and quantization, the measured context allocation was roughly 0.18 GiB per 8k tokens, or ~0.022 MiB/token. That is below a rough 0.25 GiB per 8k tokens planning estimate but close enough that 0.20-0.22 GiB per 8k tokens looks like a practical target if some overhead is desired.
At 256k context, Ollama reported about 23.99 GiB resident for the model plus context allocation. This was feasible on a 48 GB unified-memory M4 Pro when Gary was stopped, though macOS whole-system free memory dropped very low during the largest probe. Ollama API-reported size was smoother than process RSS, so I would treat the API-size fit as the cleaner estimate and RSS as a sanity check.
Raw data:
