12 novembre 2026 · Équipe VRAMfarm
Rendu Blender sur un GPU loué : Cycles sans interface, plusieurs machines, Octane et Redshift
Le client veut 240 images d’un survol d’intérieur pour demain matin. Chaque image prend 4 minutes sur votre RTX 3070 à la maison : le travail demande donc 16 heures, et vous en avez 10. Sur des cartes louées, les mêmes images prennent environ 1,5 minute chacune sur une RTX 4090, et réparties sur quatre serveurs, toute la séquence est terminée en moins de deux heures, pour à peu près le même prix qu’un rendu sur une seule carte. Cycles, le moteur de Blender, s’y prête bien : il tourne en ligne de commande, ne demande aucune licence et utilise le ray tracing OptiX de NVIDIA sur n’importe quelle carte RTX.
Quelle carte : les cœurs RT comptent plus que l’étiquette data center
Cycles avec OptiX utilise les cœurs RT des cartes RTX pour le ray tracing. Les gros GPU de data center (A100, H100, H200, B200) n’ont aucun cœur RT. Cycles tourne quand même dessus, mais une RTX 4090 rend la même image plus vite pour une fraction du prix horaire. Pour le rendu, regardez les cartes RTX et la série L.
| Carte | VRAM | Cœurs RT | Pour le rendu |
|---|---|---|---|
| RTX 3090 | 24 Go | 2e génération | Bon marché à l’heure, environ deux fois moins rapide qu’une 4090 |
| RTX 4090 | 24 Go | 3e génération | Le choix par défaut : rapide et très disponible |
| RTX 5090 | 32 Go | 4e génération | Environ un tiers plus rapide qu’une 4090, 8 Go de plus |
| RTX A6000 | 48 Go | 2e génération | Grosses scènes à la vitesse d’une 3090 |
| L40S | 48 Go | 3e génération | Grosses scènes à une vitesse proche de la 4090 |
| RTX PRO 6000 | 96 Go | 4e génération | Très grosses scènes, vitesse d’une 5090 |
| A100, H100 | 80 Go | aucun | Chères pour le rendu ; à éviter sauf si la mémoire l’impose |
Ces rapports sont approximatifs. Le benchmark Blender Open Data publie des scores mesurés pour la plupart de ces cartes et pour chaque version de Blender : c’est le meilleur moyen de comparer. Rapportez ensuite le score au prix horaire sur notre page des tarifs : la 3090 l’emporte souvent par image pour les longs rendus de nuit, la 4090 et la 5090 quand l’échéance approche.
Combien de VRAM demande une scène
Sur le GPU, Cycles a besoin de toute la scène en mémoire vidéo : géométrie, structure d’accélération (BVH), textures et tampons d’image. Si elle ne tient pas, Cycles peut déplacer une partie des données vers la RAM système, mais le rendu ralentit fortement, et les très grosses scènes échouent purement et simplement.
Quelques repères :
- Packshots, motion design, intérieurs simples : 2 à 8 Go. N’importe quelle carte du catalogue.
- Archviz détaillée avec des textures 4K : 8 à 20 Go. Cartes de 24 Go.
- Végétation dispersée, grands extérieurs, nombreuses textures 8K : 20 à 45 Go. Une texture 8K non compressée avec alpha pèse environ 256 Mo en 8 bits et quatre fois plus en flottant : une cinquantaine s’additionnent vite. Cartes de 48 Go.
- Scènes de cinéma, foules ou forêts instanciées immenses : 48 à 96 Go. RTX PRO 6000.
Pour connaître votre chiffre, rendez une image sur votre ordinateur et lisez la mémoire maximale dans la barre d’état, ou rendez une image de test sur le serveur en surveillant nvidia-smi. Simplifiez là où cela ne coûte rien : les textures des objets lointains ont rarement besoin d’être en 8K, et la limite de taille de texture de Cycles (Render Properties → Simplify) permet de tester rapidement le gain. Le guide de la VRAM applique la même logique aux modèles d’IA.
Mettre la scène sur le serveur
Un fichier .blend qui se rend parfaitement chez vous échoue souvent sur un serveur parce qu’il pointe vers des textures dans C:\Users\.... Avant l’envoi :
- File → External Data → Make Paths Relative, puis Pack Resources pour intégrer les textures au .blend. Ou bien gardez-les dans des dossiers à côté du fichier, avec des chemins relatifs, et zippez tout le dossier du projet.
- Précalculez les simulations (fluides, tissus, particules, caches de geometry nodes) chez vous, et incluez les dossiers de cache. Un serveur ne resimulera pas ce qu’il ne trouve pas.
- Vérifiez les add-ons. Ceux qui interviennent au rendu doivent aussi être installés dans le Blender du serveur. La plupart des scènes n’en ont besoin d’aucun.
- Réglez la sortie dans le fichier : format (PNG, ou OpenEXR pour un compositing ultérieur), résolution, échantillons, plage d’images. Pour les animations, activez Persistent Data (Render Properties → Performance) : Cycles garde alors la scène chargée d’une image à l’autre.
Envoyez le zip avec le bouton d’upload de Jupyter, avec scp/rsync en SSH (guide de la clé SSH), ou déposez-le sur votre propre stockage cloud et téléchargez-le sur le serveur avec wget ou rclone. Avec plusieurs machines, cette dernière option est la plus simple : chaque serveur récupère le même lien. Les téléchargements comptent comme du trafic au tarif de la machine, affiché avant le lancement.
Installer Blender et rendre en ligne de commande
Démarrez un serveur PyTorch + Jupyter vide ; peu importe qu’il soit livré avec PyTorch. Ouvrez un terminal dans Jupyter ou en SSH. Installez les quelques bibliothèques système qu’attend Blender, puis téléchargez la même version de Blender que chez vous (copiez le lien Linux sur blender.org) :
apt-get update && apt-get install -y xz-utils libxrender1 libxi6 libxkbcommon0 \
libxxf86vm1 libxfixes3 libsm6 libgl1 libegl1
cd /workspace
wget <Linux link for your Blender version from blender.org/download>
tar -xf blender-*-linux-x64.tar.xz && mv blender-*-linux-x64 blenderSi Blender signale au démarrage qu’il manque un fichier .so, installez le paquet indiqué et réessayez. Enregistrez ensuite ceci sous /workspace/gpu.py. Ce script fait passer Cycles en OptiX sur tous les GPU de la machine, quoi qu’en dise le fichier .blend :
import bpy
prefs = bpy.context.preferences.addons["cycles"].preferences
prefs.compute_device_type = "OPTIX"
prefs.get_devices()
for d in prefs.devices:
d.use = d.type == "OPTIX"
print("device:", d.name, d.type, d.use)
bpy.context.scene.cycles.device = "GPU"Lancez le rendu de l’animation :
cd /workspace/project
nohup /workspace/blender/blender -b scene.blend --python /workspace/gpu.py \
-o /workspace/render/frame_#### -s 1 -e 240 -a > /workspace/render.log 2>&1 &
tail -f /workspace/render.logL’ordre compte : le script Python et les options de sortie, de début et de fin doivent venir avant -a. Le journal affiche d’abord les périphériques. Si aucun périphérique OptiX n’apparaît, le conteneur ne voit pas la bibliothèque OptiX ; remplacez "OPTIX" par "CUDA" aux deux endroits. CUDA est plus lent qu’OptiX sur les cartes RTX, mais fonctionne partout. Rendre une seule image avec -f 1 au lieu de -a est un bon test avant le rendu complet.
nohup maintient le rendu quand vous fermez le navigateur ou perdez la connexion. Un rendu en cours occupe le GPU, la protection contre l’inactivité ne l’arrête donc pas. Une fois la dernière image écrite, le GPU se calme : si rien n’est connecté, vous recevez un avertissement d’inactivité au bout d’environ deux heures, et une heure plus tard le serveur enregistre /workspace (images comprises) et s’arrête. L’arrêter vous-même dès que les images sont téléchargées revient moins cher.
Plusieurs machines pour une même échéance
Cycles rend les images indépendamment les unes des autres : la ferme la plus simple consiste donc à découper la plage d’images.
| Serveur | Plage dans la commande |
|---|---|
| 1 | -s 1 -e 60 |
| 2 | -s 61 -e 120 |
| 3 | -s 121 -e 180 |
| 4 | -s 181 -e 240 |
Quatre, c’est aussi le nombre maximal de serveurs qu’un compte peut faire tourner en même temps. Lancez-les sur le même modèle de carte pour qu’ils finissent ensemble, appliquez la même installation sur chacun (un petit script shell collé dans chaque terminal évite les erreurs), et démarrez chacun avec sa propre plage. Une fois terminé, zippez /workspace/render sur chaque serveur, téléchargez, et réunissez les images dans un seul dossier. Votre logiciel de montage ou le séquenceur vidéo de Blender les assemble.
Quatre serveurs coûtent à peu près le même temps GPU qu’un seul serveur qui rend toutes les images, plus les minutes d’installation sur chacun (téléchargement de Blender, envoi de la scène, une dizaine de minutes) et le minimum de 15 minutes par lancement. Vous payez un peu plus pour finir quatre fois plus tôt. Pour des travaux plus gros ou réguliers, l’API VRAMfarm démarre, liste et arrête des serveurs depuis un script : un script de rendu peut ainsi arrêter son propre serveur dès que sa dernière image est écrite.
Octane et Redshift : apportez votre licence
Les deux tournent sur des cartes NVIDIA louées, mais contrairement à Blender, ce sont des moteurs commerciaux, et la licence est à votre charge. Nous n’en fournissons pour aucun des deux.
OctaneRender (OTOY) fonctionne uniquement sur GPU et tourne sous Linux. Vous vous connectez avec votre compte OTOY sur chaque serveur, et votre niveau d’abonnement détermine combien de GPU peuvent rendre simultanément ; vérifiez-le avant de démarrer quatre machines. Ce sont les conditions d’OTOY qui disent si une licence peut servir sur du matériel loué : lisez-les pour votre formule. L’édition Blender d’Octane est une version distincte de Blender, avec sa propre installation ; suivez la documentation d’OTOY pour la rendre en ligne de commande.
Redshift (Maxon) est licencié via votre compte Maxon, à raison d’un poste par machine qui rend en même temps. Sur un serveur Linux sans interface, vous vous connectez avec l’outil de licence en ligne de commande de Maxon. Le rendu lui-même passe par redshiftCmdLine avec des fichiers de scène .rs exportés, ou par le moteur de rendu par lots de l’application hôte (Houdini, Maya, ou le rendu en ligne de commande de Cinema 4D). Vérifiez les conditions actuelles de Maxon pour les nœuds de rendu avant de prévoir un travail sur plusieurs machines.
Deux points pratiques valent pour les deux. Installez la version qui correspond à la vôtre, pour que la scène se rende à l’identique. Et vérifiez la version du pilote de la machine avant le lancement, car les moteurs de rendu GPU exigent un pilote minimal ; le guide CUDA et pilotes explique quoi regarder. Les outils qui ont besoin d’un bureau, comme l’Unreal Editor ou l’interface de DaVinci Resolve, conviennent mal aux serveurs sans écran et ne sont pas traités ici.
Coût par image : calculez-le avant de louer
La formule est simple : prix horaire × minutes par image ÷ 60. Le plus difficile, ce sont les minutes par image ; mesurez-les donc : rendez l’image 1 sur le serveur loué et multipliez. Un lancement de test coûte au moins le minimum de 15 minutes, un peu plus avec l’installation.
Notre exemple de 240 images, à 1,5 minute par image sur une RTX 4090 :
- Un serveur : 240 × 1,5 = 360 minutes, plus 10 minutes d’installation : environ 6 h 10 min, 3,64 €, terminé en six heures environ.
- Quatre serveurs : 60 × 1,5 = 90 minutes chacun, plus 10 minutes d’installation : 100 minutes chacun, 6 h 40 min au total, 3,94 €, terminé en moins de deux heures.
- Sur une RTX 3090, à environ 3 minutes par image, un seul serveur : environ 12 h 10 min, 3,65 €, si l’échéance le permet.
Ajoutez le trafic de la scène et des images au tarif de la machine. Les images en représentent souvent la plus grande part : 240 images OpenEXR en 1080p peuvent peser plusieurs gigaoctets.
Pour réduire les minutes par image, les leviers habituels de Cycles sont moins d’échantillons avec débruitage (OptiX ou OpenImageDenoise), l’échantillonnage adaptatif, Persistent Data pour les animations, et moins de rebonds de rayons là où la scène n’en a pas besoin. Testez-les sur l’image 1 avant de lancer la ferme, car chaque seconde gagnée est multipliée par 240.