ローカルLLM プロンプト処理（prefill）速度 GPU別ベンチマーク 2026年版：長文・エージェント用途で効くのは tok/sec より「最初のトークンまで」
生成速度（decode tok/sec）ばかり注目されますが、長文コンテキストやエージェント用途で体感を左右するのは prefill（プロンプト処理）速度です。RTX 5090 / 4090 / Apple Silicon で 4K〜128K トークン入力時の prefill tok/s と TTFT を比較し、なぜ 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 を見てマシンを選んでください。
ローカル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 を見るべきか
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つの候補構成を提案します。
→ 診断スタート