【悲報】3.43GBのファイルでRTX4090が落ちる事態に動画生成AIユーザー困惑「メモリ7倍空いてるのに」
【悲報】3.43GBのファイルでRTX4090が落ちる事態に動画生成AIユーザー困惑「メモリ7倍空いてるのに」
ローカル環境で動画生成AIを動かすユーザーの間で、ある奇妙な現象が定番の悩みとして定着している。ネットから落としたモデルのファイルはたった3.43GB。手元のグラボは24GB積んでいる。計算上は7倍もの余裕があるはずなのに、いざ実行すると「メモリ不足」で強制終了してしまうのだ。しかも設定を間違えたわけでもなく、開発元自身が公式に「24GB以上のVRAMが必要」と明記しているという、理不尽極まりない状況である。
文章を生成するAI（LLM）なら「必要なメモリ ≒ モデルのファイルサイズ」という見積もりがほぼ正解として機能する。ところが動画生成AIでは、この常識が桁違いに外れる。場所を食っている犯人はモデルではなく、「いま作りかけの映像そのもの」だったのである。
公式が認める異常数値 3.43GBのファイルに24GB以上
騒動の中心にあるのは、動画生成AI「Wan2.2」だ。このモデルには大きさ2種類あり、小型の5Bと大型の14Bが存在する。問題の5Bについて、開発元が公開している必要スペックは「24GB以上、例としてRTX 4090」。つまり一般向け最上位クラスのグラボでも、素の設定ではギリギリか足りない前提なのである。さらに大型の14Bに至っては必要量80GB以上とされており、そのような容量を持つカードは個人向け市場にはそもそも存在しない。
一方でファイルサイズを見ると、有志が量子化によって4ビットまで削った5B版はわずか3.43GB、同じく4ビットの14B版でも9.65GBしかない。「9.65GBのファイルに80GBが必要」という差は70GBもある。この謎の空白地帯に何が入るのか。それこそが本件の核心だ。
犯人は作りかけの映像 121コマを全部同時に抱える
動画生成AIはいきなり綺麗な映像を作れない。最初はただの砂嵐のようなノイズから始めて、数十回にわたる推論ステップを経て少しずつ整えていく方式を採用している。そして致命的なのは、この途中経過を捨てられないことだ。次の一手は必ず今の状態から作られるため、消した瞬間に作業が終わってしまう。
さらに写真との決定的な違いがある。写真なら1枚だけ扱えばいいが、動画は全コマを並行して整える必要がある。前のコマと後ろのコマが噛み合っていないと人物が別人になったり背景が飛んだりして映像が破綻するためだ。5秒程度の動画でも1秒あたり24〜30コマとして120〜150コマ。つまりシステムは常に100枚超の「作りかけの絵」を同時に抱え込んでいることになる。
しかも扱っているのは生映像ではなく、VAE（Variational Autoencoder）と呼ばれる圧縮機構を通した潜在表現という縮小状態。それでも60GB級のメモリを要求するのだから、生映像のまま処理していたら想像もつかない数字になっていたはずだ。
同じ条件で測った記録 4ビットまで削っても60GBが22GBにしかならない
道具を作っている側が同じ条件で測定し公開した数字を並べると、この構造は一目瞭然になる。条件は業務用の80GBグラボ、121コマ、横1120×縦768の動画で統一した実測値だ。まずHunyuanVideoを素で動かすとピーク60.09GB。同じ条件でCogVideoX 1.5 5Bは36.51GB、LTX-Videoは17.75GBと、モデルによって大きな差がある。
ここからHunyuanVideoの軽量化を試みる。使わない部分をパソコン本体側のメモリへ追い出すオフロードを行うと28.87GBまで下がるが、これは削ったわけではなく置き場所を変えただけで中身は減っていない。さらに4ビットへの量子化と、VAEのタイリング（細かく区切って処理）を重ねても21.99GBどまり。モデルの中身を1/4まで削ったのに、必要メモリは1/3にしかならなかった。
理由は単純明快で、量子化で削れるのはモデルが覚えている中身＝重みだけであり、計算の最中に生まれる作りかけの映像はファイルに一切含まれていないためだ。いくらファイルサイズを見ても総量は分からず、見積もりのしようがない。
コマ数は線形 解像度は二乗 アテンションの対応表が底を作る
作りかけの映像がどう増えるのか。動画生成AIの本体はトランスフォーマーという仕組みで、文章AIと共通の骨格を持つ。入力を1本の列として受け取る点も同じだが、動画の場合は「縮めた映像を細かい四角（トークン）に切って並べる」ため、列の長さは コマ数 × 縦 × 横 の掛け算で決まる。
ここで恐ろしい性質が顔を出す。トランスフォーマー内部のアテンション処理は、原則として全トークンが全トークンと関係を調べるため、列の長さをnとするとn×nの対応表を作る。つまり2乗で効くのだ。列が2倍になれば対応表は4倍、10倍なら100倍。
コマ数を増やす場合はトークンが素直に比例して増えるだけだが、解像度を上げる場合は縦横2方向が同時に効く。480pを960pにする、つまり設定を1段上げただけでトークンは4倍、対応表は16倍になる。体感としては些細な変更なのに、メモリは一気に跳ね上がる。研究者たちも「このままの仕組みでは高解像度化は現実的ではない」と指摘しており、これが解像度の壁と呼ばれる所以である。
そしてもう一つの罠が、一番メモリを食うのが生成中ではなく最後のVAEデコード、つまり縮んだ映像を本来の解像度へ一気に膨らませる瞬間だということだ。数十秒〜数十分待ち抜いた末の保存直前に落ちるのは、動画生成界隈では定番の落ち方とされる。対処法は少しずつ順番に戻すタイリング処理だが、区切り目が薄っすら見えることがあるなど完全な無料の取引ではない。
三段活用で6.56GB 増えた時間はわずか3%
では軽量化技術をフル活用するとどこまで下がるのか。量子化を4ビットからFP8形式に変え、オフロードをモデル丸ごとではなく部品ごとに行い、さらにVAEタイリングを併用すると、なんと6.56GBまで到達する。同じ動画、同じグラボ、同じ121コマでの数値であり、元の60GBの約9分の1だ。
驚きは速度面にある。削る前の処理時間が863秒だったのに対し、全部乗せ後は885秒。増えたのは22秒、率にして3%未満である。「メモリが10分の1で、代償は3%」という破格の取引だ。しかし初期設定ではこれらの工夫は無効のままなので、知らないユーザーは素の設定で落ち続けることになる。
落ちた時の対処順序としては、画質を損なう量子化強化よりも先にオフロードとタイリングを試すのが筋が良い。ただしオフロードの逃し先はパソコン本体のメモリなので、そちらが細いと意味がなく、動画生成ではグラボだけでなく本体メモリもセットで重要になる。また6.56GBより先は基本的に下がらない。残ったのはアテンションの計算そのものであり、逃せず削れず、その場で計算するしかない「本当の底」だからだ。
買い物の判断材料 VRAM容量と秒数・解像度の妥協点
ここまでの知識は機材選びにも直結する。動画生成をローカルで行うなら、処理速度よりもまず乗る容量、VRAMの多さを最優先で見るべきだというのが結論だ。速くても乗らなければ動かない。加えてオフロードの逃し先となる本体メモリも一緒に確認が必要である。
なお「6GBでも動かせる」と喧伝されているツールも存在するが、これは作者本人の主張であり第三者による検証数値ではない点には注意が必要だ。モデル選択でも意見が割れており、LTX-Videoを作った側は720×1280以下の解像度、257コマ以下を得意範囲と明示し、解像度は32の倍数、コマ数は8の倍数+1という制約を設けている。これは映像を四角に切って並べる仕組み上、綺麗に割り切れないと切り分けが合わなくなるためだ。Wan2.2とLTXのどちらが速いかについては、測定条件が揃っていないため断定はできない。
80GB級の業務用カードを買うか、クラウドで借りるかという議論も定番で、借りる派は「使った時間だけ払えばいい」「必要な時だけ触れる」を主張し、手元派は「順番待ちがない」「毎日作るなら結果的に安い」「自分の顔や仕事の素材を外に出したくない」を根拠にする。月に何本作るかで答えは変わるため、ここも一概には言えない領域だ。
ネットの反応
3.43GBのファイルに24GB必要とか、初見じゃ詐欺だろって思うけど仕組み聞くと納得しかない
文章AIの感覚で動画やると確実に死ぬ。ファイルサイズは当てにならないって教訓だわ
解像度1段上げたら対応表16倍って数字が怖すぎる。480p→720pで落ちた原因がようやく分かった
最後の保存直前に落ちるの本当に腹立つんだよな。数十分待った後にね
FP8+部品ごとオフロード+タイリングで6.56GB、時間3%増だけとか神設定じゃん。早速試す
量子化強くすればするほど画質落ちるのにメモリは大して減らないの、闇深すぎる
グラボ24GB積んでるけど本体メモリ16GBだとオフロード先が細くて台無しになるパターンあるある
121コマ同時に抱えてるってことは、秒数短くすればするほど軽くなるってことで合ってる？
LTXの制約「解像度は32の倍数、コマ数は8n+1」って最初呪文かと思ったけど仕組み分かれば納得
5秒の動画に9分待つの、思ってたより動画生成って気長な趣味なんだな
クラウドで80GB借りるか、家で24GB我慢するか、月何本作るかで変わるのはその通り
アテンションの計算が底でそこからは下がらないって、数学的にそういうものなら仕方ないね
AIの所感
この話の本質は、「ファイルサイズという見える指標」への過信が生む認識のズレにあると思う。文章AIの世界で培われた「モデルの重みが主役」という直感は、動画生成においては完全に裏切られる。主役は入れ替わりの激しい途中計算の産物であり、それは配布ページのどこにも書いていない。つまりユーザーの失敗は無知のせいではなく、従来型の見積もり手法そのものが適用不能な新しい計算形態に触れているからだと言える。注目すべきは、オフロード・量子化・タイリングの三段活用で60GBが6.56GBになり、時間の増加が3%に抑えられたという実測値だ。これは「メモリ不足=諦めか金策」という二択が実は誤りで、知識による最適化で大幅に緩和できることを示している。一方でアテンションのn×n対応表という構造的な底は依然として残っており、解像度と秒数の妥協からは逃げられない。将来的に線形アテンションや分割生成などの研究が実装レベルに落ちてくればこの壁は下がるかもしれないが、現状では「自分が何秒・何ピクセルの動画を欲しているか」を先に言語化し、そこから逆算してVRAMを選ぶという逆張りの発想こそが、最も費用対効果の高い対策だろう。速さより容量、グラボと本体メモリのバランス、この二点は覚えて損のない原則だ。