llama3.2:3bとは、Metaが公開した30億パラメータの軽量ローカルLLMである。
ブログ下書き・議事録要約・メール量産といった「叩き台量産」の用途では、ローカルLLM選定の基準が大きく変わる。コーディングのように1文字違えば動かない世界ではないため、精度よりも生成速度が支配的になるからだ。RTX 5080で14モデルを実測した結果、llama3.2:3bが293.9 tokens/secで首位を獲得し、2位のphi4-mini:3.8b(253.5 tok/s)を約16%引き離した。
- llama3.2:3bはRTX 5080実測で293.9 tokens/secを記録し、ドラフト用途で最速クラス
- phi4-mini:3.8bの253.5 tokens/secを約16%上回り、体感の待ち時間が大きく変わる
- VRAM 5.1GBのみで動作するため、画像生成など他用途と並列稼働しても干渉が少ない
Llama 3.2 ファミリーと3Bの位置づけ
Llama 3.2は2024年9月にMetaが発表したオープンソースLLMファミリーで、1B/3Bの軽量テキストモデルと11B/90Bのマルチモーダルモデルが同時公開された。1B/3Bはエッジ・モバイル端末向けに最適化され、上位モデルからの知識蒸留(Knowledge Distillation)とプルーニング(Pruning)を組み合わせて軽量化が施されている。コンテキスト長は公称128,000トークンに対応し、長文要約やマルチターン対話でも実用域に収まる。
Ollamaが配布するllama3.2:3bはQ4_K_M量子化版で、4bit重み圧縮によりVRAM占有量を5GB台に抑えている。INT4精度ながら命令追従品質はFP16版から大きく劣化しないことが、Meta公式の評価指標で示されている。
「Llama 3.2 1B and 3B models are designed to run efficiently on-device, offering low-latency text generation suitable for use cases like summarization, instruction following, and rewriting tasks.」
Meta AI 公式ブログ Llama 3.2 発表記事
ドラフト用途で速度が支配的になる理由
ドラフト生成とは、AIが完成原稿ではなく「人間が手直しする叩き台」を量産する使い方を指す。
ローカルLLMの用途は大きく2系統に分かれる。1つはコード生成や数値計算のように出力の正確性が結果を左右する用途、もう1つはブログ下書きや議事録要約のように人間が後から整える前提の叩き台用途。後者では「待ち時間ゼロ」の体感が生産性に直結する。
CopilotとExcelの組み合わせ検証でも、AIは作業の代行者ではなく「優秀なアシスタント」として叩き台を提示する役割が中心だと指摘されている。ローカルLLMでも同じ。人間が設計し、AIが下書きを高速で吐き出す役割分担が現実的な使い方になる。
叩き台フローでは精度より「待ち時間ゼロ」が効く
500字のメール下書きを想定した場合、200 tok/s台と100 tok/s台では生成完了までに3〜5秒の差が生まれる。1日に何十本も処理する業務では、この差が積み上がって体感を支配する。誤字や表現の硬さは人間が修正する前提なので、若干の品質差より速度差のほうが重い。
14モデル実測で速度トップ4を抽出
当サイトの検証環境(RTX 5080 16GB / RTX 5060 Ti 16GB / i7-14700F / RAM 96GB / Ollama 0.22.1)で14モデルを計測したところ、3〜7Bパラメータ帯のモデルが上位を占めた。逆に14B以上の中規模モデルは80 tok/s前後にとどまり、ドラフト用途では明らかに不利。
量子化とメモリ帯域がトークン速度を決める
30億パラメータのモデルがFP16で動作すると、必要なVRAMは約6GB、メモリ転送量は1トークン生成あたり約6GBに達する。Q4_K_M量子化を適用すると重みが4bit表現に圧縮され、VRAM占有と1トークンあたり転送量はおおむね1/3〜1/4まで縮む。これにより同じGPUでもトークン生成の理論速度が大きく伸びる。
RTX 5080はNVIDIA公式仕様で960GB/sのメモリ帯域を持つ。3B Q4モデルで1トークンあたり約2GBの転送が必要な場合、理論上限は 960÷2 ≈ 480 tok/s 前後となる。実測293.9 tok/sはその約61%を達成しており、残り39%はKVキャッシュの読み書きとサンプリング処理のオーバーヘッドが占める。
同じ計算式を14B級モデルで当てはめると、Q4でも1トークンあたり7〜8GBの転送が必要となり理論上限が120 tok/s前後まで落ちる。実測80 tok/s台に収まるのも帯域律則の説明と整合する。逆に1B級ではさらに帯域要求が下がるため、ドライバや実装が追従できれば400 tok/sを超える余地が残る。
RTX 5080実測|llama3.2:3bが293.9 tok/sで首位
RTX 5080は16GB GDDR7 VRAMを搭載するBlackwell世代のハイエンドGPUで、3BクラスのLLMでは300 tok/s近い生成速度を引き出せる。
実測結果の上位4モデルは以下の通り。すべて当サイト検証環境(RTX 5080 16GB)で2026-05-06に計測した値です。
| モデル | tokens/sec | VRAM使用量 | TTFT | 用途相性 |
|---|---|---|---|---|
| Llama 3.2 3B(Ollama: llama3.2:3b) | 293.9 | 5.1GB | 2575ms | 長文ドラフト・メール量産 |
| Phi-4-mini 3.8B(Ollama: phi4-mini:3.8b) | 253.5 | 5.8GB | 3684ms | 構造化要約・箇条書き整形 |
| gemma3:4b | 199.6 | 5.7GB | 3860ms | 多言語混在・翻訳 |
| Mistral 7B(Ollama: mistral:7b) | 161.0 | 7.2GB | 1119ms | 長文の要点抽出 |
外部の公開ベンチマーク(Microcenter掲載)では、RTX 5080の7-8B Q4_K_M帯が概ね130 tok/s前後とされている。当サイト実測でも8B級のllama3.1:8bは151.6 tok/s、deepseek-r1:8bは136.4 tok/sと近い水準。3B帯の293.9 tok/sは明らかな突出値で、ドラフト用途に振り切ったときの優位性を示す。
phi4-mini:3.8bとの16%差はどこから生まれるか
llama3.2:3bは30億パラメータ、phi4-mini:3.8bは38億パラメータと、サイズ差は約27%。パラメータ数が少ないほど計算量と帯域要求が下がるため、メモリ帯域がボトルネックになりやすい高速生成では3Bが有利になる。VRAM使用量もllama3.2:3bが5.1GB、phi4-mini:3.8bが5.8GBと差があり、計算密度の軽さがそのまま速度に反映された形。
TTFT(最初のトークンが出るまで)の体感差
tokens/sec以外で見落とされやすい指標がTTFT(Time To First Token)。llama3.2:3bは2575ms、mistral:7bは1119msで、最初の1文字が出るまではmistralのほうが早い。短い応答ではTTFTが支配的になるため、長文ドラフトはllama3.2:3b、短い対話レスポンスはmistral:7bという棲み分けも成立する。
VRAM 5.1GBが効く|ComfyUIと並列稼働しても干渉しない
llama3.2:3bはVRAM 5.1GBで動作するため、16GBクラスGPUの3割しか占有せず、画像生成など他用途を同時に走らせても干渉が起きにくい。
ローカルLLMを使い始めると必ず直面するのが「他のAI処理と同居できるか」という問題。Stable DiffusionやComfyUIで画像を生成しながらドラフトを書きたい場面、議事録要約を回しながら動画素材を作りたい場面など、並列稼働の需要は高い。
半分以上のVRAMを他用途に回せる
RTX 5080の16GB VRAMでllama3.2:3bを常駐させた場合、残りは約10〜11GB。SDXL本体(約7GB)は十分収まり、ComfyUIで画像を生成しながらLLMで原稿を書く運用も現実的。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の動画生成を回す分担構成も可能。3B級なら5060 Tiでも100 tok/s以上を狙えるため、用途を分担すれば「待ち時間ゼロ」と「重い動画生成」を両立できる構成。
用途別プリセット|要約・ドラフト・翻訳の使い分け
速度トップ4のモデルはそれぞれ得意分野が異なるため、全用途を1モデルでこなすより、用途別に使い分けるほうが品質と速度を両立しやすい。
| 用途 | 推奨モデル | 理由 |
|---|---|---|
| ブログ下書き・メール量産 | Llama 3.2 3B(Ollama: llama3.2:3b) | 単純な日本語ドラフトで最速、文章のつながりが自然 |
| 議事録要約・箇条書き整形 | Phi-4-mini 3.8B(Ollama: phi4-mini:3.8b) | 構造化指示への追従が安定し、整形タスクの崩れが少ない |
| 多言語/翻訳プリセット | Gemma 3 4B(Ollama: gemma3:4b) | 多言語コーパスの比率が高く、英日・日中などで自然 |
| 長文の要点抽出 | Mistral 7B(Ollama: mistral:7b) | TTFT 1119msで反応が速く、長文処理でも破綻が少ない |
ブログ下書き・メール量産: Llama 3.2 3B(Ollama: llama3.2:3b)
500〜2000字程度の下書き量産では、生成速度が体感を支配する。llama3.2:3bは293.9 tok/sで2000字規模の出力を数秒で吐き出すため、複数案を比較検討する作業が一気に楽になる。文章のつながりは自然で、軽い手直しで公開レベルに届くケースが多い。
議事録要約・箇条書き整形: 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が安定する。多言語学習の比率が効いて、自然な訳出が得やすい傾向。長文翻訳ではmistral:7bも有力候補。
Ollama運用設定|TTFTを最小化するコツ
Ollamaはデフォルトで5分間アクセスがないとモデルをVRAMからアンロードする。次回の呼び出しでは再ロードが発生し、TTFTが数秒単位で増える原因になる。常駐させたいモデルがある場合は環境変数 OLLAMA_KEEP_ALIVE を24時間に設定すると、再ロードのオーバーヘッドが消える。
設定はWindowsならPowerShellで $env:OLLAMA_KEEP_ALIVE="24h"、Linux/macOSなら export OLLAMA_KEEP_ALIVE=24h をシェル起動時に追加する。サービスとして常駐させる場合は systemd の Environment ディレクティブで指定する形式が公式FAQに記載されている。
並列リクエストを処理する場合は OLLAMA_NUM_PARALLEL を2〜4に上げると、複数のドラフト生成を同時実行できる。ただし並列数を増やすほどVRAMとKVキャッシュが追加で必要になるため、5.1GB×並列数+他用途で16GB枠を超えないよう設計する。コンテキスト長を伸ばす場合は OLLAMA_CONTEXT_LENGTH で上限を引き上げるが、32k以上を常用するならVRAM消費の増加分も実機で確認したほうがいい。
トラブルシュート|速度が出ない・VRAM不足が出る
VRAMが足りないと表示される
llama3.2:3bは公称5.1GBだが、他のアプリ(Chrome / VSCode / Stable Diffusion)が同時稼働しているとVRAM逼迫が起こる。nvidia-smiで空き容量を確認し、6GB以上の空きがあるかをチェックする。逼迫している場合はChrome等のGPU使用アプリを終了するか、より軽量なqwen3:1.7bなど1B級モデルへの切り替えを検討する。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は上位モデルから日本語性能を引き継いでいるが、3B級では学術的・専門的な日本語表現で破綻するケースがある。プロンプトの先頭に「日本語で出力してください。文体は丁寧な常体で。」のような明示指示を入れると改善する。それでも品質が足りない場合はgemma3:4bやphi4-mini:3.8bへの切り替えが現実的。日本語特化モデル(ELYZA-japanese-Llama等)も選択肢に入る。
よくある質問
Q. VRAM 8GBのGPUでもllama3.2:3bは動きますか?
llama3.2:3bはVRAM 5.1GB前後で動作するため、8GBクラスのGPU(RTX 4060/5060/3060 Ti等)でも余裕がある。ただし他のアプリと同時起動するとVRAMが逼迫しやすいので、常駐前提なら12GB以上を推奨。
Q. コーディング用途にもllama3.2:3bは使えますか?
速度は速いが、3Bパラメータでは複雑なロジックや長いコード文脈の追従に限界がある。コーディング用途ならcodestral:22bやqwen3:14bなど中規模モデルを別途用意し、ドラフト生成と使い分けるのが現実的。
Q. Macでも同じ速度が出ますか?
Apple Siliconはユニファイドメモリ構成でRTX 5080とは性能特性が異なり、同じ数値は期待できない。3B級モデルが軽量に動く点は共通だが、計測条件で差が大きいため自分の機種で実測を確認すること。
Q. 商用利用は可能ですか?
Llama 3.2はLlama 3.2 Community Licenseのもとで配布されており、月間アクティブユーザー7億人未満の企業・個人は商用利用が許諾される。ただしMeta公式の利用ポリシーに記載された禁止用途(軍事/違法行為/差別助長等)に該当する場合は使用不可。ブログ下書きや業務文書作成は通常許諾範囲内。
Q. Ollama以外で動かす方法はありますか?
llama.cpp / vLLM / LM Studio / Hugging Face Transformers でも動作する。GGUF形式の量子化モデルはHugging Face上で複数の量子化レベルで配布されており、Ollamaがインポート対応している。Windowsで初めて試すならLM StudioがインストールからチャットまでGUI完結で扱いやすい。
Q. 量子化レベルはQ4_K_MとQ8_0でどちらを選ぶべきですか?
速度優先ならQ4_K_M(Ollamaのデフォルト)、品質優先ならQ8_0が一般的な選択。Q8_0はVRAM使用量と転送量がQ4_K_Mの約2倍になるため、トークン生成速度はおおむね半分前後まで落ちる代わりに微妙な日本語表現が安定する。ドラフト用途ならQ4_K_M、業務文書の最終校正に近い用途ならQ8_0という棲み分けが現実的。
Q. CPUだけでも動きますか?
動作はする。i7-14700FのCPUのみで実行すると、GPU実測の1/10以下に速度が落ちる傾向。ドラフト量産用途では実用性が下がるため、低価格GPUでも良いのでCUDA対応GPU(RTX 3060/4060/5060等)を用意する方が体感生産性は高い。CPU運用は完全オフライン環境や一時的なテスト用途に限定するのが無難。
Q. 文脈長(コンテキスト長)はどこまで使えますか?
llama3.2:3bは公称128,000トークン(約10万字相当)のコンテキスト長に対応するが、長い文脈を保持するほどKVキャッシュがVRAMを消費する。32k超のコンテキストを常用すると OLLAMA_CONTEXT_LENGTH 等の調整が必要で、VRAM 16GBで安定運用するなら32k前後を上限とする運用が現実的。10万字の超長文を投入する場合は8B以上のモデルとセットでVRAM 24GB級GPUを検討する。
まとめ
llama3.2:3bは、RTX 5080実測293.9 tokens/secでドラフト用途の最速クラスに位置する3BパラメータのローカルLLM。phi4-mini:3.8bを約16%上回る速度差は、ブログ下書きや議事録要約のように「叩き台を量産→人が整える」フローで体感生産性を直接押し上げる。
VRAM 5.1GBの軽量性は、画像生成や動画生成との並列稼働を可能にする副次的な強みでもある。まずはllama3.2:3bでドラフト用途の速度を体験し、次にphi4-mini:3.8bやgemma3:4bを用途別に試すと、自分の業務に合わせたモデルプリセットが固まる。OLLAMA_KEEP_ALIVE等の運用設定とQ4_K_M量子化を組み合わせれば、待ち時間を意識せずに使える環境が手に入る。
| パラメータ数 | 30億(3B) |
|---|---|
| RTX 5080実測速度 | 293.9 tokens/sec |
| VRAM使用量 | 約5.1GB |
| TTFT | 2575ms |
| 得意用途 | ブログ下書き・メール量産・長文ドラフト |
| 計測日 | 2026-05-06(Ollama 0.22.1 / NVIDIA 596.36) |
参考資料
- Meta AI – Llama 3.2 Connect 2024 発表記事
- Meta – Llama 3.2 Acceptable Use Policy
- Ollama – llama3.2 モデルライブラリ
- Ollama – 公式FAQ(KEEP_ALIVE / Parallel設定)
- NVIDIA – GeForce RTX 5080 公式仕様
- Hugging Face – Llama-3.2-3B-Instruct モデルカード
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

