ローカルLLM 推論を速くする llama.cpp / Ollama チューニング設定ガイド 2026年版：n-gpu-layers・KVキャッシュ量子化・flash attention で tok/sec を引き上げる

本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細はプライバシーポリシーをご覧ください。

ローカルLLM チューニング設定ガイド 2026:n-gpu-layers / KVキャッシュ量子化 / flash attention で tok/sec を上げる

結論:tok/sec が出ない時、買い替える前に設定を見直すと体感速度が大きく変わります。優先順位は (1) モデル全層を GPU に載せる(-ngl 99)→ (2) flash attention を有効化 → (3) KVキャッシュを q8_0 に量子化、の3点。特に「GPU に載りきっていない(一部CPUオフロード)」状態が最大の速度低下要因で、ここを解消するだけで数倍変わることがあります。設定で埋められるのは『そのGPUのメモリ帯域が決める上限』まで、という天井も併せて押さえておきましょう。

「同じGPUなのに、人のベンチより自分の tok/sec が出ない」。ローカルLLMでよくある状況です。原因の多くはハードウェアではなく設定で、n-gpu-layers のオフロード量、KVキャッシュの精度、flash attention の有無、コンテキスト長やバッチの取り方を整えるだけで体感が変わります。本記事は llama.cpp と Ollama の具体的なフラグ・環境変数で、同じGPUのまま tok/sec を引き上げる手順を整理します。数値の上限がどこで決まるか(=帯域)はメモリ帯域とtok/sec の関係を前提にしているので、併せて読むと「設定でどこまで詰められるか」が見えます。

まず切り分け:遅いのは「設定」か「ハードの上限」か

チューニングに入る前に、ボトルネックを切り分けます。

症状	疑う場所	対処の章
GPUが載っているのに tok/sec が一桁	モデルがVRAMに載りきっていない(CPUオフロード)	n-gpu-layers
コンテキストを伸ばすと急にOOM/遅延	KVキャッシュがVRAMを圧迫	KVキャッシュ量子化
長文を入れた瞬間の待ち(最初のトークンまで)が長い	prefill(プロンプト処理)が遅い	flash attention / batch
全部GPUに載っているのに頭打ち	GPUのメモリ帯域の上限に到達	設定では伸びない(後述)

最後の「帯域の上限」だけは設定で超えられません。生成(デコード)は1トークンごとにモデル全体のパラメータを読み出す処理で、その速度はGPUのメモリ帯域でほぼ決まります。詳しくはなぜ帯域でtok/secが頭打ちになるかを参照してください。チューニングは「帯域が決める天井まで実効値を引き上げる」作業であり、天井そのものを上げるものではない、という前提が重要です。

設定1:n-gpu-layers で全層をGPUに載せる

最も効くのがレイヤーオフロードです。llama.cpp の -ngl(--n-gpu-layers)は、モデルの何層をGPUに載せるかを指定します。

# llama.cpp: 全層をGPUに載せる(99は層数にクランプされるので「全部」の意味)
llama-server -m model.gguf -ngl 99

# Ollama: 環境変数 / Modelfile の num_gpu でオフロード層数を指定
# (通常は自動。VRAMに収まるなら全層が自動で載る)
OLLAMA_NUM_GPU=99 ollama run your-model

「一部CPUオフロード」の崖

ここが本記事で一番伝えたいポイントです。モデルがVRAMに収まりきれば全層GPUで快適に動きますが、わずかでも溢れて数層がCPU(システムメモリ)に落ちると、tok/sec が崖のように落ちます。理由は明快で、生成のたびにCPU側の層を遅いシステムメモリ帯域(GPUの数分の1)で読み出し、PCIe越しのやり取りも挟まるためです。

全層GPU:GPUのメモリ帯域で律速 → 期待どおりの tok/sec
数層だけCPU:その数層がボトルネック化 → 全体が引きずられて激減

対策は「VRAMに収まる量子化・サイズを選ぶ」こと。70B級をギリギリ載せようとして溢れるくらいなら、1段軽い量子化にして全層GPUに収める方が速いケースが多いです。どの量子化がどれだけVRAMを食うかは量子化ベンチとVRAM容量とモデルの早見表で確認できます。

Ollama の注意点:Ollama は基本的にVRAMに収まる範囲を自動で載せます。ログ(ollama ps や起動時の出力)で「何%がGPUに載ったか」を確認し、100% GPU になっているかをまずチェックしてください。

設定2:flash attention の有効化が量子化の前提

flash attention は、アテンション計算を「巨大な行列をまるごと作らずタイル単位で処理する」手法です。これにより必要メモリが系列長の二乗(O(n²))に比例して膨らむのを抑え、長コンテキストでのVRAM消費とprefill(最初のトークンまでの処理)を改善します。

# llama.cpp: flash attention を有効化
# 近年のビルドでは on/off/auto を取る形に変わっている(版により -fa 単独指定も可)
llama-server -m model.gguf -ngl 99 --flash-attn on

# Ollama: 環境変数で有効化
OLLAMA_FLASH_ATTENTION=1 ollama serve

flash attention 自体の速度・VRAM効果はprefill(プロンプト処理)ベンチで扱っていますが、本記事で押さえたいのは次の依存関係です。

KVキャッシュ量子化(設定3)は flash attention が有効でないと正しく効きません。 llama.cpp では flash attention 無しで量子化KVキャッシュを使うと、アテンション計算のたびにキャッシュを展開(dequantize)する必要があり、量子化しない場合より遅くなることがあります。Ollama でも K/V キャッシュ量子化は flash attention が前提で、対応していないアーキテクチャでは内部的に f16 に戻るため、期待したVRAM削減が効かず逆にOOMになる落とし穴があります。順番として flash attention を先に有効化してください。

設定3:KVキャッシュ量子化で長コンテキストのVRAMを半減

KVキャッシュは、会話やプロンプトのトークンごとに保持される中間状態で、コンテキストが長くなるほどVRAMを食う部分です。これを量子化すると、モデル本体とは別にコンテキスト用のVRAMを節約できます。

# llama.cpp: K/V キャッシュを 8bit (q8_0) に
llama-server -m model.gguf -ngl 99 --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q8_0

# Ollama: 環境変数で指定(flash attention 有効が前提)
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

指定できる型と方針は次のとおりです。

cache-type	精度	VRAM(f16比)	推奨度
f16	既定・最高精度	基準	既定。VRAMに余裕があるなら無理に量子化しない
q8_0	8bit	約1/2	第一候補。品質劣化はごくわずかで効果大
q4_0	4bit	約1/4	コンテキストを極端に伸ばしたい時。劣化が出やすい

実務上は q8_0 が安全策です。f16比でコンテキスト用VRAMを約半分にでき、品質劣化はほとんど体感されません。空いたVRAMをコンテキスト長(-c)に回すか、モデルを1段重い量子化に戻す原資にできます。q4_0 まで落とすと長文の一貫性が崩れることがあるので、まず q8_0 で様子を見るのが定石です。KVキャッシュがコンテキスト長に対してどれだけVRAMを消費するかはコンテキスト長とVRAM(KVキャッシュ)の関係で具体的に計算しているので、そちらを受け皿にしてください。

注意:K と V で**非対称な量子化(片方だけ別の型)**にすると、GPUオフロードできず性能が落ちる既知の挙動があります。q8_0 を使うなら K も V も同じ q8_0 に揃えてください。

設定4:コンテキスト長・バッチ・並列の取り方

残りはトレードオフの調整です。

フラグ(llama.cpp)	役割	上げると	下げると
`-c` (context size)	コンテキスト長	長文を扱える / KVキャッシュ用VRAM増	VRAM節約 / 長文が切れる
`-b` / `-ub` (batch / micro-batch)	prefillの一括処理量	プロンプト処理(prefill)が速い / 一時VRAM増	VRAM節約 / prefillが遅い
`-np` (parallel)	同時リクエスト数	複数同時処理(サーバ用途)	単一リクエストにVRAM集中

実用的な判断軸は次のとおりです。

単機で1人が使う:-np 1。コンテキストは実際に使う長さ+αに留め、余ったVRAMは量子化を1段戻すかKVキャッシュをf16に戻すのに使う。
長いプロンプト(RAG・コードベース投入)が多い:-b/-ub を上げて prefill を稼ぐ。最初のトークンまでの待ちが短くなる。
複数人・複数アプリから叩く(自宅サーバ):-np を上げる。ただしVRAMは分割されるので、収まる範囲で。サーバ構成は自宅ローカルLLMサーバの組み方を参照。

-c を闇雲に最大化するとKVキャッシュでVRAMが埋まり、結局モデルが溢れて設定1の「崖」に逆戻りします。「全層GPU」を最優先に、コンテキストはその範囲で取るのが鉄則です。

llama.cpp vs Ollama:どちらでチューニングするか

両者の関係(Ollama は内部で llama.cpp 由来のエンジンを使う)や使い分けはllama.cpp と Ollama の違い、ツール全体の比較はローカルLLMランタイム比較で詳説しています。チューニングの観点だけ要約すると:

llama.cpp(llama-server):フラグで細かく制御できる。-ngl --flash-attn --cache-type-k/v -c -b を直接指定。詰めたい人向け。
Ollama:環境変数(OLLAMA_FLASH_ATTENTION / OLLAMA_KV_CACHE_TYPE / OLLAMA_NUM_GPU)と Modelfile で設定。手軽だが、設定が効いているかをログで確認する習慣が要る。

どちらでも上げどころは同じ(オフロード→flash attention→KVキャッシュ→context/batch)です。

チューニング後に「それでも遅い」場合

設定を詰めても期待値に届かない場合、原因は設定の外にあります。

GPUのメモリ帯域の上限に達している → これ以上は設定で伸びない。帯域の話はこちら。
モデルがそもそもVRAMに対して大きすぎる → 量子化を見直す(量子化ベンチ)。
電源/熱でクロックが落ちている → 高負荷が続くとサーマルスロットリングで遅くなる。冷却・電源を点検。
複数モデルを同時に載せてVRAMが逼迫 → モデルの出し入れはllama-swapによる複数モデル運用で整理。

設定で稼げるのは「実効値を理論上限に近づける」ところまで。そこに達したら、次はGPU(帯域)そのものの見直しになります。

まとめ:上げどころは4つ、順番が大事

n-gpu-layers:まず全層GPU(-ngl 99)。一部CPUオフロードの「崖」を避けるのが最優先
flash attention:有効化(--flash-attn on / OLLAMA_FLASH_ATTENTION=1)。KVキャッシュ量子化の前提
KVキャッシュ量子化:q8_0 が安全策。K/V は同じ型に揃える。長コンテキストのVRAMを約半減
context / batch / parallel:用途に合わせて。-c の取りすぎでモデルを溢れさせない
天井は帯域:全層GPUで詰めきった後の頭打ちは設定では超えられない