deepseek-r1:8b の TTFT は llama3.1:8b の 4.5 倍

TTFTとは、リクエスト送信から最初のトークンが返るまでの応答時間である。

ローカルLLMの体感速度を決めるのは tokens/sec だけではありません。RTX 5080 で 7 モデルを横並び計測したところ、DeepSeek R1 8B（Ollama: deepseek-r1:8b） の TTFT は 4115ms、Llama 3.1 8B（Ollama: llama3.1:8b） は 910ms。同一の Llama3.1-8B-Base から派生したはずのモデル同士で約 4.5 倍の開き。サイズでも VRAM 容量でもなく、原因は思考型 LLM が抱える「思考フェーズ」という構造ペナルティにある。本記事では当サイトの RTX 5080 実測データを軸に、なぜ DeepSeek R1 8B（Ollama: deepseek-r1:8b） は出だしが遅いのに生成速度はむしろ Llama 3.1 8B（Ollama: llama3.1:8b） と同水準なのか、その分解結果を提示します。

思考型 LLM の TTFT が非思考型の 4.5 倍になる理由

「思考型 LLM は遅い」という印象は、ローカルで一度動かせば誰もが感じるところ。ところが何が遅いのかを分解せずに語ると、判断基準を誤ります。同じ 8B クラス・同じ VRAM 7〜8GB 帯のモデルで、TTFT だけが桁違いに長くなる現象が RTX 5080 上で観測されました。以下、まず数字を見るのが早いでしょう。

結論サマリー：同一ベースなのにTTFT 4.5倍

検証環境（RTX 5080 16GB / i7-14700F / RAM 96GB / Ollama 0.22.1）で計測した、DeepSeek R1 8B（Ollama: deepseek-r1:8b） と Llama 3.1 8B（Ollama: llama3.1:8b） のミニ比較が以下です。

ベースが同じLlama3.1-8B、VRAM使用量も0.3GB差、消費電力もほぼ同等。それでもTTFTだけが910msから4115msへと約4.5倍に伸びている、というのが計測値の事実。tokens/secはむしろ DeepSeek R1 8B（Ollama: deepseek-r1:8b） のほうが Llama 3.1 8B（Ollama: llama3.1:8b） より約10%低い。出だしが圧倒的に遅いのに、出始めてからの速度はほとんど変わらないという、奇妙な逆転構造になっています。

なぜ「同じベース」でこれだけ差が出るのか

純粋な計算量で説明しようとすると詰まります。両モデルともパラメータ数は8B、VRAM消費はほぼ同じ、量子化レベルもOllamaのデフォルト（Q4_K_M相当）で揃っている。にもかかわらずTTFTが4倍以上違うのは、出力の最初のトークンに到達するまでに DeepSeek R1 8B（Ollama: deepseek-r1:8b） が「内部で思考のためのトークンを大量生成している」ため。Ollama 公式のモデルカード（ollama.com/library/deepseek-r1:8b）には、DeepSeek R1 8B（Ollama: deepseek-r1:8b） が DeepSeek-R1-Distill-Llama-8B として公開されており、Llama3.1-8B-Base から強化学習で蒸留された推論モデルだと明記されている。DeepSeek 公式 GitHub でも <think> タグで囲まれた思考フェーズを明示している点が、4115ms という数字の根拠になります。

つまり TTFT 4115ms のうち大半は、ユーザーが見えないところで内部の reasoning トークンを吐き出している時間。tokens/sec が同等なのも当然で、生成エンジン自体の速度は同じLlama3.1-8Bベースなのですから差は出にくい。違いは「ユーザーに見せる前にどれだけ自問自答するか」、ここに集約されます。

RTX 5080 検証環境と計測条件

数字の信頼性は計測環境を晒しているかどうかで決まる、というのがベンチマーク記事の鉄則。当サイトでは以下の環境で 2026-05-06 に計測しました。

ハードウェア・ソフトウェア構成

検証に使用したPCの構成は次の通り。

GPU は RTX 5080 単体で、デュアルGPU構成のサブGPU（RTX 5060 Ti 16GB）はOllamaが認識しない設定にして単独計測。VRAM 16GB という同一条件で 7 モデルを順番にロードし、TTFT・tokens/sec・VRAM 使用量・GPU 温度・消費電力を nvidia-smi と Ollama 内部のメトリクスから取得しています。

TTFT・tokens/sec の計測定義

ベンチマークで紛れがちなのが「速度」の定義。本記事の数値はそれぞれ以下の意味で使っています。

TTFT（Time To First Token）は、推論リクエストを送ってから最初のトークンがユーザー側に返るまでの時間。単位はミリ秒。プロンプト処理（prompt eval）と思考フェーズの両方を含むため、思考型LLMでは特に大きく膨らむ指標です。

tokens/sec は、最初のトークンが出てから終了までの平均生成速度。TTFTを除いた純粋なデコード速度を表します。出始めてからどれだけ滑らかに文字が流れるか、という体感に直結する数値ですね。

この2つを分けて計測することで、「初回の遅さ」と「生成中の速さ」を独立に評価できる。ローカルLLMでは TTFT と tokens/sec が乖離するケースが多く、両方を見ないと選定を誤ります。

7 モデル TTFT 実測比較表

ここからが本題。同じ RTX 5080 環境で計測した 7 モデルを、TTFT・tokens/sec・VRAM・温度・消費電力の 5 軸で並べました。表に並ぶと「サイズ」と「TTFT」に相関がない事実が一目で見えてきます。

実測表（RTX 5080 / Ollama 0.22.1）

VRAM 使用量で並べ替えても、TTFT は単調増加していません。最も VRAM を食う Qwen3.5 9B（Ollama: qwen3.5:9b）（9.7GB）の TTFT が 3458ms である一方、より小さい Llama 3.1 8B（Ollama: llama3.1:8b）（7.6GB）が 910ms。サイズと TTFT は無相関、というのがこの表から最初に読み取れる事実。

表から読み取れる 3 つのパターン

7 モデルを TTFT 軸でグループ化すると、明確に 3 つのパターンが浮かび上がります。

パターン1：非思考型・中サイズ（TTFT 短い） — Llama 3.1 8B（Ollama: llama3.1:8b）（910ms）、Mistral 7B（Ollama: mistral:7b）（1119ms）。8B 前後のサイズで素直なアーキテクチャを持つモデルは、プロンプト処理が終わるとすぐに最初のトークンを出力。TTFT は 1 秒前後で収まり、対話用途で違和感がない速度。

パターン2：思考型（TTFT 長い） — DeepSeek R1 8B（Ollama: deepseek-r1:8b）（4115ms）、Qwen3.5 9B（Ollama: qwen3.5:9b）（3458ms）。サイズは中程度でも、内部に reasoning トークンを生成する構造を持つため TTFT が 3〜4 秒台に伸びる。tokens/sec はむしろ低めで、出力品質を取りにいく代わりに体感速度を犠牲にする系列。

パターン3：小型なのに TTFT が長い — Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）（3684ms）、Gemma 3 4B（Ollama: gemma3:4b）（3860ms）。3〜4B クラスでサイズは小さいのに、TTFT は思考型と同等に長い。Microsoft の Phi 系列や Google の Gemma 系列は学習データ・チューニング方針の違いでプロンプト処理に時間を要する傾向があり、サイズ＝速さの直感が外れるゾーン。

3 パターンに分けると、「TTFTを短くしたいなら Llama 3.1 8B（Ollama: llama3.1:8b） か Mistral 7B（Ollama: mistral:7b） の二択、思考型が必要なら DeepSeek R1 8B（Ollama: deepseek-r1:8b） で初動の遅さを許容する」という選択軸がそのまま見えてきます。

DeepSeek R1 8B（Ollama: deepseek-r1:8b） の正体と思考フェーズの仕組み

「思考型は遅い」とまとめてしまう前に、DeepSeek R1 8B（Ollama: deepseek-r1:8b） というモデルが何者なのかを公式情報で押さえておきます。出典が固まっていれば、TTFT 4115ms という数字の意味も腑に落ちる構造ですね。

ベースモデルと蒸留プロセス（公式情報ベース）

Ollama 公式モデルカード（ollama.com/library/deepseek-r1:8b）によれば、DeepSeek R1 8B（Ollama: deepseek-r1:8b） の正式名称は DeepSeek-R1-Distill-Llama-8B。Meta の Llama3.1-8B-Base に対し、DeepSeek-R1（フルサイズの推論モデル）の出力を教師データとした強化学習で蒸留したモデル、と明記されています。つまりベースアーキテクチャは Llama 3.1 8B（Ollama: llama3.1:8b） と同じ Llama3.1-8B 系列で、量子化レベル（Ollamaデフォルト Q4_K_M 相当）も近い。両者で VRAM 使用量が 7.9GB と 7.6GB と僅差なのは、この同根構造による帰結です。

DeepSeek 公式 GitHub（github.com/deepseek-ai/deepseek-r1）の README には、R1 系列が「テスト時間スケーリング（test-time compute scaling）」を推論パイプラインの中核に据える方針が書かれており、<think> と </think> というタグで囲まれた思考フェーズを生成してから最終回答を返す仕組みが明示されている。蒸留版である DeepSeek R1 8B（Ollama: deepseek-r1:8b） にもこの構造はそのまま継承されており、Llama3.1-8B のアーキテクチャに「思考のクセ」が学習で焼き込まれている、という理解が公式情報と整合します。

ベースは同じ、量子化も同じ、VRAM もほぼ同じ。違うのはトレーニング段階で叩き込まれた「最終回答の前にまず考える」という挙動だけ、と言い換えられます。

thinking phase が TTFT を押し上げる仕組み

ユーザーから見ると、DeepSeek R1 8B（Ollama: deepseek-r1:8b） に質問を投げると 4 秒間ほど何も返ってこず、その後にぱらぱらと文字が出始める、という体験になる。この「無音の 4 秒」の中で何が起きているかが TTFT 構造ペナルティの本質。

TTFT の内訳は大まかに以下のように分解されます。

非思考型では、プロンプトを処理し終わった瞬間から最終回答のトークンを返し始める。一方の思考型は、プロンプト処理に加えて <think>…</think> のブロックを内部で生成しきってから、ようやくユーザー向けの最終回答を吐き出す。tokens/sec が 136.4（DeepSeek R1 8B（Ollama: deepseek-r1:8b））と 151.5（Llama 3.1 8B（Ollama: llama3.1:8b））でほぼ同水準であることを思い出すと、思考フェーズで生成しているトークン数は概算で「(4115 − 910) × 0.001 × 136.4 ≒ 437 トークン」前後と見積もれます。約 400〜500 トークン分の自問自答が、ユーザーには見えない場所で走っている計算。

ここまで読むと、DeepSeek R1 8B（Ollama: deepseek-r1:8b） の TTFT 4115ms は「遅い」ではなく「設計通り」だと分かるはず。ただし設計通りであることと、用途に合うかどうかは別問題。次のパートでは tokens/sec と TTFT の逆転現象、サイズではなく系列で TTFT が決まる構造、そして実際のユースケースでどちらを選ぶべきかを掘り下げます。

tokens/sec と TTFT の逆転現象

ここからが体感差の本丸。生成速度（tokens/sec）だけ見ると差はほぼないのに、最初の応答が返るまでの沈黙時間に大きな開きが生まれます。

計算量では説明できないギャップ

当サイトの検証環境（RTX 5080 16GB / i7-14700F / RAM 96GB）の実測値を並べると、DeepSeek R1 8B（Ollama: deepseek-r1:8b） は 136.4 tok/s、Llama 3.1 8B（Ollama: llama3.1:8b） は 151.5 tok/s。差は約 10% にすぎません。一方で TTFT は 910ms と 4115ms と、4.5 倍差。仮に純粋な計算負荷だけが原因なら、tok/s も同じ比率で落ちるはず。実測はそうなっていません。差を生んでいるのは、ユーザーに見えない思考トークンの生成量です。

ストリーミング表示時の体感差

ストリーミング表示では、出始めた後の流速はほぼ同等。問題は「最初の1秒間に何も起きない」という沈黙。Llama 3.1 8B（Ollama: llama3.1:8b） は1秒未満で書き始める一方、DeepSeek R1 8B（Ollama: deepseek-r1:8b） は4秒間沈黙する。短い質問を投げる用途では、この体感差が決定的です。

「サイズ」ではなく「モデル系列」が TTFT を決める

軽いモデルなら TTFT も短い、と考えがちですが、実測は違う傾向を示します。

小型モデルが必ずしも速いとは限らない

実測値を抜粋:

• Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） → TTFT 3684ms（VRAM 5.8GB）
• Gemma 3 4B（Ollama: gemma3:4b） → TTFT 3860ms（VRAM 5.7GB）
• Mistral 7B（Ollama: mistral:7b） → TTFT 1119ms（VRAM 7.2GB）

3.8B クラスが 7B クラスより 3 倍遅い、という反直観的な現象。パラメータ数より「モデル系列が思考型寄りか、応答型寄りか」のほうが TTFT への影響が大きいと読み取れます。

モデル選定で見るべき2つの軸

ローカルLLM選定では、サイズだけでなく次の2軸で見る必要があります。

• 系列軸: 推論モデル（DeepSeek-R1系・Qwen3 thinking系）か、応答モデル（Llama3.1系・Mistral系）か
• 量子化軸: Q4_K_M / Q5_K_M / Q6_K のどれを使うか

VRAM 16GB に収まるかどうかは量子化軸、TTFT が許容範囲かどうかは系列軸で決まる構造です。

用途別の使い分け：思考型を選ぶべきケース・避けるべきケース

思考型は「常用」ではなく「用途で選ぶ」モデル。線引きを実用シーンに落とし込みます。

思考型が活きるユースケース

• コード生成（バグ修正・リファクタ・設計検討）
• 数学・論理パズル・段階推論が必要なタスク
• 長文ドラフトのリライトや構造化
• ユーザーが応答開始まで数秒待てるバッチ処理系

これらは初動の数秒沈黙が許容され、出力品質の向上が体感に勝るケース。

非思考型を選ぶべきユースケース

• チャットbot・対話UIで応答の即時性が要るとき
• 短文要約・キーワード抽出など軽量タスク
• 1秒以内に書き始めてほしいライブ字幕用途
• IDE 補完のように人間の思考速度に追随したい場面

Llama 3.1 8B（Ollama: llama3.1:8b） の 910ms と Mistral 7B（Ollama: mistral:7b） の 1119ms は、この層の有力候補。当サイト検証環境の実測でも、対話用途は応答型一択という結論になります。

主要スペックサマリー

よくある質問

Q. TTFT が長くても tokens/sec が同じなら結局同じ速度では？

長文生成だけなら近い速度に収束します。ただし短い応答や対話では「最初の1秒の沈黙」がそのまま体感の遅さに直結する点。100文字程度の応答だと、思考型は4秒沈黙＋0.7秒生成、応答型は1秒未満で書き終わる、という差になります。

Q. RTX 5060 Ti でも同じ傾向は出る？

傾向は同じく出ます。TTFT の絶対値は GPU 性能で多少伸びるものの、思考型と非思考型の比率（4〜5倍）は構造由来のため GPU を変えても消えません。当サイトの RTX 5060 Ti 16GB 検証でも、相対比は維持される結果でした。

Q. 思考型と非思考型はどちらを常用すべき？

「常用」を一本化するなら、用途の8割が対話・補完寄りなら非思考型（Llama 3.1 8B（Ollama: llama3.1:8b） 等）。コード支援・推論タスクが中心なら DeepSeek R1 8B（Ollama: deepseek-r1:8b） を別枠で用意する2モデル運用が現実解です。Ollama は複数モデルを同時保持できるため、用途で切り替える運用が手間なく組めます。

出典・参考

• DeepSeek-R1-Distill-Llama-8B 公式モデルカード (HuggingFace) — DeepSeek 公式が公開する 8B 思考型モデル。 Llama3.1-8B-Base から派生し、 DeepSeek-R1 生成サンプルで蒸留された経緯と推奨パラメータが記載されている。
• Llama 3.1 8B Instruct 公式モデルカード (Meta / HuggingFace) — Meta 公式の 8B 命令調整モデル。 128K コンテキスト長、 アーキテクチャ詳細、 学習リソース (H100-80GB 39.3M GPU 時間) が一次情報として確認できる。
• Ollama 公式ライブラリ: deepseek-r1:8b — 本記事で計測したタグの配布元。 サイズ 5.2GB / 128K コンテキストの公式記載があり、 ローカル実行時の量子化条件を一次情報として参照できる。

まとめ

同じ Llama3.1-8B-Base から派生した DeepSeek R1 8B（Ollama: deepseek-r1:8b） と Llama 3.1 8B（Ollama: llama3.1:8b） で、TTFT は約 4.5 倍の差。原因は計算量ではなく、思考型モデルが内部で生成する <think> トークン。サイズではなく系列で TTFT が決まる、という構造を押さえれば、用途別に最適なローカルLLMを選べます。対話・補完用途には応答型、推論・コード支援には思考型。RTX 5080 16GB であれば、両方を保持して用途で切り替える運用が最も合理的な選択肢。

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

計測時点: 2026-05-05 / 本ページの計測は上記時点のもの。製品アップデートや第三者ベンチマーク公表により評価が変わる可能性があります。30日以上経過した内容は再検証を推奨します。