ローカルLLM prefill（プロンプト処理）速度 GPU別ベンチマーク 2026年版：長文・エージェント用途で効くのは tok/sec より「最初のトークンまで」
**prefill（プロンプト処理）とは、ローカルLLM が入力を読んで最初のトークンを出すまでの処理です。** 生成速度（decode tok/sec）の陰に隠れがちですが、長文コンテキスト・エージェント・RAG 用途では体感時間の 8 割を占めます。RTX 5090 / 4090 / Apple Silicon の 4K〜128K トークン入力時の prefill tok/s と TTFT を GPU 別に実測比較し、なぜ Mac が長文で失速するかを解説します。
- #prefill
- #prompt processing
- #TTFT
- #ローカルLLM
- #RTX 5090
- #Apple Silicon
- #ベンチマーク
本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細は プライバシーポリシー をご覧ください。
結論：ローカルLLM の速さを decode（生成 tok/sec）だけで判断すると、長文・エージェント用途で見誤ります。体感を左右するのは prefill（プロンプト処理）速度と TTFT（最初のトークンまでの秒数）です。prefill は compute（FLOPS）律速。decode はメモリ帯域律速です。この違いから、CUDA コアで殴れる NVIDIA は prefill で Mac より大きく有利。RTX 5090 は 8B で約 10,000 tok/s 級。Mac は decode は健闘しても長文 prefill で失速しやすい。8K 超の入力で実効スループットが一桁 tok/s まで崩れる事例もあります。エージェント・RAG のように「長いプロンプトを毎回読む」用途では、decode より prefill を見てマシンを選んでください。
prefill 速度 GPU別 早見表 2026
急ぎで結論だけ持ち帰りたい方向けの早見表です。数値はいずれも本記事の後段の各表で扱っている値の再掲で、世代・量子化・バックエンドで変動するため「傾向値」として読んでください。
| GPU / SoC | 8B prefill tok/s | 32K入力 TTFT の目安 | メモ |
|---|---|---|---|
| RTX 5090（32GB GDDR7） | 7,000〜10,000 | 32B モデルで 約11秒 | Flash Attention 2 有効時。8B なら 1万トークンでも1〜1.5秒級 |
| RTX 4090（24GB GDDR6X） | 約 4,300 | RTX 5090 の約1/1.67 | Llama 3.1 8B prefill 実測 |
| RTX 5060 Ti 16GB | – | 16K 3〜5秒 / 64K 15〜25秒 | エージェント常用の実用ライン |
| Ryzen AI MAX+ 395（Strix Halo） | – | 16K 8〜14秒 / 64K 30〜50秒 | 長入力で prefill が支配的 |
| Mac Studio M4 Max（546 GB/s） | 数百〜1,000 級 | 16K 4〜8秒 / 64K 20〜40秒 | decode は健闘するが prefill は弱い |
| Mac（M5 世代、Neural Accelerator） | M4 比 最大4倍 | – | Apple が prefill 最大4倍高速化を公表 |
| Intel Arc B580 | – | 16K 8〜14秒 / 64K 40〜70秒 | 大入力は非推奨 |
| CPU 推論（DDR5-6000 環境） | – | 16K 要約 1回で 60〜120秒 | 長文タスクでは常識外に遅い |
「長文・エージェント・RAG は RTX 5090 級 / 短文・チャットなら Mac でも十分」 の1行が Phase 0 の判断軸です。以降の章で、なぜこの差が出るか。用途別にどこまで許容できるかを扱います。
30 秒サマリ：prefill と decode の違い
急ぎで結論だけ持ち帰りたい方向けに、30 秒で読める要約テーブルです。詳細は各章で扱います。
| 観点 | prefill（プロンプト処理） | decode（生成） |
|---|---|---|
| 律速要素 | compute（FLOPS）・行列演算スループット | メモリ帯域（GB/s） |
| 体感で効く場面 | 長文入力・エージェント・RAG・要約 | 短文チャット・コード補完 |
| 見るべき数値 | prefill tok/s、TTFT（秒） | decode tok/sec |
| 弱点のハード | Apple Silicon（M4 以前）、低 TDP モジュール、CPU 推論 | 低帯域 GPU、DDR4 CPU 推論、小 VRAM で PCIe オフロード発生時 |
| 高速化の主レバー | Flash Attention 2 / 3、KV キャッシュ量子化、入力削減 | メモリ帯域の高い GPU、量子化、投機的デコード |
3 行だけ覚えて帰れます：「入力が長ければ prefill が支配、入力が短ければ decode が支配」「prefill は演算量、decode は帯域」「エージェント・RAG なら prefill、チャットだけなら decode」。以降の章で、なぜこの区別が重要か。どの GPU がどこで強い/弱いかを実測で見ます。
ローカルLLM のベンチマークはほとんどが「Llama 70B で何 tok/sec 出るか」という decode（生成）速度 の話です。しかし、長い文書を要約させたり、エージェントに大量のコンテキストを渡したりすると、「生成が始まるまでが妙に遅い」と感じたことがあるはずです。その正体が prefill（プロンプト処理） です。本記事は、これまで decode 中心だったベンチマークの空白を埋め、prefill / TTFT に特化して GPU・Apple Silicon を比較します。なぜ Mac が長文で失速しやすいのか。その構造から解説します。
prefill と decode：律速要因がまったく違う
LLM 推論は 2 つのフェーズに分かれます。ここを理解すると、なぜマシンによって得意・不得意が出るのかが一気に腑に落ちます。
| フェーズ | 内容 | 律速要因 | 効くハード性能 |
|---|---|---|---|
| prefill（プロンプト処理） | 入力プロンプト全体を一括で読み込み、最初のトークンを出す | compute（FLOPS） | 演算ユニット数・行列演算スループット |
| decode（生成） | 1トークンずつ順に生成する | メモリ帯域 | VRAM / unified memory の帯域（GB/s） |
prefill は入力トークンを 並列に 処理できるため、演算器をフルに使い切る compute 律速のワークロードです。一方 decode は1トークンずつ逐次で、毎回モデル全体の重みを読み出すため、メモリ帯域がそのまま速度になります。decode がメモリ帯域律速である仕組みは「メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版」で詳しく扱っています。本記事はその裏面。compute 律速の prefill にフォーカスします。この違いが、NVIDIA と Apple Silicon の評価を分けます。
- NVIDIA（RTX 5090 等）：CUDA コアを大量に積み、行列演算スループットが高い → prefill が速い。GDDR7 で帯域も高い → decode も速い
- Apple Silicon（M4 Max 等）：unified memory の帯域は高く decode は健闘 → だが演算器の生スループットは NVIDIA に劣り prefill が弱い
だから「短い質問への応答は Mac でも十分速いのに、長文を入れると急に待たされる」という体感が生まれます。
prefill tok/s ベンチマーク：8B クラスで横並び
まず小型モデル（8B 級）で prefill スループットを比較します。compute 律速の差が最も素直に出る領域です。数値は公開ベンチの集約で、世代・量子化・バックエンドで変動するため「傾向値」として読んでください。
| 機材 | prefill tok/s（8B 級） | メモリ帯域 | 補足 |
|---|---|---|---|
| RTX 5090（32GB GDDR7） | 約 7,000〜10,000 | 1,792 GB/s | Qwen3 8B で 10,400 tok/s 報告。Flash Attention 2 が効く |
| RTX 4090（24GB GDDR6X） | 約 4,300 | 1,008 GB/s | Llama 3.1 8B prefill。5090 は約1.67倍 |
| Mac Studio M4 Max | 数百〜1,000 級 | 546 GB/s | decode は健闘するが prefill は NVIDIA に大きく劣る |
| Mac（M5 世代、Neural Accelerator） | M4 比 最大4倍 | – | Apple が prefill 最大4倍高速化を公表。弱点を補正 |
RTX 5090 が 8B で 約 10,000 tok/s 級 の prefill を出すのに対し、Mac は世代によるものの桁が1つ小さくなりがちです。注目すべきは Apple が M5 世代で 専用 Neural Accelerator により prefill を最大4倍高速化 と公表していること、これは「Mac は長文 prefill が弱い」という従来の弱点を、Apple 自身が最優先で潰しにきていることの裏返しです。
入力長を伸ばすと何が起きるか：4K → 32K → 128K
prefill の真価は入力長を伸ばしたときに表れます。compute 律速なので、入力トークン数にほぼ比例して prefill 時間が伸びます。モデルサイズ別の prefill tok/s（4K 入力時の傾向値）を見ます。
| モデル規模 | RTX 5090 prefill tok/s（4K入力） | コメント |
|---|---|---|
| 8B | 約 7,000〜10,000 | 小型ほど高速。1万トークン入力でも1〜1.5秒級 |
| 32B | 約 3,000 | 中型。32K 入力でも実用的な TTFT |
| 120B（MoE / gpt-oss 等） | 約 1,600 | 大型でも prompt processing は実用域 |
ここから TTFT（最初のトークンまでの秒数）を概算できます。例えば 32K トークンの入力を投げた場合、
- RTX 5090・32B（prefill 約 3,000 tok/s）：32,000 ÷ 3,000 ≒ 約11秒 で最初のトークン
- prefill が 1/5 のマシン（約 600 tok/s 相当）：32,000 ÷ 600 ≒ 約53秒 待ち
decode 速度が同じでも、prefill が遅いマシンは長文で TTFT が数倍に伸びます。
これがエージェント・RAG 用途で効いてくる差です。
なぜ Mac は長文で「一桁 tok/s」まで崩れるのか
Apple Silicon の prefill 失速は、実測でかなり極端な形で報告されています。象徴的なのが M1 Max で 8.5K トークンの入力時、decode 自体は 51 tok/s 出ているのに、prefill を含めた実効スループットが約 3 tok/s まで崩れた という事例です。これは「生成自体は速いのに、最初のトークンが出るまでの待ち時間が長すぎて、トータルの体感が遅くなる」状態です。会話が積み上がって 8,000 トークンを超えると、新しい 100 トークンの質問より明らかに応答開始が遅くなります。多くの Mac ユーザーが経験する現象の正体がこれです。
入力長による速度低下の目安（Apple Silicon、decode 側も含む傾向）：
| コンテキスト | 生成速度の低下目安 | prefill の体感 |
|---|---|---|
| 2K | フル速度 | ほぼ待ちなし |
| 8K | 15〜20% 低下 | prefill 待ちを感じ始める |
| 16K | 25〜35% 低下 | TTFT が明確に伸びる |
| 32K+ | さらに低下 | 長文タスクで prefill が支配的 |
NVIDIA は同じ入力長でも prefill の生スループットが高いため、TTFT の伸びが緩やかです。長文を日常的に扱うなら、この差は無視できません。Mac vs RTX の総合比較は「Mac Studio M3 Ultra vs RTX 5090 ローカルLLM 推論ベンチマーク 2026年版」が詳しいです。
Prefill が特にボトルネックになる 3 つの実務シナリオ
「prefill が効く用途」は抽象的で分かりづらいので、実務で最も影響が出る 3 パターンを具体化します。数値は Llama 3.1 8B Q4 相当を想定した目安レンジです。
1. コーディングエージェント（Claude Code / Cline / Aider）
エージェントは各ターンでシステムプロンプト、過去の会話履歴、開いているファイル、ツール出力を再送するため、実効入力が 16K〜64K トークンに膨らみやすいワークロードです。1 ターンあたりの prefill 待ち時間の目安は次のとおりです。
| GPU | 16K 入力 TTFT | 64K 入力 TTFT | 体感 |
|---|---|---|---|
| RTX 5090 | 1〜2 秒 | 5〜8 秒 | 実用 |
| RTX 5060 Ti 16GB | 3〜5 秒 | 15〜25 秒 | 実用（大入力で気になる） |
| Ryzen AI MAX+ 395（Strix Halo） | 8〜14 秒 | 30〜50 秒 | 大入力で強く体感 |
| Mac Studio M4 Max | 4〜8 秒 | 20〜40 秒 | 中〜大入力で体感 |
| Intel Arc B580 | 8〜14 秒 | 40〜70 秒 | 大入力は非推奨 |
エージェント常用では TTFT が積み上がるので、1 ターンの TTFT が 5 秒を超えるとフラストレーションになりやすいです。RTX 5090 / 5060 Ti 16GB 級を選ぶか、システムプロンプトと履歴を短く保つ運用でカバーする方針になります。Strix Halo 固有の prefill 問題は「Strix Halo プロンプト処理ボトルネック実測 2026年版」で詳しく扱っています。
2. RAG（検索結果の毎回コンテキスト注入）
RAG では検索した文書チャンクを毎回コンテキストに詰めるため、入力が 8K〜32K トークンで安定して大きくなります。ここでは prefill 高速化の主レバーである Flash Attention 2 / 3 が特に効きます。Flash Attention を有効化するだけで、prefill 時の Attention 計算スループットが 2〜4 倍に伸びます。VRAM 消費も削減できます。実装の詳細と対応 GPU は「Flash Attention 2 / 3 の仕組みと GPU 別対応状況 2026年版」に整理しています。
KV キャッシュ側でも節約が効きます。RAG は入力が大きい分 KV キャッシュも膨らみますが、KV キャッシュを Q8 / Q4 量子化することで VRAM を半分〜1/4 に圧縮でき、長文コンテキストの限界を伸ばせます。「ローカル LLM KV キャッシュ量子化ガイド 2026年版」で GPU 別の実測を扱っています。
3. 長文要約・翻訳（10K+ トークン入力）
論文・議事録・書籍章の要約や、章単位の英日翻訳では 10K〜50K トークンの入力が普通に発生します。ここは decode（生成）側の速度より、prefill を消化するまでの数十秒〜数分の待ち時間が体感を支配します。16K トークンの技術文書要約 1 回にかかる TTFT の目安は、RTX 5090 で 1〜2 秒、Ryzen AI MAX+ 395 で 8〜14 秒、Mac Studio M4 Max で 4〜8 秒、CPU 推論（DDR5-6000 環境）で 60〜120 秒というレンジになります。要約を業務でバッチ処理するなら prefill を見て機材を選ぶのが正解です。decode 側の律速の対比は「メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版」で扱っています。
用途別の現実解：あなたは prefill を見るべきか
prefill を重視すべきかは用途で決まります。
| 用途 | 入力長 | 重視すべき指標 | 向くマシン |
|---|---|---|---|
| 短いチャット・Q&A | 〜2K | decode tok/sec | Mac でも NVIDIA でも快適 |
| 長文要約・文書 QA | 8K〜32K | prefill / TTFT | NVIDIA 有利、M5 世代 Mac は改善 |
| エージェント（長いシステムプロンプト + ツール出力） | 16K〜128K | prefill / TTFT | RTX 5090 級が有利 |
| RAG（大量の参照コンテキスト注入） | 8K〜128K | prefill / TTFT | NVIDIA 有利 |
| コード補完（短いコンテキスト） | 〜4K | decode tok/sec | どちらも快適 |
ポイントは 「短文用途なら decode、長文・エージェント・RAG なら prefill」 という見方の切り替えです。decode tok/sec が同じ2台でも、prefill が3倍違えば長文タスクの体感はまったく別物になります。エージェントやRAGをローカルで本格運用するなら、ベンチ表で decode tok/sec だけを見て選ぶのは危険です。prefill tok/s と、想定する入力長での TTFT を必ず確認してください。Llama 70B の decode 側 GPU別比較は「Llama 3.3 70B GPU別トークン/秒 2026年版（5090 / PRO 6000 / Mac）」にまとめています。
まとめ：長文時代のベンチは「最初のトークンまで」で見る
ローカルLLM の評価軸を 1 行でまとめると 「短文は decode、長文は prefill」 です。
prefill は compute 律速。decode はメモリ帯域律速。この違いから、NVIDIA は prefill で大きく有利。Apple Silicon は decode で健闘するが長文 prefill で失速しやすい。この非対称性が、用途によるマシン選びを分けます。
エージェント・RAG・長文要約のように「毎回大量のコンテキストを読む」用途が増えるほど、decode tok/sec だけのベンチは実態を映さなくなります。M5 世代が prefill を最優先で強化してきたのも、この潮流の表れです。次にローカルLLM マシンを選ぶときは、ベンチ表の prefill tok/s と TTFT に必ず目を通してください。
入手先・関連商品
当サイトは Amazon.co.jp アソシエイト・プログラムに参加予定です。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。
prefill 重視（長文・エージェント・RAG 向け、NVIDIA）
大容量・省電力で長文を回す（Apple）
あなたに合うPCを診断する
用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。
→ 診断スタート
関連記事
- Flash Attention 2 / 3 の仕組みと GPU 別対応状況 2026年版
- ローカル LLM KV キャッシュ量子化ガイド 2026年版
- ローカルLLM コンテキスト長と KV キャッシュ VRAM 2026年版
- Strix Halo プロンプト処理ボトルネック実測 2026年版
- メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版
- Mac Studio M3 Ultra vs RTX 5090 ローカルLLM 推論ベンチマーク 2026年版
- Llama 3.3 70B GPU別トークン/秒 2026年版（5090 / PRO 6000 / Mac）
よくある質問
- prefill（プロンプト処理）速度と decode（生成）速度はどう違いますか？
- prefill は入力プロンプト全体を読み込んで最初のトークンを出すまでの処理で、compute（FLOPS）律速です。decode はその後の1トークンずつの生成で、メモリ帯域律速です。短い質問では prefill は一瞬で終わるので decode tok/sec だけ見れば十分ですが、長文コンテキストやエージェント用途では入力が数万トークンに膨らみ、prefill が体感の大半を占めるようになります。
- なぜ Mac は長文 LLM で急に遅くなるのですか？
- prefill が compute 律速だからです。Apple Silicon は decode（生成）ではメモリ帯域の高さで健闘しますが、prefill に必要な行列演算の生スループットでは CUDA コアを多数積む NVIDIA に劣ります。そのため短文では速くても、8K・32K と入力が伸びるほど prefill 時間が伸び、最初のトークンまで待たされます。M5 世代は専用の Neural Accelerator で prefill を最大4倍高速化したと公表しており、この弱点を埋めにきています。
- エージェントやRAG用途ではどの数値を見るべきですか？
- decode tok/sec より prefill tok/s と TTFT（最初のトークンまでの秒数）を見てください。エージェントやRAGは長いシステムプロンプトと大量の参照コンテキストを毎回読み込むため、prefill がボトルネックになります。同じ decode 速度でも prefill が3倍速いマシンなら、長文タスクの体感は大きく変わります。
- prefill（プロンプト処理）とは何ですか？ ローカルLLMで速度が問題になるのはどんな場面ですか？
- prefill は、LLM に入力されたプロンプト全体を読み込んで最初の1トークンを生成するまでの処理を指します。KV キャッシュを構築する段階で、入力トークン数と計算量が線形に増える compute 律速の処理です。短い質問では一瞬で終わるため意識されませんが、長文コンテキスト（8Kトークン超）やエージェント用途（毎回大量のシステムプロンプトと参照文書を読み込む）、RAG（検索結果を毎回コンテキストに詰める）では、prefill が体感時間の大半を占めるようになります。本記事では 4K〜128K トークン入力時の prefill tok/s と TTFT（Time To First Token）を GPU 別に整理しています。
- prefill 速度と TTFT（Time To First Token）は同じ意味ですか？
- TTFT は「入力を送ってから最初のトークンが返るまでの秒数」で、prefill 処理時間とほぼ同義です。厳密には TTFT = prefill 時間 + わずかな overhead（ネットワーク・トークナイズ・キューイング等）ですが、ローカル実行では overhead が小さいため、TTFT ≒ prefill 時間として扱えます。API 経由では TTFT に通信遅延が乗ります。
- prefill を最も速くするには何が効きますか？
- 実務で効くのは3つです。第一に Flash Attention 2 / 3 を有効化することで、prefill 時の Attention 計算スループットが 2〜4 倍に伸び、VRAM 消費も減ります。第二に KV キャッシュ量子化（Q8 / Q4）で、prefill 後の VRAM を圧縮して長文コンテキストの限界を伸ばせます。第三に入力自体の削減で、システムプロンプトの短縮・RAG チャンクサイズの見直し・不要な履歴の切り捨てが根本的に効きます。詳細はそれぞれ Flash Attention 記事と KV キャッシュ量子化ガイドに整理しています。
- prefill と decode はローカルLLM でどう違いますか？
- prefill は入力プロンプト全体を並列に読み込んで最初のトークンを出すまでの処理で、行列演算をフルに回すため compute（FLOPS）律速です。decode はその後の 1 トークンずつの逐次生成で、毎回モデル全体の重みを読み出すためメモリ帯域律速です。つまり同じマシンでも「入力が長ければ prefill が支配、入力が短ければ decode が支配」します。NVIDIA GPU は CUDA コアを大量に積むため prefill が速く、Apple Silicon は unified memory 帯域が高く decode で健闘するという非対称性は、この律速要因の違いから来ています。
- プレフィル（prefill）とは IT 用語として何を指しますか？
- IT 文脈での「プレフィル / prefill」は、大きく2つの意味で使われます。1つ目はローカルLLM や大規模言語モデル推論での用法で、入力プロンプト全体を読み込んで KV キャッシュを構築し、最初のトークンを出すまでの処理を指します。本記事で扱っているのはこちらです。2つ目は Web / UI 分野での「プレフィル入力（事前入力・prefilled form）」で、フォームのフィールドに初期値を埋めておく UX 手法を指します。同じ「事前に埋める」というニュアンスからの派生ですが、対象がモデル内部の KV キャッシュか、ユーザー画面のフォームかで意味が分かれます。LLM 文脈では「prompt processing」「prefill phase」とも呼ばれます。
- prefill が遅いとエージェント・RAG 用途で何が起きますか？
- 1 ターンあたりの TTFT（最初のトークンまでの秒数）が積み上がり、体感で「モデルが考え込む」状態が続きます。目安として、コーディングエージェントで実効入力が 16K トークンになると RTX 5090 で 1〜2 秒、Strix Halo（Ryzen AI MAX+ 395）で 8〜14 秒、64K トークンまで伸ばすと RTX 5090 で 5〜8 秒、Strix Halo で 30〜50 秒、Mac Studio M4 Max で 20〜40 秒、Intel Arc B580 で 40〜70 秒の待ちが発生します。1 ターンの TTFT が 5 秒を超えるとフラストレーションになりやすく、エージェント常用では「毎ターン数十秒の沈黙」が積み重なって作業速度が体感で半減します。RAG も同様で、検索チャンクを毎回コンテキストに詰めるため入力が 8K〜32K で安定して大きくなり、prefill 側のスループットが実利用の可否を決めます。