12 de noviembre de 2026 · Equipo de VRAMfarm
Cómo llevar datasets a un servidor GPU y traerlos de vuelta: Hugging Face, rclone, rsync, scp
Subir un dataset de 80 GB desde casa con una conexión de 40 Mbit/s lleva unas cuatro horas y media, y si ya tienes un servidor GPU en marcha, pagas cada una de ellas. Esos mismos 80 GB descargados de Hugging Face o de un bucket de S3 en una máquina con un enlace de 1 Gbit/s tardan 15–20 minutos. Así que la regla es sencilla: los datos deben ir de la nube al servidor, no desde tu portátil, y la subida lenta, si te hace falta, debe hacerse una sola vez, sin una GPU esperando.
Elige la ruta según dónde estén ahora los datos
| Dónde están los datos | Herramienta | Qué limita la velocidad |
|---|---|---|
| Hugging Face (público, privado o con acceso restringido) | hf download |
La conexión de la máquina |
| S3, Cloudflare R2, Backblaze B2, Google Cloud Storage | rclone copy |
La conexión de la máquina, la región del bucket |
| Google Drive, Dropbox, OneDrive | rclone copy |
Los límites del propio servicio, a menudo más bajos |
| Un enlace directo | wget o curl |
El servidor de origen |
| Tu ordenador, unos pocos GB | scp o la subida de Jupyter |
La velocidad de subida de tu casa |
| Tu ordenador, muchos GB o muchos archivos | rsync, o subir antes a un bucket |
La velocidad de subida de tu casa |
Las velocidades de descarga y de subida de cada máquina se muestran antes de lanzar, en Mbit/s, y el catálogo permite ordenar y filtrar por ellas. Divide para estimar: 100 GB son 800 gigabits, así que a 1000 Mbit/s son unos 13 minutos a toda velocidad, y 15–25 minutos en la práctica. Con una subida doméstica de 40 Mbit/s, los mismos 100 GB tardan cinco horas y media.
Si tus datos solo están en tu ordenador y los vas a usar más de una vez, súbelos una vez a un dataset privado de Hugging Face o a tu propio bucket, por la noche y sin ninguna GPU en marcha. A partir de ahí, cada servidor los descarga a velocidad de centro de datos.
Hugging Face: datasets y modelos
El comando hf viene con el paquete huggingface_hub:
pip install -U huggingface_hub
hf auth login # solo para repos privados o con acceso restringido; pega un token de lectura
hf download <user>/<dataset> --repo-type dataset --local-dir /workspace/data
Añade --include "train/*.parquet" para traer solo una parte de un repo. Las versiones recientes de huggingface_hub descargan por sí solas los archivos guardados en el almacenamiento Xet de Hugging Face en muchos fragmentos en paralelo, así que un solo hf download suele llenar un enlace rápido. Descargar con un token también evita los límites más estrictos de las peticiones anónimas.
Dónde acaban los archivos importa para tu siguiente sesión. Todo lo que esté en /workspace se puede guardar con Guardar y detener; lo que esté en ~/.cache/huggingface desaparece al detener. Si quieres la caché de Hugging Face en la carpeta guardada, fija export HF_HOME=/workspace/hf antes de descargar. Si no (datos públicos que puedes volver a descargar en minutos), déjala fuera y no pagues almacenamiento por ella.
Para devolver los resultados, la misma herramienta sube archivos:
hf upload <user>/<results-repo> /workspace/outputs --repo-type dataset --private
Usa para esto un token de escritura y revócalo cuando termine el proyecto.
rclone desde S3, R2 o Google Drive
rclone se entiende con casi cualquier servicio de almacenamiento. Instálalo en el servidor (el script de instalación necesita unzip, que a menudo falta en las imágenes reducidas):
apt-get update && apt-get install -y unzip curl
curl https://rclone.org/install.sh | bash
Para almacenamiento compatible con S3 puedes saltarte el archivo de configuración y pasar los ajustes como variables de entorno, lo que deja tus claves fuera de /workspace. El nombre del remoto en las variables (aquí S3) se convierte en s3: en el comando:
export RCLONE_CONFIG_S3_TYPE=s3
export RCLONE_CONFIG_S3_PROVIDER=AWS
export RCLONE_CONFIG_S3_REGION=eu-central-1
export RCLONE_CONFIG_S3_ACCESS_KEY_ID=...
export RCLONE_CONFIG_S3_SECRET_ACCESS_KEY=...
rclone copy s3:my-bucket/dataset /workspace/data --transfers 16 --progress
Para Cloudflare R2 o Backblaze B2, pon PROVIDER a Cloudflare u Other y añade RCLONE_CONFIG_S3_ENDPOINT con el endpoint de tu cuenta. --transfers 16 copia 16 archivos a la vez, lo que ayuda mucho cuando hay muchos archivos medianos. Los resultados vuelven por el mismo camino:
rclone copy /workspace/outputs s3:my-bucket/runs/2026-11-12 --progress
Google Drive necesita iniciar sesión en un navegador, y el servidor no tiene navegador. Ejecuta rclone config, añade un remoto de tipo drive, elige el ámbito de solo lectura si solo vas a descargar y responde n cuando te pregunte por la configuración automática. rclone muestra un comando rclone authorize "drive" .... Ejecútalo en tu propio ordenador (con rclone instalado ahí), inicia sesión y pega en el servidor el token que te devuelve. Drive es más lento que un bucket y tiene cuotas diarias de descarga, así que para transferencias grandes o repetidas, un bucket es mejor sitio.
Dale al servidor la clave más restringida que funcione: de solo lectura, para un solo bucket y eliminada al terminar el proyecto. Los motivos están en ¿están seguros mis datos en una GPU alquilada?.
Desde tu ordenador: scp, rsync y la subida de Jupyter
scp copia archivos con la misma clave SSH que usas para conectarte. Coge el puerto de Mis servidores:
scp -P 31001 data.tar root@vramfarm.com:/workspace/
scp -P 31001 root@vramfarm.com:/workspace/outputs.tar .
rsync es mejor para todo lo grande: muestra el progreso, se salta los archivos que ya están y, si se corta la conexión, al volver a ejecutar el mismo comando sigue donde se quedó. Las imágenes de servidor no siempre lo incluyen, así que instálalo antes ahí:
# en el servidor
apt-get update && apt-get install -y rsync
# en tu ordenador (Mac, Linux o WSL)
rsync -avP -e "ssh -p 31001" ./data/ root@vramfarm.com:/workspace/data/
rsync -avP -e "ssh -p 31001" root@vramfarm.com:/workspace/outputs/ ./outputs/
En Windows, scp funciona en PowerShell y rsync se ejecuta dentro de WSL; la guía de SSH en Windows cubre los dos, y también WinSCP si prefieres una ventana.
La subida de Jupyter (arrastrar archivos al explorador de archivos) es lo más fácil y va bien para scripts, notebooks, un LoRA o unos cientos de megas de imágenes. Con varios gigas se vuelve frágil: la pestaña del navegador tiene que seguir abierta, una subida interrumpida empieza de cero y soltar 10 000 archivos de golpe es lento. Para descargar, clic derecho → Download, archivo por archivo, así que empaqueta antes la carpeta en un archivo.
Empaqueta, y comprime solo lo que se reduce
Muchos archivos pequeños son lo más lento que puedes mover. Un millón de imágenes de 100 KB se copian mucho más despacio que un único archivo de 100 GB, porque cada archivo cuesta un viaje de ida y vuelta. Empaquétalos antes, o guarda el dataset en fragmentos (tar, Parquet, WebDataset) desde el principio:
tar cf images.tar images/ # sin compresión: los JPEG no se reducen
tar czf logs.tgz logs/ # texto, CSV y JSON se reducen entre 3 y 10 veces
Las imágenes, el vídeo, el audio, los pesos de modelos y Parquet ya están comprimidos, así que gzip solo cuesta tiempo de CPU. El texto se comprime bien. Si tienes zstd instalado (apt-get install -y zstd), tar --zstd -cf data.tar.zst data/ empaqueta y desempaqueta varias veces más rápido que gzip con un tamaño parecido.
Descomprime mientras descargas cuando el archivo está detrás de una URL, para que nunca ocupe el doble de disco:
curl -L "https://example.com/dataset.tar.gz" | tar xz -C /workspace/data
Revisa el disco antes de empezar. El tamaño del disco lo eliges al lanzar, y un archivo comprimido más su copia descomprimida necesitan el doble de espacio durante un rato. Si te sale «No space left on device»:
df -h /workspace # cuánto está lleno el disco
du -sh /workspace/* | sort -h # qué ocupa el espacio
rm -rf ~/.local/share/Trash/* # los archivos borrados en Jupyter van primero aquí
Esa última línea pilla a mucha gente: los archivos que borras en el explorador de archivos de Jupyter se mueven a una papelera y siguen ocupando disco hasta que la vacías. Según la configuración, la papelera también puede ser una carpeta oculta .Trash-0 en la raíz de /workspace; ls -a /workspace la muestra, y se incluiría en una carpeta guardada, así que vacíala también.
Cuánto cuesta y dónde deberían estar los datos
El tráfico se factura por GB en los dos sentidos con la tarifa propia de la máquina, que aparece en el catálogo antes de lanzar. La mayoría de las máquinas cobran alrededor de un céntimo por GB o menos, algunas no cobran nada y algunas máquinas con B200 y H200 cobran más. Un dataset de 100 GB de entrada y 5 GB de resultados de salida, a un céntimo por GB, sale por unos 1,05 €.
El coste mayor suele ser la GPU esperando. Veinte minutos de descarga en una H100 cuestan 1,30 €; los mismos veinte minutos en una RTX 4090 cuestan 0,20 €. Así que empieza la descarga lo primero, y aprovecha la espera para subir tus scripts o revisar la configuración.
¿Debería estar el dataset en tu carpeta guardada? El almacenamiento cuesta 0,03 € por GB al mes, así que 100 GB son 100 × 0,03 € al mes. Restaurar la carpeta en un servidor nuevo también cuenta como tráfico, y no siempre es más rápido que Hugging Face o un bucket en una buena región. En la práctica:
| Datos | Dónde guardarlos |
|---|---|
| Datasets públicos y pesos de modelos | En ningún sitio; vuelve a descargarlos cada vez |
| Tu propio dataset, usado cada semana | Tu bucket o un repo privado de Hugging Face, o la carpeta guardada si es pequeño |
| Datos que solo están en tu portátil | Súbelos una vez a un bucket o a Hugging Face y luego descárgalos desde ahí |
| Checkpoints, LoRA, resultados | La carpeta guardada, y una copia en casa o en tu bucket |
El cálculo completo de conservar o volver a descargar, con números, está en qué pasa con tus archivos al detener una GPU.
Antes de detener el servidor, haz un último rsync o rclone copy de tus resultados, o pulsa Guardar y detener. El disco del servidor se elimina con el servidor, y un dataset que puedes volver a descargar en 15 minutos es fácil de reponer. Una semana de resultados, no.