ローカルLLMの返答が遅い？tokens/sと体感速度の違い

先に結論

• TGのtokens/sは文章を生成する区間の平均速度です。送信から初回表示までや返答全体の時間とは別の指標です。
• ベンチマークと体感が合わないときは、モデルを替える前に「初回ロード」「入力処理」「思考」「サーバー待ち」「配信・画面描画」を分けて観察します。
• この記事は公式資料をもとにした調査記事です。筆者環境での計測や、掲載できる実測値はありません。手順の実行結果を示すものではありません。

おすすめ読者: ベンチマークでは速いモデルがチャット画面では遅く感じる人、どの段階が待ち時間を作るか整理したい人。

確認日: 2026年10月2日（Asia/Tokyo）
調査方法: llama.cpp公式のllama-bench・server資料を確認した机上調査です。実機ベンチマーク、API計測、各UIでの表示確認はしていません。掲載する速度値やログ例はありません。
固定した版: llama.cpp nightly release b11344（2026年10月2日 08:54 UTC公開）。以下の公式READMEはmasterではなく同release tagに固定して確認しました。

tokens/sが表す範囲

速度を比べるとき、まず「何を、どの区間で数えた値か」を確かめます。llama.cpp公式のllama-benchは、prompt processing（PP）、text generation（TG）、両方を続ける試験を分け、反復した結果を平均tokens/sとばらつきで出します。一方、公式READMEは、測定にtokenizationとsamplingの時間を含めないと明記しています。設定した入力・出力長や実行条件が、日常のチャットと一致するとも限りません。

したがってTGが高くても、「送信後すぐ文字が出る」とは限りません。初回表示までには入力のtoken化、prompt処理、最初のtoken生成、送信、受信と描画が関わります。PPも参考になりますが、ベンチマーク区間だけを実際のTTFT（最初のtokenまでの時間）と同一視しないでください。

症状から待ち場所を絞る

thinkingを隠しても、モデルが思考出力を生成しているなら、その時間は残り得ます。長い思考表示も故障と決めつけず、思考と最終回答の時間を分けて考えます。表示欄はモデルとクライアントにも依存します。

モデルを変える前の確認順

1. 同じ依頼を続けて送り、初回だけのロード差があるかを見ます。
2. 長い会話は、新規チャットで短い依頼をした場合と比べます。promptには過去の会話も含まれ得ます。
3. 画面の送信から初回表示まで、返答完了まで、生成中の文字の流れを別々に計ります。
4. APIの区間別時間・token数と画面の経過時間を比べます。llama.cpp serverにはprompt_ms、predicted_ms、token数、tokens/sの応答例があります。timings_per_tokenは既定で無効です。streamでは統計が最終chunkに含まれる場合があるため、完了応答も見ます。
5. 複数要求のときだけ遅いなら、同時実行やserver queueを確認します。llama.cppの/metrics（有効化が必要）には処理中・待機中の要求数があります。

区間を特定してから、長いpromptなら履歴や入力、生成なら出力長、初回ロードなら常駐方法を検討します。設定変更より先に遅れている場所を確かめます。

数値を比べるときの限界

モデル、量子化、backend、hardware、context、同時実行数、warm/cold状態が違う結果を単一のtokens/sで順位づけできません。UIのqueue、通信、Markdown整形、描画はserver値に含まれない場合があります。APIの計測範囲も実装・版ごとに確認し、同条件で比較してください。

llama.cppの設定そのものを見直す場合はllama.cppが遅い原因と高速化設定へ。この記事の役割は設定値を推奨することではなく、「ベンチマークと体感の差がどの区間で生じたか」を切り分けることです。

公式資料

• llama.cpp b11344: llama-bench README — PP/TG試験、反復と結果、tokenization・samplingを含まない測定範囲。
• llama.cpp b11344: server README — serverのtimings、stream応答、prompt progress、reasoning設定。