Nukeクラウドレンダーファーム：2026年のコンプをスケールでレンダリングする

クラウドレンダーファームでNukeコンプをレンダリングする

コンポジットは、VFXショットの最後の工程です。シーケンスがNukeに届く頃には、3Dレンダリングは完了し、プレートのグレーディングも終わり、アーティストは最終的な画像——マージ、キー、ディープホールドアウト、レンズワーク、グレインを組み上げています。問題は、この「最終画像」の書き出しコストが決して安くはないことです。マルチチャンネルEXR入力を何層も重ねた200フレームの4Kシーケンスに、いくつかのGPU対応ノードが加わると、シングルワークステーションが数時間にわたって占有され、レンダリング中はアーティストが他の作業を続けられません。これはまさに、クラウドレンダーファームが引き受けるべき仕事です。

Super Renders Farmでは、レンダーフリート全体でNukeXを運用しており、長年の経験から、Nukeコンプがファームで正常にレンダリングされるかどうかを左右するいくつかの重要な詳細が繰り返し浮かび上がってきました。コンポジット計算自体が失敗することはほぼありません。問題の原因は、ギズモの欠如、OCIOコンフィグの不一致、Linuxワーカー上では意味をなさないWindowsの絶対パス、あるいはどのNukeエディションがオフマシンでレンダリングできるかについての誤解です。このガイドでは、Nukeコンプがファーム全体にどのように分散されるか、送信前に理解しておくべきエディションとライセンスの概要、GPUアクセラレーションが実際に役立つ場面（そして役立たない場面）、そしてコンプを正しくパッケージングして何も欠落しないようにする方法を説明します。同じ運用の考え方は、幅広いVFXおよびプロダクトビジュアライゼーションワークフローにも適用されますが、Nukeには固有の注意点があり、本稿ではそちらに焦点を当てます。

Nukeコンプがタイルではなくフレーム単位で並列化される理由

Nukeがファーム全体にどのように分散されるかを理解するには、3Dレンダラーと比較するとわかりやすいです。V-RayやArnoldのようなパストレーサーは、1枚のフレームをバケットやタイルに分割し、各領域を別のスレッド——あるいは分散レンダリングでは別のマシン——に割り当てることができます。左上隅のピクセルは右下隅のピクセルに依存しないため、フレームを空間的に分割することが可能です。

2Dコンプは異なる動作をします。フレームNにおける任意のピクセルの値は、そのフレームの入力がノードツリーを通過したものにのみ依存します。各フレームは完全に独立しており、Nukeコンプはフレーム単位の並列処理（embarrassingly parallel by frame）が可能です：フレーム1を1台のマシンでレンダリングし、フレーム200を別のマシンでレンダリングしても、両者の間に調整は不要です。Nukeがしないことは、1枚のフレームを空間的なタイルに分割して別々のマシンに割り当てることです——Writeノードは1つのプロセスで完全なフレームをレンダリングします。1台のマシン内では、NukeはCPUスレッド間で並列処理を行い、スキャンライン/リージョンエンジンを使用しますが、マシン間での分散単位はフレームです。

この事実がファームレンダリングのすべてを規定します。レンダーマネージャーは画像を細分化せず、フレーム範囲を細分化します。1,000フレームのシーケンスは、より小さなフレーム範囲の「チャンク」に分割され、各チャンクがワーカーに割り当てられ、すべてのワーカーが自身のスライスに対してヘッドレスのNukeレンダリングを起動します。以下の図はその仕組みを示しています。

フレームは独立しているため、投入できるワーカーの数にほぼ線形にスループットが向上します——それが、クラウドで長いコンプシーケンスをレンダリングすることが価値を持つ理由です。

ヘッドレスレンダリング：ワーカー上でNukeが動作する仕組み

ファームにはGUIはありません。各ワーカーはNukeをターミナル（バッチ）モードで実行し、指定のフレーム範囲に対してすべてのアクティブなWriteノードをレンダリングして終了します。基本的なコマンドは以下の通りです。

nuke -x -F 1-50 comp.nk

-xはNukeを実行モードにします。-Fはフレーム範囲を設定し、単一フレーム（-F 7）、連続範囲（-F 1-50）、ステップ付き範囲（-F 1-100x2は1フレームおきにレンダリング）を受け付けます。非連続範囲のために複数の-F引数を1つのコマンドに渡すことも可能です。単一コンプから本番シーケンスに移行すると、さらにいくつかのフラグが重要になります。

フラグ	動作	ファームでの重要性
-x	すべてのアクティブなWriteノードを実行（レンダリング）する	標準的なバッチレンダリングスイッチ
-F a-bxc	オプションのステップ付きフレーム範囲	レンダーマネージャーがチャンクごとに設定
-X node	指定のWriteノードのみレンダリング	複数のWriteがあるコンプで1つの出力のみレンダリング
--sro	Writeノードのレンダー順序に従う	下流のReadが上流のWriteの出力に依存する場合に必須
--cont	フレームエラーが発生しても続行	1フレームの破損でチャンク全体が中断されない
-m N	レンダースレッド数を設定	マシンのコア数に合わせたワーカーごとの並列処理調整

この方法で開始したレンダーは、デフォルトでインタラクティブシートではなくレンダーライセンスを要求します——詳細は次のセクションで説明します。Nukeはまた、レンダーマネージャーがタスクの成功・失敗・リトライ要否を判断するための有用な終了コードを返します：0は成功、1はレンダーエラー、100はライセンスの失敗を示します。管理されたファームでは、これらのコマンドを自身で入力することはほとんどありません。送信ツールが自動的に構築します。しかし、内部で何が動いているかを理解することで、レンダーログで見かける動作のほとんどが説明できます。

ファームレンダリングと混同しないよう、もう1つの分散メカニズムについて触れておきます：NukeのFrame Serverです。Frame Serverは複数のバックグラウンドレンダープロセスを起動して単一のレンダリングを高速化します——ビジーなワークステーションや小規模なヘルパーマシンの組み合わせで役立ちます。これはフレーム範囲のファームスケール分散とは異なるツールであり、後者は完全なシーケンスを長い週末（数日）ではなく一晩で返したい場合に必要なものです。

ファームレンダリングのためのNukeエディションとライセンス

最も多くの人が引っかかる部分です。「Nuke」はファミリーであり、単一の製品ではなく、エディションによってファーム上での動作が異なります。

エディション	概要	ファームでレンダリング可能か
Nuke（商用）	ベースとなるノードベースのコンポジター	可——レンダーライセンスが必要
NukeX	NukeにCameraTracker、デノイズ、デブラー、レンズ歪み補正、PointCloudGenerator、ParticleSystemなどの高度なノードを追加したもの	可——レンダーライセンスが必要
Nuke Studio	NukeXツールセットにエディトリアル/コンフォームタイムラインを追加したもの	可——レンダーライセンスが必要
Nuke Indie	低コストのシングルアーティストエディション	不可——外部およびクラウドレンダーファームはサポートされていません
Nuke Assist	ペイント、ロト、トラッキング向けの制限されたノードサブセット	不可——インタラクティブアシストシートであり、レンダーライセンスではありません

この表は、特定のフリートではなく、あらゆるレンダーファームの要件に対するNukeファミリー全般を説明しています。当ファームでのレンダーサイドアプリケーションはNukeXであり、このガイドの残りの部分で説明します。表から特に注目すべき2点があります。

Nuke Indieはファームでのレンダリングが一切できません。 FoundryのIndieエディションは収益上限のある個人アーティスト向けに設計されており、その利用規約は外部サードパーティのレンダーファーム、クラウドレンダリングサービス、およびリモートFrame Serverレンダリングを明示的に除外しています。Indieはまた、商用パーサーが読み取れない独自の暗号化スクリプト形式で保存します。そのため、Indieを使用していてファームへの送信がうまくいかない場合、それは設定の問題ではなく、ライセンスの境界線です。ファームレンダリングには商用Nuke、NukeX、またはNuke Studioエディションが必要です。

ファームではインタラクティブシートではなく、レンダーライセンスを使用します。レンダーライセンスとは、ヘッドレスかつGUIなしのNukeであり、レンダリングのためだけに存在します——ターミナルレンダリングを起動すると、Nukeはデフォルトでレンダーライセンスを要求します。レンダーライセンスはアーティストが使用するインタラクティブシートとは独立しており、そのためスタジオは50台のマシンにコンプを配置しても、フルインタラクティブのNukeシートを50個購入する必要がありません。混合パイプラインに有用な詳細として、レンダーライセンスはNukeXエディション以下で作成されたすべてのノードをレンダリングできます。そのため、NukeX搭載のレンダーノードは、アーティストがベースNukeで作成したスクリプトを問題なくレンダリングします。NukeXはNukeのスーパーセットです——ノードを追加するのみで、標準ノードを読み取る能力は削除されません。逆は唯一の実際の制約です：ベースNukeはNukeX専用のノードを評価できません。

ライセンスモデルについては、Foundryは2023年初頭にNukeファミリーを年間サブスクリプションに移行し、オンラインまたはオフラインで実行できるログインベースのライセンスを採用しています。永続ライセンスやレンタルオプションも存在します。具体的な仕組みはスタジオによって異なります。これが次のセクションのポイントです。

当ファームでのライセンスの仕組み

Super Renders FarmはFoundryパートナーではなく、そのような主張もしていません。当ファームの検証済みベンダーパートナーシップは、コンポジットソフトウェアベンダーではなく、レンダーエンジンメーカーとのものです。当ファームが運用しているのはレンダーオンリー利用モデルであり、パートナーシップに縛られないフリート上の他のアプリケーションで使用しているのと同じアプローチです。

実際には、ワーカーごとにレンダーライセンスシートを自分でプロビジョニングしたり管理したりする必要はありません。ワーカーフリートはNukeXを実行し、サポートされているビルドにバージョンが固定されており、コンポジターはヘッドレスでスクリプトをレンダリングするために起動します。SuperRendersはフルマネージドファームであるため、マシンにリモートデスクトップでアクセスしたり、Nukeをインストールしたり、ライセンスサーバーを手動設定したりする必要はありません——ジョブが届いた時点で、レンダーサイドの環境はすでに整っています。これがマネージドファームと、Nukeとそのライセンスをすべてのインスタンスで自分でオンラインにしなければならないDIY IaaSセットアップとの運用上の違いです。

コスト面では、コンプレンダリングは他のCPU作業と同様に課金されます——使用したコンピューティングのGHz時間あたりで、マシンのレンタル最低額はなく、有効期限のないレンダークレジットが使用されます。新規アカウントには$25クレジットが付与されます。これは短いテストシーケンスをエンドツーエンドでレンダリングし、フルジョブをコミットする前にコンプがワークステーション上と同じようにファームで動作することを確認するには十分な量です。現在の料金とコスト計算ツールは料金ページにあります。

フレーム範囲分散の実際

ファームがフレーム範囲をチャンクに分割することを知ることと、そこからクリーンで予測可能なレンダリングを得ることは別の問題です。サポート側で繰り返し見られる実践的なポイントがいくつかあります。

チャンクサイズはトレードオフです。 小さなチャンク（数フレームずつ）は作業をより多くのマシンに分散し、失敗したタスクからより速く回復しますが、Nukeの起動コスト——スクリプトのロード、ライセンスのチェックアウト、プラグインの初期化——をより頻繁に支払います。大きなチャンクは起動コストを分散させますが、1台の遅いマシンがシーケンスの末尾を保持すると取り残しが生じます。ほとんどのコンプでは、各ワーカーを数分間ビジーに保つ程度の適度なチャンクサイズが合理的なデフォルトです。フレームごとのコンプが重い場合（ディープ、4K以上、GPUノードが多い）は、より小さなチャンクが適しています。

Writeノードの依存関係に注意してください。 スクリプトに、より前に実行されるWriteが生成したファイルに依存する下流のReadがある場合——例えばディスクに焼き付けられたプリコンプ——それらのWriteは順番に実行される必要があります。そのために--sroがあります。なければ、ワーカーが入力が存在する前に依存Writeを試みる可能性があり、マシンのタイミングに依存するためランダムに見える断続的な欠落フレームエラーが発生します。

たまに発生する問題フレームの計画を立てておいてください。 読み取り不能な入力や一時的なストレージの問題があっても、チャンク全体を中断させるべきではありません。--contはレンダリングが失敗したフレームを通り過ぎて続行できるようにするため、すべてをレンダリングし直すのではなく、後でギャップだけを再キューイングできます。レンダーマネージャーの自動タスクリトライと組み合わせることで、長いシーケンスを監視なしで進め続けることができます。

これを正しく行うことの効果は明快です：アーティストのマシンを丸1日占有するシーケンスが、最も遅い単一チャンクのレンダリング時間で返ってきます。他のすべてのチャンクは並行してレンダリングされているからです。

ファームでのNukeにおけるGPU対CPU

GPUファーストの3Dレンダリングから来た人には驚かれることがある点があります：NukeはファンダメンタルにCPUアプリケーションです。 コンポジット操作の大部分——マージ、色補正、トランスフォーム、キー、ほとんどのフィルター——はCPU上で実行されます。NukeにおけるGPUアクセラレーションは、特定のノードサブセットに対してオプトインであり、「使用可能であればGPUを使用」というコントロールによって公開されています。そのコントロールを持たないノードはCPUのみです。

ワークロード	実行場所	例
一般的なコンポジット	CPU	Merge、Grade、ColorCorrect、Transform、Keyer、ほとんどのフィルター
GPUアクセラレーションノード	GPU（オプトイン、CPUフォールバックあり）	KronosおよびMotionBlurリタイム、Denoise、VectorGenerator、Convolve、ZDefocus
BlinkScript / 機械学習	GPU	BlinkScriptカーネル、CopyCatトレーニング（NVIDIA GPUが必要）

ハードウェアの観点では、グレード、マージ、トランスフォームが中心のコンプはGPUからほとんどメリットを得られません——CPUコアとメモリが必要です。重いKronosリタイム、大きなZDefocus、Denoise、またはカスタムBlinkScript作業に依存するコンプは、GPU上で大幅に高速化できます。ほとんどの本番コンプはその中間に位置しており、そのためCPUキャパシティを主軸として、GPUを実際に使用するノードのアクセラレーターとして扱っています。

当フリートはそれを反映しています。コンポジット作業の大部分は、デュアルIntel Xeon E5-2699 V4プロセッサーを搭載し96〜256 GBのRAMを持つCPUマシン——合計20,000以上のCPUコア——で実行されます。そして、そのメモリヘッドルームが過小評価されがちな部分です。ディープコンポジットや高解像度のマルチチャンネルEXRプレートはメモリを多く消費します。4Kのディープフレームはピクセルあたりのサンプルを多数保持でき、フレームの途中でRAMが不足することは、純粋なCPU速度よりもファームレンダリング失敗のはるかに一般的な原因です。GPUノードから実際にメリットを受けるコンプには、32 GBのVRAMを搭載したNVIDIA RTX 5090カードで構成された専用のGPUクラウドレンダーファームも運用しています。そのGPU層が重いワークロードでどのようなパフォーマンスを発揮するかについては、RTX 5090クラウドレンダリングベンチマークで詳しく説明しています。ただし、Nuke向けの正直なアドバイスとしては、コンプに合わせて適切なサイズを選ぶことです：マージ中心のスクリプトが決して触れないGPU時間に費用を払わないようにしてください。

ファイルとアセットの処理：実際に壊れる部分

Nukeのレンダリングがファームで失敗した場合、その原因はコンポジットの問題ではなく、依存関係の問題である可能性が圧倒的に高いです。コンプスクリプトは主に参照の集合です——フッテージへ、ギズモへ、カラーコンフィグへ——そして、これらの参照はすべて、アーティストのマシンではないワーカー上でも同一に解決される必要があります。

依存関係	失敗モード	確認すべきこと
フッテージ / Readノード	フレーム欠落、「ファイルが見つかりません」	ネットワーク到達可能でOSに依存しないパス——アーティストのPCにのみ存在するローカルのZ:\ドライブ文字ではなく
ギズモ / OFXプラグイン	スクリプトが読み込めない、不明なノード	すべてのレンダーノードにインストール済み、または送信前にスクリプトにグループ化/ベイク済み
OCIOカラーコンフィグ	色が間違っている、グレードが一致しない	アーティストが使用したものと同じコンフィグがファームに展開され選択されている
フォント	テキストノードで代替または間違ったグリフ	使用されているフォントがレンダーノードに存在している
LUT / .cubeファイル	色変換の失敗	コンプで参照されているスタンドアロンLUTファイルが一緒に送られている
Nukeバージョン	ノードの非互換性	レンダービルドがアーティストの使用ビルドと一致している（または新しい）

いくつかの点は詳しく見る価値があります。パスは古典的な問題です：Z:\project\plates\を参照しているWindowsのアーティストは、Linuxワーカーには意味をなさないスクリプトを生成します。一貫したネットワークアクセス可能なプロジェクトパス——あるいはファームへの転送時にパスを書き換えるレンダーマネージャー——でこれを解決できます。ギズモとカスタムOFXはレンダーノード上に存在する必要があります。送信前の最も安全な習慣は、カスタムギズモをGroupに変換することで、スクリプトにベイクされ、外部依存関係を持たなくなります。

OCIOコンフィグのドリフトは最も微妙な問題であり、注目する価値があります。なぜなら、レンダリングは成功するが見た目が間違っている状態になるからです。Nukeのカラーマネジメントは、OpenColorIOコンフィグによって駆動されています。ファームがアーティストの使用したものと異なるコンフィグを解決した場合——異なるファイルパス、デプロイされなかったカスタムコンフィグ、あるいは別の場所を指す環境変数——カラートランスフォームが乖離し、ファームレンダリングはアーティストが承認したビューアと一致しません。解決策は規律です：プロジェクトを特定のデプロイ済みコンフィグに固定し、レンダリング環境がまさにそのコンフィグを使用していることを確認してください。マネージドファームはデフォルトでNukeの標準バンドルOCIOコンフィグを保持していますが、スタジオのカスタムOCIOコンフィグはジョブと一緒に持参する必要があります。

出力側では、Nukeコンプは通常マルチチャンネルEXRを読み書きします。単一のOpenEXRファイルは多くのチャンネルを含むことができます——ビューティパスとディフューズ、スペキュラー、ライティングAOV、Zデプスパス、クリプトマットマスク——すべてが1つのReadノードを通して読み込まれ、Shuffleノードでパスごとの作業として分割されます。ディープコンポジットでは、NukeはDeepReadとDeepWriteを通してディープEXRを読み書きし、ピクセルごとに複数の深度サンプルを保存して、3Dを再レンダリングすることなくホールドアウトやエッジの問題を解決します。このデータのほとんどは16ビット半精度浮動小数点で保存されており、これはHDRリニアプレートの標準で、32ビット全精度浮動小数点はワールドポジションやモーションベクターのような完全な精度が必要なデータパスに予約されています。これらは特殊なことではありませんが、それぞれのチャンネルは移動するデータが増え、保持するメモリも増えます。これが、コンプレンダリングにおいてRAMとストレージスループットがコア数と同じくらい重要である理由に直結します。

Nukeコンプの送信前チェックリスト

コンプを任意のファーム——当ファームまたは社内キュー——に送信する前に、以下の点を素早く確認することで、大多数のレンダリング失敗を防ぐことができます。

• パス： すべてのReadおよびWriteノードがネットワーク到達可能でOSに依存しないパスを使用しており、ローカルドライブ文字を使用していない。
• ギズモ： カスタムギズモがGroupに変換されている（ベイク済み）か、レンダーノードへのインストールが確認されている。
• カラー： OCIOコンフィグがファームが解決するものと一致しており、カスタムコンフィグはジョブと一緒に持参している。
• フォントとLUT： テキストノードで使用されるすべてのフォントと、参照されているすべての.cube/LUTファイルが存在している。
• バージョン： レンダービルドがコンプ作成時のビルドと一致している。
• エディション： スクリプトが商用Nuke、NukeX、またはNuke Studio由来——ファームレンダリングできないIndieではない。
• レンダー順序： 下流のReadが上流のWriteに依存する場合は、--sroでレンダリングする。
• 小さくテストする： 最初に数フレームをレンダリングして、完全な範囲をコミットする前にアーティストのローカル出力と比較する。

最後の点は安価な保険です。5フレームのテストレンダリングで、数分のコストでパス、カラー、またはバージョンの不一致を検出できます——一晩かけたジョブの800フレーム目で発見するよりはるかにましです。

Nukeレンダリングが広いパイプラインに位置するところ

最終フレームのEXR出力はNukeコンプの最も一般的なエンドポイントですが、それが唯一のものではありません。ショットがフラットなレンダリングシーケンスではなくリアルタイムエンジンに向かっている場合——バーチャルプロダクションまたはインエンジンレビュー——統合の問いは異なります。そのパスについてはNukeからUnreal Engineへのパイプラインガイドで別途説明しています。区別を明確にしておきます：この記事はファームでコンプフレームをスケールでレンダリングすることに関するものであり、Unrealのパスは Nukeのワークをリアルタイムコンテキストにもたらすことに関するものです。分散レンダリングの一般的な仕組みをまだ整理中であれば、レンダーファームとは何かのガイドが良い出発点です。

ここで説明したメカニクスの権威ある参照資料として、Foundry自身のコマンドライン操作とレンダーファームに関するドキュメントとNukeファミリーライセンスに関するFAQが正規の情報源であり、OpenEXRとOpenColorIOのプロジェクトサイトはコンプが依存するファイルとカラー標準を文書化しています。

FAQ

Q: Nuke IndieライセンスでクラウドレンダーファームにNukeをレンダリングできますか？ A: いいえ。FoundryのNuke Indieエディションは、外部サードパーティのレンダーファーム、クラウドレンダリングサービス、またはリモートFrame Serverレンダリングを明示的にサポートしておらず、商用パーサーが読み取れない暗号化スクリプト形式で保存します。ファームレンダリングには商用Nuke、NukeX、またはNuke Studioエディションが必要です。

Q: クラウドレンダーファームを使用するために、別のNukeレンダーライセンスが必要ですか？ A: ファームでは、レンダリングはインタラクティブシートではなくレンダーライセンスを使用してヘッドレスで実行されます——そのため、スタジオは各マシンにフルインタラクティブシートを購入することなく多くのマシンでレンダリングできます。当ファームでは自分でこれらをプロビジョニングする必要はありません。ワーカーフリートはレンダーオンリー利用モデルでNukeXを実行しているため、レンダーサイドのライセンスはファーム側で処理されます。

Q: NukeのレンダリングはGPUとCPUどちらが速いですか？ A: ほとんどのコンプではCPUです。NukeはファンダメンタルにCPUアプリケーションです。特定のノードサブセット——Kronos、Denoise、ZDefocus、Convolve、BlinkScript、およびCopyCatのような機械学習ツール——のみGPUアクセラレーションがあります。マージ、グレード、トランスフォームで主に構築されたコンプはCPUコアとRAMを必要とし、それらの重いノードに依存するコンプはGPUから恩恵を受けます。

Q: レンダーファームはNukeコンプをどのようにマシン間で分割しますか？ A: イメージリージョンではなく、フレーム範囲によって分割します。コンプの各フレームは独立しているため、レンダーマネージャーは合計フレーム範囲をチャンクに分割し、各チャンクをワーカーに渡します。ワーカーはそのスライスをヘッドレスでレンダリングします。スループットはジョブに投入するワーカーの数にほぼ線形に向上します。

Q: なぜNukeコンプがファームで間違った色でレンダリングされるのですか？ A: 最も一般的な原因はOCIOコンフィグのドリフトです——ファームがアーティストの使用したものと異なるOpenColorIOコンフィグを解決した場合、異なるファイルパス、環境変数、またはレンダーノードにデプロイされなかったカスタムコンフィグによるものです。プロジェクトを特定のコンフィグに固定し、レンダリング環境がまさにそのコンフィグを使用していることを確認してください。

Q: リモートでNukeスクリプトをレンダリングするために、どのファイルを送信する必要がありますか？ A: スクリプトと、それが参照するすべてのもの：フッテージと画像シーケンス、カスタムギズモまたはOFXプラグイン（またはGroupにベイク）、OCIOカラーコンフィグ、テキストノードで使用されるフォント、およびスタンドアロンのLUTファイル。レンダービルドもコンプ作成時のバージョンと一致している必要があります。

Q: NukeXは標準的なNukeコンプをレンダリングできますか？ A: はい。NukeXはベースNukeのスーパーセットです——ノードを追加するのみで、標準ノードを読み取る能力は削除されません——そのため、NukeXレンダーノードはベースNukeで作成されたスクリプトを問題なくレンダリングします。レンダーライセンスは、NukeXエディション以下で作成されたすべてのノードをレンダリングできます。唯一の制約は逆向きです：ベースNukeはNukeX専用ノードを評価できません。

Q: 当ファームでNukeコンプをレンダリングするにはいくらかかりますか？ A: コンプレンダリングは使用したCPUコンピューティングのGHz時間あたりで課金され、マシンのレンタル最低額はなく、有効期限のないレンダークレジットが使用されます。新規アカウントには$25クレジットが付与されており、短いテストシーケンスをエンドツーエンドでカバーするのに十分です。現在の料金とコスト計算ツールは料金ページにあります。