MiniMax H3を2Kにする方法｜ComfyUIコアの潜在アップスケールとSol-H3-VAEをRTX 5090で実測

Q: Sol-H3-VAE でエンコードできますか？

公式リポジトリの sol_h3_vae.safetensors はデコーダーだけなので、できません。エンコードには標準 VAE を使ってください。

この記事について（広告・アフィリエイトリンクはありません）

紹介しているソフトとモデルは、すべて無料で入手できるものです。記事内の画像と動画は AI で生成したものです。

2026年10月28日、ComfyUI 本体に MiniMax H3 向けの機能が2つ入りました。動画の下書きを潜在空間のまま拡大する「潜在アップスケール」と、デコードを速くする「Sol-H3-VAE」への対応です。

この記事では、768p で作った H3 の動画を 2K（2560×1440）に仕上げるワークフローを組みました。RTX 5090 で、どの段階に何秒かかるかを測っています。使ったのは ComfyUI 本体のノードだけで、カスタムノードは入れていません。

この記事でわかること

2K に仕上げるワークフローの組み方（配布 JSON あり）と、各段階の時間と VRAM（低解像度生成・拡大・再サンプリング・デコード）
2K を直接生成した場合、従来の「画像に戻して拡大」した場合との比較
標準 VAE と Sol-H3-VAE の速さと画質の違い、音声がどう扱われるか

先に注意（2026年11月2日時点）

この2つの機能は、リリース版の ComfyUI にはまだ入っていません。master（開発版）か nightly ビルドが必要です。
公式の 2K 用ローカルテンプレートは、現時点ではありません。この記事のワークフローは当サイトで組んだものです。
MiniMax H3 は EU・英国・韓国・米国がライセンスの対象地域外です。Sol-H3-VAE の重みも MiniMax H3 のライセンスに従います（末尾の検証メモを参照）。

先に結論（今回のテスト条件で）
試した環境
2つの新機能で何が変わる？
ComfyUI を master にする
ワークフローの組み方
実測結果
VRAM が少ない人へ
よくある質問（FAQ）
まとめ
検証メモ（ライセンスなど未確定の点）
参考リンク

先に結論（今回のテスト条件で）

経路（5秒・124フレーム）	時間
2K（2560×1440）を直接生成（Turbo 8ステップ）	1,138秒
768p で生成 → 潜在アップスケール → 3ステップ再サンプリング → Sol int8 でデコード	503秒

768p で作って 2K に仕上げると、直接生成より 約56%短く（約2.3倍速く）なりました。ただし同じシードでも、直接生成とは構図が違う絵になります。
潜在アップスケールの処理そのものは 1.5秒 です。画像に戻して拡大し、再エンコードする従来の方法より約60秒短くなります。
2K のデコードは、Sol-H3-VAE（int8）が 7.1秒、標準 VAE（int8）が18.5秒でした。約2.6倍速い代わりに、VRAM を多く使います。
2K 仕上げで一番時間がかかるのは 再サンプリング で、1ステップ約129秒でした。通しの約77%を占めます。
denoise 0.30・3ステップがおすすめです。0.44 にすると、絵の中身まで変わりました。
音声は拡大ではそのまま通ります。再サンプリングすると音も作り直されるので、元の音を残したいときは音声だけ1段目のものに戻します。

試した環境

項目	内容
GPU	RTX 5090（32GB）、ドライバー 621.01。計測前に他アプリが使っていた VRAM は約1.8GB
CPU / RAM	Ryzen 9 9950X3D / 128GB
OS	Windows 11
ComfyUI	ポータブル版＋master コミット `17ff1dcce963bd9f23095ec9b28febbfc4db8388`（2026-11-01 19:14 UTC、v0.43.0-26-g17ff1dcc）。フロントエンド 1.57.6
Python / PyTorch	3.13.14 / 2.14.0+cu130
カスタムノード	なし
生成条件	5秒（124フレーム・24fps）、同じプロンプト・シード（20261102）
モデル	fl2va pruned int8 / qwen3vl nvfp4 / 映像 VAE int8 / 音声 VAE fp32 / 公式 Turbo LoRA（fl2v 8step、強さ1.0）
1段目の設定	res_multistep・simple・8ステップ
測り方	ノードごとの実行時間。モデル読み込み後（2回目以降）の値で、初回の読み込み込みは別に記載。VRAM・RAM は1秒ごとに記録したピーク

VRAM の見方

ComfyUI は空いている VRAM にモデルをできるだけ載せます。そのため31GB 台のピークは「必要な量」ではなく「32GB をほぼ使い切った値」です。他アプリの約1.8GB も含みます。

2つの機能が入っていることは、git で確かめました。

PR	内容	マージコミット	マージ日時（UTC）
#17412	潜在アップスケール	`35060f0`	2026-10-28 20:05
#17411	Sol-H3-VAE 対応	`0df1646`	2026-10-28 23:46

2つの新機能で何が変わる？

潜在アップスケール（PR #17412）

H3 が作った動画の latent（潜在）を、画像に戻さずに拡大する機能です。latent は、画像を圧縮した中間データのことです。

ノード：MiniMax H3 Latent Upscale With Model（出力の既定は 2560×1440、32刻み）
読み込み：既存の Load Latent Upscale Model で読みます
重み：LBH-123-AI/Minimax_h3_latent_Upscaler の minimax_h3_latent_upscaler_3d_conv_v1_bf16.safetensors（690.6MB）。models\latent_upscale_models に置きます
音声：拡大しても音声の latent はそのまま通ります

前回の記事で紹介したサードパーティの Latent Upscaler と同じ重みを、ComfyUI 本体のノードで使えるようにしたものです。

アップスケーラーのモデルカードには、次のように書かれています（当サイトの実測ではありません）。

項目	モデルカードの記載
ライセンス	Apache-2.0（リポジトリに LICENSE ファイルはなし）
パラメーター数	345,280,216
サイズ	bf16・fp16 各約691MB、fp32 .pth 約1.38GB
学習データ	約8万ペア（動画約7万、2K 画像約8千）。出所の記載なし
倍率	1.0〜4.0倍

Sol-H3-VAE 対応（PR #17411）

Sol-H3-VAE は、H3 の標準デコーダー（36層）を、24層・16.2億パラメーターの非因果デコーダーに蒸留したものです（モデルカードの説明）。蒸留は、大きなモデルの動きを小さなモデルに覚えさせる方法です。新しいノードはなく、ふつうの Load VAE で読めます。

今回使ったファイルは3つです。どれも models\vae に置きます。

ファイル	入手元	サイズ
`minimax_h3_sol_vae_int8_convrot.safetensors`	Comfy-Org/MiniMax-H3 の vae/	1.99GB
`minimax_h3_sol_vae_fp16.safetensors`	同上	3.60GB
`sol_h3_vae.safetensors`（fp32、デコーダーのみ）	Efficient-Large-Model/Sol-H3-VAE	6.47GB

注意

sol_h3_vae.safetensors はデコーダーだけのファイルなので、エンコードには使えません（VAE Encode で AttributeError: ... no attribute 'quant_conv'）。I2V の入力画像などをエンコードするときは、標準 VAE を別に読み込んでください。Comfy-Org 版の Sol でエンコードできるかは試していません。

モデルカードと PR の値（当サイトの実測ではありません）

出典・条件	標準 VAE	Sol
モデルカード：768p・RTX 5090（eager）	12.5秒	5.0秒
モデルカード：720p・GB200（CUDA グラフ）	6.16秒	0.34秒
モデルカード：2K・GB200（CUDA グラフ）	14.5秒	0.89秒
PR #17411：1344×768×124 フレーム・RTX 5090	fp16 10.7秒 / int8 4.61秒	fp16 3.28秒 / int8 1.70秒

PSNR（元の画像にどれだけ近いかを表す数値。高いほど近い）は、検証用の latent で45.4dB、生成した 768p の動画で38.2dB とされています。2K の値は GB200 と CUDA グラフの条件なので、RTX 5090 の目安にはなりません。

ComfyUI を master にする

リリース版には入っていないので、master の ComfyUI を用意します。いま使っている環境を壊さないように、別のフォルダーに用意するのがおすすめです。当サイトでは、ポータブル版をもう1つ作り、ComfyUI 本体だけ master に入れ替えました。

git clone https://github.com/Comfy-Org/ComfyUI.git
cd ComfyUI
git checkout 17ff1dcc
git log --oneline -1

git checkout 17ff1dcc は、当サイトが測ったコミットに固定する手順です。当サイトでは、clone した時点の master の先端がこのコミットでした。最新の master で試すときは、この行を飛ばします。

master は毎日変わるので、動かなくなったときのためにコミットを控えておきます。モデルは extra_model_paths.yaml で既存のフォルダーを読ませると、二重に置く必要がありません。

あわせて読みたい

・ComfyUIをアップデートする方法

ワークフローの組み方

1段目：いつもの H3 T2V を 1344×768・Turbo 8ステップで作ります
拡大：Load Latent Upscale Model → MiniMax H3 Latent Upscale With Model（2560×1440）
2段目：拡大した latent を、同じモデル・同じシードで再サンプリングします。BasicScheduler を steps 3・denoise 0.30 にします。テキストは1段目のものをそのまま使います
デコード：Load VAE で Sol int8 を読み、VAE Decode → 動画として保存

minimax_h3_768p_to_2K_3step_d030_sol_int8.jsonComfyUI にドラッグして読み込みます（768p→2K、3ステップ・denoise 0.30、Sol int8）

コアのノードだけ（20個）で組んでいます。当サイトで読み込んで実行し、503.5秒で 2560×1440・124フレーム（音声つき）ができることを確かめました。シードは固定にしてあります。

実測結果

段階ごとの時間

条件	解像度	ステップ・denoise	時間	内訳	VRAM ピーク	所見
A 基準（1段目だけ）	1344×768	8・1.0	107秒	サンプラー99.5秒（12.4秒/ステップ）、標準 int8 デコード4.9秒	31.2GB	3回で106.6〜107.2秒
A 初回（読み込み込み）	1344×768	8・1.0	427秒	テキストエンコーダー99.5、サンプラー291、デコード25.9	31.7GB	モデルは HDD に置いている
拡大のみ	1344×768→2560×1440	–	1.5秒		6.1GB	読み込み込みで6.8〜9.3秒
通し（おすすめ）	1344×768→2560×1440	8 → 3・0.30	503秒	1段目98.8、拡大1.5、再サンプリング387、Sol int8 デコード7.2	31.2GB	2回。再サンプリングが約77%
通し（denoise 0.44）	同上	8 → 3・0.44	503秒	1段目99.3、拡大1.5、再サンプリング387、Sol int8 7.1	31.3GB
通し（標準 VAE でデコード）	同上	8 → 3・0.44	534秒	デコード37.5秒（VAE の載せ直しを含む）	31.3GB	1回
通し（起動直後の初回）	同上	8 → 3・0.44	580秒	テキストエンコーダー49、1段目102、拡大7.7、再サンプリング386、デコード20.7	31.6GB
E 2K を直接生成	2560×1440	8・1.0	1,138秒	サンプラー1,081秒（135秒/ステップ）、デコード41秒	31.5GB	1回。OOM にはならなかった

ComfyUI 自体の RAM 使用は、1344×768 で43GB、2K の通しで47〜50GB でした。PC 全体では最大94GB です。

2K は直接作るより2段で作るほうが速い

RTX 5090 では、2K を直接作ることもできました。ただし時間は1,138秒で、2段で作る503秒の2倍以上です。

同じシードでも、直接生成した 2K と 768p の絵は一致しません。今回は、直接生成のほうが鍋に大きく寄り、画面からはみ出しました。768p で中身を確かめてから仕上げられるのも、2段に分ける利点です。

左から、直接生成した 2K、2段で仕上げた 2K（3ステップ・denoise 0.30）、2段で仕上げた 2K（6ステップ・denoise 0.44）

再サンプリングは denoise 0.30・3ステップがおすすめ

denoise	ステップ	全体（1段目の latent から、標準 int8 デコード込み）	再サンプリング	所見
0.30	2	285秒	258秒	構図は1段目に近い。縁や持ち手の細部が増える
0.30	3	415秒	388秒	構図を保ったまま細部が増える（おすすめ）
0.30	4	542秒	515秒	麺の筋がやや太く、はっきりする
0.30	6	800秒	773秒
0.44	2	285秒	258秒
0.44	3	415秒	388秒	鍋に緑と黄色の具が現れ、麺の形も変わる
0.44	4	542秒	515秒
0.44	6	799秒	773秒

1段目（768p 生成約99秒）を含めた3ステップの通しは、503秒（Sol int8）、534秒（標準 int8、VAE の載せ直し込み）です。

どの条件も1ステップ約129秒で、時間はステップ数に比例しました。denoise を変えても時間は変わりません。
denoise 0.44 は、アップスケーラーの作者のワークフロー（2段目のシグマ 0.9035, 0.6316, 0.3158, 0）に近い値です（当サイトの換算）。作者のシグマをそのまま使っても414秒で、0.44 と同じように中身が変わりました。PR #17412 には推奨値の記載はありません。
2ステップでも細部は増えます。急ぐなら 2ステップ（通しで約366秒の見込み、段階の足し算）も選べます。

左から、1段目を画像で拡大、拡大のみ、再サンプリング後（3ステップ・denoise 0.44）の比較

解像度ごとの1ステップの時間

解像度	1ステップの時間
864×480	2.9秒
1344×768	12.4秒
1920×1088	44秒
2560×1440	129秒

目安として、画素数が約2倍で時間は約3〜4倍になりました（区間別：画素2.49倍→時間4.3倍、2.02倍→3.5倍、1.76倍→2.9倍）。解像度を上げるほど急に重くなります。理由は調べていません。

1080p 相当（864×480 → 1920×1088、3ステップ）も試しました。1080 は32の倍数ではないので 1088 にしています。

段階	解像度	ステップ・denoise	時間	VRAM ピーク
1段目	864×480	8・1.0	27秒	31.0GB
拡大	864×480→1920×1088	–	1.2秒	3.0GB
再サンプリング＋Sol int8	1920×1088	3・0.44	142秒（再サンプリング133、デコード4.1）	31.1GB

1080p 相当なら、通しで約170秒です。2K が重いと感じたら、1080p 相当で止めるのも手です。

拡大だけでは、形のある細部は増えない

再サンプリングをせずに拡大だけした動画は、輪郭が少し立っただけでした。

測る前は「拡大だけなら細部は増えない」と想定していました。ところが数値で見ると、細かい模様の量（ラプラシアン分散。2K にそろえて中央フレームで測定）は増えています。

経路	細かい模様の量
1段目を画像で拡大（lanczos）	18.1
拡大のみ（標準 int8 デコード）	51.3
拡大のみ（Sol int8 デコード）	44.0
従来経路（後述）	23.2
2K 直接生成	35.8
再サンプリング 0.30・3ステップ	63.4
再サンプリング 0.44・3ステップ	60.9

ただし4倍に拡大して見ると、拡大のみで増えた分は輪郭の乱れやオレンジ色のにじみでした。石畳の形は、画像で拡大したものより崩れています。「細かい模様は増えるが、形のある細部ではない」というのが正確なところです。2K らしい見た目にするには、再サンプリングが必要です。

従来経路（画像に戻して拡大）より約60秒短い

1段目の動画をいったんデコードし、画像として拡大（lanczos）してから、もう一度エンコードして再サンプリングする方法と比べました。再サンプリングの設定は同じ（3ステップ・0.44）です。

経路	拡大部分の時間	全体（1段目の latent から）	ComfyUI の RAM	見た目
潜在アップスケール	1.5秒	約415秒	48GB	くっきり
従来経路	63〜67秒（デコード5〜6＋拡大8〜10＋エンコード48〜53）	476〜483秒	56GB	麺の筋が柔らかい

差は拡大部分の約60秒です。RAM も8GB 少なく済み、見た目も潜在アップスケールのほうがくっきりしていました（中央フレーム1枚の目視）。

デコード単体の速さ（同じ latent、VAE を交互に3回ずつ）

解像度	VAE	時間	1回目（読み込み込み）	VRAM ピーク	開始からの増加
2560×1440	標準 int8	18.5秒	18.2秒	12.4GB	約5GB
2560×1440	標準 fp16	42.8秒	80.6秒	12.1GB	約7.2GB
2560×1440	Sol fp32	14.0秒	48.8秒	23.3GB	約16GB
2560×1440	Sol fp16	13.8秒	26.6秒	21.7GB	約13GB
2560×1440	Sol int8	7.1秒	7.1秒	16.2GB	約10.5GB
1344×768	標準 int8	5.3〜5.5秒	–	10.7GB	約3.5GB
1344×768	標準 fp16	12.0秒	–	10.6GB	約5.8GB
1344×768	Sol fp32	4.0〜4.4秒	–	16.0GB	約8.9GB
1344×768	Sol fp16	3.8秒	–	19.4GB	約6GB
1344×768	Sol int8	2.0〜2.1秒	–	9.9GB	約4.2GB

時間は2回目以降の値で、1回目（読み込み込み）は各 VAE の最初のデコードです（2K は3回、768p は2回）。開始からの増加は、デコードを始めたときから増えた VRAM の量です。VRAM ピークには、前の処理の残りも含みます。

2K では、Sol int8 が標準 int8 の約2.6倍速くなりました。開始からの増加は約2倍です（標準 int8 約5GB、Sol int8 約10.5GB）。
Sol の fp32 と fp16 は、時間も画質（後述）もほぼ同じでした。ファイルの大きい fp32 を選ぶ利点は、測った範囲ではありません。
768p の結果は、PR #17411 の表（標準 int8 4.61秒、Sol int8 1.70秒）より少し遅くなりました。環境の違いの内訳は調べていません。
通しの中で見ると、2K のデコード差は約11秒で、全体の2%ほどです。Sol で一番大きく縮むのは、再サンプリングのない「拡大のみ」や、デコードを何度もやり直すときです。

画質：標準 VAE と Sol

同じ latent を標準 VAE（int8）でデコードした結果を基準に、PSNR を測りました。124フレーム全体の値です。

素材	標準 fp16	Sol fp32 / fp16	Sol int8	Sol の最低フレーム
ラーメン屋台 2K	57.4dB	37.7dB	37.7dB	35.0dB
顔のアップ 2K	59.3dB	43.3dB	43.3dB	39.2dB
顔のアップ 768p	59.2dB	42.6dB	42.6dB	39.9dB

Sol は、fp32・fp16・int8 でほぼ同じ値でした（int8 との差は0.03dB）。
差が大きく出たのは絵柄のほうです。雨粒や石畳が多いラーメン屋台は、顔より約5〜6dB 低くなりました。
モデルカードの値（38.2〜45.4dB）と近い範囲です。

128px の継ぎ目

Sol を使うと、肌などの平らな面に 128px ごとの薄い継ぎ目が出るという報告があります（ComfyUI issue #17429）。隣り合う画素の差を、128px の境界とそれ以外で比べました。1.0 なら境界に段差がありません。

素材	標準 int8（横 / 縦）	Sol（横 / 縦）
ラーメン屋台 2K	1.14 / 1.07	1.29 / 1.23
顔のアップ 2K	1.15 / 1.27	1.23 / 1.58
顔のアップ 768p	1.14 / 1.19	1.27 / 1.53

Sol は境界の段差が数値の上で増え、特に縦方向で大きくなりました。報告と同じ傾向です。標準 VAE との差を8倍に強調すると、格子が見えます。

ただし、頬の中央フレームを2倍に拡大して見た範囲では、線は目で見て分かりませんでした。今回の肌は2段目で毛穴の質感が出ていて、報告のような平らな肌とは条件が違います。動画を再生したときの見え方と、ほかのフレームは確かめていません。気になる場合は、最後のデコードだけ標準 VAE に戻してください。標準 VAE では境界の段差が小さくなりました（2K で約11秒遅くなります）。

頬の拡大（左が標準 VAE、中央が Sol int8）と、標準 VAE との差を8倍にした画像（右）

音声は拡大では変わらず、再サンプリングで作り直される

確認したこと	結果
拡大の前後の音声 latent	完全に一致
拡大だけしてデコードした音	1段目と同じ（データが一致）
再サンプリング後	音声 latent も変わる（音が作り直される）
音声だけ1段目に戻す	1段目と同じ音になる
Sol 経路	音声も出る（AAC、5.17秒）

H3 の latent は、映像と音声がセットです。潜在アップスケールは映像だけを拡大し、音声はそのまま通します。

ただし2段目の再サンプリングでは、音声も一緒に作り直されます。1段目の音を残したいときは、2段目のあとで映像と音声の latent を分け、音声だけ1段目のものに入れ替えてからデコードしてください（ComfyUI の分離・結合ノードを使用）。音声は別の VAE を通るので、Sol の影響は受けません。

1段目と2段目のどちらの音が良いかは、耳では確かめていません。

VRAM が少ない人へ

今回の測定は RTX 5090（32GB）だけです。2K の再サンプリング中は31.7GB まで使っていますが、これは空いている VRAM に載せられるだけ載せた値です。24GB 以下で動くかは確かめていません。

Sol-H3-VAE は画像を分けてデコードする（タイル分割）ことができず、解像度と長さに比例してメモリが増えます（PR #17411 の説明）。2K のデコードでは、開始からの増加で比べると、標準 int8 より5.5GB ほど多く使いました（Sol int8 約10.5GB − 標準 int8 約5GB）。VRAM が厳しいときは、まず 1080p 相当（1920×1088）で試すのがおすすめです。

あわせて読みたい

・ComfyUIのVRAM不足を解決する方法

よくある質問（FAQ）

Q. ComfyUI のリリース版で使えますか？

2026年11月2日時点では使えません。master か nightly ビルドが必要です。

Q. MiniMax H3 で 2K の動画は作れますか？

RTX 5090 では作れました。2K を直接生成すると1,138秒、768p で作ってから潜在アップスケールで仕上げると503秒でした（5秒の動画）。公式の 2K 用ローカルテンプレートはまだありません。

Q. Sol-H3-VAE を使うと全体はどれだけ速くなりますか？

2K のデコードは18.5秒から7.1秒になりました。ただし通し全体（約500秒）から見ると、約11秒の短縮です。全体を速くしているのは、潜在アップスケールで小さい解像度から仕上げられることのほうです。

Q. 再サンプリングは何ステップがいいですか？

当サイトでは、denoise 0.30・3ステップをおすすめにしました。2ステップでも細部は増えます。1ステップ約129秒なので、時間と相談して決めてください。

Q. 音声は壊れませんか？

拡大ではそのまま通ります。再サンプリングで音も作り直されるので、元の音を使いたいときは、音声の latent だけ1段目のものに戻します。

Q. Sol-H3-VAE でエンコードできますか？

公式リポジトリの sol_h3_vae.safetensors はデコーダーだけなので、できません。エンコードには標準 VAE を使ってください。

まとめ

768p で作って 2K に仕上げる方法は、5秒の動画で503秒でした。2K を直接作る1,138秒の半分以下です。時間の大半は 2K での再サンプリング（1ステップ約129秒）で、潜在アップスケール（1.5秒）と Sol-H3-VAE（デコード7.1秒）は、どちらも短い時間で済みます。
おすすめの設定は、1344×768・Turbo 8ステップ → 2560×1440 に拡大 → 3ステップ・denoise 0.30 → Sol int8 でデコードです。
音声は拡大では変わりませんが、再サンプリングで作り直されます。

H3 の導入や基本の使い方は、こちらの記事にまとめています。

この記事の検証環境

RTX 5090（32GB）/ Ryzen 9 9950X3D / 128GB / Windows 11 / ComfyUI master 17ff1dcc（カスタムノードなし）/ 2026年11月2日
これまでの検証の一覧はこちら

検証メモ（ライセンスなど未確定の点）

Sol-H3-VAE のライセンス：リポジトリに LICENSE ファイルはありません（2026年11月2日確認）。README の License 節の原文は次のとおりです。”The code is released under Apache-2.0. The weights are distilled from the MiniMax-H3 VAE and are subject to the MiniMax-H3 license.”
MiniMax H3 のライセンスとの関係：MiniMax H3 Community License では、蒸留で作ったモデルも「Model Derivatives」に含まれます。対象地域外（EU・英国・韓国・米国）での利用の制限、年商2,000万ドルを超える場合の別途許可などが、Sol の重みにもかかると読めます。当サイトでは法的な判断はしていません。使う前にライセンス原文を確認してください。
Comfy-Org 版の Sol（int8 / fp16）：Comfy-Org/MiniMax-H3 リポジトリで配布されています。リポジトリのカードには MiniMax H3 のライセンスが示されていますが、ファイルごとの表記はありません。
アップスケーラーのライセンス：モデルカードに Apache-2.0 と書かれていますが、リポジトリに LICENSE ファイルはありません。学習データの出所も書かれていません。
デコードの1回目：2K の標準 int8 と Sol int8 だけ、1回目と2回目以降がほぼ同じでした（18.2秒と18.5秒、7.1秒と7.1秒）。この2つはデコード単体の前の通しの測定で使っていて、ほかの3つはこの測定で初めて読みました。ファイルが OS のキャッシュに残っていた可能性がありますが、キャッシュの状態は記録していないので、理由は未確認です。
測定の順序：2K の再サンプリングが1ステップ129秒と重かったので、途中で測定の順序を入れ替えました。そのとき、始まった直後の1条件を2度中断して破棄し、後でやり直しています（中断した分は数値に含みません）。
測定中の CPU 作業：2K 直接生成（1,138秒）と denoise 0.30・3ステップの1回目の測定中は、画面の読み込みと解析を CPU で並行した時間があります。
Sol の CPU デコード：CPU でのテストは9分で終わらず、ほかの計測への影響を避けるために中断しました。GPU では成功しています。
未確認のこと：音の聞き比べ、動画を再生したときのちらつき、24GB 以下の GPU での動作、128px の継ぎ目の他のフレームでの見え方。