ローカルAIの速度を測る方法｜LM Studio・Ollamaでtokens/s・メモリ・VRAMを比較

症状別クラスターから速度を測る

「遅い」をロード、Prompt Processing / TTFT、generationへ分けたら、LM StudioのPrompt Processing記事やOllamaのAPI usageへ進みます。速度記事は特定の快適ラインを決めるページではなく、同じPC・モデル・contextで再現条件を残す測定ページです。

• LM StudioのPrompt Processingが遅い - 入力処理と最初の文字までを分ける
• Ollamaが遅い - API usageとPROCESSORを読む
• LM Studioの生成中も遅い - generationの条件を固定して測る
• LM Studioの回答が途中で止まる - 正常終了と途中停止を分ける
• Ollamaの回答が途中で止まる - done_reasonとログを記録する

agentを測る時は1往復で終わらせない

agentではTTFTやtokens/sだけでなく、tool call回数、総時間、peak RAM/VRAM、ファイルI/O、失敗・再試行を記録します。同じmodel・同じ入力・同じtoolで比較し、機種一般の速度へ広げません。

• agent workload PC負荷 - 計測項目の分解を見る

MTPのA/B比較を追加する

MTPの速度差はgenerationだけでなく、prompt processing、TTFT、peak VRAM、accepted draft tokens、失敗条件まで分けて記録します。Qwen3.6-27BのColab結果を別モデルや別GPUへ一般化しません。

• Qwen3.6-27B Colab実践 - 同じpromptでbaselineとMTPを動かす
• MTPの設定と受理率 - n-maxとaccepted tokensを読む

まず結論：速度は1つの数字で決めない

最初に記録するのは、モデルを使える状態にするまでの読み込み時間、入力を送ってから最初のトークンが出るまでの時間、生成中のtokens/s、ピーク時のRAMとVRAMです。どれか1つだけ速くても、ロードに毎回時間がかかる、長文で止まる、Windows全体が重くなるなら実用性は別に判断します。

30秒で測定条件を固定する

比較を始める前に、可能なら同一のGGUFファイルを使います。ファイルをそろえられない場合は、同じベースモデル・同じリビジョン・同じ量子化・同じ変換条件をそろえ、配布形式が違う場合は「ツール差」だけでなくファイル差も含む別比較として記録します。コンテキスト長、同じ入力文、同じ出力上限もメモし、サンプリング設定やGPUオフロードを変えた場合は別の測定として扱います。

1. Windowsを再起動する必要はありませんが、ブラウザの大量タブ、同期、動画編集、ゲームなど、結果へ影響しそうな処理を閉じます。閉じたものを記録します。
2. モデル名、GGUFファイル名、ファイルサイズ、量子化、コンテキスト長、GPUオフロード設定を記録します。
3. 短い固定プロンプトと出力上限を用意し、同じ順番でLM StudioとOllamaを測ります。
4. 冷たい開始と、同じモデルをもう一度呼んだ暖かい開始を分けます。初心者がばらつきを確認する最低限の目安として、同じ条件を3回程度測り、中央値と最小・最大を残します。厳密な検証や公開比較では回数を増やしてください。

指標の意味：モデル読込・TTFT・tokens/s

モデル読み込み

モデルファイルを読み込み、推論を開始できる状態までの時間。LM Studio REST APIではload_time_secondsが返る場合があります。

TTFT

Time to First Token。入力を受け取って最初のトークンが表示されるまでの時間。入力が長いほど変わりやすい指標です。

prefill

入力プロンプトを処理する段階。入力長、コンテキスト、eval batchなどの条件を変えると比較できなくなります。

decode

回答を1トークンずつ生成する段階。tokens/sやTPOTはこの段階の見え方を表します。

ピークRAM・VRAM

タスクマネージャー等で観察した最大値。モデルのファイルサイズと同じではなく、OSや他アプリの使用分も含めて読みます。

Windowsで先に記録するもの

• 公開する記録では、ユーザー名、PC名、個人ファイルのパス、秘密や業務プロンプトを伏せます。取れない項目は空欄にせず「未確認」と書きます。

公平な比較条件

• 乱数やサンプリングが完全に同じにならない場合は、速度の比較と回答品質の比較を分けます。回答の内容が違うことを速度差の根拠にしません。
• タスクマネージャーのGPU使用率はエンジンごとの表示場所や瞬間値を含むため、GPUグラフだけでオフロード完了と断定しません。設定、Processor表示、専用VRAM、実行ログを合わせます。
• 3回の平均だけでなく中央値と最小・最大を記録します。最初の1回だけ遅いなら、ロードやキャッシュの違いを疑います。

LM Studioで測る手順

LM Studioは画面操作で始めやすい一方、モデル別の設定とサーバー/APIの設定が別の場所にあります。まずチャット画面で同じ条件を測り、必要な場合だけREST APIやLocal Serverへ進みます。

1. My Modelsから測るモデルを選び、モデル名、GGUFファイル、量子化、ファイルサイズを記録します。モデルの設定画面でコンテキストサイズ、GPUオフロード、Flash Attentionを確認します。
2. タスクマネージャーのパフォーマンスで、CPU、メモリ、GPUの専用メモリと共有メモリを表示してからモデルをロードします。ロード開始と完了の時刻を記録します。
3. 短い固定プロンプトを送り、最初のトークンまでの時間と、生成中に表示されるtokens/sを記録します。表示されない場合は、開始時刻、最初の表示時刻、完了時刻と出力トークン数を残します。
4. 同じモデルを再実行し、coldとwarmを分けます。設定を変えたら、GPUオフロードやコンテキストの変更内容を新しい測定行にします。

Ollamaで測る手順

Ollamaでは、APIの最後のレスポンスにロードと評価の時間が含まれる場合があります。時間の単位はナノ秒なので、秒へ直す式と、ストリーミング中の表示時間を混ぜないことを確認します。

1. 測るモデルを1つだけ呼び出し、同じモデル名、コンテキスト長、入力文、出力上限を使います。環境変数や同時実行を変えた場合は別条件です。
2. ollama psでCONTEXTとPROCESSORを確認し、CPU実行・GPU実行・部分配置のどれかを記録します。ピークRAMとピークVRAMはWindowsタスクマネージャーなどで別に観察します。
3. APIを使う場合は、最後のチャンクにあるtotal_duration、load_duration、prompt_eval_count、prompt_eval_duration、eval_count、eval_durationを保存します。
4. load_durationをモデルロード、prompt_eval_durationを入力処理、eval_durationを生成処理として分け、eval_count ÷ eval_duration × 1,000,000,000で生成tokens/sを計算します。

LM StudioとOllamaを同じPCで比べる

2つのランタイムを比べる場合、同じPCで同じモデルを順番に動かすだけでは、キャッシュ、バックグラウンドプロセス、GPUメモリの残り方がそろわないことがあります。結果は「この条件での観察」として残し、ツール全体の優劣へ広げません。

測定結果を症状へ戻す

• LM Studioが遅い・途中で止まる時の症状別チェック - 症状をロード・prefill・decode・メモリへ分ける
• LM StudioのGPUオフロードとは？ - CPU 100%やGPU使用率を設定と合わせて読む
• ローカルAIのモデルサイズ早見表 - ファイルサイズとPCの余白を分けて考える
• メモリ8GB・16GB・32GBで始める前に - 空き容量とピーク使用量を記録する
• コンテキスト長とは？ - 長文やPDFで重くなる条件を固定する

RAM・VRAM・モデルサイズ・contextの関係

モデルのファイルサイズは必要メモリの目安にはなりますが、実行中のピークRAMやVRAMそのものではありません。重み、ランタイムの作業領域、KVキャッシュ、Windowsと他アプリを分けて測ります。

モデル重み

GGUFファイルの主な大きさ。Q4/Q5/Q8など量子化で変わりますが、ファイルサイズだけで速度や品質を断定しません。

ランタイムの作業領域

ロード、バッチ、GPUオフロードなどに必要な実行時の領域。アプリや設定で変わります。

KVキャッシュ

会話や入力をコンテキスト内で保持するための領域。コンテキスト長を増やすほど負荷が増える場合があります。

Windows・他アプリ

OS、ブラウザ、同期、セキュリティソフトなどが使う領域。ローカルAIへ全容量を割り当てられるわけではありません。

GPU使用率が低い・CPU 100%をどう読むか

GPU使用率が低いことだけで「GPUが使われていない」と決めません。どのGPUエンジンを見ているか、専用VRAMが増えているか、設定上のGPU layersやProcessor表示が何を示すかを合わせます。Windowsの表示は環境やバージョンで見え方が変わるため、瞬間値ではなく測定中のピークと設定を残します。

よくある誤測定

• ファイルサイズだけを比べ、量子化、コンテキスト、オフロード、RAMの余白を記録していない。
• 最初のロード待ちを生成速度へ含めたり、逆にロード時間を無視して「速い」と判断している。
• 入力文や出力長が違うままtokens/sを比較している。
• タスクマネージャーの一瞬のGPU使用率だけで、モデル全体がVRAMに載ったと断定している。
• Apple SiliconやデータセンターGPUの論文値を、そのままWindowsノートPCの目標値として扱っている。

測定に失敗した場合は、まずモデルを1つ、短い入力、短い出力、標準的なコンテキストへ戻します。それでも途中で止まるなら、同時起動アプリを減らし、ピークRAM・VRAMとエラー表示を保存して、症状別ハブへ戻ります。

llama-benchを使う発展測定

llama.cppのllama-benchは、アプリの画面表示ではなく、prompt processing（pp）、text generation（tg）、prompt processing後にgenerationを続けるpgを反復して比較する開発者向けの方法です。GPU layersやFlash Attentionなどの条件を明示できますが、トークナイズやサンプリングなどを含まないため、チャット画面の体感と同じ値ではありません。PowerShellではモデルパスを引用符で囲みます。

llama-bench -m "C:\models\example.gguf" -p 512 -n 128 -r 5 -o json
llama-bench -m "C:\models\example.gguf" -pg 512,128 -r 5 -o json

コピーして使う測定記録テンプレート

以下をそのままメモに貼り、条件を変えるたびに新しい行を追加します。数値が取れない項目は空欄にせず、「表示なし」「未確認」と書くと後から誤解しにくくなります。公開するときは、ユーザー名、PC名、個人ファイルのパス、秘密や業務プロンプトを削除または伏せます。

## ローカルAI実測記録

- 測定日:
- PC / Windows:
- CPU:
- RAM容量 / 測定中のピークRAM:
- GPU / 専用VRAM / 測定中のピークVRAM:
- ランタイム / バージョン:
- backend / engine:
- モデル / GGUFファイル / 量子化 / ファイルサイズ:
- モデルリビジョン / 変換条件:
- コンテキスト長:
- GPUオフロード / Processor:
- Flash Attention / eval batch:
- 入力プロンプト（固定文）:
- 実入力トークン数（分かれば）:
- 出力上限:
- 冷たい開始 or 暖かい開始:
- モデル読み込み時間:
- TTFT（最初のトークンまで）:
- 生成tokens/s:
- 測定回数 / 中央値 / 最小 / 最大:
- 同時起動していたアプリ:
- ドライバ / 電源モード / 冷却・温度状態（分かれば）:
- 観察した症状・エラー:
- 次に変える条件（1つだけ）:

測定後の判断フロー

1. ロードだけが遅いなら、ストレージ、モデルサイズ、空きRAM/VRAMを確認し、モデルを小さくする前に「どの段階が遅いか」を確定します。
2. TTFTが遅いなら、入力長、コンテキスト長、PDF/RAGの検索処理、prefill条件を分けて測ります。
3. 生成中のtokens/sが遅いなら、GPUオフロード、CPU 100%、GPUエンジン、冷却、量子化を1つずつ確認します。
4. 途中で止まる、Windows全体が重いなら、ピークRAM/VRAMと共有メモリを確認し、同時起動アプリとコンテキストを減らして再測定します。
5. 条件を1つ変えた再測定で改善したものだけを採用し、複数の設定を同時に変えた結果は原因不明として残します。

• ローカルAI用PCスペックの見方 - 購入前・手持ちPCの条件を読む
• GPUなしPCでローカルAIは使える？ - 動くと快適の差を測って判断する
• VRAMとは？ - GPUメモリを専用・共有に分ける
• GGUFとは？ - 形式、配布元、量子化を分けて確認する

公式情報・論文と自分の測定を分ける

一次情報に設定やAPIの説明があっても、あなたのPCの速度を保証するわけではありません。論文の実験結果も、対象ハードウェア、モデル、ドライバ、ランタイム、測定方法が違えば同じ結果になりません。

• 公式：LM Studioのモデル別設定 - GPUオフロード、コンテキスト、Flash Attentionの設定位置を確認する
• 公式：LM Studio REST APIのモデル読み込み - context_length、eval_batch_size、load_time_secondsを確認する
• 公式：Ollama APIの使用量メトリクス - ナノ秒の時間値とcount/durationの対応を確認する
• 公式：Ollama FAQのProcessor表示 - CPU・GPU・部分配置の表示を確認する
• 論文：LIFEの推論性能モデル - TTFT・TPOT・TPSの研究上の扱いと適用範囲を確認する
• Local AI Compassの診断基準・測定の前提 - 公式情報と自分の実測を分ける基準を見る

2026年8月時点の公式APIで測定値を固定する

画面に表示されるtokens/sとAPIの完了メトリクスは、同じ記録表に入れても列を分けます。現行のOllama APIはロード・入力処理・生成を別のcount/durationで返し、LM Studioのnative `POST /api/v1/chat`は`stats`に入力・出力トークン、tokens/s、TTFTなどを返すためです。

LM Studioで`stream: true`を使う場合は、最初に表示された文字だけで成功と判定しません。公式のstreaming eventsは`chat.start`から始まり、通常は`chat.end`に集約された`stats`を含めて終わります。途中で`error`が出ても`chat.end`が送られる場合があるため、`error`、最終`chat.end`、完走・部分出力の状態を別列で保存します。

APIの公式フィールドは取り方をそろえる助けになりますが、別runtime・別モデル・別PCの速度を自動的に同列比較できるという意味ではありません。入力、出力上限、context、engine、offload、cold/warm、parallel数を固定し、設定変更は1つずつにします。

1. Ollamaは`/api/chat`または`/api/generate`の完了レスポンスを保存し、ナノ秒の項目を秒へ換算してロード・prompt・生成を別列にします。`done_reason`も残します。
2. LM Studioは現行native `POST /api/v1/chat`を使う場合、`stats`、`context_length`、履歴やtool定義の有無、モデルが既にロード済みかを保存します。
3. 同じ固定入力をcold/warm、parallel 1/複数要求で分け、TTFT・生成tokens/s・総時間・peak RAM/VRAMを比較します。
4. tool、PDF、RAGを追加する場合は、input tokens・tool call・抽出・embedding・検索の時間をモデル生成と別に記録します。

• 公式：LM Studio native chat API - POST /api/v1/chatのrequest、context_length、statsを確認する
• 公式：LM Studio streaming events - 完了時のstatsを測定ログへ保存する方法を確認する
• 公式：Ollama Generate API - done_reasonと完了メトリクスを確認する
• 公式：Ollama Chat API - チャットの最後のレスポンスを測定対象にする
• 公式：Ollamaのコンテキスト長 - num_ctxとメモリ条件を分けて記録する

次に読む順番

測定値を得たら、数字を集め続けるより、症状に対応する記事へ戻って1つだけ条件を変えるほうが実用的です。

• 1. LM Studioが遅い・途中で止まる時の症状別チェック
• 2. GPUオフロードとCPU/GPU使用率
• 3. モデルサイズとQ4/Q5/Q8
• 4. メモリ8GB・16GB・32GBの考え方
• 5. コンテキスト長と長文・PDFの負荷