所要時間: 約15分 | 難易度: ★★☆☆☆

この記事で作るもの

  • VRAM容量を超えた際に極端に推論速度が落ちる「Sysmem Fallback」を無効化し、常に最高速でLLMを動かす環境
  • PythonでVRAM使用状況と推論速度をリアルタイムに監視し、モデルが「溢れているか」を判定するスクリプト
  • 必要なもの: NVIDIA製GPU（RTX 30シリーズ以降推奨）、Python環境

📦 この記事に関連する商品（楽天メインで価格確認）

RTX 4060 Ti 16GB

VRAM 16GBを安価に確保でき、今回紹介したVRAM管理の検証に最適

楽天で価格を見る Amazonでも確認

※アフィリエイトリンクを含みます

先に確認するスペック・料金

ローカルLLMを実務で使うなら、GPUのVRAM容量がすべてです。 私がRTX 4090を2枚挿しているのは、単に「速いから」ではなく「モデルをVRAMに載せきらなければ仕事にならないから」です。 具体的には、Llama-3-8Bなら最低8GB（4bit量子化なら6GB）、70Bクラスなら48GB以上のVRAMが必要です。

もしVRAMが足りない場合、最近のNVIDIAドライバ（バージョン532.03以降）は「共有システムメモリ」を勝手に使い始めます。 これが曲者で、VRAM（帯域幅1TB/sクラス）からメインメモリ（帯域幅数十GB/s）にデータが溢れた瞬間、推論速度は1/10以下に激減します。 「動くことは動くが、実用には耐えない」という最悪の状態を避けるため、設定の変更が必須です。

なぜこの方法を選ぶのか

LLMの推論速度を上げる方法はいくつかありますが、設定を見直すのが最もコストパフォーマンスが良いです。 以前は「VRAMが足りなければ諦めて小さいモデルを使う」か「Linuxに移行する」しかありませんでした。 しかし、現在のWindows版NVIDIAドライバでは「共有メモリへのフォールバック（代行）」をオフにする設定が追加されています。

これをオフにすると、VRAMが足りない場合は即座にエラー（Out of Memory）で落ちるようになります。 一見不便に思えますが、実務においては「いつ終わるかわからないほど遅い処理」が走り続けるより、「メモリ不足」と即座に判明してモデルサイズを調整できる方が遥かに健全です。 あやふやな挙動を排除し、決定論的なパフォーマンスを確保することがプロの道具としての第一歩です。

Step 1: 環境を整える

まずは現在のドライババージョンを確認し、設定変更に必要なツールを揃えます。

# NVIDIAドライバのバージョン確認
nvidia-smi

このコマンドで「Driver Version」が532.03以上であることを確認してください。 もし古い場合は、公式サイトから最新のGame ReadyドライバまたはStudioドライバをインストールします。 私は安定性を重視してStudioドライバを選択することが多いですが、LLM用途ならどちらでも大差ありません。

次に、Python環境でGPUの状態を取得するためのライブラリをインストールします。

pip install nvidia-ml-py pynvml

pynvmlは、PythonからGPUの温度、メモリ使用量、クロック周波数などを詳細に取得するためのライブラリです。 nvidia-smiの結果をパースするより高速で確実です。

⚠️ 落とし穴: WSL2上で動かしている場合、Windows側のNVIDIAコントロールパネルの設定が反映されないことがあります。その場合は環境変数で制御する必要がありますが、まずはWindowsネイティブ環境での設定を優先します。

Step 2: 基本の設定

NVIDIAコントロールパネルを開き、ドライバの挙動を「LLM特化」に変更します。

  1. デスクトップを右クリック ＞ 「NVIDIA コントロール パネル」を選択。
  2. 「3D 設定の管理」をクリック。
  3. 「プログラム設定」タブを選択し、Python（python.exe）または使用しているエディタ（Cursor等）を追加。
  4. 設定項目の中から 「CUDA - Sysmem Fallback Policy」 を探します。
  5. デフォルトの「Driver Default」から 「Prefer No Sysmem Fallback」 に変更します。
# 設定を確認するためのコードではないが、概念として以下の状態を目指す
# 従来: VRAM (高速) + System RAM (低速) = 合計メモリ
# 変更後: VRAM (高速) のみ使用。溢れたら即座に停止。

この設定にする理由は、共有メモリへの転送が発生するとPCIeバスがボトルネックになり、GPUの演算性能が全く活かせなくなるからです。 私が検証した際、RTX 4090でLlama-3を動かしたとき、共有メモリに1GB溢れただけで生成速度が45 token/sから2 token/sまで落ちました。 仕事で使うスクリプトなら、この速度低下は「故障」と同じ意味を持ちます。

Step 3: 動かしてみる

設定が反映されているか、実際にVRAMの限界まで負荷をかけるスクリプトでテストします。

import torch
import time
from pynvml import *

def check_gpu_status():
    nvmlInit()
    handle = nvmlDeviceGetHandleByIndex(0)
    info = nvmlDeviceGetMemoryInfo(handle)
    # バイトからGBに変換
    used = info.used / 1024**3
    total = info.total / 1024**3
    print(f"VRAM Used: {used:.2f} GB / {total:.2f} GB")
    nvmlShutdown()

def benchmark_vram_limit():
    print("VRAM負荷テストを開始します...")
    tensors = []
    try:
        # VRAMを少しずつ占有していく
        for i in range(100):
            # 約1GBのテンソルを作成
            new_tensor = torch.randn(256 * 1024, 1024, device='cuda', dtype=torch.float32)
            tensors.append(new_tensor)
            check_gpu_status()

            # 短いダミー演算で速度を計測
            start = time.perf_counter()
            _ = torch.matmul(new_tensor[:100, :100], new_tensor[:100, :100])
            torch.cuda.synchronize()
            end = time.perf_counter()
            print(f"演算時間: {(end - start) * 1000:.4f} ms")

    except RuntimeError as e:
        print(f"\n期待通りのエラーが発生しました: {e}")
        print("共有メモリに逃げずに、ちゃんと『メモリ不足』で停止しました。")

if __name__ == "__main__":
    if not torch.cuda.is_available():
        print("CUDAが利用できません。")
    else:
        benchmark_vram_limit()

期待される出力

VRAM Used: 22.50 GB / 23.99 GB
演算時間: 0.0450 ms
...
期待通りのエラーが発生しました: CUDA out of memory.
Tried to allocate 1.00 GiB...

この出力のように、VRAMを使い切った瞬間に「CUDA out of memory」で止まれば成功です。 もし設定が「Driver Default」のままだと、VRAMを超えてもエラーにならず、演算時間が突然10msや100msに跳ね上がりながら動き続けます。

Step 4: 実用レベルにする

実務では「エラーで止まる」だけでは困ります。 VRAMの空き状況を事前にチェックし、モデルのロード可否を判定するラッパー関数を作成しましょう。 これを使えば、バッチ処理中に予期せぬ速度低下でパイプラインが詰まるのを防げます。

import torch
from pynvml import *

class VRAMGuard:
    def __init__(self, device_id=0):
        nvmlInit()
        self.handle = nvmlDeviceGetHandleByIndex(device_id)

    def get_free_vram(self):
        info = nvmlDeviceGetMemoryInfo(self.handle)
        return info.free / 1024**3  # GB単位

    def can_load_model(self, model_size_gb, safety_margin=1.5):
        """
        モデルサイズに対して十分な空きがあるか判定
        safety_margin: KVキャッシュや一時的な演算用に上乗せするバッファ
        """
        free_now = self.get_free_vram()
        required = model_size_gb + safety_margin

        print(f"空きVRAM: {free_now:.2f} GB / 必要量(余裕込): {required:.2f} GB")
        return free_now > required

# 実務での使用例
guard = VRAMGuard()
MODEL_SIZE = 4.5  # Llama-3-8B 4-bitは約4.5GB

if guard.can_load_model(MODEL_SIZE):
    print("モデルをロードします...")
    # ここにAutoModelForCausalLM.from_pretrainedなどのロード処理を書く
else:
    print("警告: VRAM不足。量子化レベルを上げるか、別のGPUを選択してください。")

このスクリプトには「safety_margin」という概念を入れています。 初心者がよくやるミスは、VRAM 8GBのカードに7.5GBのモデルを載せようとすることです。 LLMはモデル本体だけでなく、入力テキストを保持する「KVキャッシュ」や、推論時の中間データでもVRAMを消費します。 経験上、モデルサイズの1.2倍〜1.5倍程度の空きがないと、長文を入力した瞬間に落ちます。

よくあるトラブルと解決法

エラー内容原因解決策
NVIDIA-SMI has failed...ドライバが正常に認識されていないドライバの再インストール（クリーンインストール推奨）。
CUDA out of memory設定通りVRAMを使い切ったモデルをGGUF形式で量子化するか、コンテキスト長（n_ctx）を短くする。
設定したのに速度が遅いGPUの温度上昇によるスロットリングGPU温度が85度を超えていないか確認。ケースのエアフロー改善が必要。

次のステップ

共有メモリ問題を解決したら、次は「量子化」の深い世界を覗いてみてください。 実務で特定のVRAM容量にモデルを押し込むには、GGUFやEXL2といった形式の理解が不可欠です。

  1. GGUFの使い分け: CPUへのオフロードが可能なため、VRAMが1GB足りない時でも「特定のレイヤーだけメインメモリに逃がす」という細かい調整ができます。
  2. Flash Attentionの導入: 推論時のメモリ消費を劇的に抑えつつ、速度を上げることができます。
  3. 複数GPUの並列化: RTX 4090を2枚持っているなら、device_map="auto"を使ってモデルを分割配置する方法を試してください。

ローカルLLMは、ハードウェアの限界を見極めながら「設定を詰め切る」過程が一番面白いところです。 まずは今回のドライバ設定で、自分自身の環境の「真の限界速度」を把握することから始めてください。

よくある質問

Q1: この設定をするとゲームのパフォーマンスに影響しますか？

基本的には影響ありません。ゲームもVRAMを超えるとテクスチャの読み込み待ちなどでカクつきますが、LLMほど極端な停止はしません。気になるなら、グローバル設定ではなく「python.exe」などの個別プログラム設定として適用してください。

Q2: ノートPCのGPUでも同じ設定をした方がいいですか？

はい、むしろノートPCの方が重要です。ノートPCは共有メモリを使いやすく設計されているため、気づかないうちに低速なメインメモリで推論が走っているケースが多いです。ただし、排熱には十分に注意してください。

Q3: Linux環境（Ubuntu等）でも同様の設定が必要ですか？

LinuxではデフォルトでWindowsのような自動フォールバックが強力に働かないため、設定不要なケースが多いです。基本的にはVRAMが切れれば即エラーになります。これが、ディープラーニングエンジニアがLinuxを好む理由の一つでもあります。