Skip to main content
GGUF is a binary file format for storing models for inference with ggml and executors based on ggml. It is designed for fast loading and saving, ease of reading, and single-file deployment. GGUF is the successor to the earlier GGML, GGMF, and GGJT formats. The key improvement over GGJT is the use of a typed key-value structure for metadata, rather than a fixed list of untyped hyperparameters. This allows new metadata to be added without breaking compatibility with existing models.

Design goals

  • Single-file deployment — models can be distributed and loaded without external files.
  • Extensibility — new metadata can be added without breaking existing readers.
  • mmap compatibility — tensors are aligned so models can be loaded with mmap.
  • Full information — everything needed to load the model is embedded in the file itself.

File structure

A GGUF file is laid out sequentially as follows:
The header appears at the start of every GGUF file:
Models are little-endian by default. Big-endian support was added in format version 3. If no additional information is provided, assume the model is little-endian.

Tensor info

Each tensor is described by a gguf_tensor_info_t entry. The actual data starts after all tensor info entries, padded to the alignment boundary:

Alignment

The global alignment is set by the general.alignment metadata key (default: 32). Padding bytes (0x00) are inserted to align tensor data:

Metadata types

The gguf_type enum describes every value type that can appear in a GGUF key-value pair:
All enums are stored as int32_t. Strings are serialized as a uint64_t length followed by the UTF-8 bytes without a null terminator.

Key-value pairs

Each metadata entry is a gguf_metadata_kv_t:
Keys follow the convention namespace.property (e.g. general.architecture, llama.context_length). Community-defined keys should be prefixed with the community name (e.g. rustformers.my_key).

Tensor element types

The ggml_type enum covers all supported tensor element types, including floating-point and quantized formats:

C API

Initializing a context

Writing files

There are three ways to write a GGUF file:
Write everything in one call:

Reading key-value metadata

Writing key-value metadata

Working with tensors

Standardized metadata keys

Required keys

General metadata

LLM hyperparameters

For LLM architectures, replace [llm] with the architecture name (e.g. llama, gpt2):

Tokenizer

Naming convention

GGUF filenames follow this structure:
All components are separated by -. Components other than BaseName, SizeLabel, and Version are optional.
At minimum, a filename should include BaseName, SizeLabel, and Version so that it can be validated unambiguously.

Examples

Validation regex

You can validate a filename with the following regular expression:

Standardized tensor names

Models using the transformer architecture should use these tensor name conventions: Base layersAA.weight / AA.bias where AA is: Attention and feed-forward blocksblk.N.BB.weight / blk.N.BB.bias where N is the block index and BB is:

Version history