生成AIはなぜGPUで動く？画像生成とローカルAIの処理の仕組み

生成AIの説明で「GPUを使う」「VRAMが必要」という言葉を見かけます。では、なぜCPUではなくGPUが中心になるのでしょうか。答えは、生成AIの内部で同じ種類の計算を大量に繰り返す場面が多く、計算を分けて同時に進めるGPUの設計と相性がよいからです。

ただし、GPUがすべてを担当するわけではありません。入力の受け付け、ファイル管理、アプリの制御はCPUが担当し、対応する演算をGPUへ渡します。モデルや実行環境によっては、NPUやCPUへ一部を割り当てることもあります。この記事では、画像生成AIとローカルLLMを例に、どこで何が計算されているのかを分けて見ていきます。

GPUが生成AIの計算に向く理由

CPUは、OSやアプリ、条件分岐の多い処理を少数の高性能なコアで順番に処理することが得意です。一方のGPUは、同じ計算を多数のデータへ適用する処理を、大量の演算器で並列に進める設計です。

ニューラルネットワークでは、行列の掛け算、積和演算、畳み込み、アテンションなどが層ごとに繰り返されます。入力データの一つひとつへ似た計算を行うため、GPUで分割して処理しやすい部分が多くあります。Tensor CoreはNVIDIAの回路の名称です。すべてのGPUにその名前の回路があるわけではありません。

とはいえ、GPUなら常にCPUより速いとは限りません。小さな処理ではGPUへデータを送る時間が目立つことがあります。GPUに対応していない演算、VRAM不足によるCPUとのデータ交換、ドライバーやランタイムの相性がボトルネックになる場合もあります。重要なのは「GPU搭載」という一言ではなく、使うモデルと処理がそのGPUの実行経路に合っているかです。

画像生成AIは何を計算しているのか

画像生成AIでは、入力した文章がそのまま画像へ変換されるわけではありません。代表的な拡散モデルを例にすると、まずプロンプトをトークンへ分割し、テキストエンコーダーで数値ベクトルへ変換します。このベクトルが、画像に含めたい内容や条件を表す情報になります。

潜在拡散モデルの流れを簡略化した概念図です。数値ベクトルと風景は説明用で、実際のモデル内部値・生成結果の比較ではありません。最後の矢印にはVAEのデコードも含みます。

次に、モデルは最初から完成した画像を作るのではなく、ランダムな状態に近い潜在表現から始めます。ノイズ除去モデルが、プロンプトの条件を参照しながら、少しずつノイズを減らす処理を繰り返します。ここでは、アテンションや畳み込み、行列演算が何度も実行されるため、GPUの並列処理が活かされやすくなります。

モデルによってはUNetを使う構成もあれば、Transformerを中心にする構成もあります。反復回数やスケジューラーも異なるため、「何ステップなら必ず正しい」「すべての画像生成AIは同じ流れ」とは考えないでください。

エンコードとデコードは圧縮と同じ意味ではない

画像生成AIの説明では、テキストエンコードやVAEエンコード、デコードという言葉が出てきます。ここでのエンコードは、文章や画像をモデル内部で扱いやすい数値表現へ変換する意味です。VAEのデコーダーは、ノイズ除去が終わった潜在表現を、通常の画像データへ戻します。

これは、JPEGやH.264のファイル圧縮・メディアコーデックのエンコードとは別の処理です。JPEGでは画像を保存や通信に向くデータ形式へ圧縮し、H.264では動画を符号化します。AIのエンコードは、モデルが意味や特徴を計算するための表現変換です。同じ「エンコード」という言葉でも、何を入力し、何を出力するのかを確認する必要があります。

img2imgやinpaintingでは、入力画像をVAEのエンコーダーで潜在表現へ変換し、その後にノイズ除去を行い、デコーダーで画像へ戻すことがあります。画像生成では、このように生成の中心となる計算と、表現を変換する計算が組み合わさっています。

ローカルLLMは次のトークンを順番に作る

ローカルLLMでは、入力文がトークンIDへ分割され、埋め込みベクトルとしてTransformerへ渡されます。Transformerの各層でアテンションやフィードフォワード層の計算を行い、次のトークン候補の確率を計算し、選択方法に従ってトークンを決めます。

文章全体を一度に完成させるのではなく、生成したトークンを次の入力に加えながら、次のトークンを順番に決めます。出力したトークンはデコードされ、画面上の文字列になります。過去のトークンに関する中間情報をKV cacheへ保持するため、長い文章や長い会話では、モデルの重み以外にもメモリが必要です。

モデルの層をGPUへオフロードできる実装では、VRAMに載せられた部分をGPUで処理し、残りをCPUで処理する構成もあります。モデル全体がVRAMに収まらないからといって、必ず動かないわけではありませんが、CPUとのデータ交換が増えると速度が変わります。

VRAM容量と量子化を分けて考える

ローカルAIで必要なメモリは、モデルの重みだけではありません。画像生成では中間テンソル、LLMではKV cache、さらに実行環境の作業領域も使います。画像サイズ、コンテキスト長、同時実行数を増やすと必要量も変わります。

量子化は、モデルの数値表現を低いビット数へ変換し、メモリ使用量を抑える方法です。4bitや8bitのモデルなら、より少ないメモリで動かせる可能性があります。ただし、品質、速度、対応するランタイム、モデル形式の組み合わせを確認する必要があり、量子化すれば必ず同じ結果や速度になるわけではありません。

例えば、70億個の重みをすべて同じ精度で詰めて保存すると仮定した場合、重みだけの計算値は次のようになります。GBは10億bytesです。実モデルのファイルサイズや動作に必要なVRAMを測定した値ではありません。

実際には量子化のスケールなどの追加情報、異なる精度で保持する層、KV cache、作業領域が加わります。「4bitなら4GBのGPUで動く」とこの表だけから判断できません。モデルファイルとアプリの条件を確認し、利用するコンテキスト長や画像サイズも合わせて見ます。

アプリごとにGPUを使う条件が違う

DiffusersのStable Diffusion解説では、テキストエンコーダー、UNet、VAEを組み合わせます。メモリ最適化のenable_model_cpu_offload()は、処理に必要なモデルを順次GPUへ移し、他の構成要素をCPUに保持する方式です。同じ画像生成でも、全モデルを常時GPUへ置く設定とはメモリ量と転送の条件が変わります。

ONNX Runtimeは、Execution Providerが対応するノードや部分グラフを担当します。CUDA・DirectML・OpenVINOなどが一覧にあることは、使っているアプリで任意のGPUを自動利用できる保証ではありません。アプリ側のビルド、プロバイダー、対応演算を合わせて確認します。

llama.cppはLLM向けの別の実装です。公式READMEは量子化、CUDA／HIP／Metalなどのバックエンド、CPUとGPUを組み合わせた部分的な推論を示しています。Diffusersの設定名をそのまま流用せず、使うアプリのモデル形式と実行経路を確認します。

参考情報

2026年10月4日に下記の該当本文を確認しました。GPU実機での速度・メモリ測定は行っていません。

• NVIDIA Tensor Cores：Tensor Coreの名称と演算
• Diffusers：Understanding pipelines, models and schedulers：Stable Diffusionの構成要素と潜在表現
• Diffusers：Reduce memory usage：Model offloading
• ONNX Runtime Execution Providers：ノード／部分グラフの割り当てと対応一覧
• llama.cpp README：量子化・対応バックエンド・CPU＋GPU推論