llama.cppが遅い原因と高速化設定｜確認順に解説

先に結論

llama.cppの「遅い」は、model load、prompt processing、text generationのどこが遅いかで対策が変わります。まず同じGGUFと同じbuildでllama-benchを取り、推測でoptionを増やさないことが最短です。
確認順は、Release buildと正しいbackend → GPU認識とoffload → RAM／VRAMの余裕 → CPU threads → batch／ubatch → Flash Attention／KV cacheです。
2026年8月2日時点のCLIは、GPU layerがauto、device memoryへのfitがon、Flash Attentionがautoです。古い記事の-ngl 999などを最初から足すより、現在の自動判定結果と起動logを先に確認します。

おすすめ読者: 起動はするが返答が遅い人、GPUを使っているはずなのに速度が出ない人、設定変更を同条件で比較したい人。

確認日時: 2026年8月2日 14:24（Asia/Tokyo）
固定した版: llama.cpp master HEAD 11924d4c17abc27383376a1ac6a24fa3e36c1c0c
検証区分: 公式README、build資料、CLI自動生成引数表、llama-bench資料、performance troubleshooting資料とsourceを照合した机上調査です。掲載commandはBash／Zshとして構文確認しましたが、特定hardwareでのbenchmarkは実施していません。記事中に「何t/sなら速い」という実測値は置いていません。
画像: アイキャッチは推論経路のbottleneckと最適化を表した当サイトの要点図解で、benchmark結果ではありません。

「遅い」を3区間に分ける

最初に、体感ではなく遅い区間を特定します。

遅い区間	画面上の症状	主な確認候補
model load	起動から入力可能になるまで長い	storage、file size、load mode、RAM不足、swap、初回download
prompt processing（PP）	長い入力を送った後、最初のtokenまで待つ	backend、GPU offload、batch／ubatch、入力token数、prompt cache
text generation（TG）	返答は始まるが1 tokenずつ遅い	model規模・量子化、offload、memory bandwidth、CPU threads、thermal

llama-cliの終了時timingではprompt evalとevalが分かれます。llama-benchではPPを-p、TGを-nとして分離できます。APIの体感にはtokenization、sampling、network、queue待ちも含まれますが、公式資料によるとllama-benchの測定にはtokenizationとsampling時間が含まれません。この差を混同しないでください。

まだGGUFを正常に実行できていない場合は、先にllama.cppでGGUFを動かす方法を完了します。load errorならGGUFモデルが読み込めないときの対処法へ進みます。

手順1：変更前のbaselineを保存する

同じmodel file、prompt／generation長、build、電源状態で5回測る例です。MODEL_GGUFは絶対pathへ置き換えます。

MODEL_GGUF="/absolute/path/to/model.gguf"

./build/bin/llama-cli --version
./build/bin/llama-cli --list-devices

./build/bin/llama-bench \
  -m "$MODEL_GGUF" \
  -p 512 \
  -n 128 \
  -r 5 \
  -o json > bench-baseline.json

JSONにはbuild commit、CPU／GPU情報、backend、model size、parameter数、batch、ubatch、threads、GPU layer、KV type、Flash Attention、PP／TGの平均t/sと標準偏差などが入ります。最速の1回ではなく平均とばらつきを比較します。

測定前に固定するものは次の通りです。

同じGGUFとSHA-256
同じllama.cpp build／backend
同じ-p、-n、context depth
同じbatch、ubatch、KV cache型
同じ電源mode、冷却条件、background process

設定の意味はllama.cpp主要パラメータ一覧でも確認できます。

手順2：Release buildとbackendを確認する

Debug build、CPU向けbuildのままGPU optionを足しても、期待する経路にはなりません。公式build資料に沿い、対象hardwareのbackendでRelease buildします。

hardware	最初のbackend候補	build時の確認
Apple Silicon	Metal	macOSでは既定で有効。`--list-devices`で認識確認
NVIDIA GPU	CUDA	`-DGGML_CUDA=ON`、toolkit／driver条件を確認
AMD GPU	HIP／ROCm	対応GPU・OS・ROCm版を公式表で確認
Intel GPU	SYCL等	対象deviceと公式build手順を確認
GPUなし	CPU	ISA、physical core、memory bandwidthを確認

backendごとのbuild例と判断基準はllama.cpp GPUバックエンド比較にまとめています。起動logにdeviceが出ない場合は次のtuningへ進まず、buildを直します。

手順3：GPU offloadとmemory fitを確認する

現行CLIの-nglはauto、-fitはonが既定です。まず明示した状態で起動し、logに選ばれたdevice、offloaded layer数、buffer／KV cacheの配置が出るかを確認します。

MODEL_GGUF="/absolute/path/to/model.gguf"

./build/bin/llama-cli \
  -m "$MODEL_GGUF" \
  -c 4096 \
  -n 256 \
  -ngl auto \
  -fit on \
  -fitt 1024 \
  -fa auto \
  -cnv

-fitt 1024はdeviceごとに1,024MiBのmarginを目標にする指定です。ただし--fitは未指定の引数を調整します。この例の-c 4096のように明示した値まで勝手に縮める指定ではありません。OOMやswapが出るなら、次の順で負荷を下げます。

contextを必要量まで下げる。
file sizeの小さい量子化またはparameter数の少ないmodelを選ぶ。
並列実行中ならsequence数を下げる。
必要に応じてGPUへ載せるlayerを減らし、CPUとのhybrid inferenceにする。

「fileがVRAM容量より小さい」だけでは収まる保証になりません。model weightに加えてKV cacheと実行bufferが必要です。事前計算はローカルLLMに必要なVRAMの計算方法を使ってください。

手順4：CPU threadsを測って決める

threadsは多いほど速いとは限りません。公式performance troubleshootingでも、過剰なthreadsでCPUが飽和するとTGが極端に遅くなるため、1から倍増させてbottleneckを探す手順が案内されています。

MODEL_GGUF="/absolute/path/to/model.gguf"

./build/bin/llama-bench \
  -m "$MODEL_GGUF" \
  -p 0 \
  -n 128 \
  -t 1,2,4,8 \
  -r 5

8を上限にする意味ではありません。自分のphysical core数に応じて候補を追加し、TGの平均とばらつきを見ます。GPU offload中もtoken生成にCPU処理が関わるため、GPU使用率だけを見てthreadsを最大化しないでください。prompt処理用の-tbは-tと分けて設定できますが、最初は同じにして変数を増やしません。

手順5：batch／ubatchはPPだけを比較する

-bはlogical maximum batch、-ubはphysical maximum batchです。長いpromptの処理が遅い場合に、同じ入力長でubatchを比較します。

MODEL_GGUF="/absolute/path/to/model.gguf"

./build/bin/llama-bench \
  -m "$MODEL_GGUF" \
  -p 1024 \
  -n 0 \
  -b 2048 \
  -ub 128,256,512,1024 \
  -r 5

大きくすると必ず速くなるわけではなく、memory使用量とbackendの実装に依存します。OOM、速度低下、ばらつき増加が出た1段階手前を候補にします。公式build資料も、BLASによる改善は大きめbatchのprompt processingに関するもので、generation性能には影響しないと区別しています。

手順6：Flash AttentionをA/B比較する

現行の既定-fa autoは、modelとbackendに応じて可否を判断します。対応しているのにPPやmemory効率が悪い場合だけ、同条件でoffとonを比較します。

MODEL_GGUF="/absolute/path/to/model.gguf"

./build/bin/llama-bench \
  -m "$MODEL_GGUF" \
  -p 1024 \
  -n 128 \
  -fa off,on \
  -r 5

onで未対応errorになる組み合わせは、強制して解決する対象ではありません。autoへ戻します。また、改善幅はhardware、model構造、prompt長で変わるため、別環境の割合をそのまま期待しないでください。

手順7：KV cacheを小さくするのはmemory対策として行う

長contextでmemoryが足りない場合、K／V cacheをf16からq8_0などへ量子化できる構成があります。

MODEL_GGUF="/absolute/path/to/model.gguf"

./build/bin/llama-cli \
  -m "$MODEL_GGUF" \
  -c 8192 \
  -ctk q8_0 \
  -ctv q8_0 \
  -fa on \
  -ngl auto \
  -fit on \
  -n 256 \
  -cnv

量子化V cacheにはFlash Attentionが必要です。backendによって対応するKV型やperformanceが異なり、量子化は品質にも影響し得ます。これは無条件の高速化optionではありません。memoryに余裕ができたか、PP／TG、代表promptの品質を別々に再測定します。multi-GPUのtensor splitでは量子化KVが未対応という現行制約もあるため、構成を混ぜないでください。

model loadだけが遅い場合

推論速度が正常で起動だけ遅いなら、計算backendよりload経路を見ます。現行CLIの--load-mode既定はmmapです。

確認	意味
初回と2回目を分ける	OS page cacheやdownloadの影響を区別する
local SSDとnetwork storageを分ける	file読み込み経路の差を確認する
RAM／swapを見る	modelが収まらずpageoutしていないか確認する
`-lm mmap`をbaselineにする	現行既定を明示して比較する
`-lm mlock`は余裕がある場合だけ試す	swap／圧縮を避ける一方、OS全体のmemoryを圧迫し得る

mlockは速度を保証するswitchではありません。modelとOS用のmemoryが十分にある環境でのみA/B比較し、失敗したらmmapへ戻します。旧--mmap／--mlockは現行helpで--load-modeへの移行が案内されています。

serverで遅い場合はlatencyとthroughputを分ける

1 requestのTGを速くする設定と、複数requestを同時にさばく設定は別です。parallel slotやcontinuous batchingは全体throughputを上げられる一方、混雑時の個別latencyは長くなる場合があります。

次を別々に記録します。

queueに入ってから最初のtokenまでの時間
prompt processing時間
text generationのt/s
同時request数と全request完了時間
timeout／error数

構成と再現commandはllama-serverの連続バッチング設定を使ってください。単一userの対話が目的なら、同時数を増やしたthroughputだけで「高速化した」と判断しません。

変更する順番と戻し方

順番	変更	期待する改善	主なrisk
1	正しいRelease backend	PP・TG全体	build条件の違い
2	GPU認識・auto offload	PP・TG全体	VRAM不足
3	小さいmodel／量子化	TG、memory	品質低下
4	threads	主にTG	oversubscription
5	batch／ubatch	主にPP	memory増加、逆効果
6	Flash Attention	PP・memory中心	非対応構成
7	KV cache量子化	長contextのmemory	品質・互換性・速度差

1回に1項目だけ変え、結果file名へ条件を入れます。たとえばbench-11924d4-q4-ub512.jsonのようにすると、後から比較できます。llama.cppコマンド例10選の完成例を使う場合も、baselineとの差分を残してください。

FAQ

GPU使用率が100％なら最速？

断定できません。memory不足による転送、CPU側のoversubscription、長いqueue、thermal throttlingが同時に起きる可能性があります。PP／TGのt/s、offloaded layer、memory使用量、温度・電源状態を一緒に見ます。

contextを最大値にすると遅くなる？

大きなcontextはKV cacheのmemory圧力を増やします。また実際に長いpromptを処理すればPP時間も増えます。モデルが対応する最大値と、毎回確保すべき実用値は同じではありません。必要な長さから始めます。

Q4ならQ8より必ず速い？

保証できません。fileとweight memoryは小さくなりやすい一方、backendのkernel、hardware、model構造で速度順位が変わります。品質も含め、同じGGUF系統と条件で測ります。

Macで確認する点は違う？

Apple SiliconはCPUとGPUがunified memoryを共有するため、専用VRAMだけを見るPCとはmemory圧力の現れ方が異なります。Macのメモリ別・動かせるローカルLLM一覧でOSと他applicationの余裕を含めて選んでください。

まとめ

llama.cppの高速化は、option集ではなく測定順が重要です。遅い区間をload・PP・TGへ分け、versionとdeviceを記録し、Release backend、offload、memory、threads、batch、Flash Attention、KV cacheの順に1項目ずつ比較します。自動設定が増えた現行版では、まずautoの結果をlogで確かめ、その後に必要な箇所だけ固定するのが再現しやすい進め方です。

参考資料

llama.cpp公式README（commit 11924d4、2026年8月2日確認）
llama.cpp公式Build guide（commit 11924d4、2026年8月2日確認）
llama-cli公式引数表（commit 11924d4、2026年8月2日確認）
llama-bench公式README（commit 11924d4、2026年8月2日確認）
Token generation performance troubleshooting（commit 11924d4、2026年8月2日確認）
llama.cpp公式Multi-GPU guide（commit 11924d4、2026年8月2日確認）