Qu'est-ce qu'un serveur de rendu ? (Et quand une render farm s'impose)

Introduction

Si vous avez recherché « serveur de rendu », vous avez sans doute remarqué que les résultats partent dans trois directions à la fois. Certaines pages désignent une machine physique posée sous un bureau, dédiée au rendu. D'autres désignent une machine montée en rack dans un centre de données, louée au mois. Et d'autres encore désignent une plateforme complète de rendu cloud, avec des centaines de machines derrière. Tout le monde appelle ça un « serveur de rendu », et c'est ce chevauchement qui crée la confusion.

Cette distinction compte, car elle change ce que vous achetez réellement et jusqu'où cela peut monter en charge. Un seul serveur qui rend une image fixe avant une échéance est un achat très différent d'un cluster qui digère une animation de 3 000 images pendant la nuit — même si les deux sont décrits avec les mêmes mots. Ce guide trace la ligne clairement : ce qu'est littéralement un serveur de rendu, en quoi il diffère d'une render farm, quand une seule machine suffit vraiment, et les seuils honnêtes et précis où un serveur unique ne suit plus et où il faut passer à l'échelon supérieur. Nous exploitons une infrastructure de rendu distribué depuis des années, et le point où « une machine puissante » devient discrètement « insuffisante » est plus prévisible qu'on ne le pense — nous allons donc être précis sur où il se situe.

La réponse courte : serveur, farm ou service

Trois termes s'emmêlent constamment, autant les séparer avant d'aller plus loin :

• Un serveur de rendu est une machine unique dédiée au rendu. Un seul ordinateur — CPU, GPU, ou les deux — dont le rôle est de traiter des tâches de rendu plutôt que d'être le poste de travail quotidien de quelqu'un. Cela peut être une tour headless dans un coin de studio, un nœud en rack dans une baie de colocation, ou une machine dédiée que vous louez chez un prestataire.
• Une render farm est un ensemble de serveurs de rendu plus un ordonnanceur de tâches. L'ordonnanceur (un gestionnaire de rendu) répartit le travail entre les machines — en distribuant des images, des tuiles ou des tâches — puis réassemble le résultat. Ce qui définit une farm, ce n'est pas le nombre de machines : c'est la couche de coordination qui les fait agir comme un seul pool.
• Un render service est la couche commerciale — une entreprise qui vous vend l'accès à un serveur ou à une farm, avec un mélange de logiciel, de licences et de support. Nous détaillons cette distinction dans notre article complémentaire sur la différence entre un render service et une render farm ; ici, l'accent reste sur la question matérielle — un serveur contre plusieurs.

La progression est donc simple : une machine, c'est un serveur de rendu ; un groupe coordonné de machines, c'est une render farm ; et qui que ce soit qui vous vende l'accès à l'un ou l'autre exploite un render service. La plupart des confusions du monde réel viennent de fournisseurs qui utilisent « serveur de rendu » pour désigner l'un des trois, donc tout au long de ce guide, nous garderons « serveur » strictement au sens de machine unique.

Diagramme comparant un serveur de rendu unique, une render farm de plusieurs serveurs coordonnés, et la couche commerciale d'un render service

Ce qu'est réellement un serveur de rendu

Réduit à l'essentiel, un serveur de rendu est un ordinateur avec trois caractéristiques : il est dédié au rendu plutôt qu'au travail interactif, il fonctionne généralement en mode « headless » (sans écran, piloté à distance), et il est conçu pour tenir une charge complète pendant des heures ou des jours sans devoir aussi servir à autre chose.

En pratique, un serveur de rendu prend l'une de ces quelques formes :

• Un poste headless. Un studio prend une tour de rechange — souvent un ancien poste de travail principal —, la réduit à l'OS et au moteur de rendu, et la dédie au rendu de nuit ou en arrière-plan. Aucune session graphique active en cours ; les tâches sont soumises à distance et la machine tourne, tout simplement.
• Un nœud monté en rack. Un châssis serveur conçu à cet effet (1U/2U/4U), doté de CPU ou de GPU de qualité serveur, installé dans une baie en salle machines de studio ou en centre de colocation. Conçu pour la densité, le refroidissement et le fonctionnement 24 h/24, 7 j/7 — pas pour trôner sur un bureau.
• Un serveur dédié loué. Un prestataire vous donne l'usage exclusif d'une machine physique — vous ne partagez son CPU ou son GPU avec personne d'autre —, facturé au mois ou à l'heure. Vous l'administrez généralement vous-même : installation du moteur de rendu, gestion de la licence, soumission des tâches.

Le point commun aux trois formes est la singularité. Un serveur de rendu est une unité de débit. Il traite une image (ou une tuile) à la fois par thread ou GPU disponible, et son plafond est fixé par son propre silicium. Cette nature unitaire définit à la fois ses forces — simplicité, prévisibilité, contrôle total — et ses limites strictes, que nous allons aborder.

Une petite précision sur ce qu'un serveur de rendu n'est pas : il n'est pas automatiquement « dans le cloud », et ce n'est pas automatiquement une farm. Une machine GPU dédiée louée au mois est un serveur de rendu (une seule machine), pas une farm — la différence tient à l'ordonnanceur et au nombre de machines. Si vous voulez la vue d'ensemble de ce qui se passe quand plusieurs serveurs sont coordonnés ensemble, notre guide complet des render farms détaille l'architecture en profondeur.

Les réalités d'un serveur de rendu en interne

Faire tourner son propre serveur de rendu — que ce soit un poste de travail reconverti ou un nœud en rack acheté — est séduisant sur le papier : achetez le matériel une fois, rendez gratuitement pour toujours. La réalité a plus de nuances, et il vaut la peine d'être honnête sur les éléments qui n'apparaissent pas dans le prix d'achat.

La machine que vous ne pouvez pas utiliser pendant qu'elle rend. C'est le coût le plus sous-estimé d'une configuration à un seul serveur. Si votre serveur de rendu est aussi votre poste de travail, alors chaque heure passée à rendre est une heure où vous ne modélisez pas, ne texturez pas, ne compositez pas. Les artistes résolvent ce problème en dédiant une deuxième machine au rendu — moment précis où « un ordinateur » devient discrètement « deux ordinateurs », et où le fantasme du rendu gratuit commence à générer un budget matériel.

Alimentation et chaleur. Un serveur de rendu à pleine charge tire une puissance sérieuse — une machine CPU à nombre de cœurs élevé ou une machine multi-GPU peut consommer plusieurs centaines de watts en continu, pendant des heures. C'est une vraie ligne budgétaire côté électricité, et c'est de la chaleur qui doit bien aller quelque part. Une seule machine dans un bureau à domicile réchauffera nettement la pièce ; plusieurs machines nécessitent une réelle ventilation. La charge thermique soutenue compte aussi pour la longévité du matériel — des composants grand public tournant à 100 % pendant des jours se comportent différemment qu'en usage interactif par à-coups.

Licences. Les conditions de licence de votre moteur de rendu déterminent si vous pouvez même légalement le faire tourner en mode headless sur une machine dédiée, et combien d'instances simultanées vous sont autorisées. Les moteurs commerciaux comme V-Ray, Corona, Redshift, Arnold et Octane ont chacun leurs propres règles de licence par nœud de rendu ; certains incluent un nombre de nœuds de rendu avec une licence poste de travail, d'autres exigent des licences de nœud séparées. C'est facile à négliger quand on ajoute « juste une machine de plus », et c'est une vraie contrainte sur l'ampleur de croissance possible d'une configuration DIY. (Cycles, le moteur intégré de Blender, est open source et libre de toute licence par nœud — l'une des raisons pour lesquelles il revient si souvent dans les configurations de serveur de rendu DIY.)

La maintenance devient votre travail. Mises à jour de pilotes, correctifs OS, un disque en panne, un rendu qui plante à 2 h du matin — sur votre propre serveur, tout cela relève de la responsabilité de votre équipe. C'est gérable pour une machine. Cela se gère mal à mesure que ça grandit.

Illustration d'un serveur de rendu en interne montrant les coûts cachés — consommation électrique, dégagement de chaleur, contraintes de licence et charge de maintenance

Rien de tout cela ne fait d'un serveur de rendu en interne une mauvaise idée. Pour la bonne charge de travail, c'est un choix parfaitement solide — le point est simplement que « acheter une machine et rendre gratuitement » sous-estime le coût réel et continu. Là où cette équation bascule est traité en détail dans notre comparaison des coûts totaux : construire ou passer au cloud, qui chiffre le point de bascule.

Location de serveur de rendu dédié vs render farm cloud à la tâche

Si vous ne voulez pas posséder de matériel, il existe deux façons très différentes d'en louer — et les confondre est l'une des erreurs les plus coûteuses dans ce domaine.

Louer un serveur de rendu dédié signifie que vous obtenez l'usage exclusif d'une machine physique, en général au mois. Elle est à vous pour la durée : vous installez ce que vous voulez, elle est toujours disponible, et vous ne partagez pas sa puissance de calcul. Cela convient à une charge de travail prévisible et régulière — un artiste ou un petit studio qui rend la plupart des jours et souhaite un coût mensuel connu et fixe. Le hic : vous la payez qu'elle rende ou reste inactive. Une machine dédiée utilisée quatre heures par jour est facturée pour les vingt autres heures aussi. C'est aussi encore une seule machine — la location ne supprime pas le plafond de débit d'un serveur unique, elle déplace simplement le matériel hors de votre bureau. Pour les équipes qui veulent spécifiquement une machine GPU dédiée, notre guide sur le serveur de rendu RTX 5090 dédié détaille ce que ce matériel apporte réellement.

Une render farm cloud à la tâche inverse le modèle. Au lieu d'une machine toujours allumée, vous soumettez une tâche qui se répartit sur de nombreuses machines en parallèle, vous ne payez que le calcul réellement consommé par la tâche, et une fois la tâche terminée, le compteur s'arrête. Une render farm cloud est fondamentalement une farm — de nombreux serveurs plus un ordonnanceur — vendue à la consommation. L'avantage, c'est l'élasticité : une séquence de 500 images qui prendrait une nuit entière sur un serveur peut se terminer en une fraction du temps quand 50 machines traitent chacune 10 images, et vous êtes facturé pour le calcul total, pas pour la capacité inactive.

L'arbitrage honnête entre les deux dépend de votre profil d'utilisation, pas du tarif horaire brut :

Règle générale : si votre rendu est constant et prévisible, un serveur dédié peut être rentable, car vous le maintenez occupé. S'il est en pics — semaines calmes puis coup de collier avant une échéance —, une farm à la tâche gagne presque toujours, car vous ne payez pas pour laisser la machine inactive entre deux coups de collier. Pour l'arbitrage plus profond entre gestion complète et do-it-yourself sous-jacent aux deux options, consultez notre comparaison fully managed vs. DIY render farm.

Serveur de rendu ou farm pour Blender

Blender mérite une mention spécifique, car la question du « serveur de rendu » revient constamment dans les workflows Blender, et la réponse dépend fortement du moteur utilisé parmi les deux de Blender.

Cycles est le moteur de path tracing physiquement réaliste de Blender. Il est gourmand en calcul et monte magnifiquement en charge sur plusieurs machines — chaque image est indépendante, donc une farm peut rendre l'image 1 sur une machine et l'image 240 sur une autre sans coût de coordination. Cycles fonctionne à la fois sur CPU et GPU. Sur un seul serveur de rendu, une animation Cycles lourde est exactement le genre de tâche qui bloque la machine pendant des heures ; c'est aussi exactement le genre de tâche qu'une farm fait passer d'un rendu de nuit à une pause-café, tant les images se parallélisent proprement. Le fait que Cycles soit open source (pas de licence par nœud) en fait aussi le moteur le plus adapté à la montée en charge — que ce soit sur votre propre deuxième machine ou sur une farm cloud.

EEVEE est le moteur de rastérisation en temps réel de Blender, accéléré par GPU. Comme EEVEE est rapide par image, le rendu sur une seule machine est souvent parfaitement suffisant pour des images fixes et des séquences courtes — un serveur de rendu peut suffire amplement. Là où EEVEE bénéficie d'une farm, c'est sur les animations à nombre d'images élevé (animations longues) ou les passes lourdes par image où même la « rapidité » finit par s'accumuler sur des milliers d'images. EEVEE est pris en charge sur notre farm — il tourne sur nos machines GPU dédiées (NVIDIA RTX 5090, 32 Go de VRAM), donc une animation EEVEE peut être distribuée sur des nœuds GPU au lieu de monopoliser votre unique carte locale. Cela mérite d'être dit clairement, car il existe un mythe persistant selon lequel les render farms seraient « Cycles uniquement » — ce n'est pas le cas ici.

La décision Blender n'est donc pas vraiment « serveur ou farm » dans l'absolu — c'est une fonction du moteur et du nombre d'images. Une image fixe unique, ou une courte boucle EEVEE ? Un seul serveur de rendu (le vôtre ou loué) suffit généralement. Une longue animation Cycles avant une échéance, ou une lourde séquence EEVEE de plusieurs milliers d'images ? C'est là que le parallélisme d'une farm devient précieux, et où une machine — aussi puissante soit-elle — devient le goulot d'étranglement.

Quand un seul serveur de rendu suffit

Un serveur de rendu unique est réellement le bon outil pour un ensemble bien réel de tâches. Vous n'avez pas besoin d'une farm simplement parce que des farms existent. Un serveur tient très bien la route quand :

• Vous êtes un artiste seul ou une très petite équipe. Une seule personne ne peut alimenter qu'un certain volume de tâches de rendu à la fois. Si vous ne générez pas de tâches de rendu plus vite qu'une machine puissante ne peut les traiter, la capacité d'une farm reste inactive.
• Vous rendez des images fixes ou des séquences courtes. Quelques images fixes de haute qualité, ou un clip de 5 à 10 secondes, restent largement à la portée d'une seule machine pendant une nuit. Le parallélisme d'une farm n'aide pas beaucoup quand il n'y a que quelques images à répartir.
• Vos échéances laissent de la marge. Si « la semaine prochaine » est la limite et que la tâche se termine pendant la nuit sur une machine, un serveur suffit. Les farms achètent de la vitesse ; si vous n'avez pas besoin de vitesse, vous n'avez pas besoin de la farm.
• Votre licence ou votre pipeline est contraint à une seule machine. Certaines configurations de plugin ou de licence sont réellement plus simples à conserver sur un environnement unique et contrôlé. Un environnement géré multi-machines ne convient pas toujours à une pile logicielle inhabituelle.
• Votre charge de travail est stable et prévisible. Comme évoqué plus haut, un rendu quasi quotidien maintient un serveur dédié suffisamment occupé pour justifier son coût fixe.

La version honnête de cette section : la plupart des artistes solo et de nombreux petits studios ne dépassent en réalité jamais un seul serveur de rendu bien configuré. Le passage à une farm est motivé par des pressions précises et mesurables — pas par un vague sentiment que « les vrais studios utilisent des farms ».

Les seuils honnêtes : quand vous avez dépassé la capacité d'un serveur

Voici où un serveur de rendu unique cesse de suffire. Ce sont les pressions concrètes — pas des déclencheurs marketing, les plafonds réels :

Nombre d'images et calcul d'échéance. C'est le plus clair, et c'est de l'arithmétique. Prenez votre temps de rendu par image, multipliez par votre nombre d'images, et comparez au temps dont vous disposez. Une animation de 1 000 images à 6 minutes par image, c'est 100 heures de rendu sur une machine — plus de quatre jours de calcul continu. Si votre échéance est dans trois jours, un serveur ne peut mathématiquement pas terminer, aussi puissant soit-il. Une farm répartit ces 100 heures sur de nombreuses machines ; 50 machines transforment quatre jours en environ deux heures de temps réel. Quand le nombre d'images multiplié par le temps par image dépasse votre fenêtre disponible, vous avez atteint le plafond.

Plafonds de VRAM (ou de RAM). Un serveur de rendu ne peut charger qu'une scène qui tient dans sa mémoire. Si votre scène a besoin de plus de VRAM qu'un seul GPU n'en possède — géométrie lourde, textures 4K/8K, volumétrie dense —, le rendu échoue, bascule vers une mémoire hors cœur plus lente, ou vous oblige à vider la scène. C'est un mur strict, pas un problème de vitesse : une scène plus lourde ne rend pas plus lentement sur une machine sous-dimensionnée, elle ne rend pas du tout. L'accès à des machines avec plus de marge (ou la possibilité de distribuer) est parfois la seule solution. Notre article sur les limites de VRAM de la RTX 5090 dans des scènes complexes creuse exactement où se situe ce mur.

Demande de débit soutenue. Quand votre équipe génère des tâches de rendu plus vite qu'une machine ne peut les traiter — plusieurs artistes qui soumettent des tâches de nuit, des cycles itératifs de look-dev, des révisions qui s'accumulent —, un serveur unique devient une file d'attente que tout le monde subit. Le goulot d'étranglement cesse d'être une tâche particulière et devient la contention pour l'unique ressource.

Le décalage inactivité-pic. Si vous possédez ou louez un serveur dimensionné pour votre charge de pic, il reste inactif la plupart du temps entre les pics — vous avez payé pour une capacité que vous utilisez rarement. Si vous le dimensionnez pour votre moyenne, il ne tient pas les coups de collier. Une seule machine fixe ne peut pas être les deux. C'est précisément le décalage qu'une farm à la tâche résout : capacité en pic à la demande, aucun coût d'inactivité entre deux.

Remarquez ce que ces seuils ont en commun : ils sont tous mesurables. Vous pouvez calculer votre arithmétique du nombre d'images, vérifier l'empreinte mémoire de votre scène par rapport à la VRAM de votre carte, et compter combien de tâches attendent en file. La décision de passer d'un serveur à une farm doit venir de ces chiffres, pas d'un sentiment qu'il « faut » monter en échelle.

Un cadre de décision simple (avec calcul par image)

Rassemblez tout cela en une courte checklist. Commencez par un serveur de rendu, et passez à une farm quand les chiffres le disent.

1. Faites d'abord le calcul du nombre d'images. temps par image × nombre d'images = heures de rendu totales. Comparez ce résultat à votre fenêtre d'échéance. Si le total tient confortablement sur une machine dans votre délai, un serveur suffit. Sinon, il vous faut du parallélisme.
2. Vérifiez votre plafond mémoire. Votre scène la plus lourde tient-elle dans la VRAM d'un seul GPU (ou dans la RAM d'une seule machine) ? Si non, c'est un mur strict, indépendant de la vitesse.
3. Évaluez votre profil d'utilisation. Rendu quotidien régulier → un serveur dédié (possédé ou loué) peut être rentable. Charge en pics, dictée par des échéances → une farm à la tâche évite de payer pour du temps mort.
4. Comptez la file d'attente. Plus d'une tâche attend-elle régulièrement ? La contention est un signal de débit indiquant qu'une seule machine ne suit plus.

Pour rendre le calcul par image concret, voici un exemple chiffré à partir de nos tarifs publiés. Notre rendu GPU est facturé 0,003 $ par OctaneBench-heure (OBh), et une RTX 5090 dédiée (32 Go de VRAM) représente environ 5,2 $ par carte-heure de rendu. Supposons qu'une animation Cycles ou Octane tourne sur 240 images à 90 secondes par image sur ce type de carte :

• Temps GPU total : 240 images × 90 s = 21 600 s = 6 heures-carte.
• À environ 5,2 $/carte-heure, cela représente environ 31 $ de calcul GPU pour toute la séquence.
• Sur un seul serveur, ces 6 heures s'enchaînent : votre animation est terminée en environ 6 heures de temps réel.
• Sur une farm répartissant les 240 images sur, disons, 12 machines GPU, ce même calcul d'environ 31 $ se termine en environ 30 minutes de temps réel — vous payez pour le même travail total, mais vous le récupérez 12 fois plus vite.

C'est l'essence même de l'arbitrage serveur contre farm en un seul exemple : une farm change rarement beaucoup le coût de calcul total — vous êtes facturé pour le travail de toute façon — ce qu'elle achète, c'est la vitesse en temps réel en exécutant ce travail en parallèle. La décision est donc vraiment : « en ai-je besoin plus vite qu'une seule machine ne peut le faire ? » Pour le rendu CPU, la même logique s'applique avec notre tarif CPU de 0,004 $ par GHz-heure ; l'arithmétique diffère, mais le principe est identique. Notre guide du coût par image détaille davantage ces exemples chiffrés, et si vous hésitez entre posséder une seule carte et louer, la comparaison poste de travail RTX 5090 unique contre rendu cloud confronte le calcul de possession côte à côte.

Organigramme de décision : commencez par un serveur de rendu, puis orientez-vous vers une render farm selon le calcul du nombre d'images, le plafond VRAM, le profil d'utilisation et la contention de la file d'attente

À quoi ressemble le passage à l'échelon supérieur

Passer d'un serveur de rendu unique à une farm ne signifie pas forcément construire son propre cluster. Il existe, en gros, trois façons d'ajouter du débit une fois qu'on a dépassé la capacité d'une seule machine :

• Ajouter des machines soi-même. Acheter ou louer un deuxième (et un troisième) serveur, et faire tourner son propre gestionnaire de rendu pour les coordonner. C'est une vraie farm, auto-exploitée — plein contrôle, et désormais pleine responsabilité de l'ordonnanceur, des licences sur tous les nœuds, de l'alimentation et de la maintenance de chaque machine.
• Louer une configuration dédiée plus grande. Certains prestataires louent plusieurs serveurs dédiés ; vous les administrez toujours, mais vous évitez la propriété du matériel. Cela fait monter le plafond de débit sans résoudre le problème du coût d'inactivité ni de la charge opérationnelle.
• Utiliser une farm cloud à la tâche. Soumettez à une farm qui répartit votre tâche sur de nombreuses machines et facture ce que la tâche consomme. Sur un service entièrement géré, les licences, la santé des nœuds et la remise en file en cas d'échec sont gérées côté prestataire — le workflow se limite à téléverser, rendre, télécharger, sans étape de bureau à distance ni administration de serveur de votre côté. Sur notre farm, ce modèle géré tourne sur plus de 20 000 cœurs CPU aux côtés de machines GPU dédiées (NVIDIA RTX 5090, 32 Go de VRAM), avec les licences des moteurs commerciaux incluses dans le tarif horaire plutôt que facturées séparément.

Lequel de ces choix convient dépend des mêmes variables évoquées dans le cadre ci-dessus — profil d'utilisation, exigences de contrôle, et quantité de charge opérationnelle que vous voulez assumer. Il n'y a pas une seule bonne réponse ; il n'y en a qu'une qui corresponde à vos chiffres. Si vous louez de la capacité GPU transactionnelle plutôt que de traiter la question définitionnelle, un cluster dédié est un achat totalement différent — mais pour la plupart des gens, le point de départ honnête est un serveur de rendu unique, et le passage à une farm seulement quand le calcul du nombre d'images, le plafond de VRAM ou la file d'attente l'indiquent.

FAQ

Q: Qu'est-ce qu'un serveur de rendu ? A: Un serveur de rendu est une machine unique dédiée au traitement des tâches de rendu plutôt qu'utilisée pour du travail interactif. Cela peut être un poste headless, un nœud monté en rack dans un centre de données, ou une machine dédiée louée chez un prestataire. Sa caractéristique distinctive est d'être une seule machine consacrée au rendu — ce qui la distingue d'une render farm, qui regroupe plusieurs serveurs de rendu coordonnés par un ordonnanceur de tâches.

Q: Quelle est la différence entre un serveur de rendu et une render farm ? A: Un serveur de rendu est une machine ; une render farm est un ensemble de serveurs de rendu plus un ordonnanceur de tâches qui répartit le travail entre eux. L'ordonnanceur fait toute la différence — il répartit images ou tuiles entre les machines et réassemble le résultat, si bien qu'une farm agit comme un pool de débit unique et plus important. L'avantage d'une farm, c'est le parallélisme : un travail qui s'enchaîne sur un seul serveur s'exécute simultanément sur de nombreuses machines, se terminant bien plus vite en temps réel.

Q: Quand un seul serveur de rendu suffit-il ? A: Un seul serveur de rendu suffit généralement pour un artiste seul ou une petite équipe qui rend des images fixes ou des séquences courtes avec des échéances offrant de la marge. Si votre temps de rendu total (temps par image multiplié par le nombre d'images) tient dans votre échéance sur une machine, et que votre scène tient dans la mémoire de cette machine, un serveur suffit. Le passage à une farm est motivé par le calcul du nombre d'images, les plafonds de VRAM ou la contention des tâches — pas par la seule taille du studio.

Q: Puis-je utiliser un serveur de rendu pour Blender ? A: Oui. Pour des images fixes Blender ou de courtes séquences EEVEE, un seul serveur de rendu suffit souvent, EEVEE étant rapide par image. Pour de longues animations Cycles — gourmandes en calcul mais qui se parallélisent proprement d'une image à l'autre —, une farm transforme un rendu de nuit en une tâche bien plus courte. EEVEE est accéléré par GPU et pris en charge sur les machines GPU de notre farm, donc les animations EEVEE lourdes peuvent elles aussi être distribuées au lieu de monopoliser une seule carte locale.

Q: Louer un serveur de rendu dédié est-il moins cher qu'une render farm cloud ? A: Cela dépend entièrement de votre profil d'utilisation. Un serveur dédié loué a un coût mensuel fixe, qu'il rende ou reste inactif, ce qui est rentable pour un rendu régulier et quasi quotidien qui le maintient occupé. Une farm cloud à la tâche ne facture que le calcul consommé par une tâche, ce qui est moins cher pour des charges en pics ou dictées par des échéances, où une machine dédiée resterait inactive entre deux coups de collier. Comparez votre utilisation réelle, pas seulement les tarifs horaires affichés.

Q: Comment calculer si un seul serveur de rendu peut tenir mon échéance ? A: Multipliez votre temps de rendu moyen par image par votre nombre total d'images pour obtenir les heures de rendu totales, puis comparez ce résultat à votre fenêtre d'échéance disponible. Par exemple, 1 000 images à 6 minutes chacune, cela représente 100 heures — plus de quatre jours de rendu continu sur une machine. Si cela dépasse votre échéance, un serveur ne peut pas terminer à temps, quelle que soit sa puissance, et il vous faut le parallélisme d'une farm.

Q: Une render farm coûte-t-elle plus cher qu'un seul serveur de rendu pour la même tâche ? A: Généralement pas pour le calcul lui-même — vous êtes facturé pour le travail de rendu total de toute façon, donc la même tâche coûte à peu près pareil en calcul, qu'une seule machine l'exécute lentement ou que plusieurs machines l'exécutent rapidement. Ce qu'une farm achète, c'est la vitesse en temps réel : le même coût total livré bien plus vite en exécutant les images en parallèle. La vraie différence de coût vient du temps d'inactivité — un serveur dédié que vous payez pendant qu'il reste inutilisé, contre une farm à la tâche qui arrête de facturer entre deux tâches.

Q: Quels sont les coûts cachés d'un serveur de rendu en interne ? A: Au-delà de l'achat du matériel, un serveur de rendu en interne entraîne des coûts continus : électricité pour une machine tournant à pleine charge pendant des heures, chaleur nécessitant une ventilation, conditions de licence du moteur de rendu régissant l'usage headless et multi-nœud, et charge de maintenance des mises à jour de pilotes, des correctifs et des pannes matérielles. Il y a aussi le coût d'opportunité d'une machine que vous ne pouvez pas utiliser pour du travail créatif pendant qu'elle rend — ce qui pousse souvent les studios vers une deuxième machine dédiée, doublant discrètement le parc matériel.