Skip to content

GGUF compatibility

This page is the compatibility reference for GGUF models. For commands and workflows, see Run GGUF models.

The GGUF architecture column is the value stored in the file’s general.architecture metadata. Fine-tunes and model sizes within a family use the same entry.

Model familyGGUF architecture
Llama, Mistral, Mixtralllama
Mistral 3 text weightsmistral3
Gemmagemma
Gemma 2gemma2
Gemma 3 text weightsgemma3
Phi-2phi2
Phi-3 and Phi-3.5phi3
Phi-3.5 MoEphimoe
Qwen2 and Qwen2.5qwen2
Qwen3qwen3
Qwen3 MoEqwen3moe
Qwen3-Next and Qwen3-Coder-Nextqwen3next
Qwen3.5 and Qwen3.6 denseqwen35
Qwen3.5 and Qwen3.6 MoEqwen35moe
StarCoder2starcoder2
DeepSeek-V2, DeepSeek-V3, DeepSeek-R1 (non-distill), GLM-4 MoE Litedeepseek2
GLM-4 denseglm4
GLM-4 MoEglm4moe
SmolLM3smollm3
Granite densegranite
Granite MoEgranitemoe
Granite hybridgranitehybrid
GPT-OSSgpt-oss
Hunyuan densehunyuan-dense
Hunyuan MoEhunyuan-moe
LFM2 and LFM2.5 denselfm2
LFM2 and LFM2.5 MoElfm2moe

Some GGUF architectures cover more than one model family. Repository files and GGUF metadata are used together to select the family. For a standalone file that cannot be identified unambiguously, pass the original model with --tok-model-id.

GLM GGUFs configured for multimodal input are not supported as text-only models.

Multimodal GGUF requires a compatible companion projector. Depending on the family, the loader may also need the original configuration or processor assets. Repository loading selects supporting files when the repository and GGUF metadata identify them unambiguously. The direct local -f /path/model.gguf shorthand also selects an unambiguous projector stored beside the model.

Model familyGGUF architecture
Gemma 3gemma3
Gemma 3ngemma3n
Gemma 4 dense and MoEgemma4
Idefics3 and SmolVLMllama
Mistral 3 and Pixtralmistral3
Llama 4llama4
LFM2-VL and LFM2.5-VLlfm2
Muse Glimmermuse-glimmer
Qwen2-VL and Qwen2.5-VLqwen2vl
Qwen3-VLqwen3vl
Qwen3-VL MoEqwen3vlmoe
Qwen3.5 and Qwen3.6 multimodal denseqwen35
Qwen3.5 and Qwen3.6 multimodal MoEqwen35moe

Input modalities depend on the model. A listed family does not imply that every checkpoint accepts image, audio, and video. Use the model card and multimodal input guide for its supported request types.

Multimodal Qwen3.5 and Qwen3.6 accept image and video input, but not audio. Gemma 4 accepts image/video and audio when the matching components are present in the model configuration and projector files.

Muse Glimmer GGUFs require a companion muse-glimmer projector. Current published GGUF repositories also require --tok-model-id meta-models/Muse-Glimmer-30B because they do not carry enough base-model configuration metadata for standalone loading. Image input is supported. Video input is rejected because the llama.cpp conversion irreversibly sums each pair of temporal patch weights in the projector.

The gemma3n, gemma4, llama4, qwen2vl, qwen3vl, and qwen3vlmoe architectures always need a projector. Architectures that appear in both tables above, including gemma3, llama, mistral3, lfm2, qwen35, and qwen35moe, load as text models when no projector is supplied.

mistral.rs accepts GGUF files using the following storage types. A file can mix types, as common _K_M and _K_S artifacts do.

CategorySupported storage types
Floating pointF32, F16, BF16
Legacy block quantsQ4_0, Q4_1, Q5_0, Q5_1, Q8_0, Q8_1
K-quantsQ2_K, Q3_K, Q4_K, Q5_K, Q6_K, Q8_K
GPT-OSSThe GPT-OSS MXFP4 representation

IQ storage types, including IQ1, IQ2, IQ3, and IQ4 variants, are not supported for GGUF files yet. Select a supported Q/K artifact instead. Other storage types not listed above are also unsupported. Big-endian GGUF files are not supported.

CapabilityGGUF support
Local exact-file loadingYes, with -f
Hugging Face exact-file loadingYes, with -m and -f
Automatic artifact selectionYes, with -m and --quant
Tokenizer and chat-template discoveryFrom embedded GGUF metadata or supplied model assets
Multimodal projector discoveryFrom an unambiguous GGUF repository, or an adjacent projector with the direct local -f shorthand
Serving, tool calling, and agentsSame runtime paths as other loads; checkpoint and chat-template support still apply
Dynamic LoRALanguage-model adapters for compatible rotary layouts; adjacent-RoPE layouts are rejected
Multimodal LoRALanguage-model adapters only; projector, vision, and audio adapters are not supported
Legacy static LoRAText GGUF with the phi3 architecture; not supported with multimodal GGUF
X-LoRAText GGUF with the phi3 architecture; not supported with multimodal GGUF
ISQ requantizationYes, for compatible weights selected with -f
Offline loadingYes, when every required file is local or cached

Dynamic LoRA is currently rejected for native GGUF architectures that store Q/K features in adjacent rotary order: llama, mistral3, deepseek2, glm4, smollm3, granite, granitemoe, granitehybrid, llama4, and muse-glimmer. This also covers multimodal models routed through those architectures, including Idefics3, Mistral 3/Pixtral, Llama 4, and Muse Glimmer. Base-model loading is unaffected.

GGUF support covers text generation and the multimodal families listed above. GGUF is not a loading format for embedding, speech, diffusion, or image-generation pipelines.