ggml-org/llama.cpp

GGUF endianness cannot be determined from GGUF itself

Open

#3957 aperta il 5 nov 2023

Vedi su GitHub
 (20 commenti) (4 reazioni) (0 assegnatari)C++ (18.202 fork)batch import
breaking changeenhancementgood first issue

Metriche repository

Star
 (110.169 star)
Metriche merge PR
 (Merge medio 6g 8h) (389 PR mergiate in 30 g)

Descrizione

As of the time of writing, the big-endian support that was added in https://github.com/ggerganov/llama.cpp/pull/3552 doesn't encode the endianness within the file itself:

https://github.com/ggerganov/llama.cpp/blob/3d48f42efcd05381221654376e9f6f69d76af739/gguf-py/gguf/gguf.py#L689-L698

This means that there is no way to distinguish a big-endian GGUF file from a little-endian file, which may cause some degree of consternation in the future if these files get shared around 😅

The cleanest solution would be to add the endianness to the header - ideally, it would be in the metadata, but the reading of the metadata is dependent on the endianness - but that would be a breaking change.

Given that, my suggestion would be to use FUGG as the header for big-endian files so that a little-endian executor won't attempt to read it at all unless it knows how to deal with it. The same can go the other way, as well (a big-endian executor won't attempt to read a little-endian executor).

Guida contributor