ローカルLLMの記事を読んでいると、よくこんな数字が出てきます。
7 tok/s
20 tok/s
50 tok/s
200 tok/s
でも、数字だけ見せられても、正直どれくらいの速さなのか分かりにくいです。
「50 tok/sなら速い」と言われても、実際にどんな勢いで文章やコードが流れてくるのかを見たことがなければ、体感につながりません。
そんな疑問にかなり直接的に答えてくれるのが、「tokenspeed」というサイトです。
https://mikeveerman.github.io/tokenspeed
好きなtok/sを指定すると、その速度で疑似的にトークンを流してくれます。
例えば、51.7 tok/sのコード表示ならこちらです。
https://mikeveerman.github.io/tokenspeed/?rate=51.7&mode=code
実際に見れば、
「ああ、50 tok/sってこれくらいか」
と一発で分かります。
ただし、ここで一つ疑問が出ます。
そもそも「tok」って何なのか。
さらに調べていくと、同じ50 tok/sでも、モデルや文章によって見た目の速度が同じとは限らないことも分かりました。
この記事では、tokenspeedの紹介だけでなく、
- そもそもトークンとは何か
- tok/sとは何を測っている数字なのか
- 同じ50 tok/sでも体感が変わる理由
- トークン消費とは何か
- TTFTや入力処理速度との違い
- ローカルLLMでは何が速度を決めるのか
- 実際のミニPCで何tok/s出たのか
まで、できるだけ分かりやすく整理します。
そもそも「tok」とは何か
tokはtoken（トークン）の略です。
LLMは、人間が見る文章をそのまま「1文字ずつ」「1単語ずつ」処理しているわけではありません。文章をトークナイザーで細かい単位に分割し、その単位をトークンとして扱います。
例えば、イメージとしては次のような感じです。
今日はいい天気ですね
↓
[今日] [は] [いい] [天気] [ですね]
ただし、これはあくまで説明用のイメージです。
実際には、必ず単語単位で切れるわけではありません。1文字だけの場合もあれば、単語の一部、記号、句読点、空白を含むまとまりなどになる場合もあります。
OpenAIの公式説明でも、トークンは1文字ほど短い場合も、1単語ほど長い場合もあり、スペース、句読点、単語の一部もトークン数に関係すると説明されています。
https://help.openai.com/ja-jp/articles/4936856-what-are-tokens-and-how-to-count-them
重要なのは、トークンの切り方はモデルやエンコーディングによって異なるという点です。
つまり、同じ文章でも、モデルAでは100トークン、モデルBでは130トークンになることがあります。
では「50 tok/s」とは何か
tok/sは、tokens per second、つまり1秒あたり何トークン処理・生成したかを表す単位です。
LLMのベンチマーク記事で単に「50 tok/s」と書かれている場合は、回答を生成する速度、つまり出力トークンの生成速度を指していることが多いです。
例えば、500トークンを10秒で生成したなら、
500 ÷ 10 = 50 tok/s
です。
ただし、入力プロンプトを読む速度もtok/sで表現できます。そのため、厳密には「生成速度なのか」「入力処理速度なのか」を区別する必要があります。
Ollamaでは、APIの利用統計として次の情報を返します。
prompt_eval_count：処理した入力トークン数prompt_eval_duration：入力処理にかかった時間eval_count：生成した出力トークン数eval_duration：出力生成にかかった時間
https://docs.ollama.com/api/usage
出力生成速度は、概念的には次の式で求められます。
tok/s = eval_count ÷ eval_duration（秒）
Ollamaの--verbose表示では、これをeval rateとして直接確認できます。
同じ50 tok/sなら、どのモデルでも同じ速さなのか
厳密には同じとは言えません。
理由は、モデルやトークナイザーによって、同じ文章を何トークンに分けるかが違うからです。
例えば、同じ内容を出力するとして、
モデルA：100トークン
モデルB：150トークン
になったとします。
両方とも50 tok/sなら、
モデルA：100 ÷ 50 = 2秒
モデルB：150 ÷ 50 = 3秒
です。
つまり、同じ50 tok/sでも、人間から見た文章の出てくる速さが完全に同じとは限りません。
さらに、日本語、英語、コード、記号の多い文章など、内容によってもトークン密度は変わります。
そのため、tok/sは便利な性能指標ですが、人間が感じる速度を完全に共通尺度で表す数字ではありません。
「トークン消費がすごい」とは何か
AI関連でよく聞く「トークンを大量消費する」という表現も、同じトークンの話です。
例えば、
10,000トークンの資料を入力
↓
AIが2,000トークンの回答を生成
なら、少なくとも入力10,000トークンと出力2,000トークンが関係します。
会話履歴、長い資料、Web検索結果、コード、ツール実行結果などを何度もモデルに渡せば、入力トークンも増えます。
AIエージェントが、
検索
↓
検索結果を読む
↓
コードを書く
↓
実行する
↓
エラーを読む
↓
修正する
と繰り返せば、そのたびに扱うテキスト量が増え、トークン消費も大きくなります。
APIでは、入力トークンや出力トークンの量が料金に関係するサービスもあります。
この記事ではローカルLLMを中心に扱うため、APIの料金や速度については深掘りしません。APIではモデルが提供者側のサーバーで動くため、自分のPCのCPUやRAM、GPUとの関係が大きく変わります。
tok/sだけでは体感速度の全部は分からない
ここも重要です。
仮に生成速度が100 tok/sでも、回答が始まるまで10秒待たされたら、体感としては「速い」と感じないかもしれません。
LLMの待ち時間を見るときは、大きく分けて次の要素があります。
1. モデルの読み込み
モデルがまだメモリに載っていなければ、まず読み込み時間が発生します。
2. プロンプト処理（Prefill / Prompt Evaluation）
モデルは回答を始める前に、質問、会話履歴、システムプロンプト、ツール情報などを読みます。
3. 最初のトークンが出るまでの時間（TTFT）
TTFTはTime To First Tokenの略で、リクエストを送ってから最初の出力トークンが届くまでの時間です。
TTFTにはプロンプト処理だけでなく、モデル読み込み、キュー待ち、通信、アプリ側の処理などが含まれる場合があります。そのため、prompt_eval_durationとTTFTは同じものではありません。
4. 回答を生成する速度
ここが一般にtok/sとして注目される部分です。
つまり、
回答開始までの待ち時間 + 回答開始後の生成速度
の両方を見ないと、実際の使用感は分かりません。
tokenspeedは何をしてくれるサイトなのか
ここで本題のtokenspeedです。
https://mikeveerman.github.io/tokenspeed
このサイトは、指定したtok/sで疑似トークンを流し、数字だけでは分かりにくい速度を目で見て体感できるようにしたものです。
現在のWeb版には4つのモードがあります。
code
疑似コードを流します。
コーディング用LLMやコード生成AIの速度感を見るのに向いています。
text
通常の文章を流します。
チャットAIの回答速度をイメージしやすいモードです。
think
推論モデルが考えながら出力するような表示を疑似再現します。
agent
ツール呼び出し、コード生成、処理待ちなどを交互に表示し、AIエージェント風の動作を再現します。
サイトでは、5、10、20、30、60、100、200、400、800 tok/sといったプリセットを使えるほか、任意の速度も指定できます。
また、カスタムテキストを使ったり、プロンプト処理速度とコンテキスト長を設定して、最初の出力まで待つ感覚を疑似体験したりすることもできます。
ただし、tokenspeedは特定モデルの速度を完全再現するものではない
ここは誤解しやすいところです。
例えば、tokenspeedで51.7 tok/sに設定したからといって、
「この表示がGLMの51.7 tok/sそのもの」
「この表示がQwenの51.7 tok/sそのもの」
とは言えません。
tokenspeed自身が、BPE風のトークン化を近似しているだけで、tiktokenやClaudeなど、特定ベンダー・特定モデル固有のトークナイザーを正確に再現するものではないと説明しています。
https://mikeveerman.github.io/tokenspeed
つまり、正確には、
「51.7 tok/sという数字が、だいたいどのくらいの勢いで流れて見えるのかを体感するサイト」
です。
それでも、数字だけ眺めるよりは圧倒的に分かりやすいです。
実際にローカルLLMでtok/sを測ってみた
せっかくなので、実際のミニPCでOllamaを使い、複数モデルの生成速度を測定しました。
検証環境
| 項目 | 構成 |
|---|---|
| OS | Umbrel OS 1.7.3 |
| Kernel | Linux 6.12.85 |
| CPU | AMD Ryzen 7 5825U |
| CPU構成 | 8コア16スレッド |
| 最大クロック | 実機認識上 約4.546GHz |
| RAM | 64GB |
| RAM構成 | DDR4-3200 32GB×2 |
| GPU | AMD Radeon Graphics（Barcelo内蔵GPU） |
| SSD | WD_BLACK SN850X 4TB NVMe |
| 実行環境 | Ollama |
Ryzen 7 5825Uについて、PassMarkのAverage CPU Markは17,855でした（2026年7月10日時点）。PassMarkは日々更新されるため、将来は数値が変わる可能性があります。
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+7+5825U&id=4788
なお、PassMark CPU Markは一般的なCPU性能の参考値であり、LLM専用ベンチマークではありません。LLM推論速度をCPU Markだけで予測することはできません。
AMD公式仕様では、Ryzen 7 5825Uは8コア16スレッド、DDR4-3200対応、2メモリチャネルのCPUです。
今回、gemma4:e2b実行中にollama psを確認したところ、次のように表示されました。
NAME SIZE PROCESSOR CONTEXT
gemma4:e2b 6.9 GB 100% CPU 8192
つまり、少なくともこのgemma4:e2bの測定では、Ollama上で100% CPUとして実行されていました。
Ollamaでtok/sを簡単に測る方法
Ollamaなら、モデル実行時に--verboseを付けるだけで確認できます。
ollama run gemma4:e2b --verbose
回答後に、次のような情報が表示されます。
prompt eval count: 59 token(s)
prompt eval duration: 543.76ms
prompt eval rate: 108.50 tokens/s
eval count: 332 token(s)
eval duration: 19.131484s
eval rate: 17.35 tokens/s
この場合、見るべき生成速度は、
eval rate: 17.35 tokens/s
です。
入力処理速度は、
prompt eval rate: 108.50 tokens/s
です。
同じ「tokens/s」でも、入力処理と出力生成は別物です。
実測結果
今回の実測値をまとめると、次のようになりました。
| モデル | 主な実測生成速度 | 代表的な参考値 | 備考 |
|---|---|---|---|
gemma4:e2b | 17.35〜19.57 tok/s | 17.35 tok/s（332トークン） | 最も速かった |
hf.co/prism-ml/Bonsai-8B-gguf:Q1_0 | 12.67〜14.53 tok/s | 12.67 tok/s（578トークン） | Q1_0 |
gemma4:e4b | 9.55〜9.80 tok/s | 9.55 tok/s（945トークン） | 長文では約99秒生成 |
qwen3:8b | 6.96〜7.28 tok/s | 6.96 tok/s（160トークン） | 今回の中では最も遅かった |
重要な注意
この表は、厳密なモデル性能ランキングではありません。
理由は次の通りです。
- モデルごとにトークナイザーが違う
- 量子化方式が違う
- モデル構造が違う
- 入力した質問が完全には同一ではない
- 出力トークン数が違う
- 会話履歴の有無が違う場合がある
- Thinkingの量も違う
- コンテキスト状態が完全には同一ではない
そのため、この表の目的は「どのモデルが絶対に速いか」を決めることではなく、同じ検証機で実際に7〜20 tok/s程度の違いを体験した参考例として見ることです。
17.35 tok/sは実際どれくらいだったか
gemma4:e2bでは、332トークンを17.35 tok/sで生成しました。
332 ÷ 17.35 ≒ 19.1秒
実際のOllama出力でも、生成時間は約19.13秒でした。
17.35 tok/sの疑似体験はこちらです。
https://mikeveerman.github.io/tokenspeed/?rate=17.35&mode=text
個人的な体感では、17 tok/sは「快適」ではなく、かなり我慢すればギリギリ使うこともある程度でした。
基準としては、50 tok/s前後でようやく「普通に使いたい」と感じる速度です。
もちろん、この感覚には個人差があります。だからこそ、他人の「十分速い」「実用的」という評価だけを見るのではなく、自分で速度を体感できるtokenspeedに意味があります。
9.55 tok/sになると、長い回答はかなり待つ
gemma4:e4bでは、945トークンを9.55 tok/sで生成しました。
Ollamaの実測値は次の通りです。
eval count: 945 token(s)
eval duration: 1m38.991629s
eval rate: 9.55 tokens/s
生成だけで約99秒です。
9.55 tok/sの疑似体験はこちらです。
https://mikeveerman.github.io/tokenspeed/?rate=9.55&mode=text
さらに別の質問では、入力処理だけで約10.53秒かかりました。
prompt eval count: 410 token(s)
prompt eval duration: 10.530974s
prompt eval rate: 38.93 tokens/s
その後、296トークンを9.80 tok/sで生成し、全体では約44.2秒かかっています。
つまり、単に「9.80 tok/s」とだけ見ても、実際の待ち時間全部は分かりません。
生成前の入力処理にも時間がかかるからです。
同じ8B級でも速度は同じではなかった
今回、Bonsai-8Bとqwen3:8bも測定しました。
代表的な実測値を見ると、
Bonsai-8B Q1_0：約12.67 tok/s
qwen3:8b：約6.96〜7.28 tok/s
でした。
どちらも名前上は8B級ですが、速度は大きく違いました。
ここから分かるのは、パラメータ数だけ見てもtok/sは決まらないということです。
量子化、モデル構造、実装、CPU命令、メモリアクセス、コンテキスト、ソフトウェア側の最適化など、多くの要素が関係します。
速さだけでは回答品質も分からない
tok/sは速度の指標であって、回答の正確さを表す指標ではありません。
今回のBonsai-8Bでは、最初に「現在時刻は分からない」と正しく答えた後、追加で「どうしたら時間が分かるようにできる？」と尋ねると、時刻取得ツールもリアルタイム時計も使っていないのに、突然、具体的な時刻を断言する挙動がありました。
つまり、
速い = 正確
ではありません。
逆に、遅ければ賢いとも限りません。
速度と回答品質は分けて評価する必要があります。
CLIとOpen WebUIでも体感が変わった
同じローカルLLMでも、CLIから直接Ollamaを実行した場合と、Open WebUIを通した場合で体感が変わりました。
Open WebUI側では、
- システムプロンプト
- 会話履歴
- 利用可能なツール情報
- ツール呼び出し
- UI側のストリーミングや描画
などが追加される場合があります。
実際の検証では、Open WebUI側で日付や時刻を尋ねたとき、get_current_timestampツールが呼ばれ、正確な現在日時を取得できました。一方、CLI直実行ではそのツールがないため、モデルはリアルタイム時刻を取得できませんでした。
この違いがあるため、
「CLIでは速かったのに、Open WebUIでは遅く感じた」
からといって、単純にUIの性能だけが原因とは断定できません。
モデルに渡される入力や仕事量そのものが違う可能性があるからです。
この点も、tok/sだけでは実際の使用感を完全には説明できない例です。
ローカルLLMでは、CPUが良ければ必ず速くなるのか
必ずしもそうではありません。
ローカルLLMの速度には、少なくとも次の要素が関係します。
- モデルの大きさ
- モデル構造
- 量子化方式
- コンテキスト長
- CPU性能
- RAM容量
- RAM帯域
- GPU性能
- VRAM容量
- CPUとGPUへのオフロード割合
- 使用する推論バックエンド
- スレッド設定
- ソフトウェア最適化
特にCPU推論では、RAM容量とメモリ帯域が重要になる場合があります。
考え方としては、
RAM容量 = そもそもモデルを載せられるか
メモリ帯域 = 必要な重みをどれだけ速く読み出せるか
と考えると分かりやすいです。
llama.cppの開発コミュニティでも、多くの場合にメモリ帯域が主要なボトルネックになり得るという説明があります。
https://github.com/ggml-org/llama.cpp/discussions/394
ただし、すべてのモデル、すべてのハードウェアで必ずメモリ帯域だけがボトルネックになるわけではありません。
今回の検証機は64GBのDDR4-3200を32GB×2枚搭載していました。モデルをRAMに載せられても、今回の測定では最も速い参考値でも約17〜20 tok/sでした。
ここから少なくとも言えるのは、
モデルが載ることと、快適に使えることは別
ということです。
「ローカルLLMが動いた」という記事を見るときに確認したいこと
ローカルLLMの記事では、単に、
「動きました」
だけでは実用性を判断できません。
最低でも、次の情報があると判断しやすくなります。
- CPU
- GPU
- RAM容量と構成
- モデル名
- 量子化方式
- モデルサイズ
- CPU/GPUへのオフロード状況
- コンテキスト長
- 実測tok/s
- 入力処理速度
- 最初の出力までの待ち時間
- 長文生成時の速度
起動できることと、日常的に快適に使えることは別です。
例えば、今回のRyzen 7 5825U＋64GB DDR4-3200環境では、gemma4:e2bが約17.35 tok/sでしたが、体感としては「余裕で快適」ではなく、かなり我慢して使うレベルでした。
そのため、より低性能なCPUを使った記事で「ローカルLLMが動いた」と書かれていても、実測速度が示されていなければ、快適性までは判断できません。
tokenspeedで実測値を体感してみる
今回測定した代表値を、そのままtokenspeedに入れると次のようになります。
17.35 tok/s
https://mikeveerman.github.io/tokenspeed/?rate=17.35&mode=text
12.67 tok/s
https://mikeveerman.github.io/tokenspeed/?rate=12.67&mode=text
9.55 tok/s
https://mikeveerman.github.io/tokenspeed/?rate=9.55&mode=text
6.96 tok/s
https://mikeveerman.github.io/tokenspeed/?rate=6.96&mode=text
51.7 tok/s・コードモード
https://mikeveerman.github.io/tokenspeed/?rate=51.7&mode=code
このように並べると、7、10、17、50 tok/sの差をかなり直感的に確認できます。
ただし、繰り返しになりますが、tokenspeedは特定モデルのトークナイザーを完全再現するものではありません。
あくまで、数字を体感に変換するための疑似表示ツールとして使うのが適切です。
検証上の注意
この記事内のローカルLLM実測値は、特定の検証機、特定時点のOllama環境、各モデル、各プロンプトで得られた結果です。
同じCPU名でも、
- 冷却
- 電力制限
- RAM構成
- OS
- Ollamaやバックエンドのバージョン
- モデルファイル
- 量子化
- コンテキスト長
- スレッド数
- 他プロセスの負荷
などによって結果は変わります。
また、モデルごとにトークナイザーや出力内容が違うため、今回のtok/sを厳密な横並びランキングとして扱うことはできません。
この記事の実測値は、「同じ検証機でもモデルによって速度は大きく変わる」「tok/sだけでは体感の全部は分からない」ことを確認するための参考例です。
まとめ
LLMの記事で、
「この環境では50 tok/s出ます」
と言われても、数字だけでは実際の使用感が分かりにくいです。
tokenspeedを使えば、その数字がどんな勢いで流れて見えるのかを簡単に体感できます。
ただし、tok/sには注意点もあります。
- トークンの切り方はモデルやトークナイザーによって違う
- 同じtok/sでも見た目の速度が完全に同じとは限らない
- コードと普通の文章でも体感が変わる
- tok/sは回答開始までの待ち時間を表さない
- 入力処理速度と出力生成速度は別
- ローカルLLMではハードウェア構成や量子化、モデル構造などで速度が変わる
- 「動く」と「快適に使える」は別
- 速さと回答品質も別
それでも、
「20 tok/sとか50 tok/sとか言われても、実際どれくらいなのか分からない」
という疑問に対して、tokenspeedはかなり分かりやすい答えをくれるサイトです。
ベンチマーク記事を読むときに、数字をそのまま入力して見比べるだけでも役立ちます。
tokenspeed
https://mikeveerman.github.io/tokenspeed
参考資料
tokenspeed公式サイト
https://mikeveerman.github.io/tokenspeed
tokenspeed GitHub
https://github.com/MikeVeerman/tokenspeed
Ollama公式ドキュメント：Usage metrics
https://docs.ollama.com/api/usage
OpenAI公式：トークンとは何か、数え方
https://help.openai.com/ja-jp/articles/4936856-what-are-tokens-and-how-to-count-them
AMD Ryzen 7 5825U公式仕様
PassMark：AMD Ryzen 7 5825U
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+7+5825U&id=4788