VRAMとは｜確認方法・必要量の目安とLLMの計算式をPythonで解説

データは SSD からメインメモリ（RAM）に読み込まれ、GPU が使う分だけ VRAM に送られます。GPU は手元の VRAM にあるデータを高速に読み書きして、画面や計算結果を作ります。

flowchart TD
    S[ストレージ SSD<br>ファイルの置き場] --> R[メインメモリ RAM<br>CPU が使う]
    R --> V[VRAM<br>GPU 専用のメモリ]
    V --> G[GPU のコア<br>描画・AI の計算]
    G --> O[画面・計算結果]

急いでいる人向けに、よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04・Python 3.11.15。LLM に必要な VRAM の計算は、Hugging Face の各モデルの config.json（Llama 3.1 8B・Llama 3.3 70B・Qwen3-8B・Qwen3-32B・Qwen3-30B-A3B）の値から Python で実行し、パラメーター数がモデルカードの表記と、重みの大きさが llama.cpp の量子化の表と一致することを確かめました。量子化でサイズが変わる様子は gguf 0.19.0（NumPy 2.4.6）で 4096×4096 の行列を実際に量子化して測り、VRAM を読む Python スクリプトは nvidia-ml-py 13.615.71 で実行しました（この環境に GPU は無いため、GPU が無いときのエラー原文を載せています）。エラー文は PyTorch（main、2.16.0a0）・llama.cpp・ComfyUI・Ollama のソース、確認方法と製品の仕様は Microsoft・NVIDIA・Apple・AMD（Linux カーネルのドキュメント）・Adobe・CD PROJEKT RED・Runpod の公式の情報で確かめました（確認日 2026年10月22日）。

VRAMとは（読み方・役割・GPUとの関係）

この節では、VRAM が何のためのメモリで、なぜ GPU の性能を左右するのかが分かります。

VRAM（ブイラム、Video Random Access Memory）は、GPU が計算に使うデータを置いておく、GPU 専用のメモリです。 「ビデオメモリ」「グラフィックスメモリ」「GPU メモリ」とも呼ばれます。グラフィックボード（グラボ）では、GPU のチップのすぐ近くに VRAM のチップが載っています。

GPU は、計算に使うデータが VRAM に入っているときに最も速く動きます。VRAM に入りきらないデータは、メインメモリ（RAM）から PCIe という通り道を通して少しずつ運ぶことになり、その間 GPU は待たされます。VRAM の容量は「GPU が一度に手元に置けるデータの量」の上限だと考えると分かりやすくなります。

VRAM に置かれる主なものです。

VRAMの容量と速さ（帯域）

VRAM には「容量（何GB）」と「帯域（1秒に何GB読み書きできるか）」の2つの数字があります。容量は入るかどうか、帯域は入ったときにどれだけ速いかを決めます。

NVIDIA の製品ページの値です（2026年10月22日時点）。GeForce は同じ世代でも、上位ほど容量が大きく、メモリの通り道（バス幅）も広くなっています。データセンター向けの H100 NVL は HBM3 という、GPU の横に積み重ねて載せる種類のメモリを使っています。

VRAMとメモリ（RAM）の違い

この節では、パソコンの「メモリ」と VRAM の違いと、なぜ両方の容量を見る必要があるのかが分かります。

DDR5-5600 の帯域は「1秒に5600百万回 × 1回8バイト × 2枚」で計算した値です。この例では、GPU が VRAM を読む速さは、CPU が RAM を読む速さの約20倍です。だから、データが VRAM に入りきるかどうかで速さが大きく変わります。

内蔵 GPU（CPU に入っている GPU）には専用の VRAM が無く、メインメモリの一部を使います。Apple シリコンの Mac は、CPU と GPU が同じメモリを共有する「ユニファイドメモリ」です（後の節で詳しく扱います）。

VRAMの確認方法（Windows・Mac・Linux・nvidia-smi）

この節では、自分の PC の VRAM の容量と、いま使っている量を調べる方法が OS ごとに分かります。

Windows：タスクマネージャー と dxdiag

Microsoft の DirectX のブログによると、専用 GPU メモリ（Dedicated memory）は GPU だけが使うために確保されたメモリ、共有 GPU メモリ（Shared memory）は CPU と GPU のどちらも使える普通のシステムメモリです。内蔵 GPU では、専用 GPU メモリは「グラフィックス用に確保されたシステムメモリの量」になります。

DirectX 診断ツールでも確かめられます。スタートの検索で dxdiag と入力して開き、「ディスプレイ」タブの「表示メモリ(VRAM)」が VRAM の容量です（モニターが複数あると「ディスプレイ1」「ディスプレイ2」のタブに分かれます）。

NVIDIA の GPU：nvidia-smi

NVIDIA の GPU は、ドライバーと一緒に入る nvidia-smi コマンドで、Windows でも Linux でも確かめられます。

# GPU ごとの容量・使用量・空き（MiB）
nvidia-smi --query-gpu=name,memory.total,memory.used,memory.free --format=csv

# 1秒ごとに使用量を記録する（Ctrl + C で止める）
nvidia-smi --query-gpu=timestamp,memory.used,memory.total --format=csv -l 1

# 引数なしで実行すると、表の形で GPU とプロセスごとの使用量が出る
nvidia-smi

NVIDIA のドキュメントでは、表の「FB Memory Usage」が GPU に載ったメモリ（フレームバッファ）の情報で、Total（合計）・Reserved（予約）・Used（使用中）・Free（空き）が並びます。下の「Processes」には、GPU を使っているプロセスごとの「GPU Memory Usage」が出ます。--query-gpu に指定できる項目は nvidia-smi --help-query-gpu で一覧できます。

Python で VRAM の空きを調べる

NVIDIA の公式の Python バインディング（nvidia-ml-py。import 名は pynvml）で、空きを数値で取れます。

import pynvml

try:
    pynvml.nvmlInit()
except pynvml.NVMLError as e:
    print(f"NVML を使えません: {type(e).__name__}: {e}")
    raise SystemExit(1)

print("ドライバー", pynvml.nvmlSystemGetDriverVersion())
for i in range(pynvml.nvmlDeviceGetCount()):
    h = pynvml.nvmlDeviceGetHandleByIndex(i)
    m = pynvml.nvmlDeviceGetMemoryInfo(h)
    print(f"GPU {i} {pynvml.nvmlDeviceGetName(h)}: 合計 {m.total/2**30:.1f} GiB  使用 {m.used/2**30:.1f} GiB  空き {m.free/2**30:.1f} GiB")
    for p in pynvml.nvmlDeviceGetComputeRunningProcesses(h):
        print(f"  PID {p.pid}: {(p.usedGpuMemory or 0)/2**20:.0f} MiB")
pynvml.nvmlShutdown()

GPU もドライバーも無い Linux（Ubuntu 24.04）で実行すると、次のように止まりました。NVIDIA のドライバーが入っていないと、このエラーになります。

NVML を使えません: NVMLError_LibraryNotFound: NVML Shared Library Not Found

同じ環境で nvidia-smi を実行すると、bash は bash: line 1: nvidia-smi: command not found（終了コード 127）を返しました。コマンドが無いときは、ドライバーが入っているか、GPU が認識されているかを先に確かめます。

PyTorch の中からは、torch.cuda.mem_get_info() で（空き, 合計）のバイト数、torch.cuda.memory_allocated() でテンソルが使っている量、torch.cuda.memory_reserved() で PyTorch が確保している量が分かります。PyTorch のドキュメントによると、PyTorch は一度確保したメモリを手放さずに使い回すので、使っていない分も nvidia-smi では「使用中」に見えます。

Mac：システムレポートとアクティビティモニタ

• Apple メニューの「このMacについて」から「システムレポート」を開き、「グラフィックス/ディスプレイ」を選びます。グラボを積んだ Mac は、ここに VRAM の容量が出ます。
• Apple シリコン（M1〜M5）の Mac には VRAM の欄がありません。 CPU と GPU がメインメモリを共有するので、「このMacについて」の「メモリ」の容量を GPU も使います。
• 使用中の様子は、アクティビティモニタの「ウインドウ」メニューにある「GPU の履歴」で見られます。

Linux：nvidia-smi・rocm-smi・sysfs

mem_info_vram_total と mem_info_vram_used は、Linux カーネルの amdgpu ドライバーのドキュメントにある sysfs のファイルで、バイト数を返します。card0 の番号は GPU の数や順番で変わります。

VRAMは何GB必要か（ゲーム・動画編集・画像生成AI・LLMの目安）

この節では、用途ごとにどれくらいの VRAM が要るのかを、メーカーやソフトの公式の数値を根拠に見積もれます。

ゲーム：解像度と設定で変わる

ゲームの VRAM は、解像度とグラフィック設定でいちばん大きく変わります。Cyberpunk 2077 のサポートページ（Update 2.0 以降）の動作環境を例にします。

同じゲームでも、設定しだいで必要な VRAM が 6GB から 16GB まで変わります。 何に使われているのかを、画面とテクスチャの大きさで計算しました。

MiB, GB = 2**20, 10**9
print("[A] 画面1枚（フレームバッファ）の大きさ  RGBA 8ビット = 1画素4バイト")
for name, (w, h) in {"フルHD": (1920, 1080), "WQHD": (2560, 1440), "4K": (3840, 2160)}.items():
    one = w * h * 4
    print(f"  {name:6} {w}×{h}  1枚 {one/MiB:5.1f} MiB  3枚(トリプルバッファ) {3*one/MiB:6.1f} MiB")

print("\n[B] テクスチャ1枚（4096×4096）の大きさ  ミップマップ込みは 4/3 倍")
px = 4096 * 4096
for name, bpp in {"RGBA 8ビット（無圧縮）": 32, "BC7（16バイト/4×4画素）": 8, "BC1（8バイト/4×4画素）": 4}.items():
    b = px * bpp / 8
    print(f"  {name:22} {b/MiB:5.1f} MiB  ミップマップ込み {b*4/3/MiB:5.1f} MiB  → 8GB に {int(8*GB // (b*4/3)):>4} 枚")

[A] 画面1枚（フレームバッファ）の大きさ  RGBA 8ビット = 1画素4バイト
  フルHD   1920×1080  1枚   7.9 MiB  3枚(トリプルバッファ)   23.7 MiB
  WQHD   2560×1440  1枚  14.1 MiB  3枚(トリプルバッファ)   42.2 MiB
  4K     3840×2160  1枚  31.6 MiB  3枚(トリプルバッファ)   94.9 MiB

[B] テクスチャ1枚（4096×4096）の大きさ  ミップマップ込みは 4/3 倍
  RGBA 8ビット（無圧縮）          64.0 MiB  ミップマップ込み  85.3 MiB  → 8GB に   89 枚
  BC7（16バイト/4×4画素）        16.0 MiB  ミップマップ込み  21.3 MiB  → 8GB に  357 枚
  BC1（8バイト/4×4画素）          8.0 MiB  ミップマップ込み  10.7 MiB  → 8GB に  715 枚

4K の画面そのものは3枚でも 94.9 MiB で、VRAM の大半を使うのはテクスチャです。 BC7・BC1 は GPU がそのまま読める圧縮形式で、Microsoft のドキュメントでは 4×4 画素のブロックあたり BC7 が16バイト、BC1 が8バイトです。ゲームの「テクスチャ品質」を1段下げると VRAM の使用量が大きく減るのは、このためです。ミップマップは遠くに見えるとき用の縮小版で、1/4・1/16…と足していくと元の 4/3 倍になります。

動画編集：解像度と GPU エフェクト

Adobe の Premiere（26.0）の必要システム構成は、Windows で「GPU メモリ 4GB 以上」が最低、推奨が「8GB の GPU メモリ」です。Mac は Apple シリコンで最低 8GB、推奨 16GB のユニファイドメモリです。4K・8K の素材や、GPU で処理するエフェクトを重ねるほど、作業用のフレームが VRAM に置かれて使用量が増えます。

画像生成AI：モデルの大きさで決まる

画像生成は、使うモデルの重みが VRAM に入るかで決まります。重みの大きさは「パラメーター数 × 1パラメーターのバイト数」です。FLUX.1 [dev] はモデルカードで「120億パラメーター」とされているので、計算すると次のとおりです。

[C] 画像生成モデルの重み（FLUX.1 [dev] 120億パラメーター）
  BF16   12e9 × 16 ÷ 8 = 24.0 GB
  FP8    12e9 ×  8 ÷ 8 = 12.0 GB
  4ビット   12e9 ×  4 ÷ 8 =  6.0 GB

本体だけで、16ビット（BF16）なら 24GB です。実際にはテキストを読むモデル（テキストエンコーダー）や画像に戻す部分（VAE）も使います。VRAM が足りないときは、FP8 や4ビットに量子化したモデルを使うか、使っていない部分を RAM に逃がす仕組み（Diffusers の enable_model_cpu_offload、ComfyUI の --lowvram など）を使います。ComfyUI のノードと起動オプションは、関連記事「ComfyUIとは｜インストール・使い方・Manager・APIを解説」で扱っています。

LLM：計算で出せる

LLM は、モデルの設定値から必要な VRAM をかなり正確に計算できます。Runpod のドキュメントは「10億パラメーターあたり約2GB」（7B なら約14GB、70B なら約140GB）を目安に挙げ、量子化で減らせると書いています。この「2GB」は16ビットの重みだけの値なので、次の節で、量子化と文脈の長さまで入れた式を作ります。

LLMに必要なVRAMの計算式（パラメーター数・量子化・コンテキスト長）

この節では、LLM の必要な VRAM を「重み・KV キャッシュ・作業領域」の3つに分けて計算する式が分かります。

flowchart TD
    W[重み<br>パラメーター数 × ビット数 ÷ 8] --> K[＋ KV キャッシュ<br>文脈の長さ × 会話数に比例]
    K --> X[＋ 作業領域<br>途中の値・CUDA の初期化]
    X --> T[＝ 必要な VRAM]

式を文字で書くと次のとおりです。

必要な VRAM ≈ 重み ＋ KV キャッシュ ＋ 作業領域

重み         = パラメーター数 × 1パラメーターあたりのビット数 ÷ 8
KV キャッシュ = 2（K と V）× 層の数 × KV ヘッドの数 × ヘッドの次元
               × 1要素のバイト数 × コンテキスト長 × 同時の会話数
作業領域     = 計算の途中の値・CUDA の初期化など（実装と設定で変わる）

式に入れる値の調べ方

値はすべて、モデルの配布ページにある config.json に書かれています。

Q のヘッドが 32 個あるのに KV のヘッドが 8 個なのは、GQA（Grouped Query Attention）という作りで、複数の Q のヘッドが1組の K・V を共有しているためです。 KV キャッシュは KV ヘッドの数に比例するので、GQA のおかげで4分の1に減っています（次の節で計算します）。

量子化のビット数

量子化（りょうしか）は、重みを少ないビット数で表して小さくすることです。llama.cpp の量子化ツールの README に、Llama 3.1 8B を量子化したときの「1重みあたりのビット数」と大きさの表があります。

Q4_K_M は「4ビット」と呼ばれますが、ブロックごとの倍率や、一部の層を高い精度で残す分があるので、1重みあたり 4.89 ビットです。「4ビットだから16ビットの1/4」ではなく、約0.31倍と見積もると実物に近くなります。

PythonでLLMのVRAMを計算する（5モデルの結果）

この節では、上の式を Python にしたスクリプトと、5つのモデルで計算した結果が分かります。自分のモデルで計算するときは、MODELS に config.json の値を足します。

"""LLM を動かすのに必要な VRAM を、パラメーター数・量子化・コンテキスト長から見積もる。
必要な VRAM ≈ 重み + KV キャッシュ + 作業領域
  重み        = パラメーター数 × 1パラメーターあたりのビット数 ÷ 8
  KVキャッシュ = 2(KとV) × 層の数 × KVヘッドの数 × ヘッドの次元 × 1要素のバイト数 × コンテキスト長 × 同時の会話数
"""
GB, GiB = 10**9, 2**30
BITS = {"BF16": 16.0, "Q8_0": 8.5008, "Q4_K_M": 4.8944}   # bit/重み（llama.cpp の量子化の表の値）
OVERHEAD_GB = 1.0                                           # 作業領域の仮の値（実際は起動ログで確かめる）

# config.json の値（層の数, hidden, 中間層, Qヘッド, KVヘッド, head_dim, 語彙, 埋め込みを共有するか, MoE(専門家の数, 使う数, 専門家の中間層)）
MODELS = {
    "Llama-3.1-8B":  dict(L=32, h=4096, ff=14336, qh=32, kvh=8, hd=128, V=128256, tie=False),
    "Qwen3-8B":      dict(L=36, h=4096, ff=12288, qh=32, kvh=8, hd=128, V=151936, tie=False, qknorm=True),
    "Qwen3-32B":     dict(L=64, h=5120, ff=25600, qh=64, kvh=8, hd=128, V=151936, tie=False, qknorm=True),
    "Llama-3.3-70B": dict(L=80, h=8192, ff=28672, qh=64, kvh=8, hd=128, V=128256, tie=False),
    "Qwen3-30B-A3B": dict(L=48, h=2048, ff=0, qh=32, kvh=4, hd=128, V=151936, tie=False, qknorm=True, moe=(128, 8, 768)),
}

def params(m, active=False):
    attn = m["h"] * m["qh"] * m["hd"] * 2 + m["h"] * m["kvh"] * m["hd"] * 2     # q,o と k,v
    norms = 2 * m["h"] + (2 * m["hd"] if m.get("qknorm") else 0)
    if "moe" in m:
        E, k, eff = m["moe"]
        ffn = (k if active else E) * 3 * m["h"] * eff + m["h"] * E               # 専門家 + ルーター
    else:
        ffn = 3 * m["h"] * m["ff"]                                              # gate, up, down
    emb = m["V"] * m["h"] * (1 if m["tie"] else 2)                             # 入力の埋め込み + 出力層
    return m["L"] * (attn + ffn + norms) + emb + m["h"]

def kv_bytes_per_token(m, elem_bytes=2):
    return 2 * m["L"] * m["kvh"] * m["hd"] * elem_bytes

def need_gb(m, bits, ctx, batch=1, kv_elem=2):
    w = params(m) * bits / 8
    kv = kv_bytes_per_token(m, kv_elem) * ctx * batch
    return w / GB, kv / GB, w / GB + kv / GB + OVERHEAD_GB

print("[1] config.json から数えたパラメーター数（公式の表記と比べる）")
for name, m in MODELS.items():
    extra = f"  うち1トークンで使う {params(m, True)/1e9:.2f}B" if "moe" in m else ""
    print(f"  {name:14} {params(m)/1e9:6.2f}B{extra}")

print("\n[2] Llama-3.1-8B の重みの大きさ（llama.cpp の表: BF16 14.96 / Q8_0 7.95 / Q4_K_M 4.58 GiB）")
m = MODELS["Llama-3.1-8B"]
for q, b in BITS.items():
    print(f"  {q:7} {params(m)*b/8/GiB:6.2f} GiB  = {params(m)*b/8/GB:6.2f} GB")

print("\n[3] 1トークンあたりの KV キャッシュ（16ビット）")
for name, m in MODELS.items():
    t = kv_bytes_per_token(m)
    print(f"  {name:14} {t:>9,} バイト ({t//1024} KiB)  4K: {t*4096/GB:5.2f} GB  32K: {t*32768/GB:5.2f} GB  128K: {t*131072/GB:6.2f} GB")
m = MODELS["Llama-3.1-8B"]
mha = dict(m, kvh=m["qh"])
print(f"  参考: Llama-3.1-8B を KV ヘッド32（GQA なし）にした場合 {kv_bytes_per_token(mha):,} バイト = 4倍")

print("\n[4] 必要な VRAM（GB）= 重み + KV(1会話) + 作業領域 1.0")
for name in ["Llama-3.1-8B", "Qwen3-8B", "Qwen3-30B-A3B", "Qwen3-32B", "Llama-3.3-70B"]:
    m = MODELS[name]
    for q in ["BF16", "Q8_0", "Q4_K_M"]:
        row = [need_gb(m, BITS[q], c)[2] for c in (4096, 32768, 131072)]
        print(f"  {name:14} {q:7} 4K {row[0]:6.1f}  32K {row[1]:6.1f}  128K {row[2]:6.1f}")

print("\n[5] VRAM ごとに入る最大のコンテキスト長（Q4_K_M・1会話・作業領域 1.0 GB）")
for name in ["Llama-3.1-8B", "Qwen3-8B", "Qwen3-30B-A3B", "Qwen3-32B", "Llama-3.3-70B"]:
    m = MODELS[name]
    w = params(m) * BITS["Q4_K_M"] / 8 / GB
    cells = []
    for vram in (8, 12, 16, 24, 32, 48):
        rest = vram - w - OVERHEAD_GB
        cells.append(f"{vram}GB {int(rest*GB // kv_bytes_per_token(m)):>7,}" if rest > 0 else f"{vram}GB      ×")
    print(f"  {name:14} 重み{w:5.1f}GB | " + " | ".join(cells))

print("\n[6] KV キャッシュを8ビット（q8_0 など）にすると（Qwen3-8B・Q4_K_M・32K）")
m = MODELS["Qwen3-8B"]
for label, eb in [("16ビット", 2), ("8ビット", 1), ("4ビット", 0.5)]:
    w, kv, tot = need_gb(m, BITS["Q4_K_M"], 32768, kv_elem=eb)
    print(f"  KV {label}: 重み {w:.2f} + KV {kv:.2f} + 1.0 = {tot:.2f} GB")

print("\n[7] 同時に複数の会話をさばくと（Qwen3-8B・BF16・8K）")
for b in (1, 4, 16):
    w, kv, tot = need_gb(m, BITS["BF16"], 8192, batch=b)
    print(f"  {b:2}会話: 重み {w:.2f} + KV {kv:.2f} + 1.0 = {tot:.2f} GB")

print("\n[8] 生成の速さの上限の目安 = メモリ帯域 ÷ 1トークンで読むバイト数（Q4_K_M・短い文脈）")
bw = {"DDR5-5600 2枚(計算値)": 89.6, "M5 (153GB/s)": 153, "M5 Max (614GB/s)": 614, "RTX PRO 6000 (1792GB/s)": 1792, "H100 SXM (3350GB/s)": 3350}
for name in ["Qwen3-8B", "Qwen3-30B-A3B", "Llama-3.3-70B"]:
    m = MODELS[name]
    read = params(m, active=True) * BITS["Q4_K_M"] / 8 / GB
    print(f"  {name}（1トークンで {read:.2f} GB 読む）")
    for k, v in bw.items():
        print(f"    {k:24} 毎秒 {v/read:5.0f} トークンが上限")

GPU の比較に使う値は、外れたときに足りなくならないよう、1GB ＝ 10億バイト（GB）で出しています。llama.cpp の表と比べるところだけ GiB（2の30乗バイト）も出しています。

計算が公式の値と合うか（パラメーター数と重みの大きさ）

[1] config.json から数えたパラメーター数（公式の表記と比べる）
  Llama-3.1-8B     8.03B
  Qwen3-8B         8.19B
  Qwen3-32B       32.76B
  Llama-3.3-70B   70.55B
  Qwen3-30B-A3B   30.53B  うち1トークンで使う 3.35B

[2] Llama-3.1-8B の重みの大きさ（llama.cpp の表: BF16 14.96 / Q8_0 7.95 / Q4_K_M 4.58 GiB）
  BF16     14.96 GiB  =  16.06 GB
  Q8_0      7.95 GiB  =   8.53 GB
  Q4_K_M    4.58 GiB  =   4.91 GB

config.json の値だけから数えたパラメーター数は、Qwen3-8B が 8.19B（モデルカードは 8.2B）、Qwen3-32B が 32.76B（同 32.8B）、Qwen3-30B-A3B が 30.53B・使う分 3.35B（同 30.5B・3.3B）で、公式の表記と一致しました。 重みの大きさも、llama.cpp の表の 14.96・7.95・4.58 GiB と小数第2位まで同じです。式がそのまま使えることが分かります。

KV キャッシュは文脈の長さで重みを超える

[3] 1トークンあたりの KV キャッシュ（16ビット）
  Llama-3.1-8B     131,072 バイト (128 KiB)  4K:  0.54 GB  32K:  4.29 GB  128K:  17.18 GB
  Qwen3-8B         147,456 バイト (144 KiB)  4K:  0.60 GB  32K:  4.83 GB  128K:  19.33 GB
  Qwen3-32B        262,144 バイト (256 KiB)  4K:  1.07 GB  32K:  8.59 GB  128K:  34.36 GB
  Llama-3.3-70B    327,680 バイト (320 KiB)  4K:  1.34 GB  32K: 10.74 GB  128K:  42.95 GB
  Qwen3-30B-A3B     98,304 バイト (96 KiB)  4K:  0.40 GB  32K:  3.22 GB  128K:  12.88 GB
  参考: Llama-3.1-8B を KV ヘッド32（GQA なし）にした場合 524,288 バイト = 4倍

Llama 3.1 8B で 128K トークンの文脈を使い切ると、KV キャッシュだけで 17.18GB になり、16ビットの重み（16.06GB）を超えます。 「モデルが入るのに、長い文章を入れるとメモリ不足になる」のはこのためです。

モデル・量子化・文脈ごとの必要な VRAM

[4] 必要な VRAM（GB）= 重み + KV(1会話) + 作業領域 1.0
  Llama-3.1-8B   BF16    4K   17.6  32K   21.4  128K   34.2
  Llama-3.1-8B   Q8_0    4K   10.1  32K   13.8  128K   26.7
  Llama-3.1-8B   Q4_K_M  4K    6.4  32K   10.2  128K   23.1
  Qwen3-8B       BF16    4K   18.0  32K   22.2  128K   36.7
  Qwen3-8B       Q8_0    4K   10.3  32K   14.5  128K   29.0
  Qwen3-8B       Q4_K_M  4K    6.6  32K   10.8  128K   25.3
  Qwen3-30B-A3B  BF16    4K   62.5  32K   65.3  128K   74.9
  Qwen3-30B-A3B  Q8_0    4K   33.8  32K   36.7  128K   46.3
  Qwen3-30B-A3B  Q4_K_M  4K   20.1  32K   22.9  128K   32.6
  Qwen3-32B      BF16    4K   67.6  32K   75.1  128K  100.9
  Qwen3-32B      Q8_0    4K   36.9  32K   44.4  128K   70.2
  Qwen3-32B      Q4_K_M  4K   22.1  32K   29.6  128K   55.4
  Llama-3.3-70B  BF16    4K  143.4  32K  152.8  128K  185.1
  Llama-3.3-70B  Q8_0    4K   77.3  32K   86.7  128K  118.9
  Llama-3.3-70B  Q4_K_M  4K   45.5  32K   54.9  128K   87.1

読み取れることです。

• 8B のモデルは、4ビット（Q4_K_M）・4K トークンなら約6.6GB で、8GB の GPU に入る計算です。 同じモデルを16ビットのまま使うと 17.6〜18.0GB で、24GB の GPU が要ります。
• Qwen3-30B-A3B は「1トークンで使うのは 3.3B」でも、VRAM は 30.5B 分が要ります。 MoE（専門家を切り替える作り）は、使わない専門家の重みも VRAM に置いておく必要があるためです。速さは小さいモデル並み、VRAM は大きいモデル並み、という性質です。
• 70B は4ビットでも 45GB 以上で、24GB の GPU 1枚には入りません。 48GB の GPU か、24GB を2枚以上に分けて載せる構成になります。

VRAM ごとに入る文脈の長さ

[5] VRAM ごとに入る最大のコンテキスト長（Q4_K_M・1会話・作業領域 1.0 GB）
  Llama-3.1-8B   重み  4.9GB | 8GB  15,923 | 12GB  46,440 | 16GB  76,958 | 24GB 137,993 | 32GB 199,028 | 48GB 321,098
  Qwen3-8B       重み  5.0GB | 8GB  13,488 | 12GB  40,614 | 16GB  67,741 | 24GB 121,995 | 32GB 176,248 | 48GB 284,755
  Qwen3-30B-A3B  重み 18.7GB | 8GB      × | 12GB      × | 16GB      × | 24GB  43,949 | 32GB 125,330 | 48GB 288,090
  Qwen3-32B      重み 20.0GB | 8GB      × | 12GB      × | 16GB      × | 24GB  11,276 | 32GB  41,794 | 48GB 102,829
  Llama-3.3-70B  重み 43.2GB | 8GB      × | 12GB      × | 16GB      × | 24GB      × | 32GB      × | 48GB  11,704

8GB の GPU で Qwen3-8B（4ビット）を使うと、計算上は約1.3万トークンまでです。Windows ではデスクトップの表示にも VRAM を使うので、実際に使える量はさらに少なくなります。Ollama のドキュメントでは、何も指定しないときのコンテキスト長を VRAM で変えていて、24GiB 未満は 4k、24〜48GiB は 32k、48GiB 以上は 256k です。

KV キャッシュの量子化と、同時の会話数

[6] KV キャッシュを8ビット（q8_0 など）にすると（Qwen3-8B・Q4_K_M・32K）
  KV 16ビット: 重み 5.01 + KV 4.83 + 1.0 = 10.84 GB
  KV 8ビット: 重み 5.01 + KV 2.42 + 1.0 = 8.43 GB
  KV 4ビット: 重み 5.01 + KV 1.21 + 1.0 = 7.22 GB

[7] 同時に複数の会話をさばくと（Qwen3-8B・BF16・8K）
   1会話: 重み 16.38 + KV 1.21 + 1.0 = 18.59 GB
   4会話: 重み 16.38 + KV 4.83 + 1.0 = 22.21 GB
  16会話: 重み 16.38 + KV 19.33 + 1.0 = 36.71 GB

KV キャッシュも量子化できます。Ollama のドキュメントでは、環境変数 OLLAMA_KV_CACHE_TYPE に q8_0（f16 の約1/2、精度の低下はとても小さい）や q4_0（約1/4）を指定でき、既定は f16 です。Flash Attention が有効なときに使えます。

サーバーとして何人もの依頼を同時にさばくと、KV キャッシュは会話の数だけ増えます。 Ollama のドキュメントにも「2K のコンテキストで並列4件なら 8K 分のメモリ」とあります。vLLM はこの KV キャッシュを細かい区画（ブロック）で管理して無駄を減らしています。vLLM の --max-model-len や --gpu-memory-utilization との関係は、関連記事「vLLMとは｜使い方・インストール・OpenAI互換APIとOllamaとの違い」で扱っています。

VRAM の帯域で、生成の速さの上限が決まる

[8] 生成の速さの上限の目安 = メモリ帯域 ÷ 1トークンで読むバイト数（Q4_K_M・短い文脈）
  Qwen3-8B（1トークンで 5.01 GB 読む）
    DDR5-5600 2枚(計算値)        毎秒    18 トークンが上限
    M5 (153GB/s)             毎秒    31 トークンが上限
    M5 Max (614GB/s)         毎秒   123 トークンが上限
    RTX PRO 6000 (1792GB/s)  毎秒   358 トークンが上限
    H100 SXM (3350GB/s)      毎秒   669 トークンが上限
  Qwen3-30B-A3B（1トークンで 2.05 GB 読む）
    DDR5-5600 2枚(計算値)        毎秒    44 トークンが上限
    M5 (153GB/s)             毎秒    75 トークンが上限
    M5 Max (614GB/s)         毎秒   299 トークンが上限
    RTX PRO 6000 (1792GB/s)  毎秒   874 トークンが上限
    H100 SXM (3350GB/s)      毎秒  1633 トークンが上限
  Llama-3.3-70B（1トークンで 43.16 GB 読む）
    DDR5-5600 2枚(計算値)        毎秒     2 トークンが上限
    M5 (153GB/s)             毎秒     4 トークンが上限
    M5 Max (614GB/s)         毎秒    14 トークンが上限
    RTX PRO 6000 (1792GB/s)  毎秒    42 トークンが上限
    H100 SXM (3350GB/s)      毎秒    78 トークンが上限

LLM は1トークン作るたびに、使う重みを全部メモリから読みます。そのため、1人分の生成の速さは、計算の速さよりもメモリの帯域で頭打ちになりやすいです。上の数字は「帯域を100%使えた場合の上限」で、実際の速さはこれより下になります。それでも、VRAM（数百〜数千GB/s）に入るかどうかで、RAM（このメモリ構成で 89.6GB/s）の何倍も速さが変わることが分かります。MoE の Qwen3-30B-A3B は、1トークンで読む量が 2.05GB と少ないので、VRAM さえ足りれば速く動きます。

量子化でVRAMが減る仕組み（GGUFで実測）

この節では、量子化で重みが本当に小さくなること、その代わりに誤差が増えることを、実際に量子化した数値で確かめられます。

llama.cpp の Python パッケージ gguf（0.19.0）で、平均0・標準偏差0.02 の乱数で作った 4096×4096 の重み行列（約1,678万個）を量子化しました。

import os, time, importlib.metadata as md, numpy as np
from gguf import quants, GGUFWriter, GGUFReader, GGMLQuantizationType as T

rng = np.random.default_rng(0)
W = rng.normal(0, 0.02, size=(4096, 4096)).astype(np.float32)   # 4096×4096 の重み行列 1枚
n = W.size
print(f"gguf {md.version('gguf')}  numpy {np.__version__}  重みの数 {n:,}")
for name, qt in [("F32", T.F32), ("F16", T.F16), ("BF16", T.BF16), ("Q8_0", T.Q8_0), ("Q5_0", T.Q5_0), ("Q4_0", T.Q4_0)]:
    q = quants.quantize(W, qt)
    back = quants.dequantize(q, qt).reshape(W.shape)
    rmse = float(np.sqrt(np.mean((back - W) ** 2)))
    print(f"{name:5} {q.nbytes/2**20:6.2f} MiB  {q.nbytes*8/n:6.3f} bit/重み  誤差(RMSE) {rmse:.6f}")

# 同じ行列を F16 と Q4_0 で GGUF ファイルに書き、ファイルの大きさを比べる
for name, qt in [("F16", T.F16), ("Q4_0", T.Q4_0)]:
    path = f"w_{name}.gguf"
    w = GGUFWriter(path, "llama")
    w.add_tensor("blk.0.attn_q.weight", quants.quantize(W, qt), raw_dtype=qt)
    w.write_header_to_file(); w.write_kv_data_to_file(); w.write_tensors_to_file(); w.close()
    r = GGUFReader(path)
    t = r.tensors[0]
    print(f"{path}: ファイル {os.path.getsize(path):,} バイト  テンソル {t.name} 形 {[int(x) for x in t.shape]} 型 {t.tensor_type.name} {t.n_bytes:,} バイト")

gguf 0.19.0  numpy 2.4.6  重みの数 16,777,216
F32    64.00 MiB  32.000 bit/重み  誤差(RMSE) 0.000000
F16    32.00 MiB  16.000 bit/重み  誤差(RMSE) 0.000004
BF16   32.00 MiB  16.000 bit/重み  誤差(RMSE) 0.000033
Q8_0   17.00 MiB   8.500 bit/重み  誤差(RMSE) 0.000107
Q5_0   11.00 MiB   5.500 bit/重み  誤差(RMSE) 0.000853
Q4_0    9.00 MiB   4.500 bit/重み  誤差(RMSE) 0.001718
w_F16.gguf: ファイル 33,554,560 バイト  テンソル blk.0.attn_q.weight 形 [4096, 4096] 型 F16 33,554,432 バイト
w_Q4_0.gguf: ファイル 9,437,312 バイト  テンソル blk.0.attn_q.weight 形 [4096, 4096] 型 Q4_0 9,437,184 バイト

Q8_0 は 8.5 ビット、Q4_0 は 4.5 ビットになりました。 32個の重みを1つのブロックにまとめ、ブロックごとに16ビットの倍率（2バイト）を1つ持つので、Q8_0 は (32 + 2) × 8 ÷ 32 = 8.5 ビット、Q4_0 は (16 + 2) × 8 ÷ 32 = 4.5 ビットです。ファイルに書いた大きさも、F16 の 33.5MB に対して Q4_0 は 9.4MB で、約0.28倍でした。

一方で、元の値との誤差（RMSE）は、Q8_0 の 0.000107 から Q4_0 の 0.001718 へと16倍になりました。ビット数を減らすほど VRAM は減りますが、答えの質が下がる可能性も増えます。 4ビット付近（Q4_K_M など）がよく使われるのは、大きさと精度の釣り合いがとれているためです。gguf の Python パッケージは K 量子化（Q4_K など）の変換には対応しておらず、NotImplementedError になりました。K 量子化は llama.cpp の llama-quantize で作ります。

VRAMが足りないときに起きること（エラー原文）

この節では、VRAM が足りなくなったときに出るエラーの原文と、エラーにならずに遅くなる場合の見分け方が分かります。

VRAM が足りないときの動きは、ソフトによって「エラーで止まる」「一部を RAM に置いて遅くなる」の2つに分かれます。

flowchart TD
    A[VRAM に入りきらない] --> B{ソフトの動き}
    B -->|止める| C[エラーで止まる<br>CUDA out of memory]
    B -->|逃がす| D[一部を RAM に置く]
    D --> E[動くが遅くなる<br>数分の1以下になることも]

エラーの原文と直し方

原文は各ソフトのソースのメッセージの書き方そのままで、数値の部分（〈 〉）は状況によって変わります。

PyTorch の OOM のメッセージは、c10/cuda/CUDACachingAllocator.cpp で組み立てられ、最後に「Memory Management」のドキュメントへのリンクが付きます。ComfyUI は、このエラーを受けると「Got an OOM, unloading all loaded models.」とログに出し、読み込んでいたモデルをいったん下ろします。vLLM の起動時のメモリのエラー（No available memory for the cache blocks など）の原文と直し方は、関連記事「vLLMとは｜使い方・インストール・OpenAI互換APIとOllamaとの違い」で扱っています。

エラーにならずに遅くなる場合

Windows の NVIDIA のドライバー（536.40 以降）は、VRAM を使い切ると共有メモリ（RAM）を使って処理を続けます。 NVIDIA のサポートページ「System Memory Fallback for Stable Diffusion」によると、6GB の GPU で Stable Diffusion を使うとこの仕組みが働き、速度が落ちることがあります。546.01 以降のドライバーでは、NVIDIA コントロールパネルの「3D 設定の管理」→「プログラム設定」で対象の python.exe を選び、「CUDA - Sysmem Fallback Policy」を「Prefer No Sysmem Fallback」にすると切れます（その場合、足りないとエラーで止まります）。

Ollama は、モデルが VRAM に入りきらないと一部を CPU とメインメモリで動かします。Ollama のドキュメントでは、ollama ps の PROCESSOR の列が 100% GPU なら全部 GPU、100% CPU なら全部メインメモリ、48%/52% CPU/GPU なら両方に分かれています。急に遅くなったら、まず PROCESSOR が 100% GPU かを見ます。 コマンドの使い方は、関連記事「Ollamaの使い方｜ローカルLLMのコマンド一覧とAPIの呼び方」で扱っています。

ゲームでは、VRAM があふれるとテクスチャを RAM から運ぶことになり、画面の一瞬の止まり（カクつき）や、テクスチャがぼやけたまま表示される形で表れることがあります。

VRAM不足の対策（効く順）

この節では、VRAM が足りないときに、どこから手を付けると効きやすいかが分かります。

• 1ほかに VRAM を使っているプロセスを止めるnvidia-smi の Processes やタスクマネージャーの「詳細」で、前に起動した Python・ブラウザ・配信ソフトを探す
• 2LLM は文脈（コンテキスト長）を短くするQwen3-8B では 32K → 4K で KV キャッシュが 4.83GB → 0.60GB
• 3量子化したモデルを使う8B モデルで 16ビット 16.06GB → Q4_K_M 4.91GB
• 4KV キャッシュを量子化するOllama の OLLAMA_KV_CACHE_TYPE=q8_0、vLLM の --kv-cache-dtype fp8 など
• 5バッチ数・解像度・同時の会話数を減らす画像生成はバッチ数と解像度、サーバーは同時の会話数がそのまま VRAM に効く
• 6一部を RAM に逃がす（遅くなる）llama.cpp の -ngl、ComfyUI の --lowvram、Diffusers の enable_model_cpu_offload
• 7ゲームはテクスチャ品質と解像度を下げるVRAM の多くはテクスチャ。4096×4096 の無圧縮1枚は 85.3 MiB
• 8VRAM の大きい GPU を使う買い替えか、時間単位で借りるクラウドの GPU

PyTorch では、学習中のメモリを減らす方法として、混合精度（16ビットで計算する）、勾配チェックポイント（途中の値を捨てて計算し直す）、小さいバッチで勾配を貯める方法がよく使われます。torch.cuda.empty_cache() は使っていないキャッシュを手放すだけで、テンソルが使っている分は減らないと PyTorch のドキュメントに書かれています。

手元の GPU で足りないときは、VRAM の大きい GPU を時間単位で借りる方法もあります。GPU ごとの VRAM と時間単価は、関連記事「RunPodとは｜使い方・料金・PodsとServerlessの違いを実例で」で扱っています。ブラウザから GPU を使うなら、関連記事「Google Colabとは｜使い方・GPU・料金・制限とエラーの直し方」で扱っています。

共有GPUメモリと統合メモリ（Appleシリコン）

この節では、タスクマネージャーの「共有 GPU メモリ」と、Mac の「ユニファイドメモリ」が VRAM とどう違うのかが分かります。

共有 GPU メモリは VRAM に足し算できない

Windows のタスクマネージャーには「GPU メモリ ＝ 専用 GPU メモリ ＋ 共有 GPU メモリ」が表示されます。たとえば専用 8GB・共有 16GB なら「GPU メモリ 24GB」と出ますが、VRAM が 24GB あるわけではありません。

• 共有 GPU メモリは、GPU が必要に応じて借りるメインメモリです。Microsoft の DirectX のブログによると、Windows には「GPU が同時に使えるのは物理メモリの半分まで」という決まりがあり、16GB の PC なら 8GB までです。
• 共有メモリのデータは、GPU から見ると PCIe の先にあり、VRAM より何倍も遅くなります。グラボを積んだ PC で共有 GPU メモリの使用量が増えているときは、VRAM があふれている合図です。
• 内蔵 GPU は、もともと専用の VRAM が無く、共有メモリが主な置き場所です。機種によっては BIOS/UEFI の設定で、グラフィックス用に確保する量（専用 GPU メモリ）を変えられます。

Apple シリコンのユニファイドメモリ

Apple は M1 の発表で、ユニファイドメモリアーキテクチャを「高帯域幅を持つ低遅延のメモリを1つのプールに収めた」ものと説明しています。グラボの VRAM では入らない大きなモデルも、メモリの多い Mac なら1台に載せられるのが特徴です。2026年10月22日時点の Apple の仕様ページでは、MacBook Pro は M5 で 16〜32GB、M5 Max で 36〜128GB、Mac Studio は M5 Ultra で最大 512GB（帯域 1.2TB/s）を選べます。

ただし、メモリ全部を GPU が使えるわけではありません。OS やアプリもこのメモリを使い、Metal には recommendedMaxWorkingSetSize（性能を落とさずに GPU が確保できる量の目安）という値があります。計算式で見積もるときは、メモリの容量から OS とアプリの分を引いて考えます。帯域は同じ価格帯のグラボの VRAM より小さいことが多いので、前の節の計算のとおり、生成の速さの上限はチップの帯域で決まります。

VRAMの容量で選ぶ（判断表）

この節では、やりたいことから、VRAM が何GB の GPU を選べばよいかを判断できます。

迷ったら「いちばん重い用途の数字に、1〜2割の余裕を足した容量」で選びます。 VRAM は後から増やせないので、使い方が広がりそうなら一段上の容量を選ぶと、買い替えまでの期間が延びます。

よくある質問

Q. VRAMの読み方は？ A. 「ブイラム」と読みます。Video Random Access Memory の略で、ビデオメモリ・グラフィックスメモリ・GPU メモリとも呼ばれます。

Q. VRAMとメモリ（RAM）の違いは？ A. RAM は CPU が使うメインメモリ、VRAM は GPU が使う専用のメモリです。RAM を増やしても VRAM は増えず、GPU が速く使える量は VRAM の容量までです。

Q. VRAMはどうやって確認しますか？ A. Windows はタスクマネージャーの「パフォーマンス」→「GPU」の「専用 GPU メモリ」か、dxdiag の「表示メモリ(VRAM)」です。NVIDIA の GPU は nvidia-smi、Mac はシステムレポートの「グラフィックス/ディスプレイ」で確かめます。

Q. VRAMは何GBあればいいですか？ A. フルHD のゲームなら 8GB、4K や重い設定なら 12〜16GB、画像生成は 16〜24GB が目安です。LLM はモデルの大きさ・量子化・文脈の長さで決まり、8B の4ビットなら約6.6GB（4K トークン）です。

Q. VRAMは8GBでも使えますか？ A. フルHD のゲーム、8B までの LLM の4ビット版、SDXL の画像生成は、8GB でも動く計算・公式の目安です。4K のゲームの最高設定、FLUX.1 [dev] の16ビット、30B 以上の LLM には足りません。

Q. VRAMは増やせますか？ A. グラフィックボードの VRAM はチップがはんだ付けされているので増やせません。増やすには GPU を替えます。内蔵 GPU は、機種によっては BIOS/UEFI でグラフィックス用に確保する量を変えられますが、メインメモリを分けて使うだけです。

Q. 共有GPUメモリはVRAMとして足し算できますか？ A. できません。共有 GPU メモリは GPU が借りるメインメモリで、VRAM より何倍も遅く、Windows では物理メモリの半分までです。専用 8GB・共有 16GB でも、VRAM は 8GB です。

Q. 7B・8BのLLMに必要なVRAMは？ A. 16ビットなら重みだけで約14〜16GB、4ビット（Q4_K_M）なら約5GB です。文脈の KV キャッシュと作業領域を足すと、8B の4ビットで 4K トークンなら約6.6GB、32K なら約10.8GB になりました。

Q. 画像生成AIに必要なVRAMは？ A. Runpod のドキュメントは SDXL・Flux で 16〜24GB（SDXL は最低約8GB）を目安にしています。FLUX.1 [dev] は本体だけで BF16 24GB、FP8 で 12GB です。ComfyUI は 4GB の VRAM と 8GB の RAM でも動かせると README に書いています。

Q. MacのVRAMはどれくらいですか？ A. Apple シリコンの Mac には専用の VRAM が無く、CPU と GPU がユニファイドメモリを共有します。メモリの容量の大部分を GPU が使えますが、OS とアプリの分を引いて考えます。

Q. VRAMの使用率がいつも100%近いのは問題ですか？ A. 必ずしも問題ではありません。PyTorch は使い終わったメモリも手放さずに確保しておくので、nvidia-smi では使用中に見えます。ゲームも空いている VRAM をキャッシュに使います。遅くなったりエラーが出たりしなければ、満杯の表示だけでは不具合とは言えません。

Q. GDDR6とGDDR7の違いは？ A. どちらもグラフィックボード用のメモリの規格で、GDDR7 が新しい世代です。GeForce RTX 50 シリーズでは、RTX 5050 が GDDR6、RTX 5060 以上が GDDR7 です。データセンター向けの GPU には HBM という種類が使われています。

まとめ

• VRAM は GPU 専用のメモリ。容量で「入るかどうか」、帯域で「入ったときの速さ」が決まる。
• RAM と VRAM は別物で、足し算できない。共有 GPU メモリも VRAM ではない。
• 確認は、Windows はタスクマネージャーの「専用 GPU メモリ」と dxdiag、NVIDIA は nvidia-smi、Mac はシステムレポート。
• ゲームは解像度と設定で 6〜16GB（Cyberpunk 2077 の公式要件）。VRAM の多くはテクスチャが使う。
• LLM の必要量 ≈ 重み（パラメーター数 × ビット数 ÷ 8）＋ KV キャッシュ（文脈の長さに比例）＋ 作業領域。config.json から計算した値は公式の表記と一致した。
• 8B の4ビットは 4K トークンで約6.6GB、70B の4ビットは 45GB 以上。MoE は全部の専門家分の VRAM が要る。
• 足りないと、PyTorch などは CUDA out of memory で止まり、Ollama や Windows のドライバーは RAM に逃がして遅くなる。

参考・出典

確認日はいずれも 2026年10月22日です。

• Microsoft DirectX Developer Blog「GPUs in the Task Manager」：https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/
• Microsoft Learn「Texture Block Compression in Direct3D 11」：https://learn.microsoft.com/en-us/windows/win32/direct3d11/texture-block-compression-in-direct3d-11
• CLIP STUDIO PAINT サポート「GPUやVRAMの情報を確認するには（Windows）」：https://support.clip-studio.com/ja-jp/faq/articles/20250018
• NVIDIA「nvidia-smi documentation」：https://docs.nvidia.com/deploy/nvidia-smi/index.html
• NVIDIA「Compare GeForce Graphics Cards」：https://www.nvidia.com/en-us/geforce/graphics-cards/compare/
• NVIDIA「RTX PRO 6000 Blackwell」：https://www.nvidia.com/en-us/products/workstations/professional-desktop-gpus/rtx-pro-6000/
• NVIDIA「H100 Tensor Core GPU」：https://www.nvidia.com/en-us/data-center/h100/
• NVIDIA サポート「System Memory Fallback for Stable Diffusion」：https://nvidia.custhelp.com/app/answers/detail/a_id/5490
• PyTorch「CUDA semantics」（2.14）：https://docs.pytorch.org/docs/2.14/notes/cuda.html
• PyTorch ソース「c10/cuda/CUDACachingAllocator.cpp」：https://github.com/pytorch/pytorch/blob/main/c10/cuda/CUDACachingAllocator.cpp
• llama.cpp「tools/quantize/README.md」：https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
• llama.cpp ソース「ggml/src/ggml-cuda/ggml-cuda.cu」：https://github.com/ggml-org/llama.cpp/blob/master/ggml/src/ggml-cuda/ggml-cuda.cu
• Ollama Docs「Context length」：https://docs.ollama.com/context-length
• Ollama Docs「FAQ」：https://docs.ollama.com/faq
• ComfyUI ソース「execution.py」：https://github.com/comfyanonymous/ComfyUI/blob/master/execution.py
• Hugging Face Transformers「Optimizing LLMs for Speed and Memory」：https://huggingface.co/docs/transformers/llm_tutorial_optimization
• Hugging Face「meta-llama/Llama-3.1-8B」系の config.json（unsloth/Llama-3.1-8B-Instruct）：https://huggingface.co/unsloth/Llama-3.1-8B-Instruct/blob/main/config.json
• Hugging Face「Qwen/Qwen3-8B」：https://huggingface.co/Qwen/Qwen3-8B
• Hugging Face「Qwen/Qwen3-32B」：https://huggingface.co/Qwen/Qwen3-32B
• Hugging Face「Qwen/Qwen3-30B-A3B」：https://huggingface.co/Qwen/Qwen3-30B-A3B
• Hugging Face「unsloth/Llama-3.3-70B-Instruct」config.json：https://huggingface.co/unsloth/Llama-3.3-70B-Instruct/blob/main/config.json
• Hugging Face「black-forest-labs/FLUX.1-dev」：https://huggingface.co/black-forest-labs/FLUX.1-dev
• Runpod Docs「Choose a Pod」：https://docs.runpod.io/pods/choose-a-pod
• CD PROJEKT RED サポート「Cyberpunk 2077 — System Requirements」：https://support.cdprojektred.com/en/cyberpunk/pc/sp-technical/issue/1556/cyberpunk-2077-system-requirements
• Adobe「Adobe Premiere technical requirements」：https://helpx.adobe.com/premiere-pro/system-requirements.html
• Apple「MacBook Pro - 技術仕様」：https://www.apple.com/jp/macbook-pro/specs/
• Apple「Mac Studio - 技術仕様」：https://www.apple.com/jp/mac-studio/specs/
• Apple Newsroom「Apple、M1チップを発表」：https://www.apple.com/jp/newsroom/2020/11/apple-unleashes-m1/
• Apple Developer「recommendedMaxWorkingSetSize」：https://developer.apple.com/documentation/metal/mtldevice/recommendedmaxworkingsetsize
• The Linux Kernel documentation「amdgpu: Misc AMDGPU driver information」：https://docs.kernel.org/gpu/amdgpu/driver-misc.html
• ROCm「rocm_smi_lib（rocm_smi.py）」：https://github.com/ROCm/rocm_smi_lib

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。