AI業務活用 2026.05.03

ローカルLLM運用の必須知識｜VRAM・トークン数の正確な計算方法と失敗回避テク

タグ：ローカルLLM / VRAM計算 / トークンカウント / GPU運用 / tips

なぜVRAM計算が大事か

ローカルで生成AIを動かすとき、最初にぶつかる壁がメモリ不足です。GPUのVRAM（ビデオメモリ）を超えると、処理が突然落ちたり、システムが重くなったり、最悪GPUが壊れる可能性もあります。でも、計算式さえ知っていれば、導入前に「このマシンで動かせるのか」「予算をいくら積めばいいのか」が分かります。

実感としては、適切に計算して運用すれば、古めのGPUでも意外と大きな生成AIモデルが動きます。逆に、ざっくり見積もると、いざ動かしたときに予想外の失敗に遭います。

VRAM消費量の計算式

生成AIのモデルがVRAMに載るかは、この基本式で判定できます：

必要VRAM（GB）= モデルの重さ（GB） × （1 + 勾配情報の量 + バッチサイズの影響）

より詳しくは：

推論時：モデルサイズ × 1.2（オーバーヘッド含む）
学習時：モデルサイズ × 3～4（勾配やキャッシュのため）

具体例で見てみよう

例えば、70億パラメータのモデルを推論で動かす場合：

70億パラメータ = 約14GB（16ビット精度の場合）
推論時の必要VRAM = 14 × 1.2 ≒ 17GB以上

つまり、24GBのGPUなら動きますが、16GBだと危ないです。

また、複数の入力を同時に処理する「バッチサイズ」を増やすと、その分VRAMが増えます。バッチサイズを2倍にするとおおよそVRAM消費も2倍になると考えておくと、ざっくりとした見積もりに役立ちます。

トークン数を事前に数える理由

「トークン」とは、文章を細かく切った1つ1つの単位です。生成AIは、ここからどこまで入力できるかという上限（コンテキストウィンドウ）があります。それを超えるとエラーになります。

例えば、「このモデルのコンテキスト上限は4097トークン」というエラーに遭ったことがあれば、それは入力が上限を超えているサイン。あらかじめ数えておけば、こうした失敗を防げます。

Python での事前カウント方法

ローカル環境なら、専用のライブラリを使ってトークン数を数えることができます。例えば、tiktoken（OpenAIが提供しているトークンカウント用の公式ライブラリ）を使う手法があります。コード例をいくつか参考にできます。

# 例として、カウント処理の流れ
# 1. 入力テキストを準備
# 2. トークンの数を計算
# 3. コンテキスト上限と比較
# 4. 超えていれば、入力を短くする

この流れを組めば、APIリクエスト前や、ローカルモデルの実行前に「大丈夫な量か」をチェックできます。

よくある失敗パターンと回避策

パターン1：オーバーヘッドを忘れる

モデルサイズちょうどのVRAMで「大丈夫」と判断してしまう人が多いです。実際には、バッチ処理や中間結果を保存するため、追加のメモリが必要です。目安として、モデルサイズの2割増しを見ておくとより安全です。

パターン2：コンテキスト長エラーに事前対策しない

会話を続ける際に、過去のやりとり全部を入力に含めていると、いつか必ずトークン上限に引っかかります。「どの部分を含めるか」をあらかじめ決めておく、または古い会話から捨てるルールを作っておくと、運用がスムーズです。

パターン3：異なるモデルで同じ計算を使う

モデルごとに、精度や内部構造が異なるため、VRAMの消費量も変わることがあります。同じパラメータ数でも、アーキテクチャによっては消費量が2割以上変わる可能性があります。新しいモデルに切り替えるときは、再度計算し直しましょう。

応用アイデア

運用スクリプトに組み込む

トークン数カウントをスクリプト化して、モデルの実行前に自動チェックする仕組みを作れば、手作業のミスを減らせます。

GPUの複数台構成を検討するときの判断基準に

将来的にモデルを大きくしたい場合、VRAM計算をしておくと、「今の1台では足りず、2台必要」といった判断が早めに分かります。

コスト見積もりに活かす

クラウド環境でGPUをレンタルする際の料金見積もりも、必要VRAM量があれば、「どのスペックのマシンを選ぶか」が決まるので、無駄な支出を防げます。

出典

上記の計算式とベストプラクティスは、VRAM計算に関する技術記事や、OpenAI APIのトークンカウントに関するQ&Aサイトでの議論をもとにしています。実装の詳細やコード例は、参考ソースを確認することで、より具体的な手順が分かります。