ローカルAIの実行スペックを見積もるには｜RAM・VRAM・ディスクを分ける計算例

ローカル環境でAIを動かすためのスペックは、メモリの合計容量だけでは判断できません。PC本体のRAM、GPU側のVRAM、モデルを保存するディスクを分け、ほかの用途で使っている分を引いてから、試験に使える余裕を確認します。

この記事では、文章を生成する大規模言語モデル（LLM）を想定し、容量の計画表を作ります。数値はすべて架空の計算例です。モデルのダウンロードや実行、GPUの動作試験は行っていません。特定モデルの必要容量、動作保証、購入推奨ではありません。

RAM・VRAM・ディスクは別々の欄で確認する

RAMはOSやアプリが使う主記憶、VRAMはGPUの処理で使うメモリです。ディスクはモデルファイルなどを保存する領域で、空きディスクが多いだけで実行中のメモリ不足を解消できるとは判断しません。容量表では、まずこの用途の違いを分けます。

GPUに専用メモリがあるPCと、CPUとGPUがメモリを共有する構成も区別してください。共有メモリの構成で、同じ物理メモリをRAM欄とGPU欄へ重ねて計上すると、実際より大きな容量があるように見えてしまいます。機器やOSの仕様を見て、独立した容量なのか共有なのかを記録します。

実行ソフトの対応条件も別欄に置きます。Ollamaの公式Hardware supportはGPUやOS、ドライバーに関する条件を掲載しています。GPUの名前や容量が分かっても、それだけで使えると決めず、自分の環境が対象条件に合うか確認してください。本稿では対応GPUの一覧やインストール手順は扱いません。

OllamaのFAQでは、モデルがCPU側のメモリだけに読み込まれる場合と、CPU側とGPU側に分かれる場合が説明されています。ただし、読み込み先を分けられることは、RAMとVRAMを一つの自由な容量として足せることとは違います。どの部分をどこへ置くか、どの設定が使えるかは実行ソフトとモデルに依存します。

計画の単位も統一します。本稿のGiBは2の30乗バイトです。製品表示のGBと同じ数値として転記せず、容量の表示単位を確認します。空き容量を見る時点、ほかに開いていたアプリ、測定方法も添えておけば、後から条件の差を追えます。

架空のPCで使える容量を引き算し、合算しない

専用VRAMを持つPCを想定して、計算用の入力を固定します。以下の「既使用」と「予備枠」は説明用に置いた値で、実機の観測値でも一般的な推奨値でもありません。予備枠は、ほかのアプリの変動などを考えて今回の試験へ割り当てない分です。

【架空の容量入力】
RAM：搭載16GiB、既使用6GiB、予備枠2GiB
VRAM：搭載8GiB、既使用2GiB、予備枠1GiB
ディスク：空き40GiB、予備枠10GiB

この例の計画上の予算は、RAMとVRAMでは「搭載−既使用−予備枠」、ディスクでは「空き−予備枠」で求めます。ディスクの空き容量は使用済み領域を除いた値なので、そこから使用済み容量をもう一度引きません。

この表の8GiBと5GiBを足して「モデルに13GiB使える」とは書きません。別の資源だからです。同じく、保存用の30GiBを足して実行用メモリの大きさにはできません。共有メモリ型の機器なら、この表をそのまま使わず、共有している実容量から一度だけ差し引く形に直します。

ここで求めたのは、試験前に置く計画上の予算です。実行ソフトが必要とする量を測った結果ではありません。値が正でも、その範囲に収まるモデルを特定したことにはなりません。モデルファイルの情報と実行時の観測を後から突き合わせます。

ディスクについては、取得予定のモデル本体に加え、別版を残すか、ログなどを保存するかも確認します。今回の30GiBという予算に、どのファイルを含めるかを書いてください。配布ファイルの容量が未確認なら、その欄は未確認のままにします。「空きがあるから足りる」と先に結論を出すと、複数の版を保持する計画が抜けやすくなります。

予算が負になる場合は、引き算が終わった時点で、その配分案には余裕がないと分かります。数値を都合よくゼロに置き換えたり、使用中のアプリを無断で止めたりはしません。何を残す必要があるかを確認し、試験条件を見直すための材料にします。

重みの理論値は、実行時の必要メモリではない

モデルの規模から大まかな量を考える際は、学習済みの数値である「重み」の格納量と、実行に必要な総量を分けます。重みを一つ当たり一定のビット数で隙間なく保存すると仮定した計算は、理想化した下限の目安です。実ファイルや実行時の使用量を表す式ではありません。

次も架空の条件です。実在するモデルを指定していません。

【架空の重み入力】
パラメーター数P＝7000000000
重み一つ当たりのビット数b＝4
1バイト＝8ビット
1GiB＝1073741824バイト

この仮定では、重みだけの量をP×b÷8で求めます。計算すると7000000000×4÷8＝3500000000バイト、GiBへ換算すると約3.26GiBです。小数点以下2桁に丸めています。量子化は、重みなどの数値を少ないビット数で表現する方法ですが、ここでは方式ごとの実際の格納形式まで再現していません。

この3.26GiBには、量子化に伴う追加情報、モデルの管理情報、実行ソフトの作業領域を含めていません。文脈の処理で再利用するデータを保存するKVキャッシュも別です。そのため、先ほどのVRAM予算5GiBより小さいという理由だけで、GPU上に収まるとは判定できません。

配布ファイルには形式上の追加情報があり、実行中にはファイル容量とは別の領域も使います。理論値、配布ファイルの容量、読み込み後の使用量、処理中の最大使用量は別々の欄にしてください。差があること自体を計算ミスとは扱わず、何を含めた数字かを確認します。

メモリに収まるかと、仕事に使える速さかも別の問いです。この計算から待ち時間や生成速度は分かりません。特定のGPUを選ぶ順位や、最低限のRAM容量へ読み替えず、次の試験で観測すべき量を整理するために使います。

文脈長と同時処理の条件を付け、実測欄を残す

一度に扱う文脈の上限をコンテキスト長と呼びます。Ollamaの公式Context lengthは、これを大きくすると必要なメモリが増えると説明しています。短い文章での確認と、長い資料を渡す確認は同じ条件ではありません。

同時に処理する要求数も記録します。OllamaのFAQは、同じモデルの並列要求が増えると、文脈に使う領域と追加のメモリ割当が増えると説明しています。ただし、同時処理数を増やせばPC全体の使用メモリがその倍率になる、という単純な式にはしません。重みの扱いや作業領域の内訳まで同じ比率で増えるとは、この説明だけでは決められないからです。

実行を許可された環境で後から記入する票を用意します。以下は測定結果ではありません。未測定という表示を、ゼロ使用や問題なしの意味には使わないでください。

実測するときは、同じ入力を使い、実行前の使用量と処理中の使用量を分けて記録します。処理が終わった後の一時点だけでは、途中で増えた分を見逃す可能性があります。読み込み先も確認し、想定したGPU側ではなくCPU側へ分かれていたなら、その条件を残します。本稿では確認コマンドや設定変更は実行していません。

最初の判断は「動くはず」ではなく、「計画表に何が足りないか」です。資源別の予算と、対象版・文脈長・同時処理数をそろえてから、許可された試験の実測値を照合します。容量内に収まるか、処理時間が用途に合うか、通常業務を妨げないかを確かめて初めて、その条件での利用可否を判断できます。

公式資料は2026年10月17日に確認しました。公開・改訂日は今回の取得資料では確定できていません。
– Ollama FAQ
– Hardware support
– Context length