Redshift Render Farm : Guide 2026 du rendu cloud GPU

Redshift est l'un des moteurs de rendu qui génère le plus de questions sur notre render farm. C'est un moteur de rendu biaisé, accéléré par GPU, conçu pour la vitesse en production. Les artistes y ont recours pour trois raisons principales : il est conçu autour de la carte graphique, il reste prévisible sous pression de deadline, et il est intégré dans les quatre applications que la majorité de nos clients utilisent déjà — Cinema 4D, Maya, 3ds Max et Houdini.

Ce guide constitue une référence unique pour exécuter Redshift sur une cloud render farm, quelle que soit l'application dans laquelle vous construisez vos scènes. Une render farm ne modifie pas la façon dont vous éclairez ou texturez une image ; elle transforme ce qui se passe lorsque vous lancez le rendu. Au lieu d'une seule station de travail qui traite une séquence toute la nuit, de nombreuses machines GPU prennent en charge les images en parallèle et vous les restituent en une fraction du temps réel. Les compromis qui comptent — VRAM, licences, transfert de fichiers et coût — sont identiques que votre scène Redshift ait été créée dans Cinema 4D ou dans Houdini. C'est précisément pourquoi il est utile de traiter « Redshift sur une render farm » comme un seul sujet plutôt que quatre sujets distincts.

Flux de rendu cloud Redshift — Cinema 4D, Maya, 3ds Max et Houdini alimentent un seul moteur Redshift, puis les scènes sont téléversées vers une flotte GPU qui rend les images en parallèle pour téléchargement

Pourquoi Redshift effectue le rendu sur le GPU — et ce que cela implique sur une render farm

Redshift est avant tout un moteur de rendu GPU. Il utilise les chemins CUDA et OptiX de la carte graphique pour tracer les rayons, ce qui lui confère l'interactivité que les artistes lui associent. Sur notre render farm, chaque job Redshift s'exécute sur une flotte GPU dédiée, composée de cartes NVIDIA RTX 5090 avec 32 Go de VRAM chacune. Nous exécutons Redshift en mode GPU — c'est le chemin pour lequel notre matériel est configuré, et il est important d'être précis à ce sujet, car Redshift a également introduit un mode de rendu CPU à partir de la version 3.5. Sur notre render farm, Redshift est exclusivement GPU ; il n'existe pas de chemin de rendu CPU pour ce moteur. Si vous avez optimisé une scène pour le backend CPU, prévoyez de la valider par rapport à la sortie GPU avant de vous engager sur une longue séquence.

Cette conception GPU-first fait de Redshift un choix naturel pour le rendu distribué. Les images constituent des unités de travail indépendantes ; ainsi, une séquence qui prend huit heures sur une seule carte peut être répartie sur plusieurs cartes et rendue bien plus rapidement. Le rôle d'une render farm est de maintenir ces cartes alimentées, de gérer les licences et de vous restituer les images — sans que vous ayez à vous préoccuper des machines sous-jacentes.

Une render farm supprime également le principal goulot d'étranglement GPU pour les artistes indépendants : le nombre de cartes. En local, vous rendez avec une ou deux GPU dans votre station de travail. Sur une render farm, la contrainte passe de « combien de cartes est-ce que je possède » à « comment est-ce que je package la scène pour que les cartes puissent la lire » — un problème bien plus simple à résoudre, que nous abordons dans la section flux de travail ci-dessous.

Redshift sur quatre applications : Cinema 4D, Maya, 3ds Max et Houdini

Redshift se comporte de manière cohérente sur les applications hôtes, car le moteur est identique ; ce qui diffère, c'est le plugin bridge et la façon dont chaque application exporte ses données de scène. Nous prenons en charge Redshift dans les quatre DCC où nos clients l'utilisent le plus :

• Cinema 4D. Redshift y est étroitement intégré — c'est un produit Maxon, et Cinema 4D est une application Maxon, de sorte que le système de matériaux, la vue de rendu et le système de takes semblent natifs. Il s'agit du couplage Redshift le plus mature que nous observons, et celui qui dispose du plus long historique de scènes prêtes pour une render farm. Pour une analyse approfondie spécifique à Cinema 4D, consultez notre guide Cinema 4D Redshift render farm.
• Maya. Redshift for Maya est une intégration établie de longue date et éprouvée en production, avec une prise en charge complète des couches de rendu Maya, des AOV et du flux de travail habituel de matériaux basé sur les nœuds. Les scènes référencent les textures et les caches via la structure de projet Maya ; la principale considération pour la render farm consiste à s'assurer que ces chemins se résolvent une fois que les fichiers quittent votre machine.
• 3ds Max. L'intégration 3ds Max couvre les paramètres du moteur de rendu, l'éditeur de matériaux et les éléments de rendu attendus. Redshift y est fréquemment utilisé avec des plugins de dispersion et de proxy ; il convient donc de packager soigneusement les proxies et les références externes.
• Houdini. Redshift dans Houdini est l'option GPU que de nombreux artistes associent aux travaux de simulation lourde et d'instanciation, aux côtés de Karma et Mantra. Si votre pipeline est centré sur Houdini, notre page Houdini cloud render farm couvre l'ensemble des moteurs disponibles pour cette application.

Sur ces quatre applications, la licence du moteur de rendu est incluse dans ce que vous payez pour le rendu — il ne vous est pas demandé d'apporter votre propre licence Redshift. En tant que partenaire officiel Maxon, nous prenons en charge la licence de Redshift (et le reste de la gamme Maxon) pour une utilisation en rendu sur la render farm, ce qui permet au moteur d'être disponible dans chaque application prise en charge sans aucune configuration de votre côté. Vous pouvez vérifier ce statut de partenaire directement sur l'annuaire des partenaires Maxon.

Cinema 4D, Maya, 3ds Max et Houdini alimentant tous un seul moteur Redshift sur une render farm GPU, avec la licence Redshift incluse dans le tarif de rendu

VRAM, out-of-core et scènes volumineuses

Pour le rendu GPU, la VRAM est le paramètre qui détermine si une scène se rend correctement ou se bloque. Redshift charge la géométrie, les textures et les autres données de scène dans la mémoire de la carte ; lorsqu'une scène s'y adapte, la carte fonctionne à plein régime. Notre flotte GPU offre à chaque job Redshift 32 Go de VRAM, ce qui couvre un large éventail de scènes de production sans traitement particulier.

Lorsque les données d'une scène dépassent la VRAM disponible, Redshift ne se contente pas d'échouer — il bascule vers sa technologie out-of-core, en paginant les textures et la géométrie depuis la mémoire système selon les besoins de la carte. C'est la réponse honnête à la question « qu'en est-il de ma scène lourde » : Redshift peut rendre des scènes plus volumineuses que la VRAM grâce à l'out-of-core, avec un certain coût en termes de performance, car la carte doit accéder à une mémoire plus lente. Il s'agit d'une technique GPU, et non d'un transfert vers un moteur de rendu CPU. En pratique, pour qu'une scène Redshift volumineuse reste rapide, il convient de réduire d'abord la pression inutile sur la VRAM — des tailles de textures raisonnables, des proxies pour la géométrie répétée et la suppression de ce qui n'est pas réellement dans le cadre — et de laisser l'out-of-core absorber le reste.

Si vous vous demandez si les 32 Go du RTX 5090 offrent une marge suffisante pour votre travail, notre article sur les performances du rendu cloud GPU RTX 5090 explique en détail comment la carte se comporte sur des scènes réelles.

Graphique de l'utilisation de la VRAM augmentant avec la complexité de la scène, franchissant la limite de 32 Go du RTX 5090 où l'out-of-core de Redshift s'active et poursuit le rendu sur le GPU avec un certain coût en performance

Render farm entièrement gérée ou location d'une machine GPU

Il existe deux grandes façons d'effectuer le rendu Redshift dans le cloud, et la différence est plus importante que la spécification matérielle.

La première est la location d'infrastructure, où vous louez une machine GPU distante, vous y connectez via le bureau à distance, installez Redshift et votre application hôte vous-même, gérez les licences, copiez vos fichiers et administrez le rendu. Vous obtenez une machine nue avec un contrôle total, ainsi que toute la charge de configuration et de maintenance que cela implique.

La seconde est une render farm entièrement gérée, qui correspond à notre mode de fonctionnement. Vous téléversez votre scène, le moteur et les licences sont déjà en place, les images sont distribuées sur la flotte GPU pour vous, et vous récupérez la sortie. Il n'y a pas de bureau à distance auquel vous connecter, rien à installer et aucune licence à activer. Pour un artiste Redshift, cela supprime les aspects du rendu cloud qui n'ont rien à voir avec la création d'images — et c'est ce qui distingue principalement une render farm gérée des locations GPU en mode infrastructure-as-a-service que vous avez peut-être utilisées. Notre page Redshift cloud render farm est l'endroit idéal à partager avec un collègue qui souhaite une version résumée.

Le modèle qui vous convient dépend du niveau de contrôle dont vous avez besoin sur l'environnement. Si vous disposez d'une chaîne de plugins inhabituelle ou d'une version personnalisée, une machine brute peut être le bon outil. Pour la majorité des travaux Redshift — une application hôte standard, le moteur et votre scène — une render farm gérée restitue les images avec bien moins de charge opérationnelle.

Le coût du rendu Redshift sur une render farm

Le rendu GPU sur notre render farm est facturé à l'usage plutôt que selon un abonnement mensuel. L'unité est l'OctaneBench-heure (OBh) — une mesure du travail GPU effectué — facturée au tarif de base de 0,003 $ par OBh. En pratique, une carte RTX 5090 revient à environ 5,20 $ par GPU-heure de rendu. Vous payez pour le temps GPU réellement consommé par vos images, et non pour un abonnement ou un niveau tarifaire.

Quelques points qui reviennent souvent :

• Les licences sont incluses. La licence Redshift fait partie du tarif de rendu. Il en va de même pour les autres moteurs que nous exécutons — il n'y a pas de ligne de licence distincte à budgéter.
• Les crédits n'expirent pas. Vous rechargez un solde de crédits et les dépensez sur des jobs ; les crédits payés restent valides quand vous en avez besoin. Les nouveaux comptes bénéficient également de 25 $ de crédit d'essai pour calibrer un vrai job avant de s'engager sur une séquence.
• Pas de niveaux. Chaque compte effectue le rendu au même tarif basé sur l'usage. Il n'y a pas d'abonnement à choisir ni de fonctionnalité réservée à un niveau supérieur.

Pour estimer un job, prenez le temps qu'une image nécessite sur une carte comparable, multipliez par votre nombre d'images, et appliquez le chiffre de GPU-heure — réparti sur la flotte, le temps réel s'effondre, mais les GPU-heures facturées restent à peu près équivalentes au travail total effectué. Rendre un plan de 10 secondes à 24 images/seconde représente 240 images ; si chaque image prend quatre minutes sur une carte, cela représente environ 16 GPU-heures de travail, soit environ 83 $ au tarif pratiqué — restituées en une fraction de ce temps réel, car les images s'exécutent en parallèle.

Exemple de coût détaillé pour un plan de 240 images : les heures-carte facturées sont identiques sur une seule carte GPU et sur une render farm de 24 cartes, mais le temps réel de la farm est bien plus court

Choisir Redshift, ou un autre moteur, pour le job

Redshift est un choix solide lorsque vous souhaitez la vitesse GPU avec la contrôlabilité d'un moteur de rendu biaisé, et que votre application hôte est l'une des quatre mentionnées ci-dessus. Ce n'est pas la seule option, et bien choisir implique de savoir où il se situe par rapport aux alternatives.

• Face à Arnold, le compromis est la vitesse biaisée GPU de Redshift et son interactivité versus la réputation d'Arnold pour une sortie non biaisée, physiquement rigoureuse, sur CPU et GPU. Nous comparons les deux pour le travail en render farm dans Arnold vs. Redshift sur une render farm.
• Face à Octane, les deux sont des moteurs de rendu GPU avec des philosophies de shading différentes et une prise en charge d'applications hôtes différente. Notre comparatif Octane vs. Redshift explique en détail comment ils diffèrent en pratique.

Une render farm ne vous enferme pas dans un seul moteur — le même modèle upload-et-rendu s'applique aux autres moteurs que nous exécutons — de sorte que le choix du moteur peut rester une décision créative et de pipeline plutôt qu'une décision d'hébergement.

Le flux de travail upload, rendu, téléchargement

La mise en place d'une scène Redshift sur la render farm suit les trois mêmes étapes quelle que soit l'application hôte.

Upload. Packagez votre scène avec ses assets — textures, proxies, caches et références. Le téléversement web n'a pas de limite de taille stricte, bien que nous suggérions de maintenir les téléversements uniques en dessous d'environ 300 Go ; pour les fichiers plus volumineux, SFTP ou notre application cliente offre un transfert parallèle et repris automatiquement. Les formats d'archive pris en charge sont tar, tar.gz et 7z ; .zip n'est pas pris en charge, donc repackagez ou transférez les fichiers non archivés si c'est votre seule option. La cause la plus fréquente d'un job GPU bloqué est un chemin d'asset qui se résolvait sur votre station de travail mais plus une fois les fichiers déplacés ; collectez ou reliez donc les références externes avant de téléverser.

Rendu. Soumettez le job et les images sont distribuées sur la flotte GPU. Comme les jobs Redshift sont exclusivement GPU ici, chaque image est traitée sur un RTX 5090 avec ses 32 Go de VRAM, et l'out-of-core prend en charge les scènes qui en ont besoin davantage.

Téléchargement. Les images terminées sont disponibles en téléchargement via le web, via SFTP ou automatiquement via l'application cliente. La sortie est conservée pendant 45 jours après la fin d'un job, puis effacée — téléchargez rapidement ou configurez le téléchargement automatique de l'application cliente vers votre stockage local.

Une courte liste de contrôle avant d'envoyer un job Redshift

Parcourir cette liste prend quelques minutes et élimine presque toutes les raisons évitables pour lesquelles un job peut revenir incorrect.

FAQ

Q: La render farm effectue-t-elle le rendu Redshift sur le GPU ou le CPU ? A: Sur le GPU uniquement. Nos jobs Redshift s'exécutent sur une flotte NVIDIA RTX 5090 dédiée avec 32 Go de VRAM par carte. Redshift a ajouté un mode CPU à la version 3.5, mais sur notre render farm il n'existe pas de chemin de rendu CPU pour Redshift — si vous avez optimisé une scène pour le backend CPU, validez-la par rapport à la sortie GPU au préalable.

Q: Depuis quelles applications puis-je effectuer le rendu Redshift ? A: Cinema 4D, Maya, 3ds Max et Houdini. Le moteur est identique sur les quatre ; seul le plugin bridge de l'application hôte et l'export de scène diffèrent. La licence Redshift est incluse dans le tarif de rendu dans chaque cas.

Q: Que se passe-t-il si ma scène dépasse les 32 Go de VRAM ? A: Redshift utilise la technologie out-of-core pour paginer les textures et la géométrie depuis la mémoire système lorsqu'une scène dépasse la VRAM disponible. La scène continue de se rendre sur le GPU, avec un certain coût en termes de performance. La réduction des tailles de textures et l'utilisation de proxies permettent de maintenir davantage de scène en VRAM et d'accélérer le rendu.

Q: Dois-je avoir ma propre licence Redshift ? A: Non. La licence Redshift est incluse dans ce que vous payez pour le rendu. En tant que partenaire officiel Maxon, nous prenons en charge la licence de Redshift pour une utilisation en rendu sur la render farm, de sorte qu'il est disponible dans chaque application prise en charge sans rien à activer de votre côté.

Q: Comment le rendu Redshift est-il tarifé ? A: Le rendu GPU est facturé à l'usage au tarif de base de 0,003 $ par OctaneBench-heure, soit environ 5,20 $ par GPU-heure RTX 5090. Les licences sont incluses, les crédits n'expirent pas, et les nouveaux comptes démarrent avec 25 $ de crédit d'essai pour calibrer un vrai job.

Q: Comment téléverser ma scène et mes assets sur la render farm ? A: Téléversez la scène packagée via le web (pas de limite de taille stricte ; nous suggérons moins d'environ 300 Go par téléversement), ou utilisez SFTP ou l'application cliente pour les transferts plus volumineux ou pouvant être repris. Utilisez des archives tar, tar.gz ou 7z — .zip n'est pas pris en charge — et collectez ou reliez les assets externes avant de téléverser afin que les chemins se résolvent sur la render farm.

Q: Combien de temps mes images rendues sont-elles conservées ? A: La sortie est conservée pendant 45 jours après la fin d'un job, puis automatiquement effacée. Téléchargez vos images via le web, SFTP ou le téléchargement automatique de l'application cliente avant ce délai, ou configurez le téléchargement automatique pour en conserver une copie locale.