ProsGrow が FLUX.2 画像バリエーションを毎時 59,881 枚生成するまで

画像サービス全体が処理能力を決める

カタログ制作チームには、承認済みの画像バリエーションをワークフローへ届ける必要があります。サービスはプロンプトのエンコード、ノイズ除去、デコード、API 処理、PNG エンコード、出力保存を組み合わせています。モデルの実行が速くなると、提供速度を制限する段階も変わります。

ProsGrow は FLUX.2 Klein 4B でこの経路全体を測定しました。条件を揃えた単一 GPU の比較では、ネイティブ NVFP4 によりスループットが 32.5% 向上しました。次の課題は共有インフラでした。単一 GPU で最速だった設定は、ノード全体に展開すると遅くなりました。この逆転をプロファイリングし、実測で毎時 59,881 枚の画像バリエーションを提供するサービス構成に至りました。

条件を揃えた数値精度の比較

公式 NVFP4 チェックポイントは Black Forest Labs が提供し、ComfyUI がネイティブの量子化実行経路を提供します。ProsGrow は意図した数値精度の経路が有効であることを検証し、ワークフローを固定して PNG 保存まで測定しました。スループット向上とともに、リクエスト遅延は 24.5% 低下しました。

メモリ使用量の低下により処理を重ねる余地が生まれましたが、数値精度だけではノードを使い切れませんでした。最初の NVFP4 展開で観測した GPU 演算ユニットの稼働率は 52.5% にとどまりました。そこでスケジューリングと GPU 処理間のホスト側段階を詳しく調べました。

局所的な最適設定はノード全体では失速した

ComfyUI はワークフローのキューを逐次処理します。独立した常駐ワーカーを重ねて動かすことで、他のリクエストが API 通信、PNG エンコード、ファイル出力を処理している間も GPU の処理を続けられました。単独の GPU では、重複実行を増やすと使用率とスループットが向上しました。

ノード全体では同じ傾向になりませんでした。全 GPU が同じホスト資源を取り合うと、単独 GPU で最速の設定は毎時 46,759 枚にとどまりました。競合の少ないサービス構成は、保守的な再測定で毎時 57,540 枚を達成しました。低電力で横ばいになる区間はホスト、API、PNG、ファイルシステム段階の停滞と整合しましたが、トレースから単一の構成要素を唯一の原因とは特定できませんでした。

システム全体から得た中心的な教訓は、局所最適がノード全体の最適とは限らないことです。単独 GPU の高い使用率は、別の場所で競合を増やす場合があります。ProsGrow は同期したノード測定を基に、完了出力、メモリ使用量、実行間のばらつきを合わせてサービス構成を選びました。

明確に定義した制作ワークフローの処理能力

制作ワークフローでは、1 つの素材に複数の案を求めることがよくあります。この要件に向け、ProsGrow は各リクエストで 1 つのプロンプトから 2 バリエーションを生成する方式を評価しました。選定設定は、3 回の同期ノード実行の最小値で毎時 59,881 バリエーションを達成しました。従来の保守的なノード速度を4.07% 上回り、実行間の幅は 1.61%でした。

処理能力の単位は重要です。生成バリエーション数は異なるプロンプト数ではありません。クライアントは固定したプロンプトを再利用し、ノイズのシードを変え、ComfyUI のキャッシュも利用可能でした。多様な新規プロンプトの連続入力や、毎回の新規プロンプトエンコードは測定していません。

測定した 2,880 出力をすべて確認し、監視対象のエラーマーカーは検出されませんでした。各実行は約 57 秒でした。これは顧客パイロットの実測に基づく出発点であり、実際に使える能力は継続的な到着、キュー、顧客の受け入れ基準によって決まります。

処理能力がコストに意味すること

需要とサービス要件を明確にすれば、処理能力をコスト試算に使えます。既存の価格 $100,000 のノード、課金需要 10% のシナリオでは、実測速度は年間 52.46 百万件の販売バリエーションに相当します。年間インフラコストを約 $40,058 とするモデルでは、販売バリエーション 1 件当たり $0.000764です。

このシナリオでは、3 年償却、年 5% の保守費、年間 8,760 時間、電力単価 $0.10/kWh、電力使用倍率 1.30、サーバーの待機電力 1.016 kW、稼働電力 6 kW を仮定しています。人件費、事業運営、ネットワーク、ストレージ、サービス予備容量は含みません。購入判断に使う前に、需要と受け入れ可能な出力の割合を検証する必要があります。

選定設定では、ホストと冷却を除く画像 1 枚当たりの GPU ボード電力量 0.0571 Whも測定しました。どちらの数値も同じプロンプトを繰り返し、2 バリエーションを作る条件に結び付いています。ホスト型サービスとの品質やコストの同等性を示すものではありません。

本番環境の動作条件を選ぶ

バッチ制作では、1 時間当たりの受け入れ可能なバリエーション数が有用な目標です。対話型ツールには、低いリクエスト遅延と急増に備えた余裕も必要です。ワーカーの重複実行はメモリと共有ホスト能力を使うため、入力処理、保存、再試行、想定到着率のための余裕を残す構成にする必要があります。

この測定プロセスは数値精度の検証、サービスのプロファイリング、ノード全体での確認を結びます。次の顧客判断は具体的です。代表的なプロンプトの組み合わせで、必要な品質と納期を満たしながら能力向上を維持できるか。それがプライベートエンドポイントの規模設計の基礎になります。

測定方法と制約

• ハードウェアとソフトウェア：RTX PRO 6000 Blackwell GPU 8 基のノード 1 台、GPU 当たり公称 96 GB メモリ。ComfyUI 0.32.0、comfy-kitchen 0.2.30、PyTorch 2.11.0、CUDA 13.0。NVFP4 チェックポイントのリビジョンは 1db2b2f7 です。
• ワークロード：FLUX.2 Klein 4B、1024×1024 出力、Euler 4 ステップ、固定のスタジオ商品写真プロンプトです。精度比較ではリクエスト当たり 1 枚、選定したノード設定では 2 バリエーションを生成しました。同じプロンプトの反復とキャッシュ利用があるため、多様な顧客トラフィックへの推論には制限があります。
• 計時：モデルは計測前にロードし、ウォームアップ済みです。ComfyUI の比較は API キューとポーリングのオーバーヘッド、プロンプトエンコード、ノイズ除去、VAE デコード、PNG エンコード、保存を含み、各精度で 30 リクエストを測定しました。以前の Diffusers の結果は PNG エンコードを含まず、精度比較のベースラインではありません。
• ノード集計と反復：選定速度は、最初の測定クライアント開始から最後の完了までの共通区間で総出力数を割って算出します。各 960 出力の短時間実行 3 回の最小値で、単独 GPU 速度の 8 倍に対しスケーリング効率 92.49%です。以前のワーカー速度の合算値は、同条件のノードベースラインには使っていません。これらの測定は継続的な本番 SLA を確立するものではありません。
• 品質：選定出力 8 枚を目視確認しました。すべて整合性のある商品写真で、指定ラベルを判読できました。6 枚は正確で明瞭なラベル、1 枚は小さな追加文字、1 枚は余計な句読点がありました。この基本確認は、量子化の幅広い品質、プロンプト遵守、文字組み、モデレーション、顧客受容性を保証しません。

測定は 2026年8月12〜21日に実施しました。ホスト型 API の品質、運用信頼性、総コストの同等性は検証していません。

ComfyUI を使ったプライベート FLUX.2 画像生成

FLUX.2 Klein と ComfyUI によるプライベート画像生成を計画するチームにとって、このベンチマークは制作ワークフローのバリエーション数と納期に沿って能力を考える助けになります。1 時間あたりの画像バリエーション数とリクエスト遅延は、異なる計画上の問いに答えます。導入時は代表的なプロンプトで性能を確認し、品質要件を満たす出力を数える必要があります。