実行プログラムと拡張機能

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

同じGGUFを使っているのに、他の人より遅い。アプリの設定を何度か変えたら、最初の値も分からなくなりました。llama.cppを直接使う理由は、必ず速くなるからではありません。どのファイルをどんな条件で動かしたかを、確認しやすいからです。

直接実行で得られること、自分で管理すること

llama.cppはさまざまな機器でモデルを動かす推論プロジェクトで、llama-serverはそのモデルをHTTPで呼び出すサーバープログラムです。デスクトップアプリ内でも関連エンジンは使われていますが、直接起動するとファイル・コンテキスト・同時リクエストなどの条件をコマンドとして残しやすくなります。

その代わり、自分の機器に合う実行ファイルとドライバーを選び、更新を管理する必要があります。今のアプリで必要な設定を十分に確認できるなら、移る理由はあまりありません。アプリが隠している条件を確認したいときや、特定のビルドで問題を再現したいときに、直接実行の利点が出てきます。

GPUがあっても、そのGPUを使えるビルドが必要です

NVIDIAのCUDA、Apple SiliconのMetal、対応する他の機器のVulkanなど、バックエンドによって準備は異なります。CPU用の実行ファイルを起動してGPU使用率が低いからといって、グラフィックカードの問題とは判断できません。起動ログで、検出したデバイスと使用したバックエンドを確認してください。

GGUFは実行用のファイル形式であり、すべてのモデル構造に対応するという保証ではありません。新しい構造なら、現在のビルドの対応状況と変換済みファイルの情報を合わせて確認します。画像入力を使う場合は、そのモデルのマルチモーダル対応と追加ファイルも必要です。テキスト用GGUF一つで全機能が使えるわけではありません。

モデル一つ、リクエスト一つから始めます

以下はllama-serverの実行ファイルとGGUFが準備済みの場合です。./models/model.ggufを実際のファイルパスに置き換えます。別名はlocal-guide、コンテキストは4,096、同時スロットは一つと明記しています。自分の機器で最速になる設定ではなく、その後の変更を比較するための開始点です。

GPUへの配置はautoにして、実際の結果を確認します。実行ファイルのヘルプにオプションがなければ、インストール済みビルドはこの例と異なります。まずバージョンとヘルプを確認し、未対応オプションを削除して条件が変わった場合は、その変更も記録してください。

ダウンロード済みGGUFでローカルサーバーを起動

llama-server -m ./models/model.gguf --alias local-guide --host 127.0.0.1 --port 8080 --ctx-size 4096 --parallel 1 --n-gpu-layers auto

実行ファイルがPATHにある場合のターミナル例です。自分でビルドした場合は実行ファイルの場所に合わせて変更してください。GGUFの実際のパスと、そのビルドの--helpを先に確認します。

サーバーの起動と、モデルの準備完了は別です

モデルの読み込み中は、まだ回答の準備ができていない場合があります。/healthが準備完了を返すことを確認してから、短いリクエストを送ります。以下の最初のコマンドは状態確認だけを行い、二つ目は実際に回答の生成を要求します。

HTTPの応答形式が正しくても、会話テンプレートやツール呼び出し方式が合わなければ、接続したアプリで失敗することがあります。まずAPIの別名と短い文章への返答を確認してから機能を追加してください。この例は回答全体を受け取る方式なので、純粋なプリフィル時間や最初のトークンまでの時間の測定には使いません。

準備状態と回答を別々に確認

curl -sS http://127.0.0.1:8080/health
curl -sS http://127.0.0.1:8080/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"local-guide","messages":[{"role":"user","content":"Reply with one short sentence."}],"max_tokens":128,"stream":false}'

サーバーを起動したターミナルはそのままにして、別のターミナルで実行します。準備完了を確認してから二つ目のリクエストを送ってください。

遅い部分を見つけてから、一つだけ変えます

まずモデルがCPUとGPUにどう分かれているかを確認します。GPUにさらに載せる余裕があるか、コンテキストでメモリが不足していないかを見てください。その後、入力を読むプリフィルと出力するデコードを分けて考えます。入力処理用のバッチを大きくした効果が、回答生成速度にも同じ比率で現れるとは限りません。

一人で使う速度を確認するなら、同時リクエスト数を固定します。複数リクエストの合計処理量が増えても、自分の回答が早く終わるとは限りません。ファイル、量子化、入力・出力の長さをそろえ、ウォームアップ後に3回以上記録してください。設定の効果より管理の負担が大きければ、OllamaやLM Studioに戻っても構いません。目的はコマンドを増やすことではなく、必要な回答を安定して得ることです。

変更履歴

サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。

  1. llama.cppのサーバー起動・復旧案内を追加

    準備したGGUFファイル1つでサーバーを起動し、ローカルAPIを確認する例を追加しました。GPUへの配置・文脈・リクエスト数を1項目ずつ変更し、メモリ不足が起きたら正常に動いていた設定へ戻す手順を説明しました。