ローカルLLMをどれにするか選ぶとき、レビューやベンチ記事で見る「毎秒○トークン」「VRAM○GB」という数字が判断材料になる。ただ、その数字が手元のパソコンでそのまま出るとは限らない。実測では、同じモデルが16GBのGPU1枚で毎秒19トークン、2枚で毎秒125トークンと、6倍以上違った。モデルの中身は何も変えていない。変わったのは動かす条件だけだ。ほとんどの人は自分でベンチマークを取らない。だからこそ、人が出した数字を「どう読むか」を知っておくほうが、選定で失敗しない。ベンチは「このモデルは速い」と読むものではなく、「この条件では速かった」と読むものだ。
ここでは、ローカルLLMのベンチでよく出てくる数字が何を意味するのか、その数字が自分の環境でも出るのか、そして自分のGPUと用途にどう当てはめるかを順に整理する。すでにOllamaなどでモデルを動かしている人が、ベンチの数字に振り回されずに選べるようになることを狙いにしている。
ベンチで出てくる数字が何を指すか
速い・遅いと一口に言っても、ベンチに並ぶ数字は別々のものを測っている。自分の使い方でどれを見るべきかを先に知っておくと、数字が絞れる。
| 数字 | 何を表すか | 大きい／小さいとどうなる | 向く用途 |
|---|---|---|---|
| 生成速度 (tokens/sec) |
1秒あたり何トークン出力するか。文章を書き続ける速さ | 大きいほど長い出力が速く出そろう | 長文生成・要約・コード生成 |
| 初回応答 (TTFT) |
送信してから最初の文字が返るまでの待ち時間 | 小さいほど対話がキビキビ感じる | チャット・エージェント・補完 |
| VRAM使用量 | そのモデルがGPUメモリをどれだけ使うか | GPUの容量を超えると速度が崩れる／起動しない | 自分のGPUに載るかの判断 |
長い文章をまとめて書かせるなら、コーディングや要約のように生成速度が体感に直結する。出力が長いほど、毎秒のトークン数の差が待ち時間の差になって積み上がるからだ。逆に短い相づちを何度も返すチャットでは、本文が出そろう速さより、最初のひと文字が返るまでの間が気になる。この初回応答（TTFT）が長いほど、送信のたびに待たされる感覚になる。1秒待つのと0.1秒で返るのとでは、使い心地がまるで違う。そしてVRAMは、そもそもそのモデルが自分のGPUで動くかどうかの土台になる。
TTFTには、ひとつ読み方のコツがある。TTFTはモデルが大きいほど、また入力するプロンプトが長いほど伸びる。だからベンチで「TTFT ○ミリ秒」と見たときは、どれくらいの長さの入力で測ったかで変わってくる。短い質問でのTTFTと、長い文章を読ませたうえでのTTFTは別物だ。チャット用途の参考にするなら短い入力で測った値を、長文を読ませる用途なら長い入力での値を見る。まずは「自分はどの数字を気にするべきか」を決めると、ベンチが読みやすくなる。
その数字、自分の環境でも出るとは限らない
ベンチの数字でいちばん誤解されやすいのが、どこで測っても同じ数字が出る、という思い込みだ。実際には、生成速度もVRAMも測定条件に強く左右される。同じモデル・同じGPUでも、次のような違いで数字は動く。
- VRAMに収まるかどうか：GPUのメモリに載りきればCPU退避を避けやすく、高速に動きやすい。あふれてCPU側へこぼれると、一気に遅くなることがある。ここの影響がいちばん大きい。
- 推論エンジンのバージョン：Ollamaなど本体側の更新で、同じモデルの速度が変わることがある。手元の実測でも1〜2割動いたことがある。
- 量子化の強さ：同じモデルでも軽く圧縮した版と重い版では、速度もVRAMも変わる。
- thinkingの有無：thinking出力を含めて測るか、最終回答だけを測るかで、eval count（生成トークン数）や体感速度の見え方が変わる。
- GPUドライバ：ドライバやCUDA/Vulkan/Metal周りの更新で、推論速度や動作可否が変わることがある。
どれくらい変わるのか、手元の実測で見てみる。総パラメータの大きいMoEモデルを、16GBのGPU1枚と、2枚に増やしてモデルを分散して載せた構成で測り比べた。
| モデル | 構成 | 生成速度(中央値) | 状態 |
|---|---|---|---|
| qwen3.5:35b-a3b | 16GB GPU 1枚 | 約19 tok/s | VRAMからあふれCPUへ退避 |
| qwen3.5:35b-a3b | 16GB GPU 2枚(計32GB) | 約125 tok/s | 全部GPUに載って約6.6倍 |
つまり、ある記事の「このモデルは毎秒125トークン」という数字は、2枚構成だから出た数字かもしれない。手元が1枚なら、同じモデルでも毎秒19トークンということが起こりうる。だからベンチの数字を見るときは、どんな環境で測ったのか（GPU・枚数・VRAM・本体のバージョン）を必ず確認する。それが書いていない数字は、自分のパソコンに当てはめられないと考えたほうがよい。とくにVRAMぎりぎりのモデルは、収まるか収まらないかで結果がまるごと変わるので、自分のGPU容量と照らし合わせて読む。
同じ名前のモデルでも、中身が変わっていることがある
もうひとつ見落としやすいのが、モデル名が同じでも中身が更新されている場合だ。配布元はタグ名を変えずにモデルの中身（digest）だけ差し替えることがある。手元では、あるMoEモデルが、名前はそのままに中身が更新された前後で、16GB1枚での生成速度が毎秒約19トークンから約66トークンへ3倍以上変わった。名前が同じというだけでは、半年前のベンチと同じものを指しているとは限らない。だから自分で測るときは、ollama show やタグ情報で確認できる digest（中身の識別子）と量子化レベルを控えておくと、後で「同じものを測ったか」を突き合わせられる。
これは、過去のベンチ記事の数字が、今ダウンロードした同名モデルでは再現しないことを意味する。古いベンチの数字を見るときは、いつ測ったものか、その時点のバージョンは何かをあわせて見る。日付やバージョンが書かれていないベンチは、最新のモデルにそのまま当てはまるとは限らない。逆に、日付と本体・モデルの版が明記されているベンチは、それだけで信頼度が一段上がる。
「速い」という数字に振り回されない
ベンチの数字は分かりやすいぶん、一人歩きしやすい。読むときに混同しないでおきたい点をまとめておく。
速い＝賢い、ではない
生成速度やTTFTは測れる数字だが、出力の賢さ・日本語の自然さ・コードの正しさは、これらの数字には表れていない。毎秒276トークン出る小さなモデルが、毎秒37トークンの大きなモデルより賢いわけではない。速度のランキングは「速さの順位」であって「使える順位」ではない。速さと品質は別の物差しとして読み、品質は速度ベンチとは別に、実際の出力例や用途別のレビューで確かめる。
VRAMの数字は「全体」か「モデル単体」かで変わる
VRAM使用量としてよく出る数字は、計測の仕方で意味が変わる。GPU全体の使用量（デスクトップ表示などの常駐ぶんを含む）を出しているのか、モデル単体の消費を出しているのかで、数GiBずれる。さらに、公称のモデルサイズと実際の消費もずれる。量子化の方式や、扱う文章の長さ（コンテキスト長）ぶんのメモリで膨らむためだ。「○GBのモデル」と書いてあっても、長い文章を入れれば実際の消費はもっと増える。VRAMの数字は、何を含んだ値で、どれくらいの文章量で測ったのかを意識して読む。
量子化の表記（Q4・Q8など）をどう見るか
ベンチには同じモデルでも「Q4_K_M」「Q8_0」といった量子化の表記が添えられていることが多い。これは重みをどれくらい圧縮したかを表していて、数字が小さいほど強く圧縮され、VRAMは減りやすい。多くの場合は速度面でも有利になりやすいが、実装や環境によっては単純に速くなるとは限らない。出力品質はわずかに落ちることがある。同じモデル名でも、Q4のベンチとQ8のベンチでは速度もVRAMも別物になる。比べるときは量子化をそろえる。表記がないベンチは、まず量子化条件が不明な数字として扱う。Ollamaなら ollama show やタグ情報で量子化レベルを確認できるので、比べる前に自分が使うタグの量子化を確かめる。
単位と「上限」表記に注意する
VRAMはGBとGiBで約7%ずれる。16GBのGPUは正確には約14.9GiBしか使えないので、「15GBまで使える」という数字は実は余裕がない。また、ある条件で測った最大値を「このモデルの上限」と書いてある場合、それはその条件での最大にすぎない。コンテキストを伸ばせばさらに増える。断定的な「上限」表記は、測定条件つきの参考値として受け取る。
「2倍速い」「+80%」の読み方
ベンチ記事では「2倍速い」「+80%高速化」といった倍率の見出しをよく見る。こうした数字は、何と何を比べたかで意味が変わる。本体やドライバの更新による前後比較なら、その更新を自分も入れれば近い改善が出るかもしれない。だが、上位のGPUとの比較や、量子化を変えた比較だと、自分の環境では同じ倍率にならない。倍率を見たら、まず「何を基準にした何倍か」を確かめる。基準が自分の構成と違えば、その倍率は自分には当てはまらない。
速度の差はどこから来るか
同じGPUでも、モデルによって生成速度は数倍違う。なぜ違うのかを知っておくと、ベンチの数字が直感に合わないときに理由を見抜ける。差を生むのは、主にパラメータ規模・量子化・モデル構造だ。規模が大きいほど1トークンあたりの計算が増えて遅くなり、量子化を強くかけるとメモリと計算が減って速くなる。そしてMoE（Mixture of Experts）型は、総パラメータが大きくても入力ごとに一部の専門家だけを使うため、サイズのわりに速いことがある。
だから「パラメータ数が多い＝遅い」とは限らない。実際に速度を決めるのは、動かすたびに計算されるぶんがどれだけか、という点だ。ベンチでサイズと速度が直感に合わないときは、量子化が強いのか、MoEなのかをまず見ると腑に落ちる。総パラメータ数だけでは速度を当てられないからこそ、実際に測られたベンチに価値がある。
自分の場合に当てはめる
数字の読み方が分かったら、最後は自分の環境に翻訳する。まず手元のGPUのVRAMで、どのくらいのサイズのモデルが現実的に動くかをつかんでおくと、ベンチを見たときの当たりがつく。下は16GBのGPU1枚で同じ条件をそろえて測った代表値だ。
| モデル | 規模 | 生成速度(中央値) | GPU全体VRAM使用量 |
|---|---|---|---|
| llama3.2:3b | 3B | 約276 tok/s | 約5.4 GiB |
| mistral:7b | 7B | 約153 tok/s | 約7.5 GiB |
| gemma4:12b | 12B | 約74 tok/s | 約10.8 GiB |
| phi4:14b | 14B | 約76 tok/s | 約11.9 GiB |
| gemma4:26b | 26B(MoE) | 約37 tok/s | 約15.2 GiB |
| qwen3:32b | 32B | 計測不可 | 16GBに載らず |
表で qwen3:32b が計測不可なのは、4ビット量子化でおよそ20GB前後あり、16GB1枚には載らないからだ。16GBの壁は、32B級の標準的な量子化（4ビット）のDenseモデルで見えやすい。この実測を基準にすると、手元のGPU容量から動かせるモデルの当たりがつけられる。
| GPUのVRAM | 現実的に動くモデルの目安 | 向く使い方 |
|---|---|---|
| 8GB | 3B〜7B級 | 小型モデルでの対話・補完 |
| 12GB | 7B〜12B級 | 中型まで、日常的な生成 |
| 16GB | 12〜14B級が快適、MoEで26B級もぎりぎり | 多くの用途をカバー |
| 24GB | 32B級まで | 大きめのモデルや長文 |
これはあくまで目安で、量子化を強くかければ下の容量でも大きいモデルが載ることはある。ただしそのぶん出力は荒れるので、容量に対して無理なサイズを詰めるより、余裕を持って載るサイズを選ぶほうが安定する。どうしても容量を超えるモデルを動かしたいなら、GPUを2枚使ってモデルを分散配置するか、推論エンジンを変える選択になる。エンジンによって速度やVRAMの出方が違うので、Ollama・llama.cpp・LM Studio・vLLMの比較もあわせて見ておくと判断しやすい。
用途のほうも翻訳する。コード補完やチャットのように短い応答を何度も返す使い方なら、生成速度が多少遅くてもTTFTが短いモデルが快適に感じる。長文の要約や翻訳をまとめて流すなら、最初の反応の速さより、本文がどれだけ速く出そろうかが待ち時間そのものになる。同じ「速いモデル」でも、どちらの速さなのかで向き不向きが分かれる。ベンチの数字を自分の用途の物差しに置き換えて初めて、選定の役に立つ。
長い文章を扱う用途では、話が一段変わる。プロンプトが長くなるほど、それを読み込む時間が伸びてTTFTが大きくなり、VRAMもコンテキストぶん増える。短い質問で測ったベンチの数字は、長文を流し込む使い方には楽観的すぎることがある。RAGや長文要約のように大きな入力を想定しているなら、できるだけ近い入力長で測られたベンチを探すか、短文ベンチの数字は少し割り引いて読むとよい。
ベンチを見て選ぶときの順番
数字の読み方を選定につなげるなら、見る順番を決めておくと迷わない。速度のランキングからいきなり選ぶのではなく、ふるいにかける順番がある。
- 自分のGPUで動くサイズに絞る：載らないモデルのベンチは、どれだけ速くても自分には関係ない。まずVRAMで候補を削る。
- 用途で見る指標を決める：長文生成なら生成速度、対話ならTTFTというように、見る数字を1つに絞る。
- 同じ条件で測られた数字どうしを比べる：環境やバージョンがそろったベンチの中で順位を見る。条件がバラバラの数字を横並びにしない。
- 速度が近ければ品質で決める：速度が拮抗していたら、あとは出力の質や日本語の自然さで選ぶ。ここはベンチの数字ではなく、実際に試すかレビューを見る領域になる。
VRAM、用途、速度、品質の順でふるいにかければ、速さの数字だけに引っぱられずに、自分に合うモデルへたどり着ける。
信頼できるベンチかどうかの見分け方
ここまでを裏返すと、信頼できるベンチの条件が見えてくる。数字を読むときの確認ポイントとして使える。
| 確認すること | なぜ見るのか |
|---|---|
| 測定環境（GPU・枚数・VRAM）が書いてあるか | 環境が違えば数字は数倍変わる。自分の構成と比べるために必須 |
| 日付と本体・モデルのバージョン | 更新で数字は動く。古いベンチは今のモデルに当てはまらないことがある |
| 複数回の平均か、1回だけか | 1回きりの数字は数パーセント揺れる。平均なら信頼度が上がる |
| 測定条件（プロンプトやthinking）がそろっているか | 条件がバラバラだと、モデルの差なのか条件の差なのか分からない |
| 速度と品質を分けて語っているか | 「速い＝良い」で押し切っているベンチは、用途への当てはめを誤らせる |
これらが書かれていないベンチが悪いわけではないが、自分の環境に当てはめる根拠としては弱い。条件が明記された数字を優先し、条件がない数字は「だいたいの目安」として軽く受け取るのが安全だ。
自分でも確かめたいなら
たいていは、条件のそろった他人のベンチを正しく読めれば十分で、自分で測る必要はない。それでも手元の構成で確かめたい場合、Ollamaなら難しいことはいらない。実行時に --verbose を付けるだけで、生成速度（eval rate）などの内訳が表示される。
ollama run llama3.1:8b --verboseこのとき、最初の1回はモデルの読み込みで遅くなるので捨て、同じ短い質問を数回投げて、表示される eval rate の中央値を見る。これで「自分のGPUでこのモデルがどれくらい出るか」の目安がつかめる。数字を残すなら、GPU・本体のバージョン・日付もセットでメモしておくと、後で他のモデルと比べられる。自分の1台ぶんのデータがあれば、ネットのベンチが自分の環境で何倍になりそうかの換算もしやすくなる。
ひとつ注意がある。--verbose やAPIで見える prompt eval は、厳密にはTTFT（初回応答）そのものではなく、入力プロンプトを処理する時間に近い指標だ。実際の初回応答には、モデルの読み込みやスケジューリング、最初のトークン生成も関わる。対話の体感を厳密に測りたいなら、ストリーミングで最初のトークンが届いた時刻を見るのが正確になる。
ベンチ数値の読み方まとめ
最後に、ベンチの数字を見るときの勘どころをまとめておく。
- 自分の用途に関わる数字を見る（長文なら生成速度、対話ならTTFT、大きいモデルならVRAM）。
- その数字がどんな環境・日付・バージョンで測られたかを確認する。
- 同名モデルでも中身が更新されていることがある。古いベンチは鵜呑みにしない。
- 速い＝賢いではない。速度と品質は別の物差し。
- VRAMは何を含んだ値か、単位はGBかGiBかを見る。
- 自分のGPUのVRAMと用途に当てはめて、初めて選定に使う。
数字そのものより、その数字がどんな条件で出たかのほうが、選ぶときには効いてくる。条件を確かめずに数字の大小だけで決めると、手元では再現しない選択になりやすい。逆に、条件を読み取れるようになれば、ベンチの数字は他人のものでも、自分の判断材料として使えるようになる。ベンチは読み方ひとつで、当てにも外れにもなる。
参考資料
- Ollama API（Generate / Chat）—
eval_count・eval_duration・prompt_eval_duration（ナノ秒）等の計測項目とthinkオプション - Ollama Tags API /
ollama show— digest・size・quantization_level の確認 - Ollama モデルライブラリ — qwen3.5 / qwen3 / gemma4 のサイズ・量子化（Q4_K_M / Q8_0 等）の確認
- NVIDIA GeForce ドライバ — GPUドライバの更新元
