llama3.2:3bとは？ドラフト生成で最速のローカルLLM｜RTX 5080実測293.9 tok/sを解説

llama3.2:3bとは、Metaが公開した32.1億パラメータ（3.21B）の軽量ローカルLLMである。

ブログ下書き・議事録要約・メール量産といった「叩き台量産」の用途では、ローカルLLM選定の基準が大きく変わる。コーディングのように1文字違えば動かない世界ではないので、多少の粗さは後段で直せる前提で速度を優先する、という選び方になる。RTX 5080で14モデルを実測した結果、llama3.2:3bが293.9 tokens/secで首位を獲得し、2位のphi4-mini:3.8b（253.5 tok/s）を約16%引き離した。

Llama 3.2 ファミリーと3Bの位置づけ

Llama 3.2は2024年9月にMetaが公開したLLMファミリーで、1B/3Bの軽量テキストモデルと11B/90Bのマルチモーダルモデルが同時に出ている。重みは公開されており、利用条件は独自の Llama 3.2 Community License で定められている。1B/3Bはエッジ・モバイル端末向けに最適化され、上位モデルからの知識蒸留(Knowledge Distillation)とプルーニング(Pruning)を組み合わせて軽量化が施されている。コンテキスト長は公称128,000トークンに対応する。ただしこれはモデルが扱える上限で、Ollama が実際に確保する長さは別に決まる（既定値は環境によって大きく下回る）。

Ollamaが配布するllama3.2:3bはQ4_K_M量子化版が標準で、モデルファイルは約2GB。4bit系のK-quantで重みを圧縮しており、今回の計測では実行時VRAMが5.1GBだった。コンテキスト長を伸ばせば必要量は増える。量子化でどれだけ品質が落ちるかはタスクによって変わるので、この記事では速度と実運用上の挙動を実機で見ている。

Meta は Llama 3.2 の 1B / 3B を、要約・指示追従・書き換えといった用途を端末側で低遅延に回すためのモデルとして位置づけている。

ドラフト用途では速度から選ぶ理由

ドラフト生成とは、AIが完成原稿ではなく「人間が手直しする叩き台」を量産する使い方を指す。

ローカルLLMの用途は大きく2系統に分かれる。1つはコード生成や数値計算のように出力の正確性が結果を左右する用途、もう1つはブログ下書きや議事録要約のように人間が後から整える前提の叩き台用途。後者では、出来上がりの精度より、下書きが返ってくるまでの速さのほうが作業のテンポを決めやすい。

人間が構成を決め、AIが下書きを高速で吐き出す。この役割分担が現実的な使い方になる。

叩き台フローでは生成の速さが効く

tokens/secが高いほど生成にかかる時間は短くなる。ただし必要なトークン数はモデルのトークナイザーによって変わるため、同じ日本語の文章量でも所要時間の差が tokens/sec の比とそのまま一致するわけではない。日本語の文字数あたりの実時間は本記事では測っていない。それでも1日に何十本も下書きを回すなら、生成が速いほど手戻りの待ちは減る。誤字や表現の硬さは人間が修正する前提の使い方なら、速度を優先する選び方になる。

14モデル実測で速度トップ4を抽出

当サイトの検証環境（i7-14700F / RAM 96GB / Ollama 0.22.1）の RTX 5080 側で14モデルを計測したところ、3〜7Bパラメータ帯のモデルが上位を占めた。逆に14B級は80 tok/s台（phi4:14b 85.6 / qwen3:14b 82.2）、22B以上はさらに落ち、codestral:22bが38.2、gemma4:26bが39.3、qwen3.5:35b-a3bが20.3 tok/sだった。ただしこの3本はVRAM使用量が14.9〜15.4GBで、このカードが実際に使える約15.5GB（公称16GBから管理領域などを引いた分）のほぼ上限まで来ている。一部がCPU側へ退避していた可能性がある。純粋なモデルサイズの効果ではなく、16GBのカードで動かしたときの実用速度として読んでほしい。

量子化とメモリ帯域がトークン速度を大きく左右する

32.1億パラメータのモデルをFP16で動かすと、重みだけで約6.4GB、1トークン生成あたりの転送量も同じ規模になる。Q4_K_M量子化では重みを4bit級のK-quant形式に圧縮し、重みの容量と1トークンあたりの転送量はおおむね1/3〜1/4まで縮む（モデルファイルで約2GB）。転送量が減るぶん、同じGPUでもトークン生成の速度が伸びる。なお実行時にはこれにKVキャッシュなどが加わるため、実測のVRAM占有は5.1GBだった。

RTX 5080はNVIDIA公式仕様で960GB/sのメモリ帯域を持つ。3B Q4モデルで1トークンあたり約2GBの転送が必要な場合、帯域だけで決まると仮定した目安は 960÷2 ≈ 480 tok/s 前後になる。実測293.9 tok/sはその約61%にあたる。差の4割弱には、量子化した重みの展開、演算そのもの、KVキャッシュの読み書き、カーネルの実行効率などが混ざっており、本記事の計測では内訳を分けていない。

同じ計算を14B級に当てはめてみる。14B級のQ4_K_Mはモデルファイルが9GB前後になるので、重み読み出しを約9GB/トークンと単純化すれば 960÷9 ≈ 107 tok/s 前後が帯域だけから見た目安になる。今回の phi4:14b（85.6 tok/s）や qwen3:14b（82.2 tok/s）は、この単純な帯域モデルと大きくは矛盾しない。1B級はさらに帯域要求が下がるはずだが、今回は測っていない。

RTX 5080実測｜llama3.2:3bが293.9 tok/sで首位

RTX 5080は16GB GDDR7 VRAMを搭載するBlackwell世代のハイエンドGPU。今回の計測では llama3.2:3b が293.9 tok/s に届いた。ただし同じ3〜4B帯でも開きは大きく、クラスがそのまま速度を決めるわけではない。

実測結果の上位4モデルは以下の通り。すべて当サイト検証環境（RTX 5080 16GB）で2026-05-06に計測した値です。

同じ計測で8B級のllama3.1:8bは151.5 tok/s、deepseek-r1:8bは136.4 tok/sだった。3B帯の293.9 tok/sはこの倍前後にあたり、ドラフト用途に振り切ったときの差がはっきり出ている。

phi4-mini:3.8bとの16%差をどこまで説明できるか

llama3.2:3bは32.1億パラメータ、phi4-mini:3.8bは38億パラメータと、サイズ差は約18%。パラメータ数が少ないほど計算量と帯域要求が下がるため、メモリ帯域がボトルネックになりやすい高速生成では3Bが有利になる。VRAM使用量もllama3.2:3bが5.1GB、phi4-mini:3.8bが5.8GBと差があり、パラメータ数の少なさによる帯域要求と演算量の差も、速度差に効いていると考えられる。ただしアーキテクチャ・量子化の実装・トークナイザーも違うため、サイズ差だけで説明はできない。

推定TTFTはモデル間の差より常駐の有無で大きく動いた

tokens/sec以外で見落とされやすい指標がTTFT（Time To First Token、最初のトークンが返り始めるまで）。ただしモデルがVRAMに載っていれば、この4本はいずれも21〜197msに収まった。最も短いmistral:7bが21.0ms、最も長いgemma3:4bでも197.0msで、llama3.2:3bは94.5msだった。最速と最遅で9倍前後の開きはあるが、いずれも200ms未満の推定値に収まっており、この指標の上ではモデル間の絶対差は小さい。

差が出るのは載っていない時になる。同じ計測の初回実行では llama3.2:3b が7538ms、mistral:7b が3317msかかっており、常駐時の数十倍だった。今回の共通プロンプト（約100字）では、モデル間の差より読み込みが起きるかどうかの差のほうが大きかった。短い対話を繰り返す使い方でモデルを選び分ける理由としては、この4本のあいだの差は小さい。

VRAM 5.1GBが効く｜ComfyUIとVRAM容量の上では同居させやすい

llama3.2:3bの実行時VRAMは5.1GBで、16GBクラスGPUの3割ほど。画像生成など他用途を同時にVRAMへ載せる余地が残る。ただし同じGPU上で走らせれば演算資源とメモリ帯域は取り合うため、速度の面では干渉が起こりうる。

他用途でVRAMが足りなくなって退避が起きたり、5分間使わずにアンロードされたりすると、次の呼び出しでは読み込みが入って秒単位に戻る。並列で使うなら、常駐させ続けられるだけの空きを残しておきたい。

ローカルLLMを使い始めると必ず直面するのが「他のAI処理と同居できるか」という問題。Stable DiffusionやComfyUIで画像を生成しながらドラフトを書きたい場面、議事録要約を回しながら動画素材を作りたい場面など、並列稼働の需要は高い。

半分以上のVRAMを他用途に回せる

RTX 5080の16GB VRAMでllama3.2:3bを常駐させた場合、残りは約10〜11GB。SDXLの必要量はワークフロー・解像度・VAE・ControlNetの有無で変わるが、標準的な構成なら収まる。phi4-mini:3.8bやgemma3:4bも6GB前後なので近い使い勝手だが、絶対的な軽さではllama3.2:3bが一歩リード。

mistral:7bやllama3.1:8bは7〜8GB台を消費するため、SDXLとの同時起動でVRAMが逼迫する局面が出てくる。長時間のバッチ処理では3〜4B級を選んだほうが安定するでしょう。

デュアルGPU構成での役割分担

当サイトの検証環境はRTX 5080（16GB）に加えてRTX 5060 Ti（16GB）をOculink接続で運用している。LLMドラフト生成を5060 Ti側に固定し、5080側でComfyUIの動画生成を回す分担構成も可能。ただし今回の計測は RTX 5080 側だけで、5060 Ti での 3B の速度は測っていないため、この分担でどこまで速度が出るかは確かめていない。

用途別プリセット｜要約・ドラフト・翻訳の使い分け

速度トップ4のモデルはそれぞれ得意分野が異なるため、全用途を1モデルでこなすより、用途別に使い分けるほうが品質と速度を両立しやすい。

ブログ下書き・メール量産: Llama 3.2 3B（Ollama: llama3.2:3b）

500〜2000字程度の下書きを何本も作る使い方では、生成にかかる時間が積み上がる。llama3.2:3bは今回測った14モデルで最も高い293.9 tok/sを出しており、複数案を並べて比較する作業では待ちが短くなる。文章のつながりは自然で、軽い手直しで公開レベルに届くケースが多い。

議事録要約・箇条書き整形: Phi-4-mini 3.8B（Ollama: phi4-mini:3.8b）

要約タスクでは「指示通りに構造化できるか」が品質を決める。phi4-mini:3.8bは構造化指示への追従が安定しており、箇条書き出力や見出し付き要約の崩れが少ない。速度253.5 tok/sも十分実用域。

多言語/翻訳プリセット: Gemma 3 4B（Ollama: gemma3:4b）・Mistral 7B（Ollama: mistral:7b）

英語ソースの記事を日本語で要約する、日本語ドラフトを英語化するといった多言語タスクでは、gemma3:4bが安定する。140以上の言語をサポートしており、当サイトで試した範囲では訳出が安定していた。長文翻訳ではmistral:7bも有力候補。

Ollama運用設定｜TTFTを最小化するコツ

Ollamaはデフォルトで5分間アクセスがないとモデルをVRAMからアンロードする。次回の呼び出しでは再ロードが発生し、TTFTが増える原因になる。今回の4モデルでは、初回実行の推定TTFTが3.3〜11.2秒だった。常駐させたいモデルがある場合は環境変数 OLLAMA_KEEP_ALIVE を24時間に設定すると、再ロードのオーバーヘッドが消える。

Windows版のOllamaアプリを使っている場合は、Ollamaを終了してからWindowsのユーザー環境変数に OLLAMA_KEEP_ALIVE=24h を追加し、Ollamaを起動し直す。すでに常駐しているサーバーには、あとから $env:OLLAMA_KEEP_ALIVE を設定しても反映されない。PowerShellから ollama serve を直接起動するなら、起動前に $env:OLLAMA_KEEP_ALIVE="24h" を指定する方法も使える。Linux/macOSなら export OLLAMA_KEEP_ALIVE=24h をシェル起動時に追加する。サービスとして常駐させる場合は systemd の Environment ディレクティブで指定する形式が公式FAQに記載されている。

並列リクエストを処理する場合は OLLAMA_NUM_PARALLEL を2〜4に上げると、複数のドラフト生成を同時実行できる。ただし並列数を増やすほどVRAMが追加で必要になる。増えるのは主にKVキャッシュ側で、モデルの重みが並列数だけ複製されるわけではない。必要量は並列数とコンテキスト長の組み合わせで決まるため、実際に使う設定で空きを見ながら上げていく。コンテキスト長を伸ばす場合は OLLAMA_CONTEXT_LENGTH で上限を引き上げるが、32k以上を常用するならVRAM消費の増加分も実機で確認したほうがいい。

トラブルシュート｜速度が出ない・VRAM不足が出る

VRAMが足りないと表示される

llama3.2:3bの実測VRAMは5.1GBだが、他のアプリ（Chrome / VSCode / Stable Diffusion）が同時稼働しているとVRAM逼迫が起こる。nvidia-smiで空き容量を確認する。今回の条件では5.1GBを使った。実際に使う設定に対して余裕を持った空きを確保したい。逼迫している場合はChrome等のGPU使用アプリを終了するか、より軽量なqwen3:1.7bなど1〜2B級モデルへの切り替えを検討する。Chromeはハードウェアアクセラレーションを切るだけでも数百MB単位でVRAMが空く場合がある。

tokens/secが想定より遅い

RTX 5080環境で200 tok/s以下しか出ない場合、Ollamaのバージョン、NVIDIAドライバのバージョン、Power Limitの設定値を順に確認する。当サイト計測時はOllama 0.22.1 / NVIDIA 596.36 で安定。バッテリー駆動ノートPCでは省電力モードが速度に直結するため、電源プランを「最高のパフォーマンス」に設定する。Ollamaを再起動するとモデルロード状態がリセットされ、TTFTを含めた初回レスポンスは遅くなる点も計測時の留意事項。

日本語出力が不自然になる

Llama 3.2 が公式にサポートする言語は英語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語・スペイン語・タイ語の8つで、日本語は入っていない。当サイトで試した範囲では日本語も出力できるが、3B級では学術的・専門的な日本語表現で破綻するケースがある。プロンプトの先頭に「日本語で出力してください。文体は丁寧な常体で。」のような明示指示を入れると改善する。それでも品質が足りない場合はgemma3:4bやphi4-mini:3.8bへの切り替えが現実的。日本語特化モデル（ELYZA-japanese-Llama等）も選択肢に入る。

まとめ

llama3.2:3bは、2026年5月にRTX 5080で測った14モデルのうち最速の293.9 tokens/secを記録した3BパラメータのローカルLLM。phi4-mini:3.8bを約16%上回っており、ブログ下書きや議事録要約のように「叩き台を量産→人が整える」フローでは生成の待ちが短くなる。

VRAM 5.1GBという軽さは、画像生成や動画生成とVRAM容量の上で同居させやすいという副次的な強みでもある（同じGPUで同時に回せば速度は取り合う）。まずはllama3.2:3bでドラフト用途の速度を体験し、次にphi4-mini:3.8bやgemma3:4bを用途別に試すと、自分の業務に合わせたモデルプリセットが固まる。Q4_K_Mでモデルの容量を抑え、OLLAMA_KEEP_ALIVEでアイドル時のアンロードを防げば、VRAMに余裕がある範囲でモデルを常駐させやすくなる。

参考資料

• Ollama – llama3.2 モデルライブラリ
• Ollama – 公式FAQ（KEEP_ALIVE / Parallel設定）
• NVIDIA – GeForce RTX 5080 公式仕様
• Hugging Face – Llama-3.2-3B-Instruct モデルカード

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