GGUF vs Safetensors: Differences and LM Studio Support

You find a model on Hugging Face, the repository is full of files ending in .safetensors, and LM Studio will not open it. The usual conclusion is that something is broken or that the app is missing a feature. Neither is true. The two formats were built for different jobs, and the mismatch is by design.

The short answer is that LM Studio’s llama.cpp runtime opens GGUF files, and on Apple Silicon its MLX runtime opens MLX model directories. A stock PyTorch checkpoint published as safetensors is neither. The longer answer is more useful, because “safetensors” turns out not to be one thing, and that nuance decides whether a given repository will work on your machine.

What each format was designed to do

Safetensors is a storage format for tensors. Hugging Face describes it as “a new simple format for storing tensors safely (as opposed to pickle) and that is still fast (zero-copy)”. The problem it solves is a security and speed problem, not an inference problem. PyTorch’s older .bin checkpoints were Python pickle files, and unpickling can execute arbitrary code, so downloading a model from a stranger meant running their code. Safetensors stores raw tensor data behind a small JSON header, so loading a file cannot execute anything, and the layout permits zero-copy reads.

What it deliberately does not do is describe the model. A safetensors file holds weights and a minimal metadata map. The architecture configuration, the tokenizer, the chat template, and the generation defaults all live in separate files alongside it. That is fine in its native habitat, where a training or serving framework reads the whole directory, and it is precisely why a lone .safetensors file is not a runnable model.

GGUF solves the opposite problem. The specification describes it as “a file format for storing models for inference with GGML and executors based on GGML”, and its stated design goals include single-file deployment, memory-mapped loading, extensibility, and completeness. That last goal is the important one: “all information needed to load a model is contained in the model file, and no additional information needs to be provided by the user.” A GGUF file carries the tensors plus a key-value metadata block with the architecture, the hyperparameters, and the tokenizer data including vocabulary and special token IDs.

That is the whole story in one line. Safetensors is a way to store weights safely. GGUF is a way to ship an entire runnable model as one file. A desktop application that lets a non-specialist double-click a download and start chatting needs the second thing.

Side by side

	GGUF	Safetensors
Built for	Inference with GGML / llama.cpp	Safe tensor storage, training and serving
Self-contained	Yes, one file carries weights, architecture and tokenizer	No, needs config and tokenizer files alongside
Quantization	Built in, encoded in the file name (Q4_K_M, Q8_0)	Usually full precision; quantization is engine-specific
Typical consumers	llama.cpp, LM Studio, Ollama, Jan	transformers, vLLM, diffusers, MLX, ComfyUI
Memory-mapped loading	An explicit design goal	Supported, zero-copy reads
Opens directly in LM Studio	Yes	Only as an MLX model, on Apple Silicon

The nuance that trips people up

Here is where the blunt version of this answer goes wrong. MLX, Apple’s array framework, also uses safetensors as its on-disk format. LM Studio added an MLX backend in version 0.3.4, so on Apple Silicon the app can load MLX models perfectly well, and those repositories are full of .safetensors files.

So the presence of .safetensors in a repository tells you almost nothing on its own. What matters is which family the repository belongs to:

• An MLX conversion, typically published under an organisation such as mlx-community, with a config that names MLX. On Apple Silicon, LM Studio can load this.
• A stock transformers checkpoint, the canonical full-precision release of a model. LM Studio cannot load this directly on any platform, and it would rarely be what you want anyway, since a 16-bit checkpoint is roughly four times the size of the four-bit GGUF build of the same model.

Telling them apart takes a few seconds on the repository’s file list. A stock transformers checkpoint has a config.json naming the architecture, a tokenizer.json or equivalent, and often a set of numbered shards with an index file mapping tensors across them. An MLX conversion looks similar but is published under an MLX-focused organisation and usually carries the quantization in the repository name. A GGUF release looks nothing like either: a flat list of single files whose names end in the quantization level, one per level, with no accompanying config to read.

This is also why the word “safetensors” appears inside LM Studio’s own model definitions. The model.yaml specification, which describes “a model and all of its variants in a single portable file”, includes a compatibilityTypes field, and published examples list both gguf and safetensors. That field records which formats a given model is available in across engines. It is a statement about the model, not a promise that the llama.cpp runtime will open an arbitrary safetensors checkpoint.

What to do about it

Look for an existing GGUF build first. Popular models are converted within days of release, usually by well-known community packagers, and searching the model name plus GGUF finds them immediately. LM Studio’s in-app downloader filters to what it can run, which is the reason to start there rather than in a browser. This is nearly always the right move: someone has already done the conversion, validated it, and published several quantization levels.

Convert it yourself only when no build exists. llama.cpp ships a conversion script that reads a transformers checkpoint directory and writes a GGUF file, followed by a separate quantization step to produce the level you want. It is a legitimate path for a model too new or too obscure to have been packaged, and it requires a Python environment, the full-precision download, and enough disk space to hold both the source and the output. It also requires that llama.cpp already supports that model’s architecture, which is the step that actually blocks people. A brand-new architecture is not convertible until the runtime learns it, no matter how correct your command line is.

On Apple Silicon, treat MLX as a real second option rather than a curiosity, and pick per model based on what is available and what performs well on your chip.

The mistake worth avoiding

The failure mode is not the error message. It is the reaction to it: downloading a 30 GB full-precision checkpoint to “try anyway”, filling a disk, and concluding that local models need more machine than they do.

The format question and the hardware question are separate, and they are best answered in that order. Confirm the model exists in a form LM Studio can open, then decide which quantization of it your memory can hold. The second half of that is covered in choosing a GGUF quantization level, and if you are still deciding what the machine should be, LM Studio’s system requirements sets out the floors and the sizing arithmetic. To turn a specific model and context length into a memory figure, the VRAM and GGUF sizer does the calculation directly.

Once a model loads and runs, the natural next step is getting at it from other machines rather than only from the desktop app, which is what running LM Studio headless on Unraid covers.