Model requirements
What a model needs to run is mostly decided before you fetch it: the variant and quantization fix the weight size, and the context length fixes the working memory on top. This page carries the figures for the models the documentation uses and the classes of hardware they fit; clikart-cli info <source> --dry gives the on-disk number for any source, and the bench command measures the rest on your machine. --memory-stages <file> on any verb writes the runtime's memory-pool counters per device at each stage of the model's life, which is the measured form of the Run column.
How to read the tables: Disk is the snapshot size (fetch --dry total). Run is the resident memory serving one session at the default context; longer contexts and concurrent sessions add KV cache on top, roughly linear in tokens. Fits names the smallest sensible device class: phone (4 GB), laptop or small board (8 GB), workstation GPU (8 GB VRAM and up). A model's license is not restated here: the model card on the Hugging Face Hub is its source of truth, and the runtime shows it to you where it matters, as clikart-cli info <source> prints the family's license page and the checkpoint's own license link, and the same lines print at fetch and at load.
Text generation
| Model | Variant | Disk | Run | Fits |
|---|---|---|---|---|
| Qwen2.5 0.5B Instruct | fp16 (safetensors) | 0.9 GB | 1.2 GB | phone |
| Qwen3 0.6B | fp16 (safetensors) | 1.4 GB | 1.9 GB | phone |
| Qwen3 4B | GGUF Q6_K | 3.3 GB | 4.3 GB | laptop |
| Qwen3 4B | GGUF Q8_0 | 4.3 GB | 5.4 GB | workstation GPU, 8 GB |
The quantization ladder trades memory for fidelity in predictable steps: Q8_0 is near-fp16, Q6_K is the everyday default, Q4_K_M is the last stop before quality degrades noticeably in chat use. --kv-quant shrinks the per-token cache the same way when long contexts dominate the budget.
Multimodal
| Model | Variant | Disk | Run | Fits |
|---|---|---|---|---|
| Gemma 4 E2B IT (vision) | fp16 (safetensors) | 9.5 GB | 12.4 GB | workstation GPU, 16 GB |
| Gemma 4 E2B IT (vision) | GGUF Q4_0 (QAT) | 4.0 GB | 5.3 GB | laptop |
A multimodal run holds the vision tower alongside the language model, and these figures include it: the GGUF row counts the projector file (mmproj) that carries the tower beside the weights.
Speech-to-text
| Model | Variant | Disk | Run | Fits |
|---|---|---|---|---|
| Whisper base | fp16 (safetensors) | 0.3 GB | 0.6 GB | phone |
| Whisper large-v3-turbo | fp16 (safetensors) | 1.6 GB | 2.2 GB | laptop |
| Whisper large-v3 | fp16 (safetensors) | 3.1 GB | 4.0 GB | laptop |
Transcription memory is stable with audio length (the model works in 30-second windows); throughput, not memory, is what a faster device buys.
Embeddings
| Model | Variant | Disk | Run | Fits |
|---|---|---|---|---|
| Qwen3 Embedding 0.6B | GGUF Q8_0 | 0.7 GB | 1.1 GB | phone |
Embedding models run one forward per input with no generation loop, so batch size is the only memory knob that matters in practice.
After a model closes
Closing a model returns its memory to the runtime's pool, not to the operating system: the pool keeps the bytes cached so the next allocation is cheap, and releases them under memory pressure or when asked. A program that closes one model and loads another therefore holds both until it asks in between: ClikaRT::device::release_cached_memory(device) from C++, clika_runtime.empty_cache(device) from Python, Device.releaseCachedMemory() from Kotlin. The Kotlin Modelverse binding makes the call at a model's close; a C++ or Python program makes it itself, after the close and before the next load, and memory_stats(device) shows the pool's cached bytes before and after.
Reading a figure you do not see here
For any other model: clikart-cli check <model> answers the question before anything is downloaded. It reads the model's documents and its file listing and prints one row per device: the weight bytes, the cache bytes per token of context, the cache dtype, the context length, the activation estimate, the total need against the device's memory, whether it fits, and the largest sequence length that fits (--max-seq N judges another length; --assume-device phone=8G judges a device that is not this machine; --csv for a script). info --dry prints the exact disk cost, and devices prints what this machine offers. When the estimate is close to the device's limit, measure with bench before committing the deployment; it reports peak resident memory along with throughput.
On a board whose GPU and CPU share one memory (a Jetson, a phone), the device total check prices against is the whole machine's memory, which the operating system and every other process share, and the law takes no headroom off; so apply your own margin there, and size against what is free when the model starts rather than the total. --memory-stages FILE on any verb writes what a load holds on each device at each stage of the model's life, the measured form of the figure. A second model loaded beside the first takes its memory from the same pool.
clikart-cli check Qwen/Qwen2.5-1.5B-Instruct --max-seq 4096 --assume-device phone=8G
For a catalog of models, clikart-cli info <source...> --json prints
one document: each model (the base repository) with its variants, the base
weights and every quantization among the sources, read from the hub's
documents, listings and GGUF headers with nothing downloaded. Per variant it
carries the quant tag as the file names it, the precision, the bits per
weight, the files with their sizes and digests, what a runtime must decode
to serve it (requires), the fit terms check prices from, and whether
this build serves it. info --schema prints the JSON Schema the document
validates against; a served model's /props carries the same block as
variant, so a client matches the served weights to a catalog row.
clikart-cli info unsloth/Qwen3-1.7B-GGUF --json
clikart-cli info @sources.txt --json # one source per line
clikart-cli info --schema