初級gpu hardware self-hosting更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

GPU・AI ハードウェアの基礎

この記事の目的

セルフホストや調達の会話に参加できる最小限のハードウェア知識を持てるようになります。「なぜ GPU なのか」「VRAM とモデルサイズの関係」「なぜメモリ帯域が効くのか」「ハードの類型と調達の選択肢」を、選定判断に使える範囲で理解し、このモデルはこの GPU に載るか・どこで買うか を大づかみに見積もれる状態を目指します。詳細な理論ではなく、インフラ選定の会話に必要な範囲に絞ります。

対象読者

セルフホスト推論の検討で、GPU・ハードウェアの選定会話についていきたい運用・実装担当
クラウド GPU・オンプレ購入のコスト比較を求められ、判断軸がほしいテックリード

前提知識

LLM API の呼び出しと、対象業務の基本を理解していること

本文

概要: なぜハードウェアの話が要るのか

API を借りて使う限り、ハードウェアは意識しません。しかしセルフホスト(セルフホスト推論の実務)・ローカル実行(ローカル・オンデバイス LLM の実務)を検討した瞬間に、「どの GPU に載るか・いくらかかるか」が判断を左右します。本記事はその会話に必要な最小限の知識を、製品名でなく類型と概算で提供します。

なぜ GPU か

LLM の処理は、大量の行列の掛け算の繰り返しです。

GPU は、同種の計算を大量のコアで並列に行うのが得意です。行列の大きさ・精度・転送量・実装が適合すれば、行列積を高速化できます。CPU との速度比はこれらの条件を揃えて測ります
LLM の推論・学習はこの並列行列積が中心のため、GPU(や同種のアクセラレータ)が使われます
「賢さ」の計算そのものより、それを現実的な時間で回すためにハードウェアが要る、と捉えると位置づけが掴めます

VRAM とモデルサイズの関係

セルフホストでは **VRAM(GPU の搭載メモリ)**が容量計画の出発点です。以下は重みを GPU に置く推論の概算です。全体が 1 台の VRAM に載らなくても、複数 GPU への分割や CPU・ディスクへの退避で実行できるランタイムがあります。ただし転送・同期の負担が増えるため、実行可否と実用的な速度は分けて確認します(Accelerate の Big Model Inference )。

概算式: 必要な VRAM は、ざっくり「パラメータ数 × 1 パラメータあたりのバイト数」+ 実行時のオーバーヘッド(後述の KV キャッシュ等)で見積もります
精度でバイト数が変わる: 1 パラメータあたりのバイト数は数値精度で決まります。FP16(半精度)なら約 2 バイト、INT8 なら約 1 バイト、INT4 なら約 0.5 バイトです
概算の例: 70 億(7B)パラメータのモデルなら、FP16 で約 14 GB(7B × 2 バイト)、INT8 で約 7 GB、INT4 で約 3.5 GB が重みのおおよその目安です。これに後述の KV キャッシュや作業領域が上乗せされます
量子化で縮める: **量子化(quantization)**は、重み等を低い精度で表現してサイズを縮める手法です。スケール・ゼロ点などの追加データや未量子化層もあり、重みの概算だけで搭載可否を保証できません。KV キャッシュ・作業領域を含むピーク使用量と、量子化後の品質を自社タスクで検証します

メモリ帯域律速という直感

LLM 推論では、計算能力とメモリ帯域のどちらが限界になるかが処理段階・バッチサイズで変わります。NVIDIA の行列積ガイドは、読み書きするバイト数に対する演算量で両者を切り分けています。

小さいバッチの逐次生成: 毎トークンの生成で大量の重みを読み出すため、演算量に対して読み出しが多くなり、メモリ帯域が律速になりやすい条件です。一方、長い入力をまとめて処理する段階や大きいバッチでは、計算能力の寄与が大きくなります
選定への含意: 「演算性能(FLOPS)が高い GPU=推論が速い」とは限りません。メモリ帯域と VRAM 容量が、推論では効くことが多いです
バッチで効率が上がる: 複数リクエストをまとめて処理(バッチング)すると、読み出した重みを使い回せて効率が上がります。これがサーバー側サービングの要点です(セルフホスト推論の実務)

ハードの類型

製品名は変化が速いため、類型で押さえます(具体の製品・世代は下記 TODO)。

類型	位置づけ	主な用途
データセンター GPU	大 VRAM・高帯域・高価。サーバー向け	本格的なセルフホスト推論・学習
コンシューマ GPU	中 VRAM・入手しやすい	小〜中規模モデルの実行・検証
NPU・端末アクセラレータ	省電力・端末内蔵	オンデバイス推論(スマホ・PC)

データセンター GPU: 大きな VRAM とメモリ帯域を持ち、大規模モデル・高スループットに向きますが高価です
コンシューマ GPU: 入手しやすく、量子化した中小モデルの実行・検証に使えます。VRAM が上限になりがちです
NPU・端末アクセラレータ: スマホ・PC に内蔵され、省電力でオンデバイス推論を担います(ローカル・オンデバイス LLM の実務)

調達の選択肢と TCO

「GPU を使う」には調達方法が複数あり、**総保有コスト(TCO)**で比べます。

クラウド GPU(従量・予約): 使った分だけ払う/一定期間予約する。初期投資が小さく、需要変動に強い。長時間フル稼働だと割高になりやすい
専有・ホスティング: 専有インスタンスや GPU ホスティングを借りる。クラウドとオンプレの中間
オンプレ購入: 自社で GPU を購入・設置。閉域網・データ主権の要件や、常時フル稼働なら有利になりうるが、初期投資と運用負担が大きい
TCO で見る: 本体価格だけでなく、電力・冷却・設置・保守・人件費・陳腐化(GPU は世代交代が速い)を含めて比べます。「買えば安い」は稼働率と運用体制次第です

「GPU を持つ」ことの運用負担

見落とされがちですが、GPU を自前で持つと運用の仕事が増えます。

ドライバ・ライブラリのバージョン管理、故障対応、容量計画、電力・冷却、世代交代への追従が発生します
クラウドはこの多くを肩代わりします。オンプレは自由度と引き換えに、これらを自社で担います
運用負担・稼働率を織り込むと、API を借りる方が安くなる条件もあります。単価だけでなく要求品質を満たした処理件数あたりで比較します(損益分岐の詳細はセルフホスト推論の実務)

実務での注意点

アンチパターン

演算性能(FLOPS)だけで GPU を選ぶ → 推論はメモリ帯域・VRAM 律速のことが多く、期待どおり速くならない → VRAM 容量とメモリ帯域を重視する
VRAM を確認せずモデルを選ぶ → メモリ不足や退避による速度低下が起きる → 重み・KV キャッシュ・作業領域を見積もり、分割・退避も含む構成で実測する
量子化すれば無条件で使えると考える → 精度低下で品質が落ちる → 量子化後の品質を自社タスクで検証する
「買えば安い」で TCO を見ずにオンプレ購入する → 電力・運用・陳腐化で結局割高になる → 稼働率と運用体制込みの TCO で比較する
GPU 保有の運用負担を見積もらない → ドライバ・故障・世代交代の負担が想定外に重い → 運用の仕事が増えることを前提に判断する

チェックリスト

対象モデルの必要 VRAM を「パラメータ数 × 精度」+ 余裕で概算した
量子化を使う場合、量子化後の品質を自社タスクで検証する計画がある
GPU 選定で VRAM 容量・メモリ帯域を重視している
調達(クラウド従量/予約・専有・オンプレ購入)を TCO で比較した
GPU 保有に伴う運用負担(ドライバ・故障・電力・世代交代)を織り込んだ
セルフホストが API を借りるより本当に安いか、稼働率込みで確認した

参考資料

NVIDIA — Matrix Multiplication Background User’s Guide — 演算量とメモリ転送量による性能の制約、行列サイズの影響。本文の 7B の容量は重みのみの算術例です(アクセス日: 2026-09-10)
Hugging Face Accelerate — Big Model Inference — GPU・CPU・ディスクに重みを配置して、単一 GPU の容量を超えるモデルを実行する例と転送負担(アクセス日: 2026-09-10)

TODO・未確認事項

本文の未確認事項を参照してください。