> GGUF vs safetensors — decide el runtime, no el formato▋

DuckDuckGo autocompleta gguf vs safetensors como si fuera una pelea de jaula entre dos extensiones de archivo. Es un control de acceso. Eliges GGUF y se abre un estante de runtimes — llama.cpp, Ollama, LM Studio, Jan. Eliges safetensors y se abre otro estante — transformers, vLLM, ComfyUI. El formato es la lista de puertas que se abrirán; todo lo demás viene después. La mentira que este texto rechaza: que la pelea se decide por números de velocidad que nadie ha igualado en la misma máquina. Lo que el registro te da gratis — y lo que la mayoría de los argumentos se saltan — es cuánto pesa cada contenedor y dónde puede siquiera abrirse cada uno.

¿Entre qué estás eligiendo, en realidad?

GGUF es un contenedor de archivo único construido por los autores de llama.cpp, y la cuantización va horneada dentro, por tensor — la escalera de cuantización que todos discuten solo existe dentro de este formato. Un solo archivo carga pesos, tokenizer y plantilla de chat: el archivo es la distribución. Safetensors es un contenedor de serialización — un encabezado JSON más los bytes crudos de los tensores — y carga la precisión que el repo de entrenamiento publicó, usualmente BF16 o FP16. No cuantiza; almacena.

Safetensors lleva el nombre de su único trabajo: asegurarse de que nadie termine encurtido al cargar el modelo. El pickle de Python ejecuta código al desempaquetar; safetensors no ejecuta nada — ese es todo el argumento de seguridad, y por eso el ecosistema de Hugging Face lo estandarizó.

Pesa el mismo modelo en cada contenedor y las filosofías se ven en los bytes. El 14 de octubre de 2026, el mismo Qwen3-0.6B se publicaba como: GGUF Q4_K_M, 396,705,472 bytes (397 MB) · GGUF BF16, 1,198,182,848 bytes (1.20 GB) · safetensors BF16, 1,503,300,328 bytes (1.50 GB). El contenedor cuantizado cabe en un cuarto del de precisión completa porque guarda un cuarto de la precisión — y cada uno de esos números está a un curl -I de tu terminal, sin banco de pruebas. Si la precisión que falta te cuesta calidad es una pregunta de fidelidad que los bytes no responden; el artículo de niveles de quant cubre lo que cada peldaño sacrifica.

El formato no es una preferencia. Es la lista de runtimes que abrirán tu archivo.

¿Qué dicen los bytes?

La regla honesta para una lectura de registro: solo los números que el registro declara, atribuidos, sin cosplay de bench. La tabla es un modelo, tres contenedores, bytes exactos tal como se publicaron — verifícalos tú mismo antes de creer nada.

Contenedor	Precisión	Bytes tal como se publican	Parte de la precisión completa
GGUF Q4_K_M	cuantizado a 4 bits	396,705,472 (397 MB)	26%
GGUF BF16	completa, empaque llama.cpp	1,198,182,848 (1.20 GB)	80%
safetensors BF16	completa, tensores crudos	1,503,300,328 (1.50 GB)	100%

verificar: curl -sIL https://huggingface.co/unsloth/Qwen3-0.6B-GGUF/resolve/main/Qwen3-0.6B-Q4_K_M.gguf | grep -i content-length → el conteo de bytes, el mismo día o cualquier día · el mismo one-liner contra los archivos BF16 y safetensors

Lee la tabla de la forma honesta. El 26 % es toda la promesa de la escalera de cuantización: cuatro bits donde había dieciséis, en disco y en RAM. La brecha entre las dos filas de precisión completa — 1.20 contra 1.50 GB — es overhead de empaque, no física: el empaque BF16 de llama.cpp guarda los mismos tensores más flacos que el volcado crudo. Lo que los bytes no pueden decir es velocidad ni calidad; una columna de tokens por segundo sin máquina equivalente detrás es ruido de foro, y este texto se niega a imprimir una. La lectura de llama.cpp contra Ollama chocó con el mismo muro desde el lado del motor: mismo archivo, misma matemática, wrapper distinto.

Lo que el registro no puede decirte

Tres muros, dicho plano. Uno: calidad — Q4 contra BF16 es un intercambio de fidelidad, y ningún conteo de bytes lo mide. Dos: velocidad — tiempos de carga y tokens por segundo pertenecen a un bench pareado en una máquina con nombre, que este texto no tiene, así que no imprime ninguno. Tres: escala — las proporciones de bytes de un modelo 0.6B mantienen la forma a 70B, pero las esperas absolutas que sentirás a 70B son otro artículo en otro hardware.

¿Dónde corre realmente cada formato?

Esta es la parte que de verdad decide. GGUF abre en llama.cpp, Ollama, LM Studio, Jan — el ecosistema local de archivo único. vLLM también lee GGUF, vía su plugin, en GPU, con advertencias. Safetensors abre en transformers, vLLM nativo, ComfyUI y las herramientas MLX de Apple. El solape en los bordes es instructivo: Ollama — el electrodoméstico construido sobre un motor GGUF — igual publica un runner MLX para que los usuarios de Apple Silicon carguen pesos derivados de safetensors. Hasta el electrodoméstico se cubre.

Ya ejecutas	Tu formato se escoge solo	Por qué
Ollama, LM Studio o llama-server	GGUF	Sus motores comen GGUF nativo; los archivos cuantizados caben en discos pequeños
Un pipeline Python/transformers	safetensors	from_pretrained es el camino nativo; no hay paso de conversión que mantener
vLLM en un servidor GPU	safetensors	Nativo, sin plugin, sin advertencias GGUF — las advertencias GGUF en sí
ComfyUI o un pipeline de imágenes	safetensors	El ecosistema de difusión comercia checkpoints safetensors
Disco pequeño y máquina pequeña	GGUF Q4_K_M	397 MB contra 1.50 GB por los mismos pesos

GGUF hace de la cuantización el valor por defecto; safetensors hace de la precisión completa el valor por defecto. Ese default es la mayor parte de la decisión.

¿Cuál deberías servir?

Mira qué ya está instalado antes de consultar cualquier tabla. Si la máquina responde a ollama run, vives en tierra GGUF — toma el archivo Q4_K_M y deja de leer foros. Si tu día es Python, o tu capa de servicio es vLLM, safetensors nunca fue realmente una elección; es la lengua nativa del ecosistema. Convertir entre ambos es posible y casi nunca vale la pena: cada conversión es un lugar nuevo donde los pesos pueden diferir en silencio.

La línea de honestidad obligatoria, estilo de la casa: Leí el registro, no lo ejecuté. Cada número de esta página viene de los archivos tal como se publicaron, tomados la mañana en que este post subió — sin banco de pruebas, sin cosplay de tokens por segundo. Lo que el registro sí establece es la forma del intercambio — un cuarto de los bytes para el contenedor cuantizado, dos runtimes que apenas se solapan, y una precisión por defecto a cada lado que decide en silencio para la mayoría. Todo el clúster — runners, formatos, niveles de quant, el lote — está indexado en el hub de local-LLM.

Nadie cambió de formato por velocidad. Cambiaron de runtime por una función, y el formato vino incluido, como el boleto.

Así que dos preguntas de vuelta sobre el muro: qué formato abre realmente tu máquina de todos los días — y cómo sería un bench justo de estos tres contenedores en tu hardware. Nombra la máquina y el modelo en los comentarios; el mejor especificado arma la ficha técnica del próximo artículo.