llama.cpp：どの設定が遅さの原因かを自分で確かめるには

長い技術メモを要約するなら、GGUFファイルとリクエストを固定します。短いリクエストでサーバーの応答を確認してから、メモ全体を入れてください。入力の処理と回答の生成を分けると、どこで待つかが分かります。

直接実行では実行ファイル・ドライバー・更新・コマンドも管理します。アプリにない条件が必要な場合や特定ビルドの問題を再現する場合に、その作業が役立ちます。

GPU使用率が低いだけでカード故障とは判断しません。CPU⁵専用実行ファイルはGPUがあってもGPU backendを使いません。NVIDIA CUDA⁶・Apple Silicon Metal⁷・Vulkanでは準備手順が異なります。起動ログで検出デバイスと選択backendを確認します。デバイスが認識されていなければ、配置オプションを変えてもGPU実行にはなりません。

GGUFは配布形式であり、すべてのビルドがすべてのモデル構造に対応する保証ではありません。新しい構造では実行ファイルの対応と変換元モデルを確認します。画像入力が必要ならマルチモーダル実装と追加ファイルの対応も別途調べます。テキストGGUFだけで画像経路が用意されるわけではありません。

モデルファイルを用意し、例の./models/model.ggufを実際のパスに置き換えます。local-guide別名・4,096コンテキスト・並列スロット1は比較用の基準値です。コンテキストは入力と生成回答で共用するため、4,096をすべてメモ入力に使える意味ではありません。初回読み込み時間は後続要求と分けます。

GPUレイヤー配置はautoから始め、ログとGPU別メモリで実際の配置を確認します。auto指定がモデル全体のGPU配置を意味するわけではありません。実行ファイルが想定と違う場合はバージョンと--helpを確認し、動作する最小コマンドとログを保存します。非対応オプションを削除した結果は元の例と同条件ではありません。

GGUFファイル名と量子化⁸・実行ファイルのバージョン・backend・コンテキスト4,096・スロット1を記録します。モデルと実行条件を固定すれば、バッチやGPU配置を一項目ずつ変更できます。

サーバープロセス起動後、/healthが準備完了を示すか確認して短い質問を送ります。1つ目のコマンドは状態確認、2つ目はテキスト生成要求です。メモ全体を送る前に別名と接続を確認し、読み込み・接続問題を切り分けます。

API⁹成功だけではクライアントが期待するテンプレートやtool calling形式は確認できません。以下のcurlは回答全体を待つため往復時間は見られますが、最初のトークン¹⁰やprefill・decodeを個別には測りません。

長いメモを送って最初の回答が遅い場合はprefill、生成開始後のトークンが遅い場合はdecodeが原因かもしれません。長文入力はコンテキストメモリも多く使うため、コンテキスト4,096の基準要求と比較しGPUの余裕とKVキャッシュ¹¹を確認します。

prefillバッチを増やすと長文処理に役立つ場合がありますが、decodeも同じ割合で速くなるとは限りません。同時要求を増やすと総スループット¹²は変わっても、一人の完了時間が短くなるとは限りません。個人要約が目的ならスロット1を基準にし、ログが示すバッチ・コンテキスト・GPU配置の関連項目だけを一つずつ変更します。

比較では GGUF と量子化、入力・出力の長さ、backend、同時リクエスト数を固定します。準備実行の後、同じリクエストを 3 回以上送り、モデルのメモリ常駐と KV cache の再利用を記録してください。

キャッシュを消せなかった測定は cold start と呼べません。値が一度だけ大きく外れても除外せず、準備状態とバックグラウンド負荷を確認してから中央値でまとめます。

回答全体を待つcurlは往復時間用であり、prefillとdecodeを分けるベンチマークではありません。目標作業が安定して完了することを確認してから、直接管理する価値を判断します。OllamaやLM Studioに必要なオプションがあるなら、そのまま利用できます。

llama.cpp b11413は、一部の長文モデルのVulkan実行経路を改善しました。Qwen3.8-Flash-NextのQSAなど、必要な位置だけを選んで読むsparse attention¹³モデルが対象です。量子化K/Vキャッシュでも選択した位置だけを読み、文脈全体を処理する負担を減らします。

PR作者によるRadeon R9700・RX 7900 XTの測定では、q8_0 KVキャッシュで64K文脈の生成が平均19%、128Kでは15%速くなりました。短い文脈では効果が小さいか低下することがあり、ランタイム¹⁴が経路を選択します。この値はf16キャッシュやプリフィルには適用しません。以下のコマンドはVulkanビルドと対応モデルを準備してから使います。

2026年10月5日公開のllama.cpp 0.6.0には、選択結果と確率を返す/v1/systemone APIが追加されました。問い合わせの担当振り分けや文書分類に使えます。対応モデルの選び方と入力・候補の送り方は、ローカル判断モデルの実行例で説明します。0.6.0公式リリース

速度に関わる変更には、Qwen4ExpのMTP¹⁵、MetalのF16 KV Flash Attention、CUDAのNVFP4¹⁶・MXFP4演算経路の改善があります。自分のモデルに対応する機能を選び、同じ質問で更新前後を比較してください。既存の速度記録は測定時のバージョンを残し、新しい記録と比較できるようにしています。

llama.cpp b11507以降では、CPUに置いたMoE¹⁷のexpert重みを複数GPUのキャッシュに分けて保持できます。必要なexpertをGPUへ繰り返し転送する回数を減らす機能です。大きなMoEをRAM¹⁸とGPUに分けて動かす構成で試せます。

現在の--moe-cache-mibはキャッシュ全体の容量をMiBで指定し、複数GPUでは--tensor-splitの配分に従って分けます。標準値は0で無効です。llama-server --helpにオプションがあるか確認し、同じ文書でキャッシュ有無の初回応答待ちと生成速度を比べてください。

b11512にはDFlashの出力head共有の修正も入っています。DFlash構成の更新では、メイン・draftモデルを維持して同じ入力を送り、最後まで生成できるか確認しましょう。b11507・b11512は10月8日のrolling buildで、固定リリース0.6.0とは別の更新系列です。