画像・動画モデル向けのカード選び。

各モデルが必要とするもの

まず、他のすべてを決定づける違いから見ていきましょう。言語モデルは、コンテキストのトークンが増えるたびに大きくなるkey/valueキャッシュを抱えており、これが同じ70Bモデルでも、保持する会話の量次第で40 GBにも140 GBにもなり得る理由です。一方、拡散モデルにはキャッシュが一切ありません。プロンプトを読み込み、決まったステップ数だけ潜在表現をデノイズし、そして忘れます。したがって重みがほぼメモリ問題のすべてであり、プロンプトが長くなっても答えは変わりません。

重みに、アクティベーション、CUDAコンテキスト、アロケーターの断片化のための実行時マージン15%を加えたものです—これはコンフィギュレーターが適用しているのと同じマージンなので、そちらと突き合わせて確認できます。コンテキストの列がないのは、そこに入れるものが何もないからです。

あの表の中で立ち止まる価値があるのは2行だけです。まさにそこで購入の判断を誤るからです。

各カードが収められるもの

私たちが貸し出すすべての単体カードマシンと、2つの負荷の高いモデルそれぞれについて各マシンが対応できる最良の精度です。帯域幅の列は次の章のためのものなので、その章を読んでから確認してください。

緑は基準となる重み、琥珀色は量子化されたものです。拡散モデルの量子化は、言語モデルの場合のようなただ乗りではありません。同じプロンプトとシードでも、目に見えて異なる画像になり、たいていは少し柔らかい仕上がりになります。FP8であれば十分に見合う取引ですが、4 ビットでは判断が分かれるところです。

価格列の下から読んでいくと、答えは単刀直入です。NVIDIA L4は月額$125で、FLUX.1 devを収められる最安のマシンです—ただしFP8でのことです。フルBF16で収められる最安はNVIDIA RTX A6000で、$286です。 動画はフル精度で同じそのカードでそのまま始められる。

誰もが読み違える列

ここが、画像処理をこのサイトの他のすべてから分ける部分であり、あの表の中で最も安いカードが罠になっている理由です。

言語モデルが1つのトークンを生成するとき、活性化されているすべての重みをメモリから一度読み出し、それぞれについてわずかな演算を行い、1つのトークンを書き出します。次のトークンでも、その次でも、これを繰り返します。カードはその人生の大半をメモリバス待ちに費やしており、だからこそ私たちの言語モデル向けスループット推定は本質的に帯域幅を重みの読み出し量で割ったものになり、推論のガイドで帯域幅の列が重要になるのです。

拡散モデルのステップはそのようにはなりません。同じ重みが潜在テンソルに20〜50回にわたって適用され、各パスはフェッチされたバイトあたり大量の演算を行います。重みはずっと常駐したままで、実際の処理は小さなテンソルに対する畳み込みとアテンションです。これによって制約が逆転します。画像モデルの律速はメモリバスではなく、テンソルのスループットです。ここから三つの帰結が導かれ、判断を誤ればそのすべてがコストにつながります。

ドル当たりの帯域幅は—大まかなものですが—検討しているカードの階級を示す代理指標であり、私たちのカタログではNVIDIA RTX 5090とNVIDIA RTX 4090が大差で1位と2位を占めています。これは偶然でも、お得だからと勧めているわけではありません。これらはまさにこの種の計算のために設計されたパーツであり、市場がトレーニングクラスタではなくゲーミング向けに価格を付けているために、価格表では下位に位置しているだけです。

解像度、バッチ、動画

重みは固定です。動くのはワーキングセットであり、それはパラメータではなくピクセル数に応じて動きます。潜在表現そのものは無視できるほど小さく—カードを埋めているのは、その解像度でネットワークを通過するアクティベーションです。

latent_elements = (H / 8) * (W / 8) * C * batch
# C = 4 latent channels on SDXL, 16 on SD 3.5 and FLUX.

# 1024x1024, batch 1, SDXL:
128 * 128 * 4 * 1     = 65,536 elements   = 128 KB in FP16

# 2048x2048, batch 4, SDXL:
256 * 256 * 4 * 4     = 1,048,576         = 2 MB in FP16

# The latent is never the problem. The activations that pass through the
# network at that resolution are, and they scale by the SAME factor:
# doubling the edge quadruples the pixel count, and roughly quadruples
# the working set. Batch multiplies it linearly on top.

実際に出会う順番で並べた、三つの実践的な帰結です。

1. ピーク時のメモリ使用量は、サンプリングループではなく、たいていVAEデコードで発生します。デコードは潜在表現を一度のパスでフル解像度に展開します。それまで1分近く問題なく進んでいたジョブの最後の最後で、まさにこの瞬間にメモリ不足エラーが起きるのです。タイル分割デコードならこれを解消できますが、多少の時間がかかります。
2. 大きなカードを活かす方法がバッチ処理です。モデルが20 GBの余裕を残すなら、その余裕を使って一度に4枚の画像を生成する方が、1枚の画像に余白を残すよりもはるかに有効です—重みはバッチ全体に対して一度だけ読み込まれるため、これは拡散パイプラインが帯域幅律速のジョブのように振る舞う唯一の場面です。
3. 動画が加えるのは割合ではなく、次元そのものです。Wan 2.1 video 14Bはフレームのまとまりを一括で生成するため、高さと幅がすでに乗算しているワーキングセットに、フレーム数がさらに乗算されます。140億パラメータの動画モデルが120億パラメータの画像モデルよりもはるかに大きなカードを必要とする理由であり、上の重みの表がどの行よりもこれを過小評価している理由でもあります。

ComfyUIを立ち上げる

ComfyUIは、マシンが納品される前に書き込んでおけるイメージの一つであり、そのためこのセクションは読み飛ばしても構いません。ご自身で構築したい場合は、コンテナとトンネルだけの話です。

$ ssh root@203.0.113.42
$ nvidia-smi --query-gpu=name,memory.total --format=csv

# Checkpoints, LoRAs, ControlNets and VAEs on the fast local NVMe.
# This directory is the reason you are renting by the month.
$ mkdir -p /scratch/comfy/models
$ df -h /scratch

$ docker run -d --name comfy --restart unless-stopped \
    --gpus all --ipc=host \
    -v /scratch/comfy:/data \
    -p 127.0.0.1:8188:8188 \
    your-comfyui-image --listen 0.0.0.0 --port 8188

# From YOUR machine, not the server: a tunnel, then a local browser tab.
$ ssh -N -L 8188:127.0.0.1:8188 root@203.0.113.42
# http://127.0.0.1:8188

1か月で得られるもの

画像処理が月極めのマシンに向いている理由は、GPUの価格ではありません。ライブラリです。本格的なComfyUIの構成は、自分で厳選したチェックポイント、LoRA、ControlNet、アップスケーラー、VAEなど数百ギガバイトにおよび、二度と取り直したくないものです。

比較すべきはその列であり、時間課金のプラットフォームがヘッドラインの価格から外している部分でもあります。そこではディスクが別の明細項目として、1ギガバイトあたり月額いくらという形で課金され、インスタンスを停止していても課金され続けます—あるいはディスクを削除すれば、次に作業を再開するときに数百ギガバイトを再ダウンロードすることになります。

これは、時間課金の損益分岐点が説明しているのと同じ罠が、画像処理の形を取ったものです。秒単位の課金は、インスタンスを止められるという点で安全に見えますが、誰も止めません。止めることはライブラリを失うことを意味するからです。正直な問いは「何時間生成するか」ではなく「このマシンは何時間存在し続ける必要があるか」であり—厳選したモデルディレクトリを抱えている人にとって、答えは「すべての時間」です。支払いは暗号資産での送金一回だけで、初期費用はなく、お客様が誰かを一切お尋ねしません。プロンプトも、学習させたLoRAも、まだ納品していないクライアントの作業も、rootアクセスを持つのはお客様だけのマシンにとどまります。

カードを借りるべきでないとき

後悔しながらこれらのどれかを借りるくらいなら、私たちはそうしてほしくありません。そこで、答えが「ノー」になるケースを挙げます。

それ以外の場合—自分で築いてきたライブラリ、変更し続けているパイプライン、一晩かけて回すバッチジョブ、あるいは単に自分のディスクから出したくない作業—であれば、月極めの専有カードの方が安く、落ち着いて使えます。コンフィギュレーターは、カタログ内のすべてのノードについて、支払いの前に、想定しているモデルが1枚のカードに収まるかどうかを教えてくれます。