Qu'est-ce qu'une render farm GPU ? Fonctionnement et cas d'usage

Introduction

Une render farm GPU est un parc de machines construites autour de cartes graphiques dédiées au rendu, reliées par un scheduler de jobs et un stockage partagé, afin que de nombreuses images d'une scène GPU-native soient rendues en parallèle plutôt qu'en file d'attente sur une seule machine. Chez Super Renders Farm, nous en exploitons une aux côtés d'un parc CPU bien plus vaste, et les questions que nous posent les artistes sont toujours les mêmes : en quoi cela diffère-t-il de la render farm CPU, en quoi cela diffère-t-il des deux cartes supplémentaires de mon poste de travail, et que coûte réellement une carte-heure ?

Ce guide répond à ces questions du point de vue de l'opérateur. Il couvre ce qu'est réellement une render farm GPU, comment les éléments s'articulent — nœuds, scheduler, synchronisation des assets, livraison des sorties — les spécificités matérielles concrètes qui déterminent si votre scène s'y adapte réellement (VRAM, comportement out-of-core, génération de carte), quels moteurs de rendu y ont leur place et lesquels non, où une render farm GPU se justifie réellement face à une render farm CPU ou une machine multi-GPU locale et où ce n'est pas le cas, et comment fonctionne le calcul de facturation avant d'y engager une deadline. Il s'adresse aux artistes et studios qui veulent comprendre la mécanique avant d'évaluer un service en particulier, le nôtre y compris.

Ce qu'est réellement une render farm GPU

En retirant le vocabulaire marketing, une render farm GPU est constituée de trois systèmes qui fonctionnent ensemble :

• Les nœuds de rendu. Des machines dont la puissance de rendu provient d'une ou plusieurs cartes GPU dédiées au rendu plutôt que de cœurs CPU. Le débit de calcul de la carte et sa capacité VRAM définissent ce que chaque nœud peut prendre en charge.
• Un scheduler de jobs. Un logiciel qui accepte les jobs soumis, les découpe en tâches par image, les assigne aux nœuds disponibles et adaptés, relance les échecs, et rapporte la progression. Chaque farm en possède un ; on ne le remarque en général que lorsqu'il fonctionne mal.
• Un stockage partagé et une synchronisation des assets. Une couche de fichiers commune qui contient votre scène, chaque texture et cache qu'elle référence, ainsi que les sorties rendues — afin que n'importe quel nœud puisse traiter n'importe quelle image sans que votre poste de travail soit impliqué.

Ce qui fait d'une farm une farm GPU n'est pas une préférence matérielle. C'est l'ensemble des moteurs de rendu qu'elle sert : Redshift, Octane, V-Ray GPU, ainsi que Cycles et EEVEE de Blender en mode GPU exécutent tous leur rendu sur la carte graphique, si bien que la farm qui les sert doit être construite autour de cartes plutôt que de cœurs.

Ce même matériel vous parvient sous deux modèles de service très différents. Une render farm GPU managée fonctionne selon un flux upload-rendu-téléchargement : vous préparez une scène, le pipeline de la farm la synchronise, la rend avec des licences de moteur mutualisées, et vous retourne les images — sans session bureau à distance, sans installation logicielle de votre côté. Le GPU IaaS, à l'inverse, vous loue des machines virtuelles GPU brutes : vous vous y connectez à distance, installez votre DCC et votre moteur, apportez vos licences, et exploitez les machines vous-même. Les deux sont des render farms GPU au sens matériel ; sur le plan opérationnel, ce sont des produits différents avec des modes de défaillance différents.

Cet article reste au niveau des concepts. Si vous êtes en pleine évaluation et cherchez plutôt des spécificités de service — caractéristiques des nœuds, couverture des moteurs, tarifs actuels — la page GPU cloud render farm contient ces informations.

Comment fonctionne une render farm GPU : nœuds, scheduler et synchronisation des assets

Un job de rendu traverse quatre étapes, et l'essentiel de ce qui peut mal se passer se passe aux frontières entre elles.

Préparation et envoi. Le fichier de scène est la petite partie. Une scène de production référence des textures, des caches de simulation, des proxies et des données de plugin dispersés sur plusieurs disques de projet, et chacune de ces dépendances doit voyager avec elle. L'échec le plus fréquent sur un premier job que nous constatons est un asset référencé depuis un chemin local qui n'existe que sur la machine de l'artiste — l'image se rend, mais une texture ne trouve rien à résoudre. Un bon outillage de farm collecte les dépendances au moment de la soumission et valide les chemins avant qu'un nœud ne passe du temps sur le job. Chez Super Renders Farm, la synchronisation des assets est aussi incrémentale : lors de votre deuxième soumission, seuls les fichiers modifiés voyagent, ce qui fait toute la différence entre un ré-envoi de 40 minutes et un ré-envoi de 40 secondes lorsque vous itérez contre une deadline.

File d'attente et répartition. Le scheduler découpe une animation en tâches par image (ou par lot d'images) et les assigne selon la disponibilité des nœuds, l'adéquation VRAM, et la correspondance de version du moteur. Il replace en file les images d'un nœud qui plante, isole un nœud qui échoue de façon répétée, et maintient le reste du parc occupé. C'est la partie de la farm que vous louez sans jamais la voir — et c'est en grande partie pour cela qu'une farm se comporte différemment d'un simple tas de VM louées.

Exécution sur le nœud. Chaque nœud charge exactement les versions de moteur et de plugin sur lesquelles le job a été figé, vérifie une licence de rendu dans l'inventaire mutualisé de la farm, charge les données de scène en mémoire GPU, rend les images qui lui sont assignées, et écrit les sorties ainsi que les logs vers le stockage partagé. Des watchdogs détectent les images qui restent bloquées plutôt que d'échouer, ce qui compte sur les moteurs GPU où un dépassement de mémoire peut figer un process plutôt que de le terminer.

Sortie et livraison. Les images terminées arrivent dans le stockage de sortie et vous reviennent via l'interface web, SFTP, ou un client de bureau. Les sorties n'y restent pas indéfiniment — sur notre farm, la fenêtre de rétention est de 45 jours après la fin du job — la livraison fait donc partie du pipeline, pas un point secondaire.

Spécificités matérielles GPU : VRAM, génération de carte, et ce que signifie l'out-of-core pour la taille de scène

La caractéristique la plus importante au niveau du nœud sur une render farm GPU est la VRAM, pas la fréquence d'horloge ni le nombre de cœurs — et il vaut la peine d'expliquer pourquoi concrètement.

Ce que contient réellement un nœud GPU. Sur notre parc GPU, chaque nœud fonctionne avec une carte NVIDIA RTX 5090 dotée de 32 Go de VRAM. Ce chiffre résume tout pour la planification de scène : lorsque la géométrie, les textures et les données de simulation d'une scène chargées sur la carte dépassent ce plafond, le moteur doit y remédier d'une manière ou d'une autre, et aucune des options n'est gratuite.

Ce que fait réellement le rendu out-of-core. Les moteurs GPU modernes — Redshift et Octane en particulier — proposent des modes out-of-core (ou « GPU + mémoire système ») qui déversent dans la RAM système les données que la carte ne peut pas contenir et les rediffusent au besoin. C'est une véritable soupape de sécurité, pas une solution à utiliser par défaut : le streaming via PCIe est nettement plus lent que la lecture directe depuis la VRAM, si bien qu'une scène qui déverse massivement peut perdre une grande partie de l'avantage de vitesse qui rendait le rendu GPU attractif au départ. L'out-of-core vous permet de terminer une scène surdimensionnée ; il ne restaure pas la performance native GPU une fois passé le plafond VRAM.

Ce que cela signifie pour la taille de scène en pratique. Une scène construite à partir de géométrie instanciée efficace et de textures de taille raisonnable — la plupart des travaux de motion design Cinema 4D/Redshift, la plupart des visualisations produit — tient confortablement dans 32 Go et se rend à pleine vitesse GPU. Une scène avec une géométrie unique dense, des jeux de textures 8K et plus répartis sur de nombreux matériaux uniques, ou des données volumétriques/de particules lourdes (le type de charge courant en VFX et dans certaines scènes d'archviz riches en végétation) a plus de chances de heurter le plafond VRAM et de basculer soit vers le streaming out-of-core, soit vers une migration vers une render farm CPU, où la RAM système (96 à 256 Go sur nos nœuds CPU) offre une marge bien plus large. Vérifier l'empreinte VRAM réelle de votre scène par rapport à la fiche technique de la carte — et non par rapport à une hypothèse générique du type « le rendu GPU est rapide » — est l'étape de pré-vérification la plus utile avant de soumettre à une render farm GPU.

La génération de carte compte aussi, mais moins que la VRAM. Les cartes plus récentes apportent davantage de cœurs CUDA et une bande passante mémoire plus rapide, ce qui augmente le débit par carte — mais une carte plus rapide avec le même plafond VRAM se heurte toujours au même mur sur une scène surdimensionnée. Lorsque vous évaluez une render farm GPU, demandez le modèle de carte et le chiffre de VRAM ensemble ; une promesse de vitesse sans chiffre de VRAM ne vous dit rien sur la compatibilité réelle de votre scène.

Quels moteurs de rendu nécessitent une render farm GPU, et lesquels fonctionnent sur les deux

L'identité du moteur est le prisme le plus utile pour comprendre ce qui a sa place sur une render farm GPU, car une « farm GPU » se définit par les moteurs qu'elle sert, pas par une préférence matérielle.

Moteur	GPU uniquement, CPU uniquement, ou les deux	Ce que cela signifie pour le choix de farm
Redshift	GPU uniquement (Maxon)	Aucun repli CPU n'existe — un job Redshift nécessite un nœud compatible GPU. Moteur central de la farm GPU ; le type de job GPU le plus courant que nous voyons venir des pipelines Cinema 4D.
Octane	GPU uniquement (OTOY)	Même constat — Octane n'a aucun chemin de rendu CPU. Conçu pour les cartes ; son benchmark sert même de base à la facturation des farms (détails plus loin).
V-Ray GPU	Mode GPU d'un moteur compatible CPU/GPU (Chaos)	La même licence V-Ray peut rendre en CPU ou en GPU selon le mode — de nombreux pipelines V-Ray rendent encore côté CPU, si bien que V-Ray seul ne détermine pas le type de farm ; c'est le mode choisi qui le détermine.
Cycles	CPU et GPU, open source (Blender)	Fonctionne sur les deux types de farm. Sur notre farm, les jobs Cycles constituent le chemin GPU standard côté Blender.
EEVEE	GPU (moteur temps réel/rasterisation de Blender)	GPU uniquement en pratique — EEVEE est conçu autour du pipeline graphique, pas du path tracing CPU. EEVEE est pris en charge sur notre parc GPU aux côtés de Cycles ; ce n'est pas un moteur de farm CPU.
Corona	CPU uniquement (Chaos)	Aucun mode GPU n'existe. Les jobs Corona restent exclusivement sur les render farms CPU.
Arnold	CPU dans la plupart des pipelines de production (un mode GPU existe)	Généralement territoire de la farm CPU ; sur notre farm, Arnold rend côté CPU. Autodesk propose bien un mode GPU, mais les pipelines de production le font encore majoritairement tourner en CPU.

Trois remarques opérationnelles se rattachent à ce tableau. D'abord, la correspondance de version est non négociable : un nœud de farm doit faire tourner exactement les versions de moteur et de plugin sur lesquelles votre scène a été créée, ce qui explique pourquoi l'outillage de soumission des farms fige les versions par job plutôt que d'espérer que cela fonctionne. Ensuite, la licence fait partie de la question du moteur — sur une farm managée, les licences de rendu pour Redshift, Octane, V-Ray, Corona et Arnold sont mutualisées et incluses dans le tarif, et des partenariats officiels avec Maxon et Chaos soutiennent cette gestion de licence de notre côté. Cycles n'entraîne aucun coût de licence, étant open source sous l'ombrelle de Blender, et il en va de même pour EEVEE. Sur le GPU IaaS, chacune de ces licences est votre problème à provisionner par machine.

Troisièmement, la VRAM est la caractéristique à vérifier avant tout chiffre de vitesse, pour les raisons couvertes dans la section matérielle ci-dessus. Nous publions des données mesurées de performance cloud rendering RTX 5090 sur V-Ray GPU, Redshift et Octane précisément parce que le comportement par moteur à taille de scène réelle en dit plus que des chiffres de pic synthétiques. Pour une vue de benchmark plus large sur plusieurs cartes travaillant ensemble plutôt qu'un seul nœud, consultez notre benchmark de scaling multi-GPU et nos résultats de performance en cluster RTX 5090.

Render farm GPU vs render farm CPU

Les deux types de farm se distinguent d'abord par la compatibilité de moteur, et le matériel vient ensuite — une distinction qui mérite d'être posée avec précision, car les termes se mélangent dans l'usage courant.

C'est le moteur qui décide, pas la farm. Si votre projet se rend en Redshift, Octane ou EEVEE, c'est un job GPU ; s'il se rend en Corona ou en mode CPU de V-Ray, c'est un job CPU. Cycles peut aller dans les deux sens selon le device sélectionné dans les paramètres de votre scène.

Pour un tour d'horizon centré sur un moteur particulier concernant Octane sur une farm GPU managée, consultez notre guide Octane render cloud farm. Vous choisissez le moteur pour des raisons créatives et de pipeline, et c'est le moteur qui choisit le type de farm pour vous. Pour un traitement plus approfondi de ce choix au niveau du moteur, nous tenons un guide séparé GPU rendering vs CPU rendering — cet article porte sur ce à quoi ressemble la farm autour du moteur.

Les modèles de mémoire diffèrent par nature. Un nœud GPU vit à l'intérieur de la VRAM de sa carte — 32 Go sur les cartes RTX 5090 de notre parc GPU. Un nœud CPU vit à l'intérieur de la RAM système, et nos nœuds CPU bi-Xeon en portent 96 à 256 Go. Les fonctionnalités out-of-core des moteurs GPU modernes peuvent déverser certaines données de texture et de géométrie vers la mémoire système à un coût de performance (voir la section matérielle ci-dessus pour ce que cela vous coûte réellement), mais la VRAM reste le plafond pratique de la complexité de scène pour le travail GPU. Les scènes d'archviz très lourdes avec une végétation massive, ou les scènes VFX avec des volumétries profondes, restent souvent sur des render farms CPU précisément pour cette raison.

Les promesses de vitesse ont besoin de contexte. Sur des scènes qui tiennent confortablement en VRAM, un moteur GPU délivre en général une image en moins de temps d'horloge par nœud qu'un moteur CPU ne rend une image comparable. C'est une affirmation par nœud, pas un verdict sur les farms : un parc CPU de plus de 20 000 cœurs délivre du débit par sa largeur parallèle brute, et l'économie par image dépend du tarif par unité de travail, pas du silicium à la mode. Les deux modèles sont tarifés en fonction du travail qu'ils accomplissent.

Le mix de jobs penche plus vers le CPU que le climat marketing ne le suggère. Environ 70 % des jobs sur notre farm se rendent encore sur des moteurs CPU — V-Ray CPU, Corona, Arnold — le travail GPU sur Redshift, Octane, V-Ray GPU, Cycles et EEVEE constituant la part croissante restante. Une render farm GPU n'est pas la remplaçante d'une render farm CPU ; c'est la sœur qui sert une famille différente de moteurs. Pour les bases conceptuelles plus complètes que partagent les deux types de farm, notre guide qu'est-ce qu'une render farm couvre les éléments qui s'appliquent quel que soit le matériel — planification, stockage et critères d'évaluation.

Render farm GPU vs poste de travail multi-GPU local

La comparaison la plus intéressante pour de nombreux artistes ne se fait pas face aux render farms CPU, mais face à la machine sous le bureau. La version honnête présente des avantages des deux côtés.

Où les cartes locales l'emportent. Le lookdev interactif. Lorsque vous ajustez matériaux et éclairage, la latence d'aller-retour compte plus que le débit, et une carte dans votre propre machine vous donne un retour en quelques secondes. Aucune farm ne change cela, et un opérateur de farm qui prétend le contraire vous vend autre chose. Le local l'emporte aussi lorsque votre utilisation est véritablement constante — un matériel qui rend des images de production la plupart des heures de la plupart des semaines amortit son propre coût en capital d'une façon qu'un matériel à usage occasionnel ne fait jamais. Pour un tour d'horizon complet des cas où le matériel dédié a plus de sens que la capacité de farm partagée, consultez notre guide serveur de rendu RTX 5090 dédié.

Où la farm l'emporte. La largeur à la demande. Un poste de travail contient deux, peut-être quatre cartes ; une farm vous loue l'équivalent d'une douzaine de cartes en parallèle pour un seul week-end sans que vous ayez à les posséder pendant les trois années entre-temps. Le rendu d'animation en image finale est embarrassingly parallel — 300 images réparties sur de nombreuses cartes sans état partagé — ce qui est précisément la forme pour laquelle une farm est construite. Il y a aussi la contention : les images qui se rendent sur votre poste de travail immobilisent les mêmes cartes dont vous avez besoin pour le lookdev du plan suivant, si bien que les semaines de deadline se transforment en rendu la nuit et en travail dans les interstices. Et il y a la physique peu glamour de la puissance, de la chaleur et du bruit qu'imposent les boîtiers multi-GPU dans une petite salle de studio.

Le schéma que nous observons opérationnellement. Les studios tendent à arriver à un modèle hybride : cartes locales pour l'itération, farm pour les images finales et pour les deux semaines par an où tout est dû en même temps. Une petite équipe de motion design nous a rejoints après une semaine de livraison où deux cartes locales ont tourné en continu et l'animation a quand même manqué son créneau ; le même job réparti sur les nœuds de la farm a terminé du jour au lendemain. La leçon n'est pas que leur matériel était inadéquat — c'est que la capacité de pointe est un bien différent de la capacité possédée. Nous avons publié une analyse de coût d'un artiste solo comparant un poste de travail RTX 5090 unique au rendu cloud qui détaille le calcul du côté de la possession.

Farm GPU, farm CPU, GPU IaaS ou machine locale : côte à côte

Les quatre options répondent à des problèmes différents. Le tableau ci-dessous est celui que nous parcourons avec les nouveaux clients, avec les compromis laissés intacts — y compris les lignes où une farm managée n'est pas la bonne réponse. Pour comprendre comment la catégorie cloud render farm dans son ensemble s'inscrit dans le paysage du rendu, consultez qu'est-ce qu'une cloud render farm.

	Render farm GPU managée	Render farm CPU managée	GPU IaaS (VM GPU louées)	Poste de travail multi-GPU local
Ce que vous payez	Images rendues, facturées par carte-heure de travail	Images rendues, facturées par unité de travail CPU	Temps machine, que ce soit en rendu ou à l'arrêt	Matériel en amont, électricité au mois
Moteurs compatibles	Redshift, Octane, V-Ray GPU, Cycles (GPU), EEVEE	V-Ray CPU, Corona, Arnold, Cycles (CPU)	Tout ce que vous installez et licenciez vous-même	Ce que vos cartes et licences prennent en charge
Charge de mise en place	Préparer la scène, envoyer, soumettre	Préparer la scène, envoyer, soumettre	Provisionner des VM, installer DCC + moteur, gérer les licences, exploiter la file	Construire, refroidir, alimenter et entretenir la machine
Licences de rendu	Mutualisées et incluses dans le tarif	Mutualisées et incluses dans le tarif	À apporter vous-même	À apporter vous-même
Forme de scaling	Pics larges à la demande	Pics très larges à la demande	Autant de VM que vous pouvez configurer et vous permettre	Fixe à 2-4 cartes
Plafond mémoire	VRAM par carte (32 Go sur nos nœuds RTX 5090)	RAM système (96-256 Go sur nos nœuds)	VRAM de la classe de VM louée	VRAM des cartes que vous avez achetées
Gagne quand	Animation GPU en image finale sous deadline	Scènes lourdes en mémoire, pipelines à moteur CPU	Pipelines sur mesure nécessitant un contrôle au niveau OS	Lookdev interactif, utilisation constante toute l'année
Peine quand	Vous avez besoin de boucles d'itération de moins d'une minute	Idem — l'itération reste locale	Vous vouliez du rendu, pas de l'administration système	La deadline nécessite 10x votre nombre de cartes cette semaine

Ce que coûte le rendu GPU sur une farm

La facturation d'une farm GPU doit résoudre un problème de normalisation : une carte-heure ne signifie rien à travers des générations de matériel mixtes tant qu'elle n'est pas ancrée à une performance mesurée. La référence commune est OctaneBench, le benchmark public de rendu GPU d'OTOY — le score d'un nœud exprime la quantité de travail de rendu qu'il délivre réellement par heure, et la facturation se base sur cette mesure.

Sur notre farm, le tarif GPU est de 0,003 $ par OctaneBench-heure, ce qui revient à environ 5,20 $ par carte-heure sur un nœud RTX 5090. À titre de comparaison, le rendu CPU est facturé à 0,004 $ par GHz-heure au palier de priorité de base (les paliers de priorité vont de 0,004 à 0,016 $), un serveur bi-Xeon revenant à environ 2 $ par serveur-heure. Des unités différentes, un même principe : vous payez pour le travail délivré, pas pour le temps qu'une machine existe simplement.

Voici la méthode d'estimation que nous recommandons, appliquée à un scénario concret : une animation Redshift de 300 images qui se rend à l'essai en environ 4 minutes par image sur une carte de classe RTX 5090 unique. Le calcul total est de 300 × 4 = 1 200 carte-minutes, soit 20 carte-heures, quel que soit le nombre de cartes qui se partagent le travail :

Cartes travaillant en parallèle	Temps d'horloge	Carte-heures facturées	Coût estimé à ~5,20 $/carte-heure
1	~20 heures	20	~104 $
5	~4 heures	20	~104 $
10	~2 heures	20	~104 $

Ce tableau est la chose la plus utile à comprendre sur l'économie des farms : à un palier tarifaire donné, la largeur parallèle achète du temps de livraison, pas une facture plus élevée. Le job coûte ce que coûte le travail ; les cartes décident seulement si vous l'obtenez ce soir ou jeudi.

Traitez ces chiffres comme une méthode, pas comme un devis. Les temps par image varient sur une séquence, l'estimation suppose un parallélisme par image (une animation, pas une seule image géante), et le temps réel de votre image test est la donnée qui compte. Rendez deux ou trois images représentatives d'abord, puis multipliez — cette habitude détecte à la fois les surprises budgétaires et les surprises d'assets cassés avant qu'elles ne coûtent quoi que ce soit.

GPU cloud rendering vs render farm GPU : y a-t-il une différence ?

Les deux expressions s'emploient presque de façon interchangeable, et dans la plupart des cas cela ne pose pas de problème — mais il vaut la peine d'être précis sur la nuance. « Render farm GPU » décrit l'infrastructure : le parc réel de nœuds GPU, le scheduler et le stockage qui effectuent le travail, qu'on y accède via un service managé ou en le louant en IaaS brut. « GPU cloud rendering » est l'activité plus large de rendre sur du calcul GPU distant, accessible via internet, plutôt que sur du matériel local — c'est ce que vous faites, tandis que « render farm GPU » est la chose sur laquelle vous le faites.

En pratique, lorsque quelqu'un demande « GPU cloud rendering vs render farm GPU », il pose presque toujours la question de la distinction managé-vs-IaaS couverte plus haut dans ce guide, pas un véritable conflit terminologique : le GPU cloud rendering se déroule sur une render farm GPU dans les deux cas, et la vraie question est de savoir si cette farm vous propose un pipeline managé upload-rendu-téléchargement ou un ensemble de VM en bureau à distance que vous administrez vous-même. Pour la même distinction appliquée à la catégorie plus large (non spécifique au GPU) du cloud rendering, consultez notre guide cloud rendering expliqué.

Comment évaluer une render farm GPU

Les critères ci-dessous sont ceux qui distinguent les farms en pratique — ce sont les questions que nous poserions à n'importe quel prestataire, nous y compris :

• La VRAM par carte, par écrit. Le modèle de carte et sa mémoire, ainsi que des données de performance publiées pour votre moteur — pas une promesse de vitesse générique.
• Une couverture exacte des versions de moteur et de plugin. Vos versions, figées par job, pas « versions actuelles prises en charge ».
• La gestion des licences. Incluse dans le tarif, ou à votre charge ? La réponse change le véritable coût horaire.
• La forme du workflow. Upload-rendu-téléchargement managé, ou VM en bureau à distance ? Choisissez celle que votre équipe peut réellement exploiter à 23 h un soir de deadline.
• Le comportement de synchronisation des assets à la deuxième soumission. Synchronisation des seuls fichiers modifiés, ou ré-envoi complet à chaque itération ? Cela détermine la sensation réelle de l'itération.
• La prévisibilité des coûts. Des tarifs publiés dans une unité déclarée, et un moyen d'estimer à partir d'images test avant d'engager la séquence.
• La rétention des sorties et la gestion des données. Connaître la fenêtre (la nôtre est de 45 jours) et intégrer la livraison dans le planning.
• Le support pendant les fenêtres de rendu. Les rendus échouent à 3 h du matin ; un support en direct 24/7 vaut plus qu'une file de tickets traitée aux heures de bureau.

Nous exploitons une infrastructure de rendu chez Super Renders Farm depuis 2010, à la fois sur le parc CPU et sur le parc GPU RTX 5090, et le schéma qui se confirme est celui-ci : les farms qui servent bien les artistes sont celles qui publient leur mécanique — tarifs, moteurs, VRAM, comportement de synchronisation — et vous laissent vérifier le calcul vous-même. Une render farm GPU n'a rien de magique. C'est un scheduler, un tas de cartes très capables, et une couche de synchronisation, exploités avec soin pour que votre deadline ne dépende pas des deux cartes sous votre bureau.

FAQ

Q: Qu'est-ce qu'une render farm GPU ? A: Une render farm GPU est un cluster de nœuds de rendu construits autour de cartes graphiques dédiées au rendu, coordonnés par un scheduler de jobs et un stockage partagé afin que de nombreuses images se rendent en parallèle pour des moteurs GPU-natifs comme Redshift, Octane, V-Ray GPU, Cycles et EEVEE. Super Renders Farm, par exemple, associe un parc GPU RTX 5090 à un workflow managé upload-rendu-téléchargement, si bien que les jobs tournent sans session de bureau à distance ni configuration manuelle des licences.

Q: GPU cloud rendering vs render farm GPU — quelle est la différence ? A: Une render farm GPU est l'infrastructure — le parc réel de nœuds, le scheduler et le stockage — tandis que le GPU cloud rendering est l'activité plus large de rendre sur du calcul GPU distant plutôt que sur du matériel local. En pratique, l'expression que les gens visent habituellement par cette question est la distinction managé-vs-IaaS : que la render farm GPU derrière le cloud rendering vous propose un pipeline upload-rendu-téléchargement terminé ou des VM en bureau à distance brutes que vous configurez vous-même.

Q: Quelle est la différence entre une render farm GPU et une render farm CPU ? A: Le moteur sur lequel votre projet se rend détermine le type de farm dont vous avez besoin : Redshift, Octane, V-Ray GPU, EEVEE et Cycles en mode GPU tournent sur des farms GPU, tandis que Corona, Arnold et V-Ray CPU tournent sur des farms CPU. La différence matérielle en découle — les nœuds GPU sont limités par la VRAM (32 Go par carte sur notre parc) tandis que les nœuds CPU disposent d'une RAM système bien plus vaste (96-256 Go sur les nôtres), ce qui explique pourquoi les scènes lourdes en mémoire restent souvent sur des farms CPU.

Q: Quels moteurs de rendu nécessitent une render farm GPU ? A: Redshift et Octane sont GPU uniquement — ils n'ont aucun chemin de rendu CPU du tout, si bien que tout job dans l'un ou l'autre moteur nécessite une farm compatible GPU. EEVEE est aussi GPU uniquement en pratique, construit autour du pipeline de rendu temps réel de Blender. V-Ray GPU et Cycles peuvent tourner en GPU mais ont aussi des modes CPU, si bien que ces moteurs ne déterminent pas le type de farm à eux seuls — c'est le mode choisi dans vos paramètres de scène qui le fait.

Q: Une render farm GPU est-elle plus rapide qu'un poste de travail multi-GPU local ? A: Par carte, non — un nœud de farm avec la même carte rend une image en un temps à peu près équivalent à celui de votre poste de travail. La différence se situe dans la largeur parallèle et la contention : une farm peut mettre dix cartes ou plus sur une animation à la fois pendant que vos cartes locales restent libres pour le lookdev, si bien que la séquence se termine du jour au lendemain au lieu de monopoliser votre poste de travail pendant des jours.

Q: Puis-je rendre Blender EEVEE ou Cycles sur une render farm GPU ? A: Oui — sur notre parc GPU, EEVEE et Cycles (en mode GPU) sont tous deux des moteurs de rendu pris en charge pour les scènes Blender. Le pipeline de rasterisation temps réel d'EEVEE tourne sur les nœuds GPU de la même façon que Redshift ou Octane ; Cycles peut tourner en mode CPU ou GPU selon les paramètres de votre scène.

Q: Comment la facturation d'usage d'une render farm GPU fonctionne-t-elle ? A: La plupart des render farms GPU facturent des carte-heures normalisées par benchmark, afin qu'une unité de facturation corresponde à une unité de travail de rendu mesuré ; OctaneBench est la référence publique commune. Sur notre farm, le tarif est de 0,003 $ par OctaneBench-heure — environ 5,20 $ par carte-heure sur un nœud RTX 5090 — et le total d'un job dépend des carte-heures de travail, pas du nombre de cartes qui se le partagent.

Q: Ai-je besoin de mes propres licences de moteur de rendu pour utiliser une render farm GPU ? A: Sur une render farm GPU managée, non — les licences de rendu pour des moteurs comme Redshift, Octane et V-Ray sont mutualisées sur la farm et incluses dans le tarif, et Cycles ainsi qu'EEVEE sont open source sans aucune licence. Sur les locations GPU IaaS, vous apportez et gérez vos propres licences par machine, ce qui représente une réelle différence de coût et d'administration à intégrer dans votre calcul.

Q: De combien de VRAM disposent les nœuds d'une render farm GPU, et que se passe-t-il si ma scène est plus grande ? A: Cela varie selon la farm et la génération de carte, donc vérifiez le modèle de carte spécifique plutôt que d'accepter une promesse générique ; nos nœuds GPU fonctionnent avec des cartes RTX 5090 dotées chacune de 32 Go de VRAM. Si une scène dépasse ce plafond, des moteurs modernes comme Redshift et Octane peuvent déverser certaines données vers la mémoire système via le rendu out-of-core, mais à un coût de performance réel — une scène qui dépasse réellement et massivement la VRAM est généralement mieux servie par une render farm CPU à la place.

Q: Ai-je besoin d'un accès bureau à distance pour utiliser une render farm GPU ? A: Pas sur une farm managée — le workflow est upload, rendu, téléchargement : vous préparez une scène, la farm la synchronise et la rend, et vous récupérez les images terminées. Les sessions de bureau à distance sont le modèle opérationnel des locations GPU IaaS, où vous administrez les machines vous-même, et cette distinction est la ligne de démarcation la plus claire entre les deux types de service.