Redshift Render Farm : le guide 2026 du rendu cloud GPU

Redshift est un moteur de rendu biaisé, accéléré par GPU — sur notre farm, et sur toutes les render farms que nous connaissons, il tourne exclusivement sur du matériel GPU, sans chemin de rendu CPU. Les artistes s'en servent dans Cinema 4D, Maya, 3ds Max et Houdini pour les trois mêmes raisons : il est conçu autour de la carte graphique, il reste prévisible sous la pression des délais, et il s'intègre directement dans les applications que la plupart des pipelines de production utilisent déjà. Redshift est aussi un moteur courant pour les plans de véhicules et de produits ; notre guide render farm pour le rendu automobile couvre ce type de charge de travail sur une farm GPU.

Ce guide est une référence unique pour faire tourner Redshift sur une render farm cloud, quelle que soit celle de ces quatre applications dans laquelle vous construisez vos scènes. Une render farm ne change rien à la façon dont vous éclairez ou shadez une image ; elle change ce qui se passe quand vous lancez le rendu. Au lieu qu'une seule station de travail traite une séquence toute la nuit, de nombreuses machines GPU prennent les images en parallèle et vous les renvoient en une fraction du temps réel. Les compromis qui comptent — VRAM, licences, transfert de fichiers et coût — sont les mêmes que votre scène Redshift ait démarré dans Cinema 4D ou dans Houdini, ce qui explique pourquoi il est utile de traiter « Redshift sur une farm » comme un seul sujet plutôt que quatre sujets séparés.

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

Pourquoi Redshift rend sur GPU — et ce que cela signifie sur une farm

Redshift est avant tout un moteur GPU. Il utilise les chemins CUDA et OptiX de la carte graphique pour tracer les rayons, ce qui lui donne le ressenti interactif que les artistes lui associent. Sur notre farm, chaque job Redshift tourne sur une flotte GPU dédiée, construite sur des cartes NVIDIA RTX 5090 avec 32 Go de VRAM chacune. Nous faisons tourner Redshift en mode GPU — c'est le chemin pour lequel notre matériel est provisionné, et il est important d'être précis à ce sujet, car Redshift le produit a aussi acquis un mode de rendu CPU en version 3.5. Sur notre farm, Redshift est GPU uniquement ; il n'existe aucun chemin de rendu CPU ici. Si vous avez réglé une scène pour le backend CPU, prévoyez de valider le résultat par rapport à la sortie GPU avant de vous engager sur une longue séquence.

Cette conception GPU en priorité est ce qui fait de Redshift un candidat naturel pour le rendu distribué. Les images sont des unités de travail indépendantes, donc une séquence qui prend huit heures sur une carte peut être répartie sur de nombreuses cartes et vous être rendue bien plus vite. Le rôle d'une farm est de garder ces cartes alimentées, de résoudre les licences et de vous remettre les images — rien de tout cela ne devrait vous obliger à réfléchir aux machines sous-jacentes.

Une render farm supprime aussi le goulot d'étranglement GPU le plus courant pour les artistes solo : le nombre de cartes. En local, vous rendez avec les une ou deux cartes de votre tour. Sur une farm, la contrainte passe de « combien de cartes est-ce que je possède » à « comment packager la scène pour que les cartes puissent la lire » — un problème bien plus simple à résoudre, et que nous couvrons dans la section workflow ci-dessous. Si vous voulez savoir combien une deuxième (ou une vingtième) carte vous apporte réellement en pratique, notre benchmark de scaling multi-GPU mesure directement les temps de rendu à 1 GPU contre 2 GPU plutôt que de supposer un scaling linéaire.

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

Redshift se comporte de façon cohérente d'une application hôte à l'autre car le moteur est le même ; ce qui diffère, c'est le plugin de liaison et la manière 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, donc le système de matériaux, la vue de rendu et le système de takes paraissent natifs. C'est le couplage Redshift le plus mature que nous observons, et celui qui a le plus long historique de scènes prêtes pour la farm. Pour une plongée spécifique à Cinema 4D — y compris des spécificités de workflow motion-design que ce guide multi-DCC ne couvre pas — consultez notre guide render farm Redshift pour Cinema 4D.
• Maya. Redshift pour Maya est une intégration établie et éprouvée en production, avec un support complet des layers de rendu de Maya, des AOV, et du workflow habituel de matériaux basé sur des nœuds. Les scènes référencent textures et caches via la structure de projet de Maya, donc la principale considération pour la farm est de s'assurer que ces chemins se résolvent bien une fois les fichiers sortis de votre machine.
• 3ds Max. L'intégration 3ds Max couvre les réglages du moteur de rendu, l'éditeur de matériaux et les render elements attendus. Redshift y est fréquemment utilisé avec des plugins de scatter et de proxy, donc les proxies et les références externes sont les éléments à packager avec soin.
• Houdini. Redshift dans Houdini est l'option GPU que beaucoup d'artistes associent à des travaux lourds de simulation et d'instanciation, aux côtés de Karma et Mantra. Si votre pipeline est centré sur Houdini, notre page render farm cloud pour Houdini couvre le panorama plus large des moteurs pour cette application.

Sur les quatre, la licence du moteur de rendu est incluse dans ce que vous payez pour rendre — on ne vous demande pas d'apporter votre propre siège Redshift. En tant que partenaire officiel Maxon, nous licencions Redshift (et le reste de la gamme Maxon) pour un usage de rendu sur la 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, la licence Redshift étant incluse dans le tarif de rendu

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

Pour le rendu GPU, la VRAM est le chiffre qui détermine si une scène rend proprement ou cale. Redshift charge la géométrie, les textures et les autres données de scène dans la mémoire de la carte ; quand une scène tient dedans, la carte tourne à plein régime. Notre flotte GPU donne à chaque job Redshift 32 Go de VRAM à disposition sur une NVIDIA RTX 5090, ce qui couvre un large éventail de scènes de production sans traitement particulier.

Quand les données d'une scène dépassent la VRAM disponible, Redshift n'échoue pas simplement — il bascule sur sa technologie out-of-core, en paginant textures et géométrie depuis la mémoire système au fur et à mesure des besoins de la carte. C'est la réponse honnête à la question « et ma scène lourde, alors » : Redshift peut rendre des scènes plus grandes que la VRAM grâce à l'out-of-core, à un certain coût de performance, car la carte doit aller chercher dans une mémoire plus lente. C'est une technique GPU, pas un renvoi vers un moteur CPU — l'image est toujours calculée sur la RTX 5090, simplement avec un accès mémoire plus lent pour la portion qui ne tient pas dans les 32 Go de la carte. En pratique, la façon de garder une scène Redshift lourde rapide est d'abord de réduire la pression VRAM inutile — des tailles de texture raisonnables, des proxies pour la géométrie répétée, et l'élagage de ce qui est réellement dans le champ — et de laisser l'out-of-core absorber le reste.

Si vous vous demandez si les 32 Go de la RTX 5090 offrent assez de marge pour votre travail en particulier, notre article sur les performances de rendu cloud GPU RTX 5090 détaille comment la carte se comporte sur des scènes réelles, et notre benchmark de scaling multi-GPU montre ce qu'ajouter une deuxième carte fait réellement au temps réel sur une scène comparable.

Graphique de l'usage de la VRAM augmentant avec la complexité de la scène, franchissant la limite des 32 Go de la RTX 5090 où l'out-of-core de Redshift s'active et continue de rendre sur le GPU à un certain coût de performance

Farm entièrement gérée contre location d'une machine GPU par vous-même

Il existe deux grandes façons de rendre avec Redshift dans le cloud, et la différence compte davantage que la fiche technique du matériel.

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

La seconde est une farm entièrement gérée, ce qui correspond à notre mode de fonctionnement. Vous envoyez votre scène, le moteur et les licences sont déjà en place, les images sont réparties sur la flotte GPU — cartes RTX 5090, 32 Go de VRAM chacune — pour vous, et vous récupérez le résultat. Il n'y a pas de bureau à distance où se connecter, rien à installer, et aucune licence à activer. Pour un artiste Redshift, cela supprime les parties du rendu cloud qui n'ont rien à voir avec la fabrication d'images — et c'est ce qui distingue le plus une farm gérée des locations GPU en infrastructure-as-a-service que vous avez pu utiliser. Notre page render farm cloud Redshift est l'endroit vers lequel orienter un collègue qui veut la version courte.

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

Ce que coûte le rendu Redshift sur une farm

Le rendu GPU sur notre farm est facturé à l'usage plutôt que par un abonnement mensuel. L'unité est l'OctaneBench-hour (OBh) — une mesure du travail GPU effectué — facturée à un tarif de base de 0,003 $ par OBh. En pratique, une carte RTX 5090 revient à environ 5,20 $ par heure-carte de rendu. Vous payez le temps GPU réellement consommé par vos images, pas un siège ni un palier d'abonnement.

La même facturation à l'heure-GPU s'applique aux jobs Octane ; notre guide render farm cloud Octane explique comment les scènes Octane tournent sur la flotte.

Quelques précisions qui reviennent souvent :

• La licence est incluse. La licence Redshift fait partie du tarif de rendu. C'est vrai aussi pour les autres moteurs que nous exploitons — il n'y a pas de ligne de licence séparée à budgéter.
• Les crédits n'expirent pas. Vous rechargez un solde de crédits et le dépensez sur des jobs ; les crédits payés restent valables pour quand vous en aurez besoin. Les nouveaux comptes démarrent aussi avec 25 $ de crédit d'essai pour dimensionner un vrai job avant de s'engager sur une séquence.
• Aucun palier. Chaque compte rend au même tarif basé sur l'usage. Il n'y a pas de plan à choisir ni de fonctionnalité verrouillée derrière un palier supérieur.

Pour estimer un job, prenez le temps qu'une image demande sur une carte comparable, multipliez par votre nombre d'images, et appliquez le tarif horaire par carte — réparti sur la flotte, le temps réel s'effondre, mais les heures-GPU facturées restent à peu près le même travail total accompli. Rendre un plan de 10 secondes à 24 im/s représente 240 images ; si chaque image prend quatre minutes sur une carte, cela fait environ 16 heures-carte de travail, soit dans les 83 $ au tarif pratique — restitué en une petite fraction de ce temps réel car les images tournent en parallèle sur plusieurs cartes RTX 5090 plutôt que de faire la queue sur une seule.

Exemple de coût détaillé pour un plan de 240 images : les heures-carte facturées sont les mêmes 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 excellent choix quand vous voulez la vitesse GPU avec la contrôlabilité d'un moteur biaisé, et quand votre application hôte est l'une des quatre citées plus haut. Ce n'est pas la seule option, et bien choisir passe aussi par savoir où il se situe par rapport aux alternatives.

• Face à Arnold, le compromis oppose la vitesse et l'interactivité GPU-biaisée de Redshift à la réputation d'Arnold pour un rendu non biaisé et physiquement fondé, sur CPU comme sur GPU. Nous comparons les deux pour le travail en farm dans Arnold contre Redshift sur une render farm.
• Face à Octane, les deux sont des moteurs GPU avec des philosophies de shading et des supports d'applications hôtes différents. Notre comparaison Octane contre Redshift détaille leurs différences en pratique.
• Face à Cycles, le moteur intégré de Blender, la comparaison porte moins sur GPU uniquement contre CPU uniquement que sur l'écosystème — Cycles tourne à la fois sur CPU et sur GPU selon les besoins de la scène, tandis que Redshift sur notre farm est GPU uniquement sur les quatre DCC pris en charge.

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

Le workflow envoi, rendu, téléchargement

Faire arriver une scène Redshift sur la farm suit les trois mêmes étapes quelle que soit l'application hôte.

Envoi. Packagez votre scène avec ses assets — textures, proxies, caches et références. L'envoi web n'a pas de plafond de taille strict, mais nous conseillons de garder les envois individuels sous environ 300 Go ; au-delà, le SFTP ou notre application client offre un transfert reprenable et parallèle. Les formats d'archive pris en charge sont tar, tar.gz et 7z ; .zip n'est pas pris en charge, donc réarchivez ou transférez les fichiers non archivés si c'est votre seule option. La cause la plus fréquente d'un job GPU qui cale est un chemin d'asset qui se résolvait sur votre poste de travail mais plus une fois les fichiers déplacés, donc rassemblez ou reliez les références externes avant l'envoi.

Rendu. Envoyez le job et les images sont réparties sur la flotte GPU. Comme les jobs Redshift sont GPU uniquement ici, chaque image atterrit sur une RTX 5090 avec ses 32 Go de VRAM, et l'out-of-core couvre les scènes qui en demandent davantage.

Téléchargement. Les images terminées sont disponibles au rapatriement via le web, via SFTP, ou automatiquement via l'application client. La sortie est conservée 45 jours après la fin d'un job, après quoi elle est effacée — téléchargez donc rapidement ou laissez l'application client télécharger automatiquement vers votre stockage local.

Une courte checklist avant d'envoyer un job Redshift

Parcourir cette liste prend quelques minutes et élimine presque toutes les causes évitables d'un job qui revient faux.

FAQ

Q: Redshift est-il GPU uniquement sur une render farm ? A: Sur notre farm, oui — chaque job Redshift tourne sur GPU, spécifiquement sur des cartes NVIDIA RTX 5090 avec 32 Go de VRAM chacune, sans chemin de rendu CPU. Redshift le produit a ajouté un mode CPU à partir de la version 3.5, mais ce n'est pas ce mode qui tourne ici ; notre matériel et notre pipeline sont provisionnés pour un rendu Redshift GPU uniquement. Si vous avez réglé une scène pour le backend CPU ailleurs, validez-la par rapport à la sortie GPU avant de vous engager sur une séquence complète.

Q: Combien coûte une render farm Redshift ? A: Sur notre farm, le rendu GPU est facturé à l'usage à 0,003 $ par OctaneBench-hour, ce qui revient à environ 5,20 $ par heure-carte RTX 5090. La licence Redshift est incluse dans ce tarif — il n'y a pas de frais de licence séparé — et les crédits n'expirent jamais. Les nouveaux comptes démarrent avec 25 $ de crédit d'essai, suffisant pour dimensionner un vrai job avant de s'engager sur un rendu complet.

Q: La farm rend-elle Redshift sur GPU ou sur CPU ? A: GPU uniquement. Nos jobs Redshift tournent sur une flotte NVIDIA RTX 5090 dédiée avec 32 Go de VRAM par carte. Redshift le produit a ajouté un mode CPU en version 3.5, mais sur notre farm il n'existe aucun chemin de rendu CPU pour Redshift — si vous avez réglé une scène pour le backend CPU, validez-la d'abord par rapport à la sortie GPU.

Q: Depuis quelles applications puis-je rendre Redshift ? A: Cinema 4D, Maya, 3ds Max et Houdini. Le moteur est le même dans les quatre cas ; seuls le plugin de liaison de l'application hôte et l'export de scène diffèrent. La licence Redshift est incluse dans le tarif de rendu dans tous les 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 textures et géométrie depuis la mémoire système quand une scène dépasse la VRAM disponible. La scène rend toujours sur le GPU, à un certain coût de performance. Réduire les tailles de texture et utiliser des proxies garde une plus grande partie de la scène résidente en VRAM et rapide.

Q: Ai-je besoin de ma propre licence Redshift ? A: Non. La licence Redshift est incluse dans ce que vous payez pour rendre. En tant que partenaire officiel Maxon, nous licencions Redshift pour un usage de rendu sur la farm, donc il est disponible dans chaque application prise en charge sans rien à activer de votre côté.

Q: Comment le rendu Redshift est-il tarifé au quotidien, et y a-t-il des paliers ? A: Il n'y a pas de paliers d'abonnement — chaque compte rend au même tarif basé sur l'usage décrit ci-dessus. La licence est incluse dans ce tarif pour chaque moteur que nous exploitons, pas seulement Redshift, donc il n'y a pas de ligne séparée à budgéter, quelle que soit celle des quatre applications prises en charge depuis laquelle vous rendez.

Q: Comment envoyer ma scène sur la farm, et combien de temps mes images sont-elles conservées ensuite ? A: Envoyez la scène packagée via le web (pas de plafond de taille strict ; nous conseillons de rester sous environ 300 Go par envoi), ou utilisez le SFTP ou l'application client pour des transferts plus volumineux ou reprenables. Utilisez des archives tar, tar.gz ou 7z — .zip n'est pas pris en charge — et rassemblez ou reliez les assets externes avant l'envoi pour que les chemins se résolvent sur la farm. Une fois les images rendues, la sortie est conservée 45 jours après la fin du job, puis effacée automatiquement — téléchargez via le web, le SFTP, ou l'auto-téléchargement de l'application client avant cette échéance, ou configurez l'auto-téléchargement pour garder une copie locale.