0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@plasmon

RTX 4060 8GBでQwen2.5-14Bを実用運用する — ngl・量子化・コンテキスト長の最適設定レシピ

0
Posted at

🧱 結論から言う: 8GBで14Bは「実用になる」

RTX 4060 (8GB VRAM) + Qwen2.5-14B Q4_K_M。この組み合わせは、2026年4月時点で実用レベルのローカルLLM環境として成立する。設定は -ngl 32 --flash-attn -c 4096。これだけ覚えて帰ってもらっても構わない。

「8GBじゃ14Bは無理」は2年前の常識だ。llama.cppのGPU/CPUハイブリッドオフロードが、この常識を過去のものにした。Ryzen 7 7845HS / 32GB RAM / RTX 4060環境で追試して確認している。

ただし「動く」と「実用になる」と「限界を把握している」は全然別の話だ。

この記事のテーゼ: 14Bモデルを8GBで"運用"するには、量子化・レイヤー配分・コンテキスト長の3変数を同時に最適化する必要がある。そのレシピと根拠をすべて書く。

以下、実際に手を動かして突き当たった壁と突破口を書いていく。理論だけの記事じゃない。「VRAM食い潰して落ちた」「ctx伸ばしたら急に遅くなった」という体験込みの話だ。

🔢 8GB VRAMの物理的限界を正確に理解する

まず前提を整理する。RTX 4060のVRAMは8GB。これは数字としては小さく見えるが、何に使われるかを分解すると、意外と使える余地がある。

LLMのVRAM消費は主に3つの成分で構成される:

成分 内容 典型的な割合
モデルウェイト 量子化後の重み 50〜70%
KVキャッシュ コンテキスト × ヘッド数 × レイヤー 20〜40%
ランタイムオーバーヘッド CUDA context, temp buffers 0.3〜0.8GB固定

Qwen2.5-14B をQ4_K_Mで量子化した場合、モデルウェイト自体は約8.7GBになる。8GBのVRAMには収まらない。ここが最初の壁だ。

しかしllama.cppの-ngl（n_gpu_layers）パラメータを使えば、モデルの一部レイヤーだけをGPUに乗せて残りをCPU RAMに置くことができる。Ryzen 7 7845HSの32GB RAMがここで効いてくる。CPUオフロード分はDDR5帯域になるためGPU推論より遅くなるが、「全部CPUで動かすよりは速い」という中間解として機能する。

# Qwen2.5-14B Q4_K_M, RTX 4060 (8GB) でのハイブリッド起動例
./llama-server \
  -m ./models/qwen2.5-14b-instruct-q4_k_m.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 32 \        # 全40レイヤーのうち32をGPUに、8をCPUへ
  -c 4096 \        # コンテキスト長: まず保守的に
  --n-predict 512 \
  -t 8 \           # CPU推論スレッド数 (7845HSの物理コア数)
  --flash-attn     # FlashAttention有効化でVRAM節約

-ngl 32という数字は試行錯誤の産物だ。-ngl 40（全GPUオフロード）を試みると、KVキャッシュ分のVRAMが確保できずにOOMで落ちる。-ngl 28まで下げると速度が顕著に落ちる。32がRTX 4060 × Qwen2.5-14B Q4_K_Mの現実的スイートスポットだ（この値はRAM量やKVキャッシュ設定にも依存するため、個人環境での再チューニングは必須）。

⚗️ 量子化の選択は「品質とVRAMの交換レート」で考える

量子化の種類を「精度が下がる」という一言で片付けるのは解像度が低すぎる。実際にはどの量子化が何を犠牲にしているかを理解しないと、間違った選択をする。

Q4_K_M  ≈ 4.83 bits/weight (重要レイヤーに高精度、それ以外は4bit)
Q5_K_M  ≈ 5.68 bits/weight
Q6_K    ≈ 6.57 bits/weight  
Q8_0    ≈ 8.50 bits/weight  ← ほぼ元モデルと同等の精度

Qwen2.5-14Bのファイルサイズ比較（公開データ参照）:

量子化 サイズ RTX 4060全積載 速度目安
Q8_0 ~14.7GB 不可 最速(精度最高)
Q6_K ~11.4GB 不可 高速
Q5_K_M ~9.8GB 不可(ギリギリ) 中高速
Q4_K_M ~8.7GB 不可(ハイブリッド必要) 中速
Q4_0 ~7.7GB 可(KVキャッシュ制限あり) 中速
IQ3_M ~6.0GB 可(余裕あり) 速いが品質低下大

正直に言う。Q4_Kシリーズ（_M/_S）とQ5_K_Mの間には品質の断絶がある。特にコード生成や論理推論タスクでは、Q4_0やIQ3系への劣化は体感できる。一方Q4_K_MとQ5_K_Mの差は、日常的な会話用途では見つけにくい。

RTX 4060で14Bクラスを動かすなら、Q4_K_M + -ngl調整のハイブリッドが現実解。Q4_0でVRAM全積載を狙うという選択肢もあるが、KVキャッシュに使えるVRAMがほとんど残らず、実質的に短文応答専用マシンになる。

⏱️ コンテキスト長の「崖」はどこにあるか

「llama.cppでCtx 32Kまで伸ばしてみたら激遅になった」——これは初見では意味がわからない現象だ。

KVキャッシュはコンテキスト長に比例してVRAMを食う。具体的には:

KVキャッシュ消費 ≈ 2 × n_layers × n_heads × head_dim × ctx_len × bytes_per_element

Qwen2.5-14Bの場合（48レイヤー、64ヘッド、128次元、FP16）:

コンテキスト長 KVキャッシュ概算
2,048 tokens ~0.8GB
4,096 tokens ~1.6GB
8,192 tokens ~3.2GB
16,384 tokens ~6.4GB ← RTX 4060では危険域
32,768 tokens ~12.8GB ← 不可能

つまりRTX 4060 + Q4_K_Mのハイブリッド構成では、GPUに乗せているレイヤーのKVキャッシュが4096〜8192が現実的な上限になる。--flash-attnフラグでKVキャッシュ消費を削減（理論的には最大50%近く）できるが、それでも16K以上は厳しい。

# コンテキスト長とスループットの関係を計測するスクリプト
import time
import requests

def measure_throughput(ctx_len: int, prompt_tokens: int = 500) -> dict:
    """llama-server に対して指定ctx長で速度計測"""
    payload = {
        "prompt": "A" * prompt_tokens,  # ダミープロンプト
        "n_predict": 100,
        "cache_prompt": False,
    }
    
    start = time.perf_counter()
    resp = requests.post(
        "http://localhost:8080/completion",
        json=payload,
        timeout=120
    )
    elapsed = time.perf_counter() - start
    
    data = resp.json()
    tokens_generated = data.get("tokens_predicted", 0)
    
    return {
        "ctx_len": ctx_len,
        "tokens_per_sec": tokens_generated / elapsed if elapsed > 0 else 0,
        "elapsed_sec": elapsed,
    }

# 実測するときのメモ: ctx_lenはllama-serverの起動パラメータ側で変える
# スクリプト側からは動的変更不可
results = []
for ctx in [2048, 4096, 8192]:
    r = measure_throughput(ctx)
    results.append(r)
    print(f"ctx={ctx}: {r['tokens_per_sec']:.1f} tok/s")

体感として、ctx 4096→8192への変化でスループットは20〜30%程度落ちる（KVキャッシュのメモリ帯域ボトルネックが支配的になるため）。これは公開ベンチマークとも概ね一致する傾向だ。

📡 Inference-Time Token Allocationという新視点

2026年4月に arXiv に上がった論文 "Understanding Inference-Time Token Allocation and Coverage" (2604.15657) は、ハードウェア検証という文脈でLLMのinference-time token消費を分析したものだが、Local LLM運用にも刺さる視点を提供している。

要約すると: LLMはタスクの複雑度に関係なく、ほぼ一定のトークン予算を「使い切ろうとする」傾向がある。シンプルな質問でも、n_predict上限まで生成しようとするケースがある。

これはLocal LLM運用における重大な非効率だ。RTX 4060のような制約ある環境では、無駄なトークン生成はスループットを直撃する。

対策として有効なのが--n-predictの動的制御と、grammarによる早期停止の組み合わせだ:

# タスク種別に応じてn_predictを変える制御層
PREDICT_BUDGET = {
    "code_completion": 256,    # コード補完: 短めでOK
    "summarization": 512,      # 要約: 中程度
    "reasoning": 1024,         # 推論: 長め
    "conversation": 384,       # 会話: 中程度
}

def call_llm(task_type: str, prompt: str) -> str:
    n_predict = PREDICT_BUDGET.get(task_type, 512)
    
    payload = {
        "prompt": prompt,
        "n_predict": n_predict,
        "stop": ["</s>", "<|im_end|>", "\n\nHuman:", "\n\n---"],
        "temperature": 0.7,
    }
    
    resp = requests.post("http://localhost:8080/completion", json=payload)
    return resp.json().get("content", "")

たった数行の制御層で、実効スループットが15〜20%改善することがある。n_predictの過剰確保は「保険」のつもりで設定されることが多いが、KVキャッシュ消費と推論時間の両方に影響するという認識が薄い。

⚡ M4 MacとRTX 4060の本当の差はどこか

筆者のサブ機はApple Silicon M4だ。この2台を並べると、アーキテクチャの思想の違いが如実に出る。

M4のUnified MemoryはモデルウェイトとKVキャッシュが同じメモリプールを使う。これは16GB構成なら16GB全てをLLMに使えることを意味する。RTX 4060の8GB VRAMとは実効帯域の議論が成立しない（比較対象が違いすぎる）。

比較軸 RTX 4060 (8GB VRAM) M4 (16GB Unified)
モデル収容 〜7B全積載 / 14B ハイブリッド 〜13Bクラス全積載
メモリ帯域 ~272 GB/s (GDDR6) ~120 GB/s
CPU-GPU転送コスト あり(PCIe帯域) なし(同一バス)
消費電力 GPU 115W + CPU SoC 28W程度
拡張性 VRAMは固定 UMも固定

帯域だけ見るとRTX 4060が圧倒的に有利なのだが、ハイブリッドオフロード時のPCIe転送コストがその優位性を削る。7Bクラスの全GPUオフロードではRTX 4060が速い。14Bのハイブリッドでは、条件によってはM4と大差ない、あるいは逆転するケースもある。

「RTX 4060ならWindowsゲーミングPCで追加コストなし」という現実を考えると、コスパの観点では依然としてRTX 4060の価値は高い。M4 Macは"LLM専用機"として買うには高すぎる。

🔭 2026年後半の予測: 8GB VRAMは「普及帯」になるか

ここからはエビデンスを起点にした個人的考察だ。

根拠①: NVIDIAがRTX PC向けにLocal LLM導入ガイドを積極的に出し始めている（2026年4月ニュース）。これはコンシューマGPUでのLLM実用が「ニッチな実験」から「想定ユースケース」に格上げされたシグナルだ。

根拠②: Groq LPUの登場（NVIDIA × Groq技術統合の動き）は、推論専用アーキテクチャのコモディティ化への圧力を示す。GPUがすべての推論を担う現行モデルは2〜3年スパンで揺らぐ可能性がある。

根拠③: llama.cpp自体の進化速度が異常に速い。2024年末にはなかったFlashAttentionのネイティブ統合、speculative decodingの安定化、GGUF形式の柔軟性向上。エコシステムとしての成熟度が急加速している。

この3点から私が考える2026年後半のシナリオ:

Q4_K_M の後継として IQ（i-quant）系の量子化が主流になり、8GB VRAMで20Bクラスのモデルが実用速度で動く時代が来る。

IQ4_XS、IQ3_M などのimportance matrix活用型量子化は、同ビット数のQ系より品質劣化が小さい。現時点ではまだ実験的な位置づけだが、これが安定したとき、「14Bで十分」だった限界が「20Bが普通」に変わる。

RTX 4060を今持っている人間にとって、これは1世代分の寿命延長を意味する。

🛠️ 実際に使えるセットアップ手順（Windowsネイティブ編）

llama.cppはWindowsネイティブビルドより、CUDA対応のビルド済みバイナリを使うほうが現実的だ:

# llama.cpp CUDA対応バイナリをGitHub Releasesから取得
# https://github.com/ggerganov/llama.cpp/releases
# "llama-b****-bin-win-cuda-cu12.x.x-x64.zip" を選択

# 展開後、Qwen2.5-14B Q4_K_Mをダウンロード
# HuggingFace: Qwen/Qwen2.5-14B-Instruct-GGUF

# 起動スクリプト (start_llm.ps1)
$env:CUDA_VISIBLE_DEVICES = "0"

.\llama-server.exe `
  -m ".\models\qwen2.5-14b-instruct-q4_k_m.gguf" `
  --host 127.0.0.1 `
  --port 8080 `
  -ngl 32 `
  -c 4096 `
  -t 8 `
  --flash-attn `
  --log-disable `
  -np 1

# OpenAI互換APIとして使う (llama-serverはv1/chat/completionsに対応)
from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:8080/v1",
    api_key="dummy",  # llama-serverはAPIキー不要
)

def chat(message: str, system: str = "You are a helpful assistant.") -> str:
    response = client.chat.completions.create(
        model="local-model",  # 任意の文字列でOK
        messages=[
            {"role": "system", "content": system},
            {"role": "user", "content": message},
        ],
        max_tokens=512,
        temperature=0.7,
    )
    return response.choices[0].message.content

# 実際に使ってみる
result = chat("Pythonで非同期HTTPクライアントを実装してください")
print(result)

OpenAI互換エンドポイントとして動かすと、ContinueやCursor、あるいは自作ツールとの統合が即座にできる。これがllama-serverを使う最大の理由だ。

📋 結論: 8GBは「制約」ではなく「定義」だ

RTX 4060で14Bクラスを動かすのは「無理やり」ではない。正確な設定と、自分のユースケースに合わせた量子化・コンテキスト長のチューニングがあれば、2026年時点のLocal LLM実用水準は明らかにクリアできる。

ただし「何も考えずに全部GPUに乗せれば最速」という時代は終わった。8GB VRAMの制約は、むしろ「何を優先するか」を考えさせてくれる設計的制約だと思っている。

やるべきアクション:

  1. llama-server --flash-attn を使っていないなら今すぐ追加する（KVキャッシュ削減効果は確実）
  2. -nglを「最大値」ではなく「OOMしない最大値」に設定する（この差は大きい）
  3. コンテキスト長をユースケース別に変えるラッパーを作る（4096で足りる用途に16384を確保するのは無駄）
  4. IQ系量子化（IQ4_XS等）を一度試してみる（Q4_K_Mより小さいファイルで同等品質を出せるケースがある）

8GBの壁は、工夫次第で意外と遠い。

📚 参考

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?