12 novembre 2026 · Équipe VRAMfarm

Transférer des données vers un serveur GPU et retour : Hugging Face, rclone, rsync, scp

Envoyer un dataset de 80 Go depuis chez vous sur une connexion à 40 Mbit/s prend environ quatre heures et demie, et si un serveur GPU tourne déjà, vous payez chacune d’elles. Les mêmes 80 Go récupérés depuis Hugging Face ou un bucket S3 sur une machine reliée à 1 Gbit/s prennent 15 à 20 minutes. La règle est donc simple : les données doivent aller du cloud vers le serveur, pas depuis votre portable, et l’envoi lent, si vous en avez besoin, ne doit avoir lieu qu’une fois, sans GPU qui attend.

Choisir la méthode selon l’endroit où se trouvent les données

Les débits de téléchargement et d’envoi de chaque machine s’affichent avant le lancement, en Mbit/s, et le catalogue permet de trier et de filtrer selon ces valeurs. Divisez pour estimer : 100 Go font 800 gigabits, soit environ 13 minutes à pleine vitesse à 1 000 Mbit/s, et 15 à 25 minutes en pratique. Avec un débit d’envoi domestique de 40 Mbit/s, les mêmes 100 Go prennent cinq heures et demie.

Si vos données n’existent que sur votre ordinateur et que vous allez vous en servir plus d’une fois, envoyez-les une fois pour toutes vers un dataset Hugging Face privé ou votre propre bucket, pendant la nuit, sans GPU en marche. Ensuite, chaque serveur les récupère à la vitesse d’un data center.

Hugging Face : datasets et modèles

La commande hf est fournie avec le paquet huggingface_hub :

pip install -U huggingface_hub
hf auth login                      # seulement pour les dépôts privés ou à accès restreint ; collez un token en lecture
hf download <user>/<dataset> --repo-type dataset --local-dir /workspace/data

Ajoutez --include "train/*.parquet" pour ne récupérer qu’une partie d’un dépôt. Les versions récentes de huggingface_hub téléchargent d’elles-mêmes les fichiers stockés sur le stockage Xet de Hugging Face en de nombreux morceaux parallèles : un seul hf download suffit donc généralement à saturer une liaison rapide. Télécharger avec un token évite aussi les limites plus strictes appliquées aux requêtes anonymes.

L’endroit où arrivent les fichiers compte pour votre prochaine session. Tout ce qui se trouve dans /workspace peut être conservé avec Enregistrer et arrêter ; tout ce qui se trouve dans ~/.cache/huggingface disparaît à l’arrêt. Si vous voulez le cache Hugging Face dans le dossier enregistré, faites export HF_HOME=/workspace/hf avant de télécharger. Sinon (des données publiques que vous pouvez récupérer à nouveau en quelques minutes), laissez-le à l’extérieur et ne payez aucun stockage pour lui.

Pour renvoyer les résultats, le même outil sait envoyer :

hf upload <user>/<results-repo> /workspace/outputs --repo-type dataset --private

Utilisez pour cela un token en écriture, et révoquez-le à la fin du projet.

rclone depuis S3, R2 ou Google Drive

rclone sait parler à presque tous les services de stockage. Installez-le sur le serveur (le script d’installation a besoin de unzip, souvent absent des images allégées) :

apt-get update && apt-get install -y unzip curl
curl https://rclone.org/install.sh | bash

Pour un stockage compatible S3, vous pouvez vous passer de fichier de configuration et transmettre les réglages en variables d’environnement, ce qui garde vos clés hors de /workspace. Le nom du remote dans les variables (ici S3) devient s3: dans la commande :

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

Pour Cloudflare R2 ou Backblaze B2, mettez PROVIDER à Cloudflare ou Other et ajoutez RCLONE_CONFIG_S3_ENDPOINT avec l’endpoint indiqué dans votre compte. --transfers 16 copie 16 fichiers à la fois, ce qui aide beaucoup avec de nombreux fichiers de taille moyenne. Les résultats repartent de la même façon :

rclone copy /workspace/outputs s3:my-bucket/runs/2026-11-12 --progress

Google Drive demande une connexion dans un navigateur, et le serveur n’en a pas. Lancez rclone config, ajoutez un remote de type drive, choisissez la portée en lecture seule si vous n’avez qu’à télécharger, et répondez n à la question sur la configuration automatique. rclone affiche une commande rclone authorize "drive" .... Lancez-la sur votre propre ordinateur (où rclone doit être installé), connectez-vous, puis collez sur le serveur le token qu’elle affiche. Drive est plus lent qu’un bucket et impose des quotas de téléchargement quotidiens : pour des transferts gros ou répétés, un bucket est un meilleur choix.

Donnez au serveur la clé la plus restreinte qui fonctionne : lecture seule, un seul bucket, supprimée après le projet. Les raisons sont expliquées dans l’article sur la sécurité des données sur un GPU loué.

Depuis votre ordinateur : scp, rsync et l’envoi par Jupyter

scp copie des fichiers avec la clé SSH qui vous sert à vous connecter. Prenez le port dans Mes serveurs :

scp -P 31001 data.tar root@vramfarm.com:/workspace/
scp -P 31001 root@vramfarm.com:/workspace/outputs.tar .

rsync convient mieux à tout ce qui est volumineux : il affiche la progression, saute les fichiers déjà présents et, si la connexion tombe, relancer la même commande reprend là où elle s’était arrêtée. Les images des serveurs ne l’incluent pas toujours : installez-le d’abord sur le serveur :

# sur le serveur
apt-get update && apt-get install -y rsync

# sur votre ordinateur (Mac, Linux ou 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/

Sous Windows, scp fonctionne dans PowerShell et rsync tourne dans WSL ; le guide SSH pour Windows couvre les deux, ainsi que WinSCP si vous préférez une fenêtre.

L’envoi par Jupyter (glisser des fichiers dans l’explorateur de fichiers) est le plus simple et convient très bien pour des scripts, des notebooks, un LoRA ou quelques centaines de mégaoctets d’images. Pour plusieurs gigaoctets, il devient fragile : l’onglet du navigateur doit rester ouvert, un envoi interrompu repart de zéro, et déposer 10 000 fichiers d’un coup est lent. Le téléchargement se fait par clic droit → Download, un fichier à la fois : regroupez donc d’abord un dossier dans une archive.

Archivez, et ne compressez que ce qui rétrécit

Beaucoup de petits fichiers, c’est ce qu’il y a de plus lent à déplacer. Un million d’images de 100 Ko se copient bien plus lentement qu’une seule archive de 100 Go, car chaque fichier coûte un aller-retour. Regroupez-les d’abord, ou stockez dès le départ le dataset en shards (tar, Parquet, WebDataset) :

tar cf images.tar images/           # pas de compression : les JPEG ne rétrécissent pas
tar czf logs.tgz logs/              # le texte, le CSV et le JSON rétrécissent de 3 à 10 fois

Les images, la vidéo, l’audio, les poids de modèles et le Parquet sont déjà compressés : gzip ne fait que consommer du temps CPU. Le texte se compresse bien. Si zstd est installé (apt-get install -y zstd), tar --zstd -cf data.tar.zst data/ archive et désarchive plusieurs fois plus vite que gzip pour une taille similaire.

Décompressez pendant le téléchargement quand l’archive se trouve derrière une URL : elle n’occupe ainsi jamais deux fois l’espace disque.

curl -L "https://example.com/dataset.tar.gz" | tar xz -C /workspace/data

Vérifiez le disque avant de commencer. Vous choisissez la taille du disque au lancement, et une archive plus sa copie décompressée occupent le double de place pendant un moment. Si vous obtenez « No space left on device » :

df -h /workspace                        # taux de remplissage du disque
du -sh /workspace/* | sort -h           # ce qui occupe la place
rm -rf ~/.local/share/Trash/*           # les fichiers supprimés dans Jupyter arrivent d'abord ici

Cette dernière ligne en surprend beaucoup : les fichiers que vous supprimez dans l’explorateur de fichiers de Jupyter partent dans une corbeille et continuent d’occuper le disque tant que vous ne la videz pas. Selon la configuration, la corbeille peut aussi être un dossier caché .Trash-0 à la racine de /workspace ; ls -a /workspace le montre, et il serait inclus dans un dossier enregistré : videz-le aussi.

Ce que cela coûte, et où garder les données

Le trafic est facturé au Go dans les deux sens, au tarif propre à la machine, affiché dans le catalogue avant le lancement. La plupart des machines facturent environ un centime par Go, voire moins, certaines rien du tout, et certaines machines B200 et H200 davantage. Un dataset de 100 Go à l’aller et 5 Go de résultats au retour, à un centime par Go, reviennent à environ 1,05 €.

Le coût le plus important est généralement celui du GPU qui attend. Vingt minutes de téléchargement sur une H100 coûtent 1,30 € ; les mêmes vingt minutes sur une RTX 4090 coûtent 0,20 €. Lancez donc le téléchargement en tout premier, et profitez de l’attente pour envoyer vos scripts ou vérifier la configuration.

Le dataset doit-il rester dans votre dossier enregistré ? Le stockage coûte 0,03 € par Go et par mois : 100 Go reviennent donc à 100 × 0,03 € par mois. Restaurer le dossier sur un nouveau serveur compte aussi comme du trafic, et ce n’est pas toujours plus rapide que Hugging Face ou un bucket dans une bonne région. En pratique :

Le calcul complet entre conserver et retélécharger, chiffres à l’appui, se trouve dans ce que deviennent vos fichiers quand vous arrêtez un GPU.

Avant d’arrêter, lancez un dernier rsync ou rclone copy de vos résultats, ou cliquez sur Enregistrer et arrêter. Le disque du serveur est supprimé avec le serveur, et un dataset que vous pouvez retélécharger en 15 minutes se remplace facilement. Une semaine de résultats, non.