RTX 5080でTTFTが速いLLM 8モデル実測｜phi4-mini 1194msが最速、リアルタイム対話の選定基準

TTFTとは、ユーザー送信から最初のトークンが返るまでの時間である。

チャットUIで「送信ボタンを押してから最初の文字が画面に出るまで」を短縮したいなら、見るべき指標はtok/sではなくTTFT (Time to First Token)。当サイトの検証環境（RTX 5080 16GB / i7-14700F / RAM 96GB）で8つのローカルLLMを計測したところ、phi4-mini:3.8bが1194msで最速、qwen3.5:9bが3299msで最遅という結果が得られました。tok/s最速のllama3.2:3b（272.8 tok/s）はTTFT 2781msで「話し出すまで」が遅く、初手応答型UIには不向き。tok/sだけでモデルを選ぶと、リアルタイム対話の体感速度を取りこぼします。本記事では2026年5月時点の一次実測データをもとに、TTFTとtok/sを2軸で切り分け、用途別の選定基準を提示する。

TTFTとは何か、なぜtok/sだけでは体感速度が決まらないのか

LLMの速度指標として広く知られているのはtokens/sec (tok/s) ですが、これは「最初のトークンが出てから後続のトークンが流れる速さ」を意味する。一方TTFT (Time to First Token) は「ユーザー送信から最初のトークンが返るまでのms」を指す。両者は別レイヤーの指標で、混同するとUI設計を誤ります。

TTFTの定義とユーザー体感への影響

チャットUIで読者が「速い／遅い」と感じる起点は、送信ボタンを押した直後の沈黙。ここに2〜3秒の空白があると、tok/sがどれだけ高くても「もたついている」という印象が残る。逆にTTFTが1秒前後なら、その後のtok/sが多少遅くても「会話が成立している」感覚を保てます。音声エージェントの場合は、ASR (音声認識) → LLM → TTS (音声合成) のパイプライン全体で応答ラグが累積するため、LLM単体のTTFTを縮める価値はさらに高まる。エンドツーエンドの応答遅延に占めるLLM寄与分を下げる発想が、リアルタイム対話設計の出発点。

tok/sとTTFTは別物（llama3.2:3bの逆転例を予告）

当サイトの検証データで象徴的なのが、llama3.2:3bの位置づけ。tok/sは272.8で全モデル中最速にもかかわらず、TTFTは2781msと遅い。3Bという小型モデルにもかかわらず初回応答が3秒近くかかる理由は、モデルロード後の最初の推論パスでKVキャッシュ構築に時間がかかること、Ollama側の初期化処理のオーバーヘッドが効いていることが考えられる。逆にmistral:7bは7Bと中堅サイズでありながらTTFT 1230msと速く、tok/s 157.9を維持。「モデルサイズ＝TTFT」という単純な比例関係は成立しないという結果。

「ストリーミング応答の体感が遅い」という相談で見落とされがちなのが、このTTFT軸の存在。tok/sだけのベンチマーク表を見てモデルを選ぶと、チャットUIの最初の沈黙時間を改善できないまま終わるケースが少なくありません。

検証環境と計測方法

ベンチマーク数値は計測環境とランタイムに強く依存するため、まず当サイトの検証条件を明示します。

ハードウェア構成

当サイトの検証環境は以下の通り。

本記事のTTFT・tok/sはすべてRTX 5080単体で実行した値。Oculink接続のRTX 5060 Tiは別系統の検証用で、本ランキングには含まれません。

計測条件と母数

各モデルはOllamaのストリーミングAPIで起動し、同一のプロンプトで初回応答のmsを計測。モデルは事前にウォームアップ済みの状態とし、初回ロードのコールドスタートは除外している。tok/sは生成全体の平均値。VRAM使用量はnvidia-smi基準でモデルロード後の実測値。本記事の数値はすべて2026年5月13日時点の一次計測データで、Ollamaバージョンや量子化ビットの変更で再現性は変動します。GGUF Q4_K_MデフォルトをOllamaが選択するパターンが多く、量子化条件もモデルごとに異なる点には注意。

8モデルのTTFT実測ランキング（2026年5月版）

ここからが本題の比較表。TTFT昇順でソートし、tok/sとVRAM使用量を併記しました。下位レイヤーのオプティマイザではなく、エンドユーザーから見た「話し出すまで」の体感に直結する数値です。

8モデル＋参考2モデルを一覧化。注目すべきはphi4-miniとmistral:7bが1200ms前後で並んでいる点と、deepseek-r1:8bが同サイズのllama3.1:8b（1572ms）より約1.7倍遅い点。

低レイテンシ帯（1000〜1600ms）

この帯に入るのはphi4-mini:3.8b、Mistral 7B（Ollama: mistral:7b）、llama3.1:8bの3モデル。サイズで見ると3.8B〜8Bの中小型に偏っており、初回応答の沈黙時間を抑えたい用途の第一候補。phi4-miniは1194msで唯一1200msを切る数値を出しました。mistral:7bは7Bモデルとしては初手応答が際立って速く、tok/s 157.9との両立が魅力。llama3.1:8bは1572msとやや遅れますが、8Bサイズで日本語・英語のバランスが取れた汎用モデルとして使いやすい。

中レイテンシ帯（2600〜3300ms）

DeepSeek R1 8B（Ollama: deepseek-r1:8b）（2740ms）、Llama 3.2 3B（Ollama: llama3.2:3b）（2781ms）、Gemma 3 4B（Ollama: gemma3:4b）（2991ms）、Qwen3.5 9B（Ollama: qwen3.5:9b）（3299ms）はいずれも2.6秒以上のTTFTを示した。この帯では「話し出すまで」の沈黙が体感に残るため、ストリーミング送出を前提としたチャットUIでは扱いづらい。逆にバッチ処理・長文生成のように「結果が一括で返ればよい」用途なら、tok/sの大小で選んで問題ない領域。llama3.2:3bはこの帯で最遅のTTFTを記録した一方、tok/sは272.8で全モデル中最速。バッチ翻訳やドラフト記事生成に向く性格。

tok/s × TTFT 2軸で見るモデル選定マップ

TTFTとtok/sを別軸として扱うと、モデルは4つの象限に分かれる。横軸をTTFT（左が速い）、縦軸をtok/s（上が速い）として整理しました。

初手応答型UI向け（チャット・音声）

象限①「TTFT速い × tok/s速い」に入るのはphi4-mini:3.8bが唯一。TTFT 1194ms × tok/s 245.0で、リアルタイム対話の総合最適解。次点で象限③「TTFT速い × tok/s中庸」にmistral:7b（1230ms / 157.9）とllama3.1:8b（1572ms / 152.0）が入る。tok/sは200前後あれば人間の読み取り速度を上回るため、チャットUI用途では象限①と③が事実上の選択候補。音声エージェントのように「最初の一言が出るまでが勝負」のUIでは、TTFTを最優先軸に置き、tok/sは150以上あれば十分という割り切りも成立する。

体感を考えると、TTFTが2秒を超えるとユーザーは「待たされている」感覚を覚えやすい。逆に1秒台前半なら「テンポよく返ってくる」印象を保てる。当サイトの検証データではphi4-miniとmistral:7bが1.2秒台で並び、この2モデルが対話UI設計の現実的な選択肢として浮上する。

長文生成型UI向け（要約・記事生成）

象限②「TTFT遅い × tok/s速い」の代表がllama3.2:3b。TTFT 2781msは遅い部類だが、いったん出力が始まれば272.8 tok/sで猛スピードで流れる。記事ドラフト・長文要約・バッチ翻訳のように「リクエストを投げて数秒待ち、その後に大量のトークンが流れてくる」UIなら、この特性はむしろ歓迎されます。象限④「TTFT遅い × tok/s中庸」にはdeepseek-r1:8b、Gemma 3 4B（Ollama: gemma3:4b）、qwen3.5:9bが入る。これらはチャットUIには不向きだが、qwen3.5:9bは日本語性能、deepseek-r1:8bは推論性能で固有の価値を持つため、用途次第で選択肢に残る。

象限を意識せずに「最新の高性能モデル」を選ぶと、ストリーミング応答のUIなのに推論系モデルを採用してしまい、初手の沈黙でユーザーが離脱するという失敗が起きやすい。「UIの形」と「象限位置」を照合する習慣が、モデル選定の事故を減らします。

phi4-miniがリアルタイム対話で総合最適解になる理由

8モデル比較で唯一象限①に入ったphi4-mini:3.8b。なぜこのモデルだけがTTFT・tok/sの両指標を制したのか、構造的な理由を見ていきます。

モデルアーキテクチャの裏付け

Microsoftが公開しているPhi-4-mini-instructのモデルカード（Hugging Face）によれば、Phi-4-mini-instructは3.8Bパラメータのdense decoder-only Transformerである。3.8Bという小型サイズが直接効くのは、各レイヤーの行列演算量とKVキャッシュサイズが小さい点。最初のトークン生成にはプロンプト全体のフォワードパスが必要で、ここでの計算量が小さいほどTTFTが縮みます。当サイトの検証ではTTFT 1194msという数値が出ており、3.8Bという軽量構造がTTFT短縮に有利という方向性と整合する結果。

加えてphi4-miniはMicrosoftが推論効率を意識して設計したモデルで、コンパクトなパラメータ数でも実用的な精度を確保する方針が公式モデルカードに記されています。同じ3〜4B帯のgemma3:4b（TTFT 2991ms）やllama3.2:3b（TTFT 2781ms）と比較すると、phi4-miniのTTFTは半分以下。サイズだけでなく実装最適化・トークナイザの構造などの差が、TTFT 1.2秒台という結果を生んだと考えられる。

想定ユースケース

phi4-miniが最も適するのは、初手応答が体感を支配するUI。具体的にはWeb上のチャットボット、社内ドキュメント検索のQ&Aフロント、音声エージェントのLLM部分、IDE統合のコード補完ポップアップなど。VRAM使用量は6.2GBと小さく、RTX 4060 Ti 8GBクラスのGPUでも動作余地がある点も実運用上のメリット。

一方で3.8Bという小型サイズゆえに、長文要約・複雑な推論・専門分野の高精度回答では14B〜32Bクラスのモデルに劣る場面がある。「最初の一言が速いことが価値を持つUI」かどうかを基準に、phi4-miniを採用すべきか判断する流れが現実的。リアルタイム対話の総合最適解という結論は、用途を絞った前提のもとで成立する話で、すべての用途で最強というわけではありません。

deepseek-r1:8bのTTFTが伸びる構造的理由

同じ8Bクラスでも、TTFTの結果は大きく分かれた。当サイトの検証環境（RTX 5080 16GB / i7-14700F / RAM 96GB / Ollama 0.22.1）ではllama3.1:8bのTTFTが1572ms、deepseek-r1:8bは2740msと約1.7倍の差。パラメータ数がほぼ同じなのに、なぜここまで差がつくのでしょうか？

thinking traceの影響

deepseek-r1系は推論モデルと呼ばれるカテゴリで、回答の前に内部的な思考過程（thinking trace）を生成する設計。<think>〜</think>のようなブロックで考えを書き出してから回答に移る仕組みです。

この構造がTTFTを直接押し上げる。「最初の可視トークン」が回答ではなく思考過程の冒頭になり、思考の長さがそのまま初手応答の遅延に積み上がる。当サイトの計測でTTFT 2740msという数値は、通常のthinking trace生成を経た結果と考えられる。

非推論系のllama3.1:8b（TTFT 1572ms）はプロンプト処理→直接回答という単純な流れ。パラメータ数ではなくモデル構造の違いが、初回応答の遅延を決定づけている。

推論系モデルの適性

deepseek-r1:8bがリアルタイム対話に向かないという話と、モデル自体が劣るという話は別物。tok/sは132.2と8Bクラスとして妥当な値で、思考過程を含めた回答品質では非推論モデルを上回るタスクもある。向くのはチャットUIではなく、バッチ処理寄りの用途。長文の分析・ロジカルな手順検討・複雑な質問への深い回答など、ユーザーが結果を待つ前提のタスクに合います。

用途別おすすめモデル早見表

当サイトの実測値（RTX 5080環境）を用途別に整理した早見表が以下。

リアルタイム対話系の3用途

音声エージェント・Webチャット・コード補完の3用途は、いずれも初手応答の速さが体感を決める。TTFT 1.5秒以下のphi4-miniかmistral:7b（TTFT 1230ms / tok/s 157.9）の二択が現実的。tok/sも160以上で、ストリーミング送出時の文字流れが詰まりません。

バッチ生成・推論系の2用途

長文要約はトータル生成時間が支配的なため、tok/s重視で選ぶ。llama3.2:3bは272.8 tok/sと最速で、初手の2.8秒さえ許容できれば後続生成が速い。推論タスクではdeepseek-r1:8bのthinking traceが回答品質に寄与する場面が多く、TTFTを犠牲にしても採用する価値があります。

Blackwell世代でローカルLLMがどう変わるか

Wccftechの報道によれば、NVIDIAはBlackwell GPUのNVFP4アーキテクチャで巨大モデル側の最適化を進めている。当サイトの検証スコープは3B〜14Bのローカル推論層ですが、上位層で蓄積された最適化（FP4変換・KVキャッシュ圧縮など）は順次中堅GPU側に降りてくる流れ。

上位層の最適化が中堅GPUに降りてくるか

RTX 5080のような中堅Blackwell GPUでも、Ollama・llama.cpp等のランタイムが最適化を取り込めばTTFTとtok/sはさらに改善する余地がある。本記事の実測値は2026年5月時点の基準点として残し、ランタイム・ドライバ更新ごとに再計測する運用が現実的でしょう。

よくある質問

Q. TTFT 1秒以下は実現可能ですか？

当サイトの実測では最速のphi4-miniでTTFT 1194ms。1秒以下を狙うには、より小型のモデル採用やプロンプト短縮、ランタイム側の最適化が必要になる。Ollama標準設定のRTX 5080環境では、3.8B以上のモデルで1秒以下は厳しいというのが現状の結果です。

Q. VRAM 8GB環境でも同様の結果が出ますか？

phi4-mini（VRAM使用量6.2GB）はRTX 4060 Ti 8GBクラスでも動作余地がある。ただしGPUの帯域幅・CUDAコア数が異なるとTTFTも変動する。本記事の値はRTX 5080基準の参考値として捉え、自環境での再計測が望ましいです。

Q. ストリーミング送出をオフにした場合もTTFTは気にすべきですか？

streaming=falseでは全生成完了まで何も見えないため、TTFTより全体のレスポンス時間が支配的になる。バッチ処理ではtok/s重視で構いません。

まとめ：迷ったらこれを選べ

リアルタイム対話用途ならphi4-mini一択。TTFT 1194msとtok/s 245.0で総合最適、VRAM 6.2GBという小ささも実運用上のメリット。低レイテンシのチャットでphi4-miniが手に合わない場合はmistral:7bが現実的な選択肢。長文要約ならllama3.2:3bの272.8 tok/sを最大活用、深い分析を求めるならdeepseek-r1:8bのthinking traceに頼る。tok/sだけ見ない選定軸を、自分の用途に当てはめて判断してみてください。

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

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