GGUF is a single-file format that bundles weights (usually quantized), architecture metadata, tokenizer and chat template for llama.cpp apps such as LM Studio and Ollama. Safetensors is Hugging Face’s safe, tensor-only storage format, used by transformers, vLLM, MLX and ComfyUI. Download GGUF for local chat on consumer hardware; use safetensors for training, fine-tuning and GPU serving.
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.
In LM Studio, the short answer is that the llama.cpp runtime opens GGUF files, and on Apple Silicon the 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. Per the format description, a file opens with an 8-byte little-endian integer giving the header length, then the JSON header (currently capped at 100MB “to prevent parsing extremely large JSON”), then the tensor bytes.
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. Every file opens with the magic bytes GGUF and a version number (3 in the current spec), and the chat template travels inside it as a Jinja template under the tokenizer.chat_template key.
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 |
| File layout | GGUF magic bytes, version 3 header, key-value metadata, aligned tensor data | 8-byte header length, JSON header, raw tensor bytes |
| Chat template | Inside the file (tokenizer.chat_template) | In separate files next to the weights |
| Quantization | Built in, encoded in the file name (Q4_K_M, Q8_0) | Usually full precision; quantization is engine-specific (FP8, MLX 4-bit) |
| Typical consumers | llama.cpp, LM Studio, Ollama, Jan, ComfyUI via a custom node | 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 |
Can LM Studio run safetensors?
Only on an Apple Silicon Mac, and only when the safetensors files belong to an MLX conversion. LM Studio 0.3.4 and newer for Mac bundles mlx-engine, which loads MLX models. On Windows and Linux, and for any stock transformers checkpoint on any platform, the answer is no: download a GGUF build instead.
Trying anyway fails: a report on LM Studio’s bug tracker shows version 0.3.15 on Windows 11 returning Error: No LM Runtime found for model format 'safetensors'!. As of October 2026, LM Studio’s own site still describes its runtime as “MLX and llama.cpp under the hood”. The MLX route also needs Apple Silicon (M1 through M4) and macOS 14.0 or newer; the system requirements page says Intel Macs are not supported.
To find a version LM Studio will open:
- Search the model name or paste its Hugging Face URL in the Discover tab (Cmd+2 or Ctrl+2), per the download docs.
- In a terminal,
lms get qwen --mlxorlms get qwen --gguffilters results by format, and appending@Q6_Kto a repository URL picks the quantization, according to Hugging Face’s LM Studio guide. - If only the original checkpoint exists, convert it to GGUF (steps below) or, on a Mac, run
mlx_lm.convert --model <repo> -qfrom MLX LM.
GGUF vs MLX vs safetensors
These are not three interchangeable file formats. GGUF packages a model for GGML-based inference; safetensors stores tensors; MLX is a framework that can use safetensors weights. The distinction matters when selecting an LM Studio download.
| Choice | What to download for LM Studio | Runtime and platform |
|---|---|---|
| GGUF | A supported model’s .gguf file | llama.cpp on supported LM Studio platforms |
| MLX | A supported MLX model directory, including weights, configuration and tokenizer | MLX on Apple Silicon |
| Stock safetensors checkpoint | Find a compatible GGUF or MLX version first | The extension alone does not establish LM Studio compatibility |
LM Studio’s MLX announcement describes its two runtimes, and notes you can load several models at once and “mix and match” llama.cpp and MLX models. MLX LM’s conversion documentation also supports quantized models: a four-bit MLX conversion and Q4_K_M use different schemes, so compare the model and quantization details rather than treating the labels as equivalent.
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 more than three times the size of the Q4_K_M GGUF build of the same model: llama.cpp’s quantize documentation lists Llama 3.1 8B at 14.96 GiB in F16 against 4.58 GiB at Q4_K_M.
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.
GGUF vs safetensors in ComfyUI
In ComfyUI, safetensors is the native format and GGUF is an add-on: the built-in loaders read safetensors, while GGUF files need the ComfyUI-GGUF custom node pack. Use the official safetensors when it fits in VRAM, and a GGUF quant of a transformer model such as Flux when it does not. city96’s GGUF conversion of FLUX.1-dev shows the spread:
| Quant | F16 | Q8_0 | Q6_K | Q5_K_S | Q4_K_S | Q3_K_S | Q2_K |
|---|---|---|---|---|---|---|---|
| File size | 23.8 GB | 12.7 GB | 9.86 GB | 8.29 GB | 6.81 GB | 5.23 GB | 4.03 GB |
The safetensors-only middle ground is FP8. ComfyUI’s Flux examples offer flux1-dev-fp8.safetensors for the standard Load Checkpoint node, and say setting weight_dtype to fp8 in Load Diffusion Model will “lower the memory usage by half”.
Setting up GGUF takes three steps:
- Run
git clone https://github.com/city96/ComfyUI-GGUFinsideComfyUI/custom_nodes, thenpip install --upgrade gguf. - Put the
.ggufmodel file inComfyUI/models/unet. - Replace the Load Diffusion Model node with Unet Loader (GGUF), found under the
bootlegcategory.
The README calls the project “very much WIP”, describes LoRA loading as experimental, and says quantization “wasn’t feasible for regular UNET models (conv2d)”. SD 1.5 and SDXL checkpoints therefore stay safetensors in models/checkpoints, where the Load Checkpoint node splits each into MODEL, CLIP and VAE.
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. 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.
Converting safetensors to GGUF
llama.cpp’s convert_hf_to_gguf.py writes a 16-bit GGUF and llama-quantize shrinks it, per the quantize documentation:
- Clone and build llama.cpp, then run
python3 -m pip install -r requirements.txt. - Download the complete repository: every
.safetensorsshard plusconfig.jsonand the tokenizer files. The converter’s positional argument is a “directory containing model file”. - Convert with
python convert_hf_to_gguf.py ./Model-Dir --outfile model-bf16.gguf --outtype bf16. The--outtypeflag also accepts f32, f16, q8_0, tq1_0, tq2_0 and auto, the default. - Quantize with
./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M. - Run
lms import model-Q4_K_M.gguf, which the import docs mark experimental. Loading a model in LM Studio covers the rest.
For Llama 3.1 8B the 16-bit intermediate alone is 14.96 GiB, so budget disk for every stage. The experimental --remote flag reads safetensors from the Hub without saving them (gated repos need HF_TOKEN), and --mmproj exports a vision model’s projector. With no local toolchain, the GGUF-my-repo Space converts and quantizes Hub weights to GGUF, according to Hugging Face’s GGUF docs.
Converting GGUF to safetensors
Converting GGUF to safetensors is possible for architectures the Transformers loader supports. Transformers’ GGUF guide loads a file with AutoModelForCausalLM.from_pretrained(repo, gguf_file=filename). Apart from Qwen3.5 and Qwen3.5 MoE, which have a packed path, every architecture goes through a legacy loader that “always dequantizes”; the guide names Llama, Mistral, Qwen2, Phi3, Falcon and StableLM among them. For a dense model in a chosen precision, pass quantization_config=GgufConfig(dequantize=True) with dtype=torch.bfloat16, and plan for far more memory than the quantized file occupies.
Then model.save_pretrained("output-directory") and tokenizer.save_pretrained("output-directory") write the weights, config and tokenizer, as the model API reference describes. Since Transformers v5, safetensors is the only format it writes: the v5 migration guide says the safe_serialization parameter “has been removed from all save_pretrained and push_to_hub methods”, so delete that argument from older snippets. This is a conversion workflow, not a filename-extension change.
Dequantization expands the stored approximations; it cannot recover precision discarded during quantization. Prefer the original checkpoint when that precision matters. The exported directory is also not automatically an MLX conversion or an LM Studio-compatible download. If the goal is simply to run the model in LM Studio, keep the supported GGUF or choose an existing supported MLX build.
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; how much VRAM a 7B model needs works through one common size. The second half of that is covered in which GGUF quant level: Q4_K_M vs Q8_0, 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.
FAQ
is gguf better than safetensors
Neither is better in general; they do different jobs. GGUF is better for running a model locally, because one file carries quantized weights, tokenizer and chat template for llama.cpp, LM Studio and Ollama. Safetensors is better for training, fine-tuning, GPU serving with vLLM or transformers, and as the source you quantize from.
is gguf smaller than safetensors
Usually, but only because most GGUF downloads are quantized. An F16 GGUF stores about 16 bits per weight, the same as a 16-bit safetensors checkpoint. llama.cpp’s quantize documentation lists Llama 3.1 8B at 14.96 GiB in F16 and 4.58 GiB at Q4_K_M, so the common 4-bit download is under a third the size.
why does lm studio say no lm runtime found for model format safetensors
Because neither of its runtimes accepts a stock safetensors checkpoint. The error, reported on LM Studio’s bug tracker for version 0.3.15 on Windows 11, appears for Hugging Face safetensors models. llama.cpp needs GGUF, and the MLX engine runs only MLX conversions on Apple Silicon. Delete the download and fetch a GGUF build of the same model.
does gguf lower image quality in comfyui
Some, because any quantization trades fidelity for size. The ComfyUI-GGUF author notes that transformer models such as Flux “seem less affected by quantization” than conv2d UNet models, where it was not feasible. ComfyUI’s own Flux examples say even fp8 “degrades the quality a bit”, so start at Q8_0 and step down only as VRAM requires.