✓この記事でわかること
- 1GPUは行列演算やテンソル演算を大量に並列実行しやすい
- 2画像生成AIはプロンプトの変換、ノイズ除去、画像への復元を段階的に行う
- 3ローカルAIはモデル本体だけでなくVRAM、KV cache、量子化、対応ランタイムも確認する
生成AIの説明で「GPUを使う」「VRAMが必要」という言葉を見かけます。では、なぜCPUではなくGPUが中心になるのでしょうか。答えは、生成AIの内部で同じ種類の計算を大量に繰り返す場面が多く、計算を分けて同時に進めるGPUの設計と相性がよいからです。
ただし、GPUがすべてを担当するわけではありません。入力の受け付け、ファイル管理、アプリの制御はCPUが担当し、対応する演算をGPUへ渡します。モデルや実行環境によっては、NPUやCPUへ一部を割り当てることもあります。この記事では、画像生成AIとローカルLLMを例に、どこで何が計算されているのかを分けて見ていきます。
GPUが生成AIの計算に向く理由
CPUは、OSやアプリ、条件分岐の多い処理を少数の高性能なコアで順番に処理することが得意です。一方のGPUは、同じ計算を多数のデータへ適用する処理を、大量の演算器で並列に進める設計です。
ニューラルネットワークでは、行列の掛け算、積和演算、畳み込み、アテンションなどが層ごとに繰り返されます。入力データの一つひとつへ似た計算を行うため、GPUで分割して処理しやすい部分が多くあります。GPUに搭載されたTensor Coreなどの専用回路は、機械学習でよく使われる行列の積和を高速化するために使われます。
とはいえ、GPUなら常にCPUより速いとは限りません。小さな処理ではGPUへデータを送る時間が目立つことがあります。GPUに対応していない演算、VRAM不足によるCPUとのデータ交換、ドライバーやランタイムの相性がボトルネックになる場合もあります。重要なのは「GPU搭載」という一言ではなく、使うモデルと処理がそのGPUの実行経路に合っているかです。
画像生成AIは何を計算しているのか
画像生成AIでは、入力した文章がそのまま画像へ変換されるわけではありません。代表的な拡散モデルを例にすると、まずプロンプトをトークンへ分割し、テキストエンコーダーで数値ベクトルへ変換します。このベクトルが、画像に含めたい内容や条件を表す情報になります。
生成AIの処理を、プロンプト、数値表現、ノイズ除去、画像の流れで整理した独自図解です。
次に、モデルは最初から完成した画像を作るのではなく、ランダムな状態に近い潜在表現から始めます。ノイズ除去モデルが、プロンプトの条件を参照しながら、少しずつノイズを減らす処理を繰り返します。ここでは、アテンションや畳み込み、行列演算が何度も実行されるため、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のモデルなら、より少ないメモリで動かせる可能性があります。ただし、品質、速度、対応するランタイム、モデル形式の組み合わせを確認する必要があり、量子化すれば必ず同じ結果や速度になるわけではありません。
GPUが使えない場合でも、CPUやNPUの実行経路を使える環境があります。ONNX Runtimeのように、CUDA、TensorRT、DirectML、OpenVINOなど複数の実行プロバイダーを選べる仕組みもあります。特定メーカーのGPUだけが生成AIを動かせると決めつけず、使いたいアプリの対応状況とドライバーを確認しましょう。
まとめ：GPUの性能だけでなく処理経路を見る
生成AIがGPUを使うのは、行列演算やテンソル演算のような大量の並列計算を効率よく処理しやすいからです。画像生成ではテキストの表現変換、ノイズ除去、VAEによる画像復元が行われ、ローカルLLMではTransformerが次のトークンを順番に予測します。
GPUの購入や設定を考えるときは、演算性能だけでなくVRAM容量、量子化、モデル形式、ランタイム、CPUとの分担を確認してください。「GPUだから速い」「エンコードだから動画圧縮」と短絡せず、処理の入力と出力をたどると、必要な構成が見えやすくなります。