TTFTとは、ユーザー入力から最初のトークンが返るまでの時間（ms）である。
ローカルLLMの「体感速度」を決めているのは、tokens/secではなくTTFT（Time To First Token）。当サイトのRTX 5080実機計測では、mistral:7bが792ms、phi4-mini:3.8bが840msと1秒を切る応答速度を出した一方、tokens/sec最速のllama3.2:3bはTTFT 2557msで対話用途では遅く感じる結果に。「速いモデル」と「対話で快適なモデル」は別物だった。
この記事では、RTX 5080実測値を土台に、TTFTという軸でローカルLLMを選び直すための知識を体系的にまとめる。基礎概念の定義から、サブ秒応答が出るモデルの特徴、tokens/sec上位モデルが遅く感じる理由、用途別の選び方、トラブル対処までを一記事で整理した。
- 対話AIの体感速度を決めるのはtokens/secではなくTTFT（初トークン応答時間）
- RTX 5080実測でmistral:7b 792ms・Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） 840msがサブ秒応答を達成
- tok/s最速のllama3.2:3bはTTFT 2557msで対話用途では3倍遅く感じる非単調性
- TTFTとは｜ローカルLLMの体感速度を決める指標
- RTX 5080実測サマリー｜TTFT 1秒以下のモデル
- サブ秒TTFT組の実力｜Mistral 7B（Ollama: mistral:7b） 792msの安定性
- phi4-mini:3.8bがクラウドAPI水準でローカル動作する事実
- tok/s上位なのに遅く感じるパラドクス｜Llama 3.2 3B（Ollama: llama3.2:3b） 260.9 tok/s問題
- 3秒組の特性｜qwen3.5:9bとgemma3:4bが向く用途
- TTFTがモデルサイズに比例しない理由
- 用途別マッピング｜リアルタイム対話・バッチ要約・エージェント
- VRAM・消費電力・温度のトレードオフ
- 他GPUで動かす場合の目安｜RTX 5060 Ti 16GBとの比較観点
- まとめ｜TTFTで選ぶローカルLLMの実用解
- よくある質問
TTFTとは｜ローカルLLMの体感速度を決める指標
ローカルLLMの性能評価でよく目にするのはtokens/sec（毎秒生成トークン数）。しかしチャットUIで「速い」「遅い」を決めているのは、別の指標です。プロンプトを送ってから最初の文字が画面に出るまでの待ち時間、それがTTFT。tokens/secが秒間60で同じだったとしても、TTFTが0.8秒のモデルと2.5秒のモデルでは、人間が受ける印象は別物になる。
機械翻訳分野のレイテンシ論考（machinetranslation.com）でも、TTFTがユーザー体験における主要因として論じられています。当サイトの実測値はこの議論を、ローカル実機の具体数値で補完する位置付け。
TTFT と tokens/sec は別軸の指標
TTFTは「最初の応答までの遅延」、tokens/secは「応答が始まった後の速度」を測る指標。両者は完全に別の処理段階を反映しているため、相関は弱いケースが多い。
具体例を出すと、tokens/secが260.9と当サイト計測中で最速のllama3.2:3bでも、TTFTは2557ms。逆にtokens/sec 141.6と中位のmistral:7bは、TTFTが792msとサブ秒。生成中の速度は2倍近い差があるのに、応答開始のタイミングは3倍違うという結果でした。
| 指標 | 測るもの | 影響する要素 |
|---|---|---|
| TTFT（ms） | 入力後、最初のトークンが返るまで | プロンプト処理・コンテキスト初期化・モデル構造 |
| tokens/sec | 1秒あたりの生成トークン数 | パラメータ数・量子化・GPU性能 |
両指標は単独では「速さ」を語れない。対話用途ならTTFT優先、長文生成ならtokens/sec優先という使い分けが現実解。
人間が「遅い」と感じる閾値は概ね1秒前後
UX分野では、応答までの遅延が1秒を超えるとユーザーの注意が途切れやすくなるとされてきた。チャット型AIで「タイピングインジケーターが2秒以上動いていると違和感がある」と感じた経験はないですか？ これは1秒という閾値が体感に近いから。
サブ秒のTTFTを実現できているローカルLLMは、当サイト計測対象の中ではmistral:7bとphi4-mini:3.8bの2モデル。クラウドAPIに近い体感を、ローカル環境で実現できる選択肢として有力候補になる。
RTX 5080実測サマリー｜TTFT 1秒以下のモデル
ここからは当サイトの検証環境で計測した、9モデルのTTFTとtokens/secを提示する。数値は2026年5月10日の計測値。
検証環境と計測条件
検証環境のスペックは以下の通り。記事内で言及するTTFT・tokens/sec値はすべてこの環境での計測結果です。
| CPU | Intel Core i7-14700F |
|---|---|
| RAM | 96GB |
| GPU | NVIDIA GeForce RTX 5080（VRAM 16GB） |
| NVIDIAドライバ | 596.36 |
| Ollamaバージョン | 0.22.1 |
| OS | Windows 10（10.0.26200） |
| 計測日 | 2026-05-10 |
計測はOllamaのデフォルト量子化（Q4_K_M相当）で行い、各モデルに同条件のプロンプトを投入してTTFTとtokens/secを記録。再現性を重視するため、ドライバ・Ollamaバージョン・計測日まで明示しています。
モデル別TTFT・tokens/sec比較表
掲載対象は9モデル。VRAM 16GB制約下で動作確認できたものに絞っています。
| モデル | TTFT(ms) | tokens/sec | VRAM使用量 | 消費電力 | グループ |
|---|---|---|---|---|---|
| Mistral 7B（Ollama: mistral:7b） | 792 | 141.6 | 7.0GB | 265W | サブ秒組 |
| Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） | 840 | 227.2 | 5.6GB | 229W | サブ秒組 |
| Llama 3.1 8B（Ollama: llama3.1:8b） | 1171 | 134.3 | 7.4GB | 250W | 中間組 |
| Phi-4 14B（Ollama: phi4:14b） | 1216 | 75.6 | 11.7GB | 278W | 中間組 |
| gemma3:12b | 1664 | 77.9 | 10.5GB | 245W | 中間組 |
| Gemma 4 (8B)（Ollama: gemma4:latest） | 1922 | 135.2 | 11.3GB | 189W | 中間組 |
| DeepSeek R1 8B（Ollama: deepseek-r1:8b） | 2477 | 120.1 | 7.7GB | 243W | 3秒組 |
| Llama 3.2 3B（Ollama: llama3.2:3b） | 2557 | 260.9 | 4.9GB | 227W | 3秒組 |
| Gemma 3 4B（Ollama: gemma3:4b） | 2705 | 173.2 | 5.5GB | 203W | 3秒組 |
| Qwen3 14B（Ollama: qwen3:14b） | 2776 | 72.0 | 11.4GB | 264W | 3秒組 |
| Qwen3.5 9B（Ollama: qwen3.5:9b） | 3036 | 96.8 | 9.5GB | 227W | 3秒組 |
サブ秒組は2モデル、中間組は1〜2秒帯、3秒組は2.5秒以上のグループ。注目してほしいのは、TTFTがパラメータ数の昇順に並んでいない点。3.8Bのphi4-miniがサブ秒で、3Bのllama3.2が2.5秒超え、9Bのqwen3.5が3秒超え。サイズだけでは応答速度を予測できない事実を、この表は示している。
数値で見ると地味ですが、TTFT 800msと2500msの差は体感では「サクッと返ってきた」と「待たされた」の差。対話を主目的にローカルLLMを選ぶなら、最優先で確認すべき軸はTTFTです。
サブ秒TTFT組の実力｜Mistral 7B（Ollama: mistral:7b） 792msの安定性
サブ秒TTFTを実現した2モデルのうち、特に注目したいのがmistral:7b。tokens/sec 141.6・VRAM使用量7.0GB・GPU温度64°C・消費電力265Wというバランスで、対話と長文生成の両方に対応できる万能型。
応答速度・VRAM・消費電力のバランス
mistral:7bの実測値を整理すると、以下のような特徴が見えてくる。
- TTFT 792ms：チャットUIで違和感のないサブ秒応答
- tokens/sec 141.6：長文生成も実用的な速度
- VRAM 7.0GB：8GBクラスGPUでも何とか動かせる軽さ
- 消費電力 265W：TDPの範囲内で安定動作
7Bパラメータ帯としては平均的なVRAM消費に対し、応答速度の出方が頭ひとつ抜けている。海外のローカルAI評価記事（localaimaster.com「Best Small AI Models 2026」）でも、7-8B帯の応答速度比較でmistralが推奨候補に挙がっており、当サイト実測値と整合する評価でした。
7-8B帯でmistralが選ばれる理由
なぜ7Bクラスでサブ秒TTFTが出るのかは、断定できる根拠が公式から示されているわけではない。考えられる要因は以下の通り。
- プロンプト処理の最適化が効いている可能性
- トークナイザの初期化処理が軽量と推測される
- アーキテクチャ側でコンテキスト初期化が高速化されているとの見方もある
これらは推測の域を出ない。実機で安定して792msのTTFTが出ている事実が確認できているだけで、原因の特定は公式情報の更新待ちです。同じ7Bクラスのllama3.1:8bがTTFT 1171msと中間組に位置する点を踏まえると、パラメータ数だけで応答速度は決まらないという事実が際立つ。
実用的な観点で言えば、対話AIをローカル化したいなら最初の検討候補にmistral:7bを置くのが現実的な選択。VRAM 8GBクラスのGPUでも動作可能で、サブ秒応答とそこそこの生成速度を両立する点は他のモデルでは代替しにくい。
phi4-mini:3.8bがクラウドAPI水準でローカル動作する事実
サブ秒TTFTを出したもう一方、phi4-mini:3.8bにはさらに興味深い特徴がある。クラウドAPIで公開されているTTFT値とほぼ一致する応答速度を、ローカル実機で出している点。
クラウドAPI実測値との突合
外部ベンチマークサイトのArtificial Analysisが公開しているphi-4 mini のクラウドAPI上のTTFTは0.83秒。当サイトのRTX 5080実測値は840ms（≒0.84秒）。誤差10ms以内で一致している計算。
| 計測元 | TTFT |
|---|---|
| Artificial Analysis（クラウドAPI公開値） | 約830ms |
| 当サイト実測（RTX 5080ローカル） | 840ms |
ローカルLLMを「クラウドより遅い妥協案」と捉える先入観があったかもしれませんが、少なくともphi4-mini:3.8bでは応答開始の速さでクラウドAPIと並んでいる。tokens/secでクラウドサービスに勝つのは難しくても、TTFTという軸では肉薄できる事実が見えてきます。
3.8Bパラメータでの応答速度の意味
phi4-mini:3.8bはパラメータ数が小さいため、tokens/sec 227.2とllama3.2:3b（260.9）には及ばない。ただし対話用途では、tokens/sec差より先にTTFT差が体感に出る。phi4-mini:3.8bが840ms、llama3.2:3bが2557msという開きは、3倍以上の応答遅延差。
VRAM 5.6GBという軽さも実用的。VRAM 8GBクラスのGPUに余裕を持って収まり、他のアプリと同居しやすい。「対話AIをローカルで動かしたい、でもVRAM 16GBクラスのGPUは予算的に厳しい」という読者にとって、現実解として強い候補になる。
クラウドAPIと同等のTTFTがVRAM 8GBクラスで再現できる事実は、ローカルLLMの選定基準を変える可能性がある。「ローカル化＝速度妥協」ではなく、「対話用途ならローカルでも遅延を感じない選択肢が出てきた」と読み替えるのが正確。
tok/s上位なのに遅く感じるパラドクス｜Llama 3.2 3B（Ollama: llama3.2:3b） 260.9 tok/s問題
ベンチマーク数値を眺めていると陥りやすい罠がある。tokens/secが速ければ「速いモデル」だと判断してしまう癖。実機で動かすと、この前提が崩れる現象に出会う。
実測値の非単調性（サイズ順に並ばない）
llama3.2:3bは当サイト計測中で最速のtokens/sec 260.9。3Bパラメータという軽さも相まって、ベンチマーク表で見れば「最速モデル」という判断になりやすい。しかしTTFTを見ると2557ms。応答が始まるまで2.5秒以上待つ計算。
具体的に体感を比較すると以下の通り。
- Llama 3.2 3B（Ollama: llama3.2:3b）：2.5秒待った後にスムーズな高速生成
- Mistral 7B（Ollama: mistral:7b）：0.8秒で応答開始、その後やや遅めの生成
- 体感総合：mistral:7bの方が圧倒的に「速い」と感じる
短いやり取り（数行のチャット応答）が中心なら、生成スピードよりも応答開始の早さの方が体感を支配する。長文を一気に読みたい用途なら逆転するが、対話の主流は短文の往復。「tok/s上位＝対話で速い」という直感が崩れる典型例でした。
ベンチマーク数値の読み解き方
ベンチマークを読むときに必要なのは、用途とのマッチング。tokens/secだけ見て選ぶと、対話UIで「期待外れ」になりかねない。
具体的なチェック手順を整理すると以下のようになる。
- TTFTを最初に見る：1秒以下ならサブ秒組、2秒以上なら待ち時間が体感に出る
- 次にtokens/secを見る：100超えなら長文生成も実用範囲
- 最後にVRAM使用量とGPU余裕を確認：他アプリと同居するなら余裕がいる
この順序で評価すれば、「速そうに見えて遅いモデル」を選んでしまう失敗は減らせます。当サイトのベンチマーク表でTTFTを最初の列に置いているのも、この優先順位を反映した設計。
llama3.2:3b自体は「遅いモデル」ではない。TTFTを許容できる用途、たとえば長文要約・バックグラウンド処理・オフライン文章生成では、tokens/sec 260.9の速さが活きる。「対話に使うかどうか」で評価が変わるモデルです。
3秒組の特性｜qwen3.5:9bとgemma3:4bが向く用途
TTFT 2.5秒以上の3秒組は、対話用途では候補から外れる。ただし「使えないモデル」ではなく、用途を切り替えれば強みが出る。
バッチ用途では生成速度が支配的
非同期で処理を投げるバッチ用途では、最初の応答までの遅延より、トータルでの生成速度が重要。たとえば1000トークン分の文章を生成する場面を想定する。
- Gemma 3 4B（Ollama: gemma3:4b）：TTFT 2705ms + tokens/sec 173.2 で1000トークン約8.5秒
- Qwen3.5 9B（Ollama: qwen3.5:9b）：TTFT 3036ms + tokens/sec 96.8 で1000トークン約13.4秒
- Mistral 7B（Ollama: mistral:7b）：TTFT 792ms + tokens/sec 141.6 で1000トークン約7.9秒
mistral:7bがトータルでも速いケースですが、長文化するほどtokens/secの差が支配的になる。10000トークン規模の処理なら、tokens/sec差の方が結果を分けます。
TTFTを許容できる場面
3秒組が向く用途を具体化すると、以下のようなケース。
- 長文要約（数千〜数万トークンの入力を要約する処理）
- バッチで複数ジョブを順次処理（夜間に走らせる類のタスク）
- 文章校正・翻訳の一括処理
- 検索結果の再ランキング・分類タスク
これらの用途では、ユーザーが画面の前で待っているわけではない。応答開始が3秒遅れることに体感的な不満は出にくい。代わりに生成速度が処理時間を直接決めるため、tokens/sec優先の選択が合理的になる。
qwen3.5:9bやgemma3:4bを「遅いから使わない」と切り捨てるのは早計。「用途のレイヤーが違う」と捉え直して、使い分ける発想が建設的です。
TTFTがモデルサイズに比例しない理由
実測値を見ると、TTFTはパラメータ数の昇順に並ばないという結果が出ている。3.8Bのphi4-miniが840ms、3Bのllama3.2が2557ms、9Bのqwen3.5が3036msという非単調性は、何が原因なのか？ 公式から決定的な説明は出ておらず、推測の域を出ません。
量子化と TTFT の関係（弱い相関）
当サイト計測はすべてOllamaのデフォルト量子化（Q4_K_M相当）で揃えている。量子化レベルが同じ条件下で、これだけTTFT差が出る事実は、量子化単独ではこの非単調性を説明できないことを示している。
| 観点 | 影響度（推測） | 備考 |
|---|---|---|
| 量子化レベル | 弱い | 同条件でも大きな差が出る |
| パラメータ数 | 中程度 | 大きすぎると遅くなる傾向はあるが線形ではない |
| モデル構造 | 大きい可能性 | アーキテクチャ差が支配的との見方もある |
量子化を変えればTTFTも変動はする。ただし「量子化を上げればTTFTが線形に下がる」という単純な関係ではないと考えられる。
モデル構造側の要因
TTFTがモデル構造側で決まる要因として、以下のような可能性が議論されている。
- アテンション機構（attention head数や層構造）の差
- トークナイザの初期化コスト差
- コンテキスト初期化処理の実装差
- KVキャッシュの確保タイミング
これらはモデル設計時の選択であり、量子化や推論実装側のチューニングだけでは埋められない部分。phi4-miniとllama3.2:3bのTTFT差（840ms vs 2557ms）が、パラメータ数だけでは説明できない理由はこのあたりにあると推測される。
ただし繰り返しになりますが、これは推測の域を出ない。Ollama側の実装やモデルアーキテクチャの組み合わせで決まる現象を、外部から定量的に分解するのは難しい。「TTFTは実機で計測しないと予測できない」というのが当サイトの結論。スペック表を眺めても、対話用途で快適なモデルかどうかは判断できず、計測値が必須情報として浮上する。
用途別マッピング｜リアルタイム対話・バッチ要約・エージェント
TTFTとtokens/secという2つの軸で当サイト計測9モデルを再整理すると、用途ごとに最適解が分かれる構図が見えてきます。チャットUIで使うなら速い初動が必須。長文要約を非同期で投げるなら生成速度こそ命。エージェントのように複数推論を連鎖させるなら、両方のバランスが効いてくる。一つの「最強モデル」は存在しません。
このセクションでは、TTFT軸とtok/s軸を二次元マトリクスとして読み解き、用途別にどのモデルが適するかを整理します。
対話UIならサブ秒TTFT必須
リアルタイム対話に求められる条件は明確。ユーザーが質問を送信してから1秒以内に最初の文字が表示されること。この基準を満たすのは、当サイト計測9モデルのうちmistral:7b（792ms）とphi4-mini:3.8b（840ms）の2モデルだけ。
| 用途 | 推奨モデル | TTFT | tokens/sec |
|---|---|---|---|
| リアルタイム対話 | Mistral 7B（Ollama: mistral:7b） | 792ms | 141.6 |
| リアルタイム対話 | Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） | 840ms | 227.2 |
| 中間（許容範囲） | Llama 3.1 8B（Ollama: llama3.1:8b） | 1171ms | 134.3 |
llama3.1:8bは1171msとサブ秒には届かないものの、3秒組と比べれば対話体験は大きく改善する。「許容できる」ラインで使うなら選択肢に入る位置。逆に言えば、対話用途で2.5秒以上のTTFTを示すモデル群（Llama 3.2 3B（Ollama: llama3.2:3b）、Gemma 3 4B（Ollama: gemma3:4b）、Qwen3.5 9B（Ollama: qwen3.5:9b））は、いくらtokens/secが速くても対話UIには向かないという判定になります。
phi4-mini:3.8bは生成速度も227.2 tok/sと高く、対話開始の速さと文章生成の速さを両立する稀少なモデル。VRAM消費も5.6GBと軽く、8GB級のGPUでも動作する。バランス型として最初に試す候補に挙げられるのではないでしょうか。
エージェントは複数推論を連鎖させるためバランス重視
エージェント用途（ツール呼び出しやチェーン処理）は、対話UIともバッチ処理とも違う独特な要件を持つ。1つのタスクで5回〜10回の推論を連鎖させる場合、各回のTTFT遅延が累積して全体の応答時間を決めることになります。
たとえばqwen3.5:9bで5回連鎖させると、TTFTだけで15秒以上の遅延が積み上がる計算。これはユーザー側から見れば「動作が止まっているように見える」状態。エージェント用途では、TTFTとtok/sの両方が中位以上のバランスが取れたモデルが向くと考えられます。
| 用途タイプ | 評価軸 | 当サイト計測の候補 |
|---|---|---|
| リアルタイム対話 | TTFT < 1000ms | Mistral 7B（Ollama: mistral:7b）、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） |
| エージェント連鎖 | TTFT < 1500ms かつ tok/s 130+ | Llama 3.1 8B（Ollama: llama3.1:8b）、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） |
| バッチ要約 | tok/s 150+ | Llama 3.2 3B（Ollama: llama3.2:3b）、Gemma 3 4B（Ollama: gemma3:4b）、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） |
| 長文生成 | tok/s 100+、VRAM余裕 | Mistral 7B（Ollama: mistral:7b）、Llama 3.1 8B（Ollama: llama3.1:8b） |
phi4-mini:3.8bが対話・エージェント・バッチの3用途すべてに登場する点は注目に値する。3.8Bパラメータでこのバランスを実現している事実は、サイズ別の常識を覆すデータと言える。
VRAM・消費電力・温度のトレードオフ
TTFTが速いモデルが必ずしも省電力・低発熱とは限らない事実を、当サイト計測値は明確に示しています。mistral:7bは265Wを記録し計測9モデル中で最も高い消費電力。phi4-mini:3.8bは229Wでやや低めだが、それでも200W超え。「TTFTが速い＝GPU負荷が低い」という直感は実測値とは合いません。
VRAMの観点でも、対話用途で推奨される2モデル（Mistral 7B（Ollama: mistral:7b） 7.0GB、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） 5.6GB）は、8GB級GPUでもギリギリ動作する程度の消費量。日常使いするなら12GB以上のVRAMが安心という結論に向かいます。
消費電力とTTFTの関係は弱い
消費電力とTTFTの相関を当サイト計測値で確認すると、明確な比例関係は見えてきません。
| モデル | TTFT(ms) | 消費電力(W) | GPU温度(°C) |
|---|---|---|---|
| Mistral 7B（Ollama: mistral:7b） | 792 | 265 | 64 |
| Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b） | 840 | 229 | 59 |
| Llama 3.1 8B（Ollama: llama3.1:8b） | 1171 | 250 | 55 |
| Llama 3.2 3B（Ollama: llama3.2:3b） | 2557 | 227 | 61 |
| Gemma 3 4B（Ollama: gemma3:4b） | 2705 | 203 | 61 |
| Qwen3.5 9B（Ollama: qwen3.5:9b） | 3036 | 227 | 56 |
TTFTが792msと最速のmistral:7bが消費電力でも最大の265Wを記録する一方、TTFTが3036msと最遅のqwen3.5:9bは227Wに収まっている。「速いほど電気を食う」が単純には成り立たない構図。
GPU温度も同様で、TTFTとの相関は弱い。51°Cから64°Cの範囲に収まり、計測中にサーマルスロットリングを起こすモデルはなかった。RTX 5080の冷却性能の余裕がうかがえる結果。
VRAM 8GB / 12GB / 16GBで何が動くか
VRAM容量別に動作可能なモデルを整理すると、8GB／12GB／16GBで明確な境界線が引けます。
| VRAM容量 | 動作可能なモデル例 |
|---|---|
| 8GB | Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）、Llama 3.2 3B（Ollama: llama3.2:3b）、Gemma 3 4B（Ollama: gemma3:4b）、Mistral 7B（Ollama: mistral:7b）（ぎりぎり） |
| 12GB | 上記＋Llama 3.1 8B（Ollama: llama3.1:8b）、DeepSeek R1 8B（Ollama: deepseek-r1:8b）、Qwen3.5 9B（Ollama: qwen3.5:9b） |
| 16GB | 上記＋Gemma 4 (8B)（Ollama: gemma4:latest）、Gemma 3 12B（Ollama: gemma3:12b）、Phi-4 14B（Ollama: phi4:14b）、Qwen3 14B（Ollama: qwen3:14b） |
mistral:7bはVRAM 7.0GBを消費するため、8GB GPUではギリギリの動作。コンテキスト長を長く取ると不安定になる可能性があります。常用するなら12GB以上を推奨。
phi4-mini:3.8bは5.6GBで済むため、8GB GPUでも余裕を持って動作する。サブ秒TTFTを狙う読者で予算が限られる場合、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）＋VRAM 8GBクラスのGPUという組み合わせが現実的な解になります。
ただし16GB VRAMがあると選択肢が一気に広がる。RTX 5060 Ti 16GBは新品10万円前後で入手できる最安の16GB GPUであり、AI入門用途のコスパ基準として参照される位置にあります。
GPU性能を体感できる4K 60fps生成例
LLM推論とAI動画生成は同じVRAMを取り合うリソース。記事中で取り上げたmistral:7b（VRAM 7.0GB）を常駐させながら動画生成を回す場合、合計VRAM消費は16GBの上限に近づく。RTX 5080の16GBが「ギリギリ足りる」境界線であり、これより小さいVRAM容量だと並行運用は難しくなります。
逆に言えば、16GB VRAMがあれば対話用LLMを起動したまま動画生成ワークフローを走らせる運用が成立する。当サイトの検証環境はこの想定で構成されています。
他GPUで動かす場合の目安｜RTX 5060 Ti 16GBとの比較観点
本記事ではRTX 5080実測のみを提示しているが、当サイトの検証環境にはRTX 5060 Ti 16GBも含まれます。RTX 5060 Ti 16GBで同じモデルを動かした場合、tokens/secは下がる傾向にあり、TTFTも遅くなる可能性が高いと推測されます。CUDAコア数（5080: 10752 vs 5060 Ti: 4608）と帯域幅の差が、推論速度に直結するため。
ただし「動作するかどうか」という観点ではRTX 5060 Ti 16GBで本記事掲載のモデルはすべて動作可能。VRAM 16GBあれば、phi4-mini:3.8bからqwen3:14bまでの範囲はカバーできるという確認情報を提示できます。
VRAM 16GBクラスでの動作可否
VRAM 16GBクラス（RTX 5080、RTX 5070 Ti、RTX 5060 Ti 16GB、RTX 4060 Ti 16GB等）であれば、本記事で取り上げた9モデルはすべて動作する。違いはtokens/secとTTFTの数値そのもの、そして同時に動かせるバックグラウンドタスクの余裕度。
| GPU | VRAM | CUDAコア | 推論速度の傾向（推測） |
|---|---|---|---|
| RTX 5080 | 16GB | 10752 | 当サイト計測値の基準 |
| RTX 5070 Ti | 16GB | 8960 | 5080比で10〜20%減 |
| RTX 5060 Ti 16GB | 16GB | 4608 | 5080比で30〜50%減と推定 |
これらの推測値は、CUDAコア数とメモリ帯域幅から導いた目安。実機計測ではない点に注意が必要。RTX 5060 Ti 16GBの実測データは別記事で順次公開予定です。
tok/s と TTFT は GPU 世代で変動する
GPU世代が変わるとtokens/secもTTFTも変わります。RTX 4070 Super（VRAM 12GB）でphi4-mini:3.8bを動かす場合、CUDAコア数が7168でRTX 5080の66%程度。tokens/secはおおよそその比率まで落ちると推定されます。TTFTについても、PCIe世代やメモリ帯域の差が影響して、サブ秒を割れない可能性がある。
実測値はGPU世代・モデル・量子化レベル・コンテキスト長など複数の要因で変動する。本記事の数値はあくまで「RTX 5080 + Ollama 0.22.1 + Q4_K_M量子化」という特定条件下での記録です。読者の環境でそのまま再現される保証はない点に留意してください。
まとめ｜TTFTで選ぶローカルLLMの実用解
ローカルLLM選定はtokens/secでなくTTFTで決まる。これが当サイトのRTX 5080実測9モデルから導いた結論です。tokens/secで全モデル最速のllama3.2:3b（260.9 tok/s）が、TTFT 2557msで対話用途では遅く感じる現象。サイズ順に並ばない非単調なTTFT分布。クラウドAPI水準のTTFTがローカル実機で再現される事実。これらの発見が、本記事の差別化ポイント。
実用的な結論を3つにまとめます。
- 対話用途はmistral:7b（TTFT 792ms）かphi4-mini:3.8b（TTFT 840ms）
- バッチ要約はllama3.2:3b（260.9 tok/s）で十分
- TTFTはスペック表から予測できないため実機計測で確認すべき指標
| サブ秒TTFT組 | Mistral 7B（Ollama: mistral:7b）（792ms / 141.6 tok/s）、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）（840ms / 227.2 tok/s） |
|---|---|
| クラウドAPI比較 | phi4-mini ローカル840ms ≒ Artificial Analysis公開値0.83s |
| tok/s最速 | Llama 3.2 3B（Ollama: llama3.2:3b） 260.9 tok/s（ただしTTFT 2557ms） |
| VRAM要件 | サブ秒組で5.6GB〜7.0GB、8GB GPUでも動作可 |
| 計測環境 | RTX 5080 16GB / i7-14700F / RAM 96GB / Ollama 0.22.1 / ドライバ596.36 |
ローカルLLMをチャットUIで使うなら、まずmistral:7bかphi4-mini:3.8bを試してみてください。生成速度の数値（tokens/sec）だけを見て選ぶと、対話体験が想定より重く感じる結果になりかねない。実機でTTFTを計測する一手間が、選定精度を大きく上げることになります。
よくある質問
Q. tokens/secが速ければ会話も速い？
いいえ、対話用途ではtokens/secよりTTFTが体感速度を決めます。当サイト計測ではllama3.2:3bがtokens/sec 260.9で最速ですが、TTFTは2557ms（2.5秒）。逆にmistral:7bはtokens/sec 141.6と中位ですが、TTFTは792ms（サブ秒）。チャット画面で「最初の文字が早く出る」のはmistral:7bの方。会話の体感速度を決めるのは初動の速さであり、生成速度はその後の文章を読みやすさに影響する別軸の指標です。
Q. VRAM 8GBでもmistral:7bは動く？
動作はしますがギリギリのライン。当サイト計測でmistral:7bのVRAM消費は7.0GB。RTX 5060 Ti 8GBやRTX 4060 Ti 8GBで起動できますが、コンテキスト長を長くしたり他のアプリと並行起動するとOOM（メモリ不足）の可能性が高まります。常用するなら12GB以上を推奨。VRAM 8GBで対話用途を快適に使うなら、Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）（5.6GB消費）の方が余裕を持って動作します。
Q. RTX 4070 Super でも同じTTFTが出る？
同じ数値にはならないと推測されます。RTX 4070 SuperはCUDAコア7168でVRAM 12GB、対するRTX 5080はCUDAコア10752でVRAM 16GB。アーキテクチャ世代も異なるため、推論速度に差が出るのは自然。「動作するかどうか」では本記事掲載モデルの大半は動きますが、tokens/secもTTFTも数値は変動します。実機計測しないと正確な数値は出せないため、参考値として捉えてください。
Q. 量子化を変えるとTTFTは変わる？
量子化レベルを変えるとTTFTも変動はしますが、線形な関係ではないと考えられます。当サイト計測はすべてOllamaのデフォルト量子化（Q4_K_M相当）で揃えており、同条件下でも3.8B（840ms）と3B（2557ms）でTTFTが3倍違う事実が確認されている。量子化を上げればTTFTが必ず短くなる、という単純な関係にはなっていません。モデル構造側の要因（アテンション機構やトークナイザの実装差）が大きく影響している可能性があり、量子化単独では非単調性を説明できない構図です。
Q. ローカル実機でクラウドAPIと同等のTTFTは本当に出るのか？
phi4-miniに限っては、当サイト実測のRTX 5080環境で840ms、Artificial Analysisが公開するクラウドAPI公開値は0.83s（830ms）。ほぼ同等の数値が再現されています。ただしこれはphi4-miniという特定モデルでの結果。すべてのモデルでローカル＝クラウドAPI同等が成立するわけではなく、モデルアーキテクチャやサイズによって差は出ます。「ローカル実機でもクラウドAPI水準のTTFTが達成可能なケースがある」という事実が確認できた、というのが正確な表現です。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
