What is inside a GGUF file, in order (header, metadata key-values, tensor infos, padding, tensor data), and what fixed rules (magic, version, endianness, alignment, key and tensor-name limits) does the ggml specification state?
Partially verified: the curator re-read none of the cited sources; S1, S2, S7 rest on the producer's pinned reading. At ggml commit da8e2a54 (observed 2026-10-22), docs/gguf.md defines a single-file binary: a header (magic bytes GGUF, version 3, tensor_count, metadata_kv_count), then typed key-value metadata, then one tensor-info record per tensor (name, dimensions, ggml type, offset), then padding to a global alignment, then the tensor data. Keys are ASCII lower_snake_case segments joined by dots (max 65,535 bytes), tensor names at most 64 bytes, default alignment 32 when general.alignment is absent, little-endian unless the file is a big-endian variant that the spec says cannot be detected from the file. A reader can find every tensor from the header and tensor infos alone, which is why layout can be inspected without loading weights.
Structured fields
{
"citations": [
{
"url": "https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/docs/gguf.md",
"note": "candidate evidence excerpts"
},
{
"url": "https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/include/gguf.h",
"note": "candidate evidence excerpts"
},
{
"url": "https://github.com/ggml-org/llama.cpp/blob/c7fc5094179bf8a9c73c18593db714f8da41a402/gguf-py/gguf/constants.py",
"note": "candidate evidence excerpts"
}
]
}Evidence claims
- [sourced_fact] At ggml commit da8e2a54 (observed 2026-10-22), docs/gguf.md defines a single-file binary: a header (magic bytes GGUF, version 3, tensor_count, metadata_kv_count), then typed key-value metadata, then one tensor-info record per tensor (name, dimensions, ggml type, offset), then padding to a global alignment, then the tensor data. Keys are ASCII lower_snake_case segments joined by dots (max 65,535 bytes), tensor names at most 64 bytes, default alignment 32 when general.alignment is absent, little-endian unless the file is a big-endian variant that the spec says cannot be detected from the file. A reader can find every tensor from the header and tensor infos alone, which is why layout can be inspected without loading weights. · locator: candidate evidence excerpts source
Rights
| component | license | hosting | redistribution | modification | training | Evidence and notes |
|---|---|---|---|---|---|---|
| documentation | unknown | permitted | permitted | unknown | unknown | Applies to this original summary only, not to the cited sources. |
Linked records
- cites → https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/docs/gguf.md
- cites → https://github.com/ggml-org/ggml/blob/da8e2a54b919557b816b1c2beb432ccb766f7ce0/include/gguf.h
- cites → https://github.com/ggml-org/llama.cpp/blob/c7fc5094179bf8a9c73c18593db714f8da41a402/gguf-py/gguf/constants.py