In breve: il formato del modello decide quale runtime puoi usare, prima ancora della VRAM. GGUF è il formato di llama.cpp: un file solo, già quantizzato, che leggono anche Ollama e LM Studio. safetensors è il formato dei pesi originali su Hugging Face: lo usa vLLM, lo usano gli strumenti di fine-tuning, e da lì partono tutte le conversioni. MLX non è un'estensione nuova: sono file safetensors con una quantizzazione pensata per il framework di Apple, da usare con mlx-lm o LM Studio su Apple Silicon. Laptop con Ollama o LM Studio: GGUF. Server GPU con vLLM: safetensors. Mac: MLX o GGUF, e la scelta la fa il runtime che preferisci.
Questo pezzo è uno spoke della serie Guida AI locale. I runtime sono in puntata 2, il conto della memoria e la scelta tra Q4 e Q8 in puntata 3. Qui parlo solo di formati, compatibilità e conversioni. Nessun test mio: uso la documentazione ufficiale di llama.cpp, Hugging Face, MLX, Ollama, LM Studio e vLLM, letta il 21 ottobre 2026.
La domanda sbagliata e quella giusta
Non "quale formato è migliore?". È: quale runtime userò, e che file legge. Su una pagina di Hugging Face lo stesso modello compare in tre forme: la cartella originale con i safetensors, un repository con una decina di file .gguf (uno per livello di quantizzazione) e una versione -4bit della community MLX. Sono gli stessi pesi, preparati per motori diversi. Se scegli il file prima del runtime, finisci a convertire.
Cosa c'è dentro ciascun formato
GGUF è il formato binario di GGML e llama.cpp. La specifica lo vuole in un file unico, caricabile con mmap, con dentro tutto quello che serve per avviare il modello: i tensori e i metadati in forma chiave-valore (architettura, tokenizer, parametri). I tensori di solito sono già quantizzati: le sigle come Q4_K_M o Q8_0 nel nome del file indicano il tipo. La tabella di Hugging Face riporta per esempio 4,5 bit per peso per Q4_K e 6,5625 per Q6_K. La differenza con safetensors, nelle parole della stessa pagina: GGUF codifica i tensori e un insieme standard di metadati, safetensors solo i tensori.
safetensors è il formato di Hugging Face per salvare tensori in modo sicuro, senza pickle, quindi senza codice eseguibile nascosto nel file, e veloce da caricare (zero-copy). Il file ha un'intestazione JSON con nome, tipo e forma di ogni tensore: si legge anche con due richieste HTTP Range, senza scaricare i pesi. Da solo però non basta per avviare un modello: accanto servono config.json, il tokenizer e gli altri file del repository. È il formato in cui escono quasi sempre i pesi originali, a 16 bit (BF16 o F16).
MLX è il framework di Apple per il machine learning su Apple Silicon, e mlx-lm è il pacchetto per generare testo e fare fine-tuning con quel framework. Un modello "MLX" su Hugging Face è un repository con file .safetensors e un config.json che dichiara la quantizzazione. Per esempio, mlx-community/Llama-3.2-3B-Instruct-4bit, il modello di default di mlx-lm, dichiara "bits": 4 e "group_size": 64. Il contenitore è safetensors, ma i pesi sono quantizzati nel modo di MLX: servono a mlx-lm e ai runtime che lo usano, non a un generico caricatore safetensors.
Tabella rapida: chi legge cosa
Runtime | GGUF | safetensors (formato Hugging Face) | MLX |
|---|---|---|---|
llama.cpp | Sì, è il suo formato | No: prima converti con | No |
Ollama | Sì, import con | Sì, import di una cartella con | Runner MLX su Apple Silicon dalla 0.40, gestito da Ollama |
LM Studio | Sì, con il runtime llama.cpp su Mac, Windows e Linux | Non documentato: i suoi runtime sono llama.cpp e MLX | Sì, su Mac con Apple Silicon e macOS 14 o successivo |
vLLM | Sperimentale, con il plugin | Sì, è il formato principale | No |
mlx-lm | No | Sì: li carica dal Hub e li converte con | Sì, è il suo formato |
Verdetto di riga: GGUF è il formato dei runtime "da scrivania", safetensors quello dei server e del training, MLX quello del Mac quando vuoi il motore di Apple.
Ollama, LM Studio e llama.cpp: GGUF prima di tutto
Ollama importa un GGUF con un Modelfile di una riga, FROM /percorso/file.gguf, poi ollama create. Se il modello è diviso in più file, la documentazione di import chiede di tenere i nomi originali e usare un wildcard come FROM /percorso/model-*.gguf. Un dettaglio da sapere: Ollama non quantizza i GGUF durante l'import. Se vuoi un Q4 da un file a 16 bit, lo prepari prima con llama-quantize di llama.cpp.
Ollama accetta anche una cartella di safetensors, con FROM che punta alla directory. È comodo se hai fatto un fine-tuning e vuoi provare il risultato senza passare da llama.cpp. Su Mac, dalla 0.40 Ollama usa in automatico MLX per le architetture supportate: lo racconto in Ollama 0.40 e lo spazio su disco. Il formato che importi però resta GGUF o safetensors.
LM Studio, secondo la sua documentazione, fa girare i GGUF con llama.cpp su Mac, Windows e Linux, e i modelli MLX con il motore di Apple sui Mac con Apple Silicon. Per i file scaricati fuori dall'app c'è lms import, che la pagina di import documenta per i GGUF. Secondo il riferimento della CLI, di default sposta il file nella cartella dei modelli; con --copy lo copia, con --symbolic-link crea un link.
vLLM: safetensors, e GGUF solo per provare
vLLM carica i modelli dal formato Hugging Face: un repository con config.json e pesi safetensors. Per sapere se un modello è supportato in modo nativo, la pagina dei modelli supportati indica di guardare il campo architectures del config.json.
Il GGUF su vLLM esiste, ma la documentazione lo definisce "altamente sperimentale e poco ottimizzato" e possibilmente incompatibile con altre funzioni. Oggi richiede un plugin separato, vllm-gguf-plugin. Le docs consigliano anche di usare il tokenizer del modello base invece di quello convertito dal GGUF, perché la conversione è lenta e instabile. Se servi più utenti su una GPU con vLLM, parti dai safetensors. Il discorso sulle API compatibili con OpenAI è in API OpenAI-compatible in locale.
Conversioni: da dove si parte
La regola pratica è una: si converte dall'originale a 16 bit, non da un file già quantizzato.
Da safetensors a GGUF il percorso documentato nel README di llama-quantize ha due passi. Prima converti in un GGUF ad alta precisione, poi quantizzi:
python convert_hf_to_gguf.py --outfile modello-bf16.gguf --outtype bf16 /percorso/modello-hf
./build/bin/llama-quantize modello-bf16.gguf modello-Q4_K_M.gguf Q4_K_MSe non vuoi installare niente, lo stesso README indica lo Space GGUF-my-repo su Hugging Face, sincronizzato con llama.cpp ogni sei ore.
Da safetensors a MLX basta mlx-lm. Il flag -q quantizza, di default a 4 bit:
mlx_lm.convert --model /percorso/modello-hf -qAnche qui c'è uno Space, mlx-my-repo.
La direzione inversa, da GGUF quantizzato a qualcos'altro, non è il percorso previsto. llama-quantize ha un'opzione --allow-requantize, e la sua documentazione avverte che riquantizzare un tensore già quantizzato può ridurre molto la qualità rispetto a partire da 16 o 32 bit. Se hai solo il GGUF e ti serve un altro formato, cerca prima i pesi originali.
Quale ti serve, caso per caso
- Laptop Windows o Linux, uso personale. GGUF con Ollama, LM Studio o llama.cpp. Scegli il livello di quantizzazione con il conto della puntata 3, non con il nome più corto.
- Mac con Apple Silicon. Due strade: MLX con LM Studio o mlx-lm, oppure GGUF con Ollama, LM Studio o llama.cpp. Non do numeri su quale vada più veloce: se ti interessa, prova lo stesso modello in entrambe le forme con i tuoi prompt. Il quadro hardware è in Mac con Apple Silicon o GPU NVIDIA.
- Server con GPU NVIDIA e più utenti. safetensors con vLLM. Il GGUF solo se devi provare un modello che esiste solo in quella forma.
- Fine-tuning. Parti dai safetensors originali. Il formato di destinazione (GGUF per Ollama, MLX per il Mac) si sceglie alla fine, quando sai dove girerà il modello.
Errori comuni
- Scaricare la cartella safetensors e aspettarsi che llama.cpp la apra. Non succede: serve prima la conversione in GGUF.
- Prendere un GGUF Q4 e riquantizzarlo in Q3 per risparmiare spazio. Meglio rifare la quantizzazione dall'originale a 16 bit, o scaricare direttamente il file Q3.
- Pensare che "MLX" sia un formato di file a sé. L'estensione resta
.safetensors: a dire che è MLX sono ilconfig.jsone il modo in cui sono quantizzati i pesi. - Usare in vLLM il tokenizer estratto dal GGUF. La documentazione di vLLM consiglia
--tokenizercon il modello base. - Scaricare un repository GGUF intero. Contiene una versione per ogni quantizzazione: ne serve una sola.
Cosa conviene fare adesso
- Decidi prima il runtime, poi il file. Se usi Ollama o LM Studio su un PC, cerca il GGUF; se usi vLLM, il repository originale.
- Su Hugging Face guarda la scheda "Files": i
.ggufhanno la quantizzazione nel nome, i repository MLX hanno il numero di bit nelconfig.json. - Tieni sempre un riferimento ai pesi originali: è da lì che parte ogni conversione futura, compreso un fine-tuning.
- Se un termine non ti è chiaro (GGUF, KV cache, runtime), c'è il glossario.
Domande frequenti
01Qual è la differenza tra GGUF e safetensors?
GGUF è un file unico con tensori e metadati (architettura, tokenizer, parametri), di solito già quantizzato, pensato per llama.cpp e i runtime basati su GGML. safetensors contiene solo i tensori, in modo sicuro e veloce da caricare; per avviare il modello servono anche config.json e il tokenizer del repository.
02Ollama può usare un modello in safetensors?
Sì. La documentazione di import di Ollama prevede un Modelfile con FROM che punta alla cartella dei safetensors, seguito da ollama create. Per i GGUF il Modelfile punta al file, e Ollama non li quantizza durante l'import.
03Un modello MLX funziona su Windows o Linux?
Non è il caso d'uso previsto: mlx-lm si presenta come pacchetto per Apple Silicon, e LM Studio usa MLX solo sui Mac. Su Windows e Linux la strada documentata è il GGUF con llama.cpp, Ollama o LM Studio, oppure i safetensors originali con vLLM.
04Posso convertire un GGUF in safetensors?
Non è il percorso previsto. Il GGUF di solito è già quantizzato, e riquantizzarlo, secondo la documentazione di llama.cpp, può ridurre molto la qualità. Se ti serve un altro formato, cerca i pesi originali a 16 bit e converti da lì.
