画像・動画生成でシステムRAMは何GB要るか｜RTX 5080・VRAM 16GBで回したときのRAMピークをワークフロー別に実測

16GBのカードで画像・動画を回すと、RAMはどこまで要ったか

RTX 5080 16GB を1枚挿した機体（システムRAM 96GB、使用可能 95.78 GiB）で ComfyUI 0.31.1 のワークフローを回し、2026年9月11日に RAM のピークを採った。画像を1枚生成する Krea 2 のワークフローは観測RSSピークが 20.5 GiB と 20.98 GiB、864×480・56フレームの動画を作る MiniMax H3 は 44.04 GiB から 44.73 GiB。同じ GPU・同じ ComfyUI で回していても、ワークフローが変わると観測RSSピークは倍以上動いた。

測定全体で観測RSSピークが最大だったのは、入力 1344×768・192フレームのアップスケールで 69.17 GiB。同じ入力解像度でフレーム数だけを変えたスイープでは、16フレームの回が観測RSS 6.21 GiB だった。ただしアップスケールが常に生成より重いわけではなく、MiniMax H3 が作った 864×480・56フレームの動画をそのままアップスケールした回は観測RSS 9.6 GiB で、その動画を生成したときの 44.04 GiB を下回っている。一方で同じアップスケールのなかでは、入力解像度 1344×768 のままフレーム数を16から192へ振るだけで観測RSSピークが11倍動いた。どちらの軸でも数値は動いているが、画像と動画のようにモデルもワークフローも違う組み合わせでは、差がどの要素から来ているかは分けて測っていない。

この1台で見るかぎり、ComfyUI 0.31.1 で観測RSSピークを動かしていたのは「何を作るか」と「何フレーム分か」だった。動画生成は 0.37.1 で測り直すと 13.2〜18.0 GiB まで下がったが、画像生成は 0.37.1 で測っていないので、画像と動画の差が 0.37.1 でも同じ向きで残るかは分からない。GPU を変えたときにどう動くかは測っていない。アップスケールの確保量ピークはフレーム数に沿って直線に乗ったが、フレーム数に依存しない切片があるため、尺を半分にしても確保量が半分になるわけではない。観測RSSピークのほうは、フレーム数に依存しない分がいくらあるかを測った5点からは読めない。

容量ごとにどこまで回るかは「手持ちのRAMで何ができるか」に、メモリが足りない状況で手がかりになる話は「よくある質問」にまとめている。

RAMの数字は3種類ある — 観測RSS・1本目・確保量

表を読む前に指標を分けておく。当サイトの計測ハーネスが同じ測定から採っている RAM の数字は3種類あり、取り方は実測データベースの行ごとに併記している。

• 観測RSSピーク: ComfyUI のプロセス木のワーキングセット（RSS）を0.25秒間隔で観測した最大値。システム全体ではなくプロセス木の値で、回をまたいだ最大を採る。
• 1本目だけの値: プロセスを立ててから最初の1回のみを見た値。本記事の表には出しておらず、実測データベースに行ごとの記録がある。
• 確保量ピーク: Windows の private bytes の最大。物理RAMに載っていない分も含む。

観測RSSピークが数えているワーキングセットは、Microsoft のドキュメントの定義では、そのプロセスの仮想アドレス空間のうち物理RAMに載っているページの集合になる。ただしプロセス専用のページだけでなく共有ページも含むため、複数プロセスぶんを足し上げると同じページを重複して数える可能性がある。逆に、OS のサービスやドライバが使う分は入らない。メモリの空きが減ると OS がワーキングセットからページを切り詰めるため、同じ処理でも空き具合によって数値が増減する。観測は0.25秒間隔で、その合間に立って消えた短いスパイクは取り逃す。物理RAMに載っている量の観測値であって、必要な搭載量を示す値ではない。

3つは同じ回の測定から出ていても別物で、どれを見るかで見積もりが変わる。確保量ピークと観測RSSピークの差は、1344×768 のアップスケール5条件のうち4条件で 7.69 GiB から 8.61 GiB、192フレームの回だけ 14.07 GiB、入力解像度が違う 864×480・56フレームの回で 6.78 GiB、画像生成と動画生成のワークフローでは 15.28 GiB から 15.77 GiB だった。これらの範囲は互いに重ならず、差の大きさは測定によって一定ではない。そうなる理由は測っていないので、確保量から一定量を引いて観測RSSを出すことはできない。以降の表では観測RSSピークと確保量ピークを並べて出す。

ワークフロー別のRAMピーク

動画生成 FP8・4ステップの回では GPU のピークが 15,393 MiB で、16GB の枠に収まったままだった。同じ回の RAM は 44.04 GiB まで伸びている。nvidia-smi の memory.used のピークなので、デスクトップ表示など他の利用も含む値になる。0.31.1 の測定で VRAM を記録できたのはこの条件だけで、画像生成とアップスケールの回では記録していない。

測定環境は RTX 5080 16GB 単体 / システムRAM 96GB（使用可能 95.78 GiB）/ i7-14700F / ComfyUI 0.31.1、観測RSSピークは ComfyUI プロセス木の RSS を0.25秒間隔で採った最大、確保量ピークは Windows の private bytes の最大、測定日は 2026年9月11日。RAM は回をまたいだ最大、所要は中央値で、この2つは統計の取り方が違う。画像生成 Krea 2 は RAM が6回の最大・所要が12回の中央値、動画生成 MiniMax H3 は RAM が2回の最大・所要が3回の中央値で、FP8・8ステップの条件だけ2セッション分の中央値になる。OS やほかのアプリが使う分は含まない（ComfyUI のプロセス木だけの値）。画像と動画ではモデルもワークフローも違うため、RAM の差がどの要素から来ているかは分けて測っていない。

動画生成のワークフローの導入手順とモデル構成はMiniMax H3をVRAM 16GBで動かす記事に、画像生成のほうはKrea 2 Turboの4ステップ蒸留LoRAの実測にまとめてある。

アップスケールのRAMピークは同じ入力解像度ではフレーム数で動いた｜確保量は直線に乗る

測定環境は RTX 5080 16GB 単体 / システムRAM 96GB（使用可能 95.78 GiB）/ ComfyUI 0.31.1、アップスケールモデルは 4x-UltraSharp（4倍）、素材は MiniMax H3 で作った動画、測定日は 2026年9月11日。RAM は2回の最大、所要は2回の中央値で、192フレームだけ1回。この回では GPU のピークを記録していない。フレーム数のスイープは 1344×768 の1解像度だけで、864×480 は1点のみ。アップスケールモデルを変えた場合は測っていない。192フレームはほかの条件より回数が少ないため、回ごとのばらつきの幅も見ていない。

確保量ピークは、1344×768 の5点（16・32・64・128・192フレーム）に最小二乗で直線を当てると、1フレームあたり 0.3914 GiB・切片 8.05 GiB に乗る。5点の残差は最大 0.30 GiB なので、この解像度とこのアップスケールモデルの範囲なら、フレーム数から確保量をおおよそ見積もれる。他の解像度・他のアップスケールモデルには当てていない。

観測RSSピークもフレーム数とともに増えるが、同じ5点に当てた直線（傾きは1フレームあたり 0.3627 GiB）の残差が最大 2.11 GiB あり、切片 1.06 GiB より大きい。フレーム数に依存しない分がいくらあるかは、この5点からは読めない。

いちばん重い 192フレームの回は確保量 83.24 GiB、観測RSS 69.17 GiB だった。確保量は物理RAMに載っていない分も含むので、この機体で使用可能な 95.78 GiB と比率で並べられる量ではない。確保量より物理RAMとの比較に近いのは観測RSSピークのほうだが、これも必要な搭載量そのものを示す値ではない。OS やほかのアプリが使う分は入らず、共有ページを含む取り方や0.25秒間隔という観測の制約もある。

864×480・56フレームのアップスケールは観測RSS 9.6 GiB・確保量 16.38 GiB で、フレーム数は 1344×768 の32フレームと64フレームのあいだにありながら、観測RSSは 32フレームの 11.75 GiB より小さい。ただし 864×480 はこの1点しか測っていないので、解像度と観測RSSピークの関係が比例するかは言えない。

RAM が伸びた分は何に使われているのか

RAM が増える経路は1つではない。少なくとも次の要素が混ざっている。

• アップスケールでは、1344×768 のままフレーム数を増やすと RAM が増えた。出力フレームや途中の計算結果の保持などが候補になるが、本測定では内訳を分離していない。
• ComfyUI は既定で、GPU との転送に使うメモリ領域をページアウトされない状態（ピン留め）で確保する。起動オプション --disable-pinned-memory を付けるとこの使用を止められ、引数の既定は「無効にしない」、つまりピン留めを使う設定になっている。公式ドキュメントの起動オプション一覧と実装の引数定義から読めるのはフラグの存在と既定値までで、確保の仕方（起動時に一定量を予約するのか、必要に応じて積み増すのか）は本記事では確かめていない。
• プロンプトの与え方でも動く。当サイトの別記事では、毎回プロンプトを変える条件と同じプロンプトを繰り返す条件とで、プロセスが使う RAM に 24.1GB の差が出ている。この差について同じ記事は「テキストエンコーダの載せ替えが加わるかどうかの差であって、載せ替えが起きるか起きないかの差ではない。」と書いている。載せ替えそのものは同じプロンプトを繰り返す条件でも起きていて、毎回変える条件ではそこに別の載せ替えが上乗せされる、という記述になる。1216×672・97フレームの条件での記述で、本記事では測り直していない。

この測定の詳細はLTX 2.5 を 16GB VRAM で回す記事にある。アップスケールの経路については、ESRGAN 系のアップスケールを ComfyUI の外で直接動かす構成に変えると、8秒・4K・60fps の動画で 67〜77GB 使っていた RAM が 1.4GB まで下がったという測定がComfyUIのアップスケールはRAMを67GB食う記事にある。条件は本記事のスイープとは別（8秒・4K・60fps）で、本記事では測り直していない。

手持ちのRAMで何ができるか

観測RSSピークから言えるのは、次の程度になる。値は記載のない限り ComfyUI 0.31.1 で測ったもので、動画生成だけ 0.37.1 の測り直しを併記した。いずれも ComfyUI のプロセス木だけの値で、OS やほかのアプリが使う分を足す前になる。32GB や 64GB を積んだ機体で実際に完走するかは試していない。

• 32GB: ComfyUI 0.31.1 では、画像1枚の生成が 20.5 GiB と 20.98 GiB で観測RSSピークは 32GB を下回り、動画生成とフレーム数の多いアップスケールは 32GB を超えた。動画生成は ComfyUI 0.37.1 で測り直すと 13.2〜18.0 GiB で、32GB を下回った。画像生成とアップスケールは 0.37.1 では測っていない。
• 64GB: ComfyUI 0.31.1 で、864×480・56フレームの動画生成が 44.04 GiB から 44.73 GiB、1344×768・128フレームのアップスケールが 49.6 GiB で、観測RSSピークはどちらも 64GB を下回った。
• 96GB: 1344×768・192フレームのアップスケールが観測RSS 69.17 GiB、確保量 83.24 GiB。確保量は物理RAMに載っていない分も含むので、この機体で使用可能な 95.78 GiB と比率で並べられる量ではなく、確保量が搭載量に近い値になっていること自体は物理RAMを使い切ったことを意味しない。確保量より物理RAMとの比較に近いのは観測RSSピークのほうだが、これも必要な搭載量そのものを示す値ではない。

RAM が不足したときに何が起きるか（速度が落ちるのか、失敗するのか）の境界は本記事では測っていない。ここで言えるのは観測RSSピークがその容量を下回ったか上回ったかまでで、その容量を積んだ機体で完走することを確かめたわけではない。メモリの規格や価格の選び分けはAI用途別 必要メモリ容量ガイドに、ComfyUI を回すうえでの VRAM を含む要件はComfyUI推奨スペック実測ガイドにまとめてある。

LLM推論ではRAMの要り方が違う

LLM 推論では、重みが VRAM に収まっているあいだシステムRAMは補助にとどまり、VRAM に載せきれない分が本体のメモリに残ったときに、RAM の容量と帯域、CPU の処理、GPU との転送が所要に関わってくる。ただし読み込みの段階は別で、VRAM に収まる構成でも RAM のピークが出る経路がある。VRAM に余裕があっても RAM が枯渇して落ちる経路はllama.cppのGemma 4でRAMが枯渇する原因で扱った。本記事の実測は ComfyUI のワークフローだけで、LLM の RAM ピークは測っていない。

この記事の測り方と、測っていないこと

本記事の実測値は、追記の測り直し（2026年9月25日・ComfyUI 0.37.1）を除き、2026年9月11日・RTX 5080 16GB 単体／システムRAM 96GB の構成での測定に基づく。CPU は i7-14700F、ComfyUI のバージョンは 0.31.1、システムRAM の使用可能量は 95.78 GiB。RAM の値は回をまたいだ最大、所要は中央値で、この2つは統計の取り方が違う。回数は条件によって異なり、画像生成 Krea 2 が RAM は6回の最大・所要は12回の中央値、動画生成 MiniMax H3 が RAM は2回の最大・所要は3回の中央値（FP8・8ステップの条件だけ2セッション分の中央値）、アップスケールが RAM は2回の最大・所要は2回の中央値で、192フレームだけ1回。観測RSSピークは ComfyUI のプロセス木のワーキングセット（RSS）を0.25秒間隔で観測した最大、確保量ピークは Windows の private bytes の最大で、どちらも OS やほかのアプリが使う分を含まない。条件ごとの記録は実測データベースに、機体の詳細は検証環境にある。

測っていないのは次の条件になる。

• RAM が不足した状態そのもの。搭載を超える条件を意図的に作っていないため、どこで速度が落ちてどこで失敗するかは扱っていない。2026年9月14日に測定記録を確認した範囲では、この機体でRAM不足に至った回の記録は見つけられなかった。
• 1344×768・192フレームのアップスケールの回ごとのばらつき。この条件だけ1回で、ほかの条件より回数が少ない。
• 画像生成とアップスケールの回の VRAM ピーク。0.31.1 で記録したのは動画生成 FP8・4ステップの1条件のみで、0.37.1 の測り直しも動画生成だけ。
• 解像度を変えたときの増え方。1344×768 のスイープと 864×480 の1点しかなく、比例するかは言えない。
• アップスケールモデルを変えた場合。4x-UltraSharp の4倍でしか測っていない。
• 他の機体・他の GPU。1台1構成での測定にとどまる。
• ComfyUI 0.37.1 での画像生成とアップスケール。0.37.1 で測り直したのは動画生成の4条件だけ。
• LLM 推論の RAM ピーク。本記事の測定は ComfyUI のワークフローに限る。

よくある質問

VRAM 16GB のカードなら、システムRAMは32GBで足りるのか

作るものと、使っている ComfyUI の版や環境による。ComfyUI 0.31.1 では、画像を1枚生成する Krea 2 のワークフローは観測RSSピークが 20.5 GiB と 20.98 GiB で、32GB を下回った。一方 864×480・56フレームの動画生成は 44.04 GiB から 44.73 GiB、1344×768・128フレームのアップスケールは 49.6 GiB で、どちらも 32GB を上回った。動画生成は ComfyUI 0.37.1 で測り直すと 13.2〜18.0 GiB で、32GB を下回った（画像生成とアップスケールは 0.37.1 では測っていない）。いずれも ComfyUI のプロセス木だけの値で、OS やほかのアプリが使う分を足す前になる。32GB を積んだ機体で実際に完走するかは試していない。測ったのは RTX 5080 1台での値で、他の 16GB のカードで同じになるかも測っていない。

観測RSSピークと確保量ピークのどちらで見積もればいいか

確保量より物理RAMとの比較に近いのは観測RSSピークのほう。確保量ピークは Windows の private bytes の最大で、物理RAMに載っていない分も含む。ただし観測RSSピークも必要な搭載量そのものを示す値ではなく、ComfyUI のプロセス木のワーキングセットを0.25秒間隔で観測した最大にとどまる。OS やほかのアプリが使う分は入らず、共有ページを含む取り方や観測間隔の制約もある。2つの差は測定によって一定ではなく、アップスケールの6条件では 6.78 GiB から 14.07 GiB、画像生成と動画生成のワークフローでは 15.28 GiB から 15.77 GiB あった。差がこの幅に収まる理由は測っていないので、確保量から一定量を引いて観測RSSを出すような使い方はできない。

ComfyUIの設定でRAMを減らせるか

ComfyUI は既定で、GPU との転送に使うメモリ領域をページアウトされない状態（ピン留め）で確保する。起動オプション --disable-pinned-memory を付けるとこの使用を止められ、引数の既定は「無効にしない」で、ピン留めを使う設定になっている。当サイトの別記事では、1216×672・97フレームの条件でこれを無効にすると、プロセスが使う RAM が 48.5GB から 33.5GB へ 15.0GB 減った。プロンプトの与え方でも動き、毎回変える条件が 47.8GB、繰り返す条件が 23.7GB だった。引用した値は本記事の測定とは別で、観測RSS・確保量のどちらで採ったかも単位も引用元の表記のままなので、本記事の表と直接引き算はできない。本記事のスイープでは、これらの設定を変えて測り直していない。

アップスケールでRAMが足りなくなるのを避けるには

測った範囲で言えるのは、同じ入力解像度ならフレーム数の少ない回のほうが観測RSSピークも小さかった、ということになる。1344×768 では 192フレームで観測RSS 69.17 GiB・確保量 83.24 GiB、64フレームで観測RSS 25.26 GiB・確保量 32.95 GiB だった。ただし尺を分けて連続で回す操作は測っていないため、前の回で使った分が次の回までに戻るかは見ていない（観測RSSピークは回をまたいだ最大で採っている）。別の経路としては、ComfyUI の外で ESRGAN を直接動かす構成で 67〜77GB が 1.4GB になったという測定が当サイトの別記事にある。8秒・4K・60fps の条件で採った値で、単位も指標も引用元の表記のままなので、本記事の表と直接引き算はできない。

参考資料

• 当サイトの実測データベース（条件ごとのRAM・VRAM・所要）
• 当サイトの検証環境
• ComfyUI 公式ドキュメント（起動オプション一覧）
• Microsoft Learn: Working Set（ワーキングセットの定義）