GGUF tensor reordering script with gguf-py plus hash verification
Parent: Mac local LLMs: Memory and wired limits · Published reference · snapshot 2026-10-05
↓ Facts as markdownall context files
A duplicate tensor name raises ValueError.
These notes link each claim to its source. A source may be a research report hosted on this site rather than the primary document. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Facts
- A duplicate tensor name raises ValueError. [source]
- Adding tensors after the file is opened raises ValueError. [source]
- Output is a new file; the writer does not edit in place. [source]
- With split_max_tensors or split_max_size set, tensors are partitioned into shards in insertion order. [source]
- Endianness mismatches cause a byteswap copy. [source]
- The exact posted script (Reddit r/LocalLLM 1vz927j) was refused by the fetch helper. [source]
- GGUFWriter keeps tensors as dicts and writes the data section in dict iteration order, with a code comment relying on Python dict insertion order. [source]
- write_ti_data_to_file emits tensor info in the same order, with each offset equal to the running sum of ggml_pad(nbytes, data_alignment) of earlier tensors. [source]
- The writer's default data alignment is GGUF_DEFAULT_ALIGNMENT and can be changed with an alignment setter, so a reorder must carry over any general.alignment value from the source. [source]
- add_tensor_info raises ValueError("Duplicated tensor name ...") on a repeated name and raises if the output file is already open. [source]
- add_tensor accepts raw_shape and raw_dtype for pre-quantized data, so existing quantized tensor bytes can be copied without requantizing. [source]
- write_tensors_to_file raises ValueError if a tensor writes a different byte count than expected, so a short write cannot pass silently. [source]
- With use_temp_file the writer spools tensors to a SpooledTemporaryFile (256 MiB in memory) and copies them at the end; without it each tensor is held until written, so a reorder of a 90 GB model needs the reader's memory-mapped tensor views, not copies. [source]
- Reorder recipe: open the source with GGUFReader, copy every KV pair, call add_tensor for each source tensor in the desired order with the large CPU-only table last, write header, KV, then tensors, then compare per-tensor sha256 and the tensor-info table (name, shape, type). [source]
- Name-keyed hashing (not offset-keyed) is the correct check because every offset changes after a reorder. [source]
Children
- No children recorded.