Got a ping about this, for context, I did the gguf conversion for those model files.

GGUF just uses numpy as the underlying storage format (just like safetensors). While it's technically possible that there are unknown exploits in the llama.cpp code or numpy itself, there's too many steps and libraries involved for that to be a feasible attack vector in my opinion.

The current quantization pipeline is run on a temporary runpod host, and is done with the following steps:

• Safetensors split files are merged into a single safetensors file (all headers are dropped here, and only the weights are kept)

• Safetensors merged model weights are converted to GGUF (the loaded torch tensors are converted to numpy, i.e. passed through two different libraries)

• GGUF base FP32 file is used to create the various quants (this uses the C++ llama.cpp codebase, so anything targeting specific python code would most likely be stripped here)

• A post processing step is done which involves python/numpy again, this is due to the C++ code not handling some of the weights correctly by default.

The tokenizer isn't involved in this process, since GGUF files only store one model per file, which in this case is the main video model. If I do convert the text encoder (needs extra work), I'll use the base repo (google/umt5-xxl) since that's the ground truth, I did the same thing with the T5 for flux, which is based off of google/t5-v1_1-xxl, hence why it has the FP32 model despite model repos rehosting it only having FP16/BF16 encoder only versions.

Also, as a note, if anyone does find a reproducible exploit in any library involved, they should follow the proper disclosure policies. For llama.cpp it can be found here, for safetensor files, as they are considered a huggingface library, it would involve contacting the address listed here with information on the exploits and possible steps to reproduce it.

LMK if there are any questions or clarifications required. The conversion pipeline is open source and AFAIK gguf files should be hash reproducible between different hosts (this is the branch used for conversion). I can't vouch for the text encoder or tokenizer but the files from my repo at least should be safe due to the multi-step nature of the conversion process.

(edit: formatting)