SaaS render farm vs 専用クラスタ:バイヤー向けの誠実な比較

はじめに

2026 年の render farm をめぐる議論は、いまだに 1 つの問いから始まります。どのベンダーが自分のジョブを早く終わらせ、安く請求してくれるか、です。その問いは重要ですが、答えるべき層を取り違えています。エンゲージメント全体を形づくる判断 — 価格の計算、セキュリティ境界、スケーリング挙動、統合コスト、データの所在 — は、その上にあるベンダーブランドではなく、ベンダーが売っているデプロイメントモデルそのものです。モデルが異なる二つのよく運用された farm は、同じシーンをレンダリングできても、まるで別の製品のように感じられます。

この市場における二つの支配的なデプロイメントモデルは、SaaS マネージド render farm(共有インフラ、ベンダー管理の認証情報、ベンダー運用のワークフロー)と専用 render クラスタ(ベンダー提供のハードウェア、顧客保有の認証情報、顧客制御のワークフロー)です。多くの cloud render farm は SaaS モデルしか運用しておらず、より小さなグループがエンタープライズおよび IP センシティブな購入者向けの並列オプションとして専用を提供しています。当社は両方を運用しています — SaaS マネージドはデフォルトサービスで顧客基盤の大半が存在する場所であり、専用クラスタはワークロード、IP 姿勢、ワークフロー複雑度が専用のトレードオフを支払うだけの価値を生むスタジオ向けにデプロイするオプションです。各モデルがどちらで勝つかについては率直に述べます。専用が過剰で SaaS が明らかに正解となるワークロードもあれば、SaaS ベンダーの品質に関わらず SaaS が誤った選択となるワークロードもあります。

本稿は、各モデルが実際に何であるか、その経済性がどう機能するか、データ管理と IP 隔離をどう扱うか、どうスケールするか、10 行のユースケース適合マトリックス、午後の時間で答えられる 10 問のバイヤーフレームワーク、そして各カテゴリの誠実なベンダー例を順に取り上げます。対象読者は、スタジオの CTO、パイプライン TD、エージェンシーのプロダクションリード、実プロジェクトのために cloud rendering を評価しているフリーランス VFX スーパーバイザーです。render farm を初めて評価する方には、what is a fully managed render farm ガイド が出発点として適しています。本稿は render farm が何かをすでにご存じで、それをどう消費するかを選んでいるという前提で進めます。

SaaS マネージド render farm とは

SaaS マネージド render farm はマルチテナントなレンダリングサービスです。ベンダーがハードウェアプール — CPU ノード、GPU ノード、あるいはその両方 — を所有および運用し、そのプールをダッシュボード、DCC プラグイン、ウェブアップロードフォーム経由で多数の顧客に同時公開します。シーンをアップロードし、レンダー設定を選び、ジョブを投入すると、ベンダーのキューが空いているハードウェアにディスパッチします。本稿を読むスタジオの多くは、ある時点で SaaS render farm を使ったことがあるはずです。cloud rendering を地図に乗せたモデルです。

SaaS モデルの定義的な特徴は、ベンダーがハードウェアだけでなくワークフローを扱う点にあります。ベンダーは DCC のインストールとプラグインバージョンを保守し、レンダリングソフトウェアのライセンスを保有し、render manager(通常は Deadline またはその同等品)を運用し、アセットアップロードのパイプラインを管理し、レンダーキューのスケジューラを運用し、完成したフレームを顧客に届けます。顧客視点の表面は「アップロード、レンダー、ダウンロード」です。価格は使用量ベースで、GPU レンダリングなら OctaneBench-hour あたり、CPU レンダリングなら GHz-hour あたり、エンジンによってはフレームあたりが一般的です。

経済性は特定の形のワークロードに合います。500 フレームに対して Karma テストシーンを投入し、千ドル単位ではなくドル単位の請求書を受け取り、翌朝までに終わらせるスタジオが、SaaS の典型的なユースケースです。クライアントの締切に向けて単発の archviz ジョブをレンダリングするフリーランサーは、そのジョブの代金を払って去ります。バースト的なレンダリング需要を持つスタジオ — 静かな週、ピークの週 — は、レンダリングするときだけ支払い、静かな週に容量を抱えません。ベンダーの共有プールがバーストを吸収するのは、他の顧客の静かな週がそれを補助しているからです。

このカテゴリのベンダーには、iRender、RebusFarm、GarageFarm.net、FoxRenderFarm、および SaaS-managed 構成の Super Renders Farm が含まれます。これらベンダー間の差別化は実在しますが、モデルそのものの下に位置しています — サポートされる DCC とプラグイン、ハードウェア仕様、地理的レイテンシ、OctaneBench-hour あたりの価格、必要に応じたパートナー認可ライセンス、締切週でのカスタマーサポート品質などです。モデル自体は、これらのベンダーを横断して認識可能なほど同じです:共有インフラ、ベンダー運用のワークフロー、pay-per-use。

専用 render クラスタとは

専用 render クラスタは、重要な軸において SaaS モデルの建築的対極にあります。ベンダーは引き続きハードウェアを提供および運用します — 同じシャーシ、同じ GPU、同じネットワーク — が、運用境界はハードウェアで止まります。顧客が認証情報を保持し、自身の render manager を運用し(多くの場合、自身の Deadline リポジトリをクラスタに移動)、自身のソフトウェアスタックを保守し、クラスタをベンダーのデータセンタにたまたま存在するオンプレミスハードウェアのように扱います。ベンダーは物理層、OS のベースライン、ネットワーク、共有ストレージに責任を負い、顧客はそれより上のすべてに責任を負います。

専用モデルの定義的な特徴は、クラスタがシングルテナントであることです。他の顧客のジョブはそれらのノードに着地しません。他の顧客のユーザアカウントはクラスタの認証境界内に存在しません。render manager がアセットパスやライセンスチェックアウトをログに残すとき、顧客のパイプラインだけを指します。エンゲージメント終了時にクラスタはワイプされ、顧客はデータが除去されたという証明書を受領できます。これは、マルチテナントレンダリングを禁ずる NDA を抱えるスタジオ、アセットライブラリが定義された信頼境界を出られないライセンス済みアセットワークフロー、そして社内で大幅にカスタマイズされ SaaS ベンダーの投入 UI で表現しきれないパイプラインに対して、意味を持つモデルです。

モデルの経済性は別の形のワークロードに合います。価格は通常、月次リテイナー + セットアップ料金、複数月の最小コミットです。ハードウェア資本はベンダーが吸収し、リテイナーを通じて償却します。顧客はフレーム単位の変動請求ではなく、予測可能な月額数値を支払います。数式が成立するのは、顧客の稼働率が、月次リテイナーが SaaS レートでの同等の per-OctaneBench-hour 請求より安くなるほど高く、なおかつ「同じクラスタ、同じ構成、すべてのプロジェクト」という運用継続性がコミットを正当化する場合です。

専用クラスタ市場は SaaS 市場より相当に小さいです。多くの cloud render farm はこのオプションをまったく提供しません — ビジネスモデル全体が共有インフラ利用を中心に構築されており、シングルテナント展開は運用前提に反するからです。当社の顧客基盤の中で、専用クラスタの展開はエンゲージメントの少数派ですが、エンタープライズ売上の重要な部分を占めます。顧客のワークロード、IP 姿勢、ワークフローが専用のトレードオフを最良の適合とする場合に運用し、顧客のワークロードが専用の提供するものを必要としない場合は SaaS-managed サービスへルーティングします。Self-hosted on-premise は第 3 の選択肢です — 顧客は自身のハードウェアを購入し、自身のデータセンタでクラスタを運用できます。資本、不動産、電源、冷却、運用負荷を完全な制御の自由と交換するわけです。各モデルには正解となる場面があります。

価格モデル比較

価格は、紙の上で 2 つのモデルが最も異なって見える領域であり、比較が最も頻繁に誤って枠付けされる領域でもあります。誠実なバージョンは、ヘッドラインレート対ヘッドラインレートではなく、現実的な稼働率における同じワークロードを両モデルで通すことを要求します。

SaaS の価格は使用量ベースです。GPU レンダリングでは、標準的な課金単位は OctaneBench-hour です:ベンダーがあなたのシーンの compute 消費量を OctaneBench-hour 換算で測定し、per-OB-hour レートを掛けます。CPU レンダリングでは課金単位は GHz-hour です。代表的な例として、典型設定で 1 枚あたり約 20 分かかる RTX 5090 で 500 フレームの Karma シーンを分散レンダーするとき、合計でおよそ 1900 OctaneBench-hour を消費し、業界一般的な $0.10 per OctaneBench-hour ではジョブあたりおよそ $190 となります。顧客はその請求を一度払えばエンゲージメントは完了し、次のジョブの請求は次のジョブのスコープに依存します。請求は仕事に対して線形にスケールします。

専用クラスタの価格はリテイナーベースです。代表的な形は、10–20 ノード GPU クラスタに対する低位 - 中位 5 桁の月次リテイナー、ビルドをプロビジョニングするための 4 桁 - 5 桁のセットアップ料金、そして複数月の最小コミット — 通常 3 〜 12 か月です。公開価格表が一般的でないのは、構成が大きく効くからです。ノード数、GPU 選択、ストレージサイジング、ネットワーク容量、顧客のライセンスモデルがすべて数値を動かします。パターンは一貫しています:予測可能な月次コスト、フレームあたりの変動なし、そして顧客がクラスタを満たそうと満たすまいと支払う硬い床です。

SaaS は稼働率が低い、もしくはバースト的なときに価格で勝ちます。レンダー需要がプロジェクトベースで、エンゲージメント間に静かな期間があるスタジオは、SaaS の方が安くなります。アイドル容量を補助していないからです。月次 SaaS 請求が低位 4 桁以下のスタジオには、専用への数学的根拠はありません。

専用は稼働率が高く持続的なときに価格で勝ちます。SaaS 請求が月次で中位 5 桁に常に着地するスタジオは、月次リテイナーが同等の per-OB-hour 請求より安くなるクロスオーバーに達します。クロスオーバーはエンジン、ハードウェア、交渉レートによって変動しますが、パターンは再現可能です:専用が安い運用モデルになる稼働率の閾値があります。リテイナーには運用継続性の層も含まれます — 同じクラスタ、同じ構成、同じウォームキャッシュ、同じ顧客所有 render manager — これらは SaaS の請求単位比較が捉えないものであり、大量運用者にとっては実銭の価値があります。

一般的なケースでは、いずれのモデルも価格で勝ちません。それぞれが異なる運用レジームで勝ちます。正しい比較は、ヘッドラインレートではなく、顧客の実稼働率における両モデルを通した顧客の実ワークロードです。

データ管理と IP セキュリティの比較

データとセキュリティの比較は、SaaS の姿勢が契約上禁じられる顧客にとってモデル決定が下されがちな領域です。両モデルは異なるデフォルト境界を持ち、専用モデルにはそれを必要とする顧客のためにさらに境界を絞る追加の構成バリエーション — Bring Your Own Credentials(BYOC)— があります。

SaaS モデルでは、ベンダーは顧客データをベンダーの運用境界内で扱います。顧客のシーンファイルはベンダーのストレージに着地し、ベンダーの render manager がマルチテナントワーカーへディスパッチし、ベンダーの認証情報がソフトウェアライセンスのチェックアウトを認可し、レンダリング出力は顧客がダウンロードするまでベンダーのストレージに置かれます。ベンダーはアセットを目にし、認証情報を管理し、テナンシ内で運用します。IP センシティブでないワークロード — 消費者向け archviz の多く、フリーランス作業の多く、契約上のデータ取扱義務がないプロジェクトの多く — に対してはこの姿勢は通常で受容されており、マルチテナントの経済性が SaaS モデルを手頃にしています。

専用クラスタモデルでは、顧客の認証情報がクラスタ内で運用されます。クラスタはシングルテナントなので、他の顧客のジョブが隣接して走ることはありません。顧客はベンダーアクセスをどこまで絞るかを選べます:顧客がすべての認証情報を保持し、ベンダーは OS ベースラインを超える論理的アクセスを持たない完全な BYOC が一方の端にあり、ベンダーが認証情報管理を支援するが認証情報は依然として顧客のテナンシ内にあるベンダー支援運用が中間にあります。エンゲージメント終了時にクラスタはワイプされ、顧客はデータが除去されたという証明書を受領できます。

専用姿勢を必要とする顧客は、自身が必要としていることを承知しています。要件はレンダリング判断の外側 — クライアントの NDA、ライセンス IP を扱う film studio の契約義務、規制業界のコンプライアンス要件、あるいはマルチテナントレンダリングを受け入れない顧客の CISO のセキュリティ姿勢 — から来るからです。専用クラスタは、顧客が自身でハードウェアを購入して運用する必要なくこれらの要件を満たします。BYOC が実務上何を意味するかについては、当社の customer-owned credentials ガイド がモデルを詳しく扱います。

専用姿勢は自動的にセキュリティを改善するわけではありません — 運用の悪い専用クラスタは、運用の良い SaaS デプロイメントより弱いです。そして一定規模以上の SaaS ベンダーの多くは、多くのスタジオが 10 年間で投じる以上をセキュリティエンジニアリングに投じてきました。専用が提供するのは 異なる境界 — マルチテナントという性質ゆえに SaaS 境界が満たせない契約およびコンプライアンス要件を満たす境界 — です。選択は、抽象的にどちらのモデルが「より安全か」ではなく、顧客の契約と義務がどちらの境界を要求するかについてのものです。

スケーラビリティの比較

スケーラビリティは、2 つのモデルが真に異なる振る舞いを見せる比較軸であり、正解が顧客が必要とするスケーリングの種類によって変わる領域です。

SaaS はベンダーの共有プール上限まで即座にスケールします。顧客が 2 時間 80 ノードを必要とするジョブを投入すると、ベンダーのスケジューラはプール内の空き 80 ノードにわたってディスパッチします。顧客はプロビジョニングせず、ウォームアップせず、未使用容量に対して支払いもしません — 弾力性は共有プールが吸収します。予測不能なバースト — 1 週間分のレンダリングを 36 時間に圧縮するクライアントの締切変更、完成したショットでのレンダリングやり直し、予期せぬジョブ到着 — に対しても SaaS は容量計画なしにピークを処理します。天井はベンダーの総プールサイズと、同時に大型ジョブを走らせる他の顧客との競合ですが、年に数回のピーク期を除けば実務上ほとんど真の制約になりません。

専用は計画容量でスケールします。20 ノードの専用クラスタは顧客に 20 ノードを与えます — ジョブが走っていてもいなくても、毎日毎時です。20 ノードを超えるバーストは、クラスタを成長させる(数日 - 数週間かかる調達およびプロビジョニングのステップ)か、専用容量がベースラインを処理し SaaS 容量がピークを吸収するハイブリッドを運用するかが必要です。クラスタはピークではなく定常状態に向けてサイジングされます。

正しいスケーリングモデルは、負荷の予測可能性に依存します。月次レンダリング量がベースラインの 30 % 以内で変動し、大型プロジェクトの着地時期を数か月前に把握しているスタジオは専用に合います。月次負荷が静かな月と忙しい月の間で 5× 変動するスタジオは合いません — その顧客は静かな月に過剰プロビジョニングされるか、忙しい月に過小プロビジョニングされ、SaaS の方が変動を自然に吸収します。

意図的に両モデルを使うハイブリッドパターンもあります:予測可能な部分は専用、ピークは同じベンダーの SaaS。ハイブリッドは両モデルをサポートするベンダーを要し、純粋 SaaS フェーズを超えたスタジオの一般的な最終状態です。

ユースケース適合マトリックス

2 つのモデルは異なるスタジオシナリオに合います。下のマトリックスは一般的状況にデフォルト推奨をマップします。いずれも絶対ではありません — 制約が典型パターンから外れたスタジオは別のセルに着地しうるからです — が、デフォルトは見込み顧客との会話で提示する出発点です。

いくつかの行は明示的に「ワークロード依存」の扱いが妥当です。クロスカントリーのチーム分散は、ワークフローが「アセットをアップロード - レンダー - ダウンロード」のスタジオなら SaaS で機能します。SaaS ベンダーが地理を内部で扱うからです。一方、大陸を跨いで永続的な低レイテンシのアーティストアクセスをレンダリング環境に必要とするスタジオは、WireGuard と共有 SMB キャッシュを用いた クロスカントリーアーキテクチャ を持つ専用モデルに行き着きます。カスタムプラグインスタックは、SaaS ベンダーのプラグインサポートが顧客のスタックをすでにカバーしていれば SaaS で動きます。SaaS ベンダーが共有ワーカーに入れられない社内プラグインやニッチな第三者ツーリングを運用する場合は、専用がデフォルトになります。中規模エージェンシークライアント業務は多くのエージェンシーでデフォルト SaaS ですが、最大の顧客がシングルテナントレンダリングを要求する NDA を持つエージェンシーでは専用へ振れます — IP 姿勢が稼働率の経済性をオーバーライドするからです。

マトリックスは「何をするか」ではなく「会話をどこから始めるか」として読むべきものです。状況が 2 つのセルに跨るスタジオは、どちらのセルがより強い制約を持つかを考えるべきです。IP 姿勢と稼働率は、他をオーバーライドする頻度が最も高い 2 つのセルです。

10 問のバイヤー意思決定フレームワーク

マトリックスはシナリオごとのモデル推奨を提示します。下のバイヤーフレームワークはより細かい版で、誠実に答えれば特定状況における正しいモデルへ導く 10 の問いです。多くのスタジオは午後の時間でこの 10 問すべてに答えられます。

1. 平均プロジェクト長はどれくらいですか? 短期プロジェクト(単独納品、単月エンゲージメント)は SaaS を好みます。レンダー負荷が持続する複数月エンゲージメントは専用を好みます。
2. クライアント契約や NDA がシングルテナントレンダリングを要求する、またはデータ処理の所在を制限しますか? ここで「はい」が出ると、他の要因に関わらず判断は専用へ大きく傾きます。
3. ライセンスモデルは何ですか — BYOL(Bring Your Own License)、それともベンダー提供? いずれのモデルも両アプローチを支持しますが、運用コストは変わります。専用は通常 BYOL とよりすっきり組みます。SaaS は vendor-provided ライセンスを per-OB-hour レートに含めることが多いです。
4. 異なるパイプラインで複数の並行プロジェクトを走らせる必要がありますか? はいの場合、プロジェクト隔離の議論は専用に傾きます。各プロジェクトに独自のユーザアカウントと設定を持たせられるからです。SaaS は並行プロジェクトを扱いますが、ベンダーのキュー経由であり、顧客管理の隔離経由ではありません。
5. 社内 IT とパイプラインエンジニアリングの容量はどの程度ですか? 専用は render manager とパイプラインを運用できる社内チームを必要とします。スタジオにその容量がない場合、SaaS が要件を取り除きます。ベンダーがパイプラインを運用するからです。
6. CapEx と OpEx の柔軟性、どちらを好みますか? SaaS は純 OpEx です — 請求は使用量とともにスケールし、コミットなしです。専用はリテイナー形の OpEx ですが、複数月のコミットを伴うため固定費に近い振る舞いをします。ハイブリッドは両者を分けます。
7. プラグインと DCC スタックはどれほど複雑ですか? 標準的な 3ds Max + V-Ray パイプラインは市場のあらゆる SaaS ベンダーで動きます。カスタム HDA、ニッチな第三者プラグイン、特定の OS 依存性を持つ社内 Houdini パイプラインは、SaaS ベンダーの共有ワーカーに収まらない可能性があり、判断を専用へ押し出します。
8. チームメンバーは地理的にどこにいますか? 単一国チームは地理的制約が最も軽いです。複数大陸のチームは、ワークフローのレイテンシを適正に保つため専用モデルのクロスカントリーネットワークアーキテクチャを必要とすることがあります。
9. コンプライアンス要件は何ですか? SOC 2、ISO 27001、MPA-readiness などの姿勢は通常、マルチテナントの SaaS モデルが既製では提供できないシングルテナントレンダリングや特定のデータ取扱コミットメントを要求します。
10. 年次レンダリング量は OctaneBench-hour または GHz-hour でいくつですか? 計算してください:業界一般的な SaaS レートで、年間ボリュームは SaaS でいくらになり、同期間の同等の専用リテイナーはいくらになりますか? 専用があなたのボリュームで安いなら、稼働率の経済性は専用を好みます。SaaS が安いなら SaaS を好みます。

これら 10 問に誠実に答えるスタジオの多くは、明確なデフォルトに着地します。判断が真に分かれるスタジオは通常、IP 姿勢が専用を、稼働率が SaaS を示すケースで、その場合は通常専用へ解決します。IP 要件は稼働率の経済性とは異なる仕方で非交渉的だからです。

ベンダー例(誠実)

モデル決定はベンダーリストを絞ります。買い手が誠実にランドスケープを評価するのに役立つところでは名前を挙げます。SRF が本セクションの最後に登場するのは意図的です — どちらのカテゴリでも当社が唯一の選択肢ではなく、判断はたまたま読んだベンダーの記事ではなく、ベンダーのワークロード適合に基づいてなされるべきだからです。

確立された運用実績を持つ SaaS マネージド render farm ベンダー:

• iRender — ベトナム拠点、GPU-first 志向、ハイブリッドな subscription と pay-per-use の価格。アーティストがパイプラインの多くを自己管理する市場で強力です。
• RebusFarm — ドイツ拠点、20 年の運用実績、広範な DCC とエンジンサポート、複数の地理的データセンタ。広範な言語カバレッジを持つ確立された商用レンダーサービス。
• GarageFarm.net — UK 登記、ポーランドのデータセンタ(Toruń の Copernicus Computing、ISO 27001 認証)、韓国のカスタマーサービスハブ、16 年の運用実績。広範な DCC サポートを持つジェネラリスト farm。AE は deprecated され、Houdini は 2026 年時点でネイティブにはサポートされません。
• FoxRenderFarm — 中国拠点、広範な DCC サポート、多言語カバレッジ。アジア太平洋市場で強力です。
• Super Renders Farm(SaaS-managed) — 当社のデフォルトサービス。GPU レンダリングは per-OctaneBench-hour 課金、CPU レンダリングは per-GHz-hour。3ds Max、Maya、Cinema 4D、Blender、Houdini、After Effects、NukeX をサポート。レンダーエンジン:V-Ray、Corona、Arnold、Redshift、Octane、Cycles。Chaos Group(V-Ray、Corona)および Maxon(Cinema 4D、Redshift)を通じたパートナー認可ライセンス。Fleet:20,000+ CPU コアと、各 32 GB VRAM の NVIDIA RTX 5090 専用 GPU fleet。

専用 render クラスタはより小さな市場です。上記の SaaS ベンダーの多くは、専用を並列オプションとして提供しません — ビジネスモデルは共有利用を中心に構築されており、シングルテナント構成はデフォルト提供の外にあるためです。専用が必要な顧客は、infrastructure-as-a-service レール(AWS、GCP、bare-metal ベンダー)上に構築して自身の render manager を載せるか、両モデルを運用するベンダーと組みます。

Super Renders Farm(専用クラスタ) — 当社の専用クラスタ提供。SaaS サービスが動くのと同じハードウェアに顧客固有のクラスタをデプロイしますが、顧客保有の認証情報、顧客制御の render manager、BYOC 能力、エンゲージメント終了時のデータ証明書、そして必要時に共有プールから SaaS バーストを吸収できるハイブリッド容量を備えたシングルテナントとして構成します。専用提供は、複数月エンゲージメントにわたって顧客サイトで本番クラスタを運用して学んだ運用パターンを中心に構築されており、US 拠点のアーティストとベトナム拠点のインフラを暗号化トンネルで結ぶクロスカントリー展開も含みます。

第 3 の選択肢としての self-hosted に関するメモ:強いインフラエンジニアリング能力を持つスタジオは、同じオープンソースコンポーネント(Linux、Samba SMB3、Deadline など)を用いて、所有するハードウェア上、賃借するコロケーション施設で同じアーキテクチャを構築できます。ベンダー付き専用と self-hosted の判断は、スタジオの利用可能資本、不動産、電源と冷却、運用成熟度を巡る build-vs-buy の問いです。render farm build vs cloud total cost ガイド は self-hosted-vs-vendor の数式を別途扱います。

FAQ

Q: 専用クラスタの ROI は、いつ SaaS マネージドを上回りますか? A: クロスオーバーは、SaaS レートでの持続的な月次稼働率が同等の専用リテイナーを超えるときに起こります。正確な閾値は顧客の per-OB-hour レート、ハードウェア構成、契約期間に依存しますが、パターンは再現可能です:月次 SaaS 請求が中位 5 桁以上に常に着地するスタジオは通常、専用の数式が成立することを見出します。加えて運用継続性(同じクラスタ、同じウォームキャッシュ、同じ顧客保有 render manager)の追加価値が上に乗ります。

Q: SaaS マネージドから始めて、後で専用にアップグレードできますか? A: はい、よくある道筋です。スタジオは通常 SaaS から始めてワークフローを検証し実稼働率を測定し、月次請求や IP 姿勢が正当化されるや否や専用へ移ります。両モデルを運用するベンダーであれば移行は主に調達ステップとパイプライン移行ステップですが、SaaS 専業のベンダーでは移行はベンダー変更や self-hosted を要し、より大きな労力になります。

Q: 専用クラスタはエンタープライズ専用ですか? A: エンタープライズに偏ります。リテイナーの数式が小さなスタジオが通常持たない持続稼働率を要するからです。しかしエンタープライズ専用ではありません。IP センシティブなワークロード(NDA で制約された顧客を持つエージェンシー、ライセンスプロパティのプロジェクトを行うインディ VFX ハウス)を持つ中規模スタジオは、稼働率の経済性が要求しなくとも姿勢が必要なため、低稼働率でも専用をデプロイすることが多いです。そのケースでは IP 要件がボリューム要件をオーバーライドします。

Q: render manager(Deadline)は両モデルでどう扱いが異なりますか? A: SaaS ではベンダーが render manager を運用し、顧客はベンダーの投入 UI またはプラグイン経由でジョブを投入します。顧客は Deadline に直接ログインしません。専用では顧客がクラスタ内で自身の Deadline リポジトリを運用するか、ベンダーが顧客のために運用するものを使うかですが、いずれにせよ顧客は render manager に直接アクセスでき、プールとグループを構成し、Deadline API に対して自身のパイプラインツールを統合し、ベンダーサポート依頼を経ずにスケジューリング挙動を変更できます。

Q: SaaS と専用のハイブリッド — 一部のジョブをそれぞれで — はどうですか? A: 純粋 SaaS フェーズを超えたスタジオの一般的な最終状態です。ベースライン負荷は単位コストの経済性と運用継続性のために専用で走り、バーストピークはその期間中、同じベンダー(または別のベンダー)の SaaS にプッシュされます。ハイブリッドは両モデルを運用するベンダー、または 2 つのベンダー間でワークフローを分割する運用規律を要します。ハイブリッドに着地するスタジオの多くは SaaS で始め、ベースラインを専用に移し、ピーク吸収のために SaaS を残しました。

Q: 両モデルで uptime と SLA はどう異なりますか? A: SaaS の SLA は通常キューの可用性コミットメントです — ベンダーはキューがジョブを受け付け、ある時間枠内にディスパッチすることを保証しますが、顧客個別のジョブレイテンシは共有プールの競合次第で変動します。専用の SLA は通常ノード単位の可用性コミットメントです — ベンダーは専用ノードが起動し到達可能であることを保証し、顧客はキュー挙動を制御します。締切センシティブなワークフローを持つスタジオは、専用 SLA を好むことが多いです。キュー制御を自分の手に置き、共有プールの変動性をクリティカルパスから取り除けるからです。

Q: 専用クラスタエンゲージメントの典型的な契約期間は? A: 最小コミットは、短いエンゲージメントなら 3 か月から、完全なエンタープライズ展開なら 12 か月までが通常で、クラスタサイズとセットアップ料金構造に依存します。トライアルや単一プロジェクトの作業にはより短いコミットも存在しますが、セットアップ償却のため月次レートは高めになります。複数年契約はコミット長と引き換えにレート譲歩を伴います。正しい契約期間は、そのクラスタを正当化するワークロードに対する顧客の計画ホライズンと合致します。

Q: ワークロードが伸びた場合、専用クラスタはエンゲージメント途中でスケールアップできますか? A: はい、ただしスケーリングは即時ではなく計画的です。ノードを追加して専用クラスタを成長させるには調達、プロビジョニング、短いコミッショニング窓が要ります — 通常は SaaS の即時弾力ではなく、数日 - 数週間です。スケールアップが予測可能なワークロードなら問題ありませんが、予測不能な成長に対しては、顧客は通常、SaaS がピークを吸収する間に専用クラスタが新しい定常状態へスケールするハイブリッド体制を構成します。