12GBのVRAMで動くローカルLLM｜おすすめモデルと選び方

まず結論

12GB GPUでの第一候補はGemma 4 12B QAT Q4_0です。gemma-4-12b-it-qat-q4_0.ggufをダウンロードし、コンテキスト長16kから始めてください。著者によるRTX 3080 Tiでの測定では、コンテキストに16kを割り当てたときに90.0 tokens/s、7,816 MiBと報告されています。別途実施したRTX 4070でのコーディングテストでは、動作するSnakeゲームと5つのボールのシミュレーションを、どちらも2回以内の試行で完成させました。

著者の測定では、同じファイルを64kの割り当てで読み込んだときの使用量は8,632 MiBでした。ただし、これは64kを使い切る会話全体での回答品質を実証するものではありません。LFM2.5-2.6Bは速度表で最速の218.5 tokens/sを記録しましたが、視覚的に評価する2つのコーディング課題にはどちらも失敗しました。

著者によるRTX 3080 Tiでの速度とメモリ使用量の測定結果を以下に示します。別途実施したRTX 4070でのテストについては、Snakeと5つのボールの結果をご覧ください。

BonsaiにはPrismのランタイムが必要です。Gemma E4Bは埋め込みにシステムRAMも使用するため、VRAMの数値は必要なメモリの総量ではありません。

選定基準

16kのコンテキスト長で報告されたデバイスメモリ使用量が11 GiB未満になることを目安に、約8 GiB以下のGGUFビルドを選びました。これにより、画面表示や他のアプリケーションに使う余裕をある程度残せます。

対象はRTX 3060 12GBやRTX 4070などの12GB NVIDIA GPUです。メモリ使用量はバックエンド、OS、画面表示の負荷によって変わります。GPUオフロードを使っても、すべてのテンソルがVRAMに配置されるわけではありません。llama.cpp b10988では、入力埋め込みはデフォルトでシステムメモリに保持されます。特にGemma E4Bは層ごとの埋め込みにもホストメモリを使うため、この影響を受けます。以下のデバイスメモリの数値には、これらの割り当ては含まれていません。

8GBおよび16GBのカードで動かすのに最適なローカルLLMについてもご覧ください。

テスト方法

以下の速度とメモリ使用量の表には、元の記事で提供された測定値をそのまま掲載しています。報告された構成は、VRAM 12,288 MiBのNVIDIA RTX 3080 Ti、ドライバー580.65.06、CUDA 12.8を使用するllama.cpp b10988、並列スロット1つ、Jinjaテンプレート、fp16 KVキャッシュで、GPUオフロードを指定していました。Bonsaiには標準のllama.cppではなく、Prismの互換フォークを使用しました。今回の公開前レビューではRTX 3080 Tiの生ログを入手できなかったため、これらの数値を独立に再現してはいません。私たちによるRTX 4070での視覚的なテストは、別のデータセットです。

RTX 3060 12GBでLLMを動かす場合は、これらのメモリ使用量を初期の目安とし、実際の負荷を確認してください。RTX 3080 Tiの速度の数値を別のGPUにそのまま当てはめないでください。

著者は、4,096トークンのプロンプト処理テストと128トークンの生成テストを実施したと報告しています。

メモリ測定では、著者は8k、16k、32k、64kのそれぞれでllama-serverを新たに起動しました。最初の回答の後に、nvidia-smiでVRAM使用量を読み取りました。これはコンテキストの割り当てを確認するものであり、長いコンテキストでの情報検索や正確性のテストではありません。提供された測定方法によると、対応するモデルでは思考を無効にしていました。LFM2.5は常に推論が有効なため、そのスループットには推論トークンが含まれます。

12GB VRAMに最適なローカルLLM

各モデルのセクションにあるベンチマークスコアは、リンク先の各開発元のモデルカードに基づきます。評価設定が異なるため、ここでテストしたGGUFファイルを同一条件で比較したものではありません。BonsaiのスコアはPrismの三値モデルのものです。この記事のローカル実行はすべてテキストの入出力を使用しました。元のチェックポイントが画像、音声、動画に対応していても、テストしたGGUF環境での対応が実証されたことにはなりません。

Gemma 4 12B it

Gemma 4 12Bは、ネイティブのコンテキストウィンドウが256kの、Googleの11.95Bパラメータのデンスモデルです。元のチェックポイントはテキスト、画像、音声、動画を入力できます。テストでは、量子化を考慮した学習を施したGoogle公式のQ4_0 GGUFを使い、テキスト推論を行いました。

Gemma 4 12Bのベンチマーク：

Gemma 4 12Bは速度で9Bモデルに並び、64kでの使用量は8,632 MiBで、他のプロセスに十分なメモリを残せました。また、標準のllama.cppが対応するモデルの中では、このテストで最大のデンスモデルです。

汎用のテキストアシスタントには、まずGemma 4 12Bを使ってみてください。視覚的に評価する2つのコーディング課題にも、どちらも合格しました。

Ornith 1.5 9B

Ornith 1.5 9Bは、コーディング、推論、ツール利用、エージェントの実行基盤を中心に学習された、Qwen3.5ベースのデンスモデルです。

Ornith 1.5 9Bのベンチマーク

Ornithは、コンテキスト長256kのOpenHandsを使用し、5回の実行の平均でSWE-bench Verifiedのスコアが70.6だったと報告しています。これはリポジトリの課題解決に関するベンダーの評価であり、私たちが行った16kのブラウザーゲームのテストではありません。

Q6_Kビルドは16kで7,182 MiBを使用し、他のGPUワークロードを加える前の空き容量は5,106 MiBでした。Ornithはデフォルトで推論を行うため、適切な推論パーサーとチャットテンプレートが必要です。

適切なコーディングエージェント環境でリポジトリの作業を行うなら、Ornithを検討してください。私たちのブラウザー課題では、Snakeには失敗し、5つのボールのシミュレーションには物理挙動の制限付きで合格しました。Ornithの使い始め方については、Ornith 1.5セットアップガイドをご覧ください。

Qwen3.5-9B

Qwen3.5-9Bは、Gated DeltaNetと標準的なアテンション層を備えた、デンス型ハイブリッドモデルです。201の言語・方言、ツール利用、元のチェックポイントでの画像認識、ネイティブの256kコンテキストウィンドウに対応しています。

Qwen3.5-9Bのベンチマーク

提供された表では、Qwenは他の2つの9Bビルドよりわずかに高速でした。

汎用チャットや多言語用途にはQwen3.5-9Bを選んでください。私たちのテストでは、視覚的に評価する2つの課題はどちらも制限付きで動作しました。

MiMo-V2.6-Distill-Qwen-9B

MiMo-V2.6-Distill-Qwen-9Bは、MiMoが生成したエージェントデータを用いて、XiaomiがQwen3.5-9Bに教師ありファインチューニングを施したモデルです。

MiMo-V2.6-Distill-Qwen-9Bのベンチマーク：

MiMoの学習は、リポジトリ全体にわたるソフトウェアエンジニアリングとエージェントのワークフローを対象としています。SWE-benchのスコアにはavg@3を使用し、ターミナルとツールの結果にはavg@1を使用しています。評価設定が異なるOrnithとの直接的な順位比較として解釈すべきではありません。

MiMoは9Bモデルの中で4kプロンプトの処理が最速で、64kでの使用量は9,180 MiBでした。テストに使ったカードの12,288 MiBのうち、追加のワークロードを加える前の空き容量は3,108 MiBでした。

ツールを使うワークフローでMiMoを試し、ご自身の課題で出力を検証してください。私たちの視覚的なテストでは、Snakeには失敗し、ボールのシミュレーションは、許可された低エネルギー条件を満たさない場合でも速度を瞬間的に増加させる追加処理を適用していました。

Granite 4.2 8B

Granite 4.2 8Bは、コード、ツール、エージェントのワークフロー、多言語対話に向けた、IBMのデンス型推論モデルです。

Granite 4.2 8Bのベンチマーク：

IBMはLiveCodeBench v6で73.24と報告しています。このスコアから、私たちのブラウザー課題におけるこの量子化版の結果を予測することはできません。どちらの課題も、上限の3回の試行では成功しませんでした。

Graniteの6.72 GiBのファイルは9BのQ6_Kファイルより小さいものの、報告されたメモリ使用量は8kから16kの間で約1.3 GiB増加しました。著者は32kでメモリ不足による失敗を報告しています。これはテストしたGPU、量子化形式、キャッシュ設定による制約であり、Graniteのネイティブのコンテキスト長の上限ではありません。

これらの設定では、Graniteを8kまたは16kで使用してください。32kまたは64kのコンテキスト長が必要なら、別のモデルを選んでください。

Bonsai 2 27B

Bonsai 2 27Bは、Qwen3.8-27Bアーキテクチャを三値の重みに圧縮したモデルです。テストしたPTQ1_0のパッキング形式は、重みあたり約1.75ビットを使用します。

Bonsai 2 27Bのベンチマーク：

Prismは、思考モードで実行した14のベンチマークの平均スコアについて、三値モデルが84.78、比較基準のFP16モデルが86.32だったと報告しています。

Bonsaiは16kで7,052 MiBを使用し、このテストの複数の9Bモデルより少ない使用量でした。速度は57.7 tokens/sと遅く、64kではVRAM使用量が10,172 MiBに増加しました。標準のllama.cpp b10988はPTQ1_0を読み込めません。テストしたBonsaiビルドにはPrismのランタイムが必要です。以下のAtomic Chatの手順は、このビルドを対象としていません。

三値の27Bモデルを試したく、Prismのllama.cppフォークをインストールできる場合は、Bonsaiを使用してください。視覚的に評価する2つの課題にはどちらも合格しましたが、ランタイムと生成に使えるトークン数の上限は他のモデルと異なりました。このモデルをローカルで動かす方法は、Bonsai 2セットアップガイドをご覧ください。

Gemma 4 E4B it

Gemma 4 E4Bは、有効パラメータ数が4.5B、層ごとの埋め込みを含む総パラメータ数が8Bです。テキスト、画像、音声の入力に対応しています。

Gemma 4 E4Bのベンチマーク：

Q8_0ファイルは9BのQ6ファイルより大きいものの、報告されたデバイスメモリ使用量は少なくなっています。テストしたランタイムでは、入力埋め込みと層ごとの埋め込みはGPUメモリの外に保持されます。そのため、VRAMの数値は必要なメモリの総量ではありません。提供されたスループット表ではGemma 12Bより高速で、私たちが視覚的に評価した2つの課題にも、どちらも合格しました。

システムRAMの使用を許容でき、高速なテキスト推論を求める場合は、Gemma E4Bを検討してください。元のチェックポイントのマルチモーダル機能には、ランタイム側で別途対応が必要であり、ここではテストしていません。

LFM2.5-2.6B

LFM2.5-2.6Bは、デバイス上のエージェント、情報抽出、RAG、ツール利用に向けた、Liquid AIの2.69Bパラメータのハイブリッドモデルです。30層は、22の短い畳み込みブロックと8つのグループ化クエリアテンションブロックを組み合わせた構成です。

LFM2.5-2.6Bのベンチマーク：

IFStructは、構造化された指示に従う能力を測定します。

LFMはGemma E4Bのほぼ2倍、9Bモデルの2倍以上の速度でした。多くの知識を要する課題やコーディングエージェント用途は比較的苦手で、回答前に必ず推論を行います。

高速な情報抽出、ローカルのツール、出力を検証できる限定的な課題にはLFM2.5を選んでください。スループット表では首位でしたが、視覚的に評価する2つのコーディング課題にはどちらも失敗しました。

コーディングテスト

2026年9月29日に、レンタルしたRTX 4070 12GBで別途テストを実施しました。同じ8つのGGUFビルドそれぞれに、自動プレイするSnakeゲームと、単独のHTMLページで動く5つのボールの物理シミュレーションという2つのプロンプトを与えました。生成されたソースを調べ、ページの動作を30秒間確認し、選択した結果を並べて録画しました。Snakeには、ビューポート全体に表示されること、餌を見つけること、成長すること、負けた後に再開することを求めました。ボールの課題には、動く5つのボール、半径に基づく質量、弾性衝突、ウィンドウに合わせてサイズが変わるキャンバスを求めました。総運動エネルギーがしきい値を下回った場合に限り、速度を少し上げることを許可しました。

各課題では、モデルに最大3回の試行を認めました。結果が失敗だった場合はモデルにフィードバックを与え、HTMLを手作業で修正することはしませんでした。生成は合計37回だったため、これらの動画は再試行後に選んだ結果を示しており、8つのモデルが初回で完成させたものではありません。7つのモデルはllama.cpp b10988を使用し、BonsaiはPrism prism-b10709-9a9394aを使用しました。実行時の設定は、コンテキスト長16k、fp16 KVキャッシュ、並列スロット1つ、temperature 1、top-p 0.95、top-k 64、seed 42でした。他の7つのモデルの出力上限は8,192トークンでした。BonsaiはPrismのフォークを使用し、推論強度は中、出力上限は16,384トークンでした。修正のための再試行の一部では思考を無効にするよう要求しましたが、すべてのモデルがそれに従ったわけではありません。こうした違いがあるため、結果を同一条件でのランキングとして扱うことはできません。

動画に表示される時間は、各モデルの試行にかかった生成時間の合計です。モデルの読み込み、ブラウザーでのレビュー、録画の時間は含まれていません。

合格は、レビューしたページが見た目と動作の主要な要件を満たしたことを意味します。制限ありは、デモの主要部分は動作したものの、要求された動作や物理挙動の細部に誤りがあったことを意味します。失敗は、選択したページに動作を妨げる問題が残っていたことを意味します。

自動プレイするSnake

Gemma 4 12B、Bonsai 2、Gemma E4Bが合格しました。Qwenのゲームは動作しましたが、ゲームオーバー後に再開しませんでした。Ornith、MiMo、Granite、LFMには、3回試行しても動作を妨げる不具合が残りました。

5つのボールの物理シミュレーション

Gemma 4 12B、Bonsai 2、Gemma E4Bが合格しました。Ornith、Qwen、MiMoは、制限があるものの動くシミュレーションを生成しました。GraniteとLFMは失敗しました。両方の課題を合わせると、合格6件、制限あり4件、失敗6件です。

コンテキスト長別のVRAM使用量

元の記事では、各コンテキスト割り当てで読み込み、回答を生成した後のデバイスメモリ測定値として、これらの数値が提供されました。コンテキストウィンドウ全体を使い切るプロンプトでの品質を測定したものではありません。

デスクトップや他のGPUアプリケーションもVRAMを使用します。余裕を残し、コンテキスト長を増やす前に実際の使用量を確認してください。会話の長さがメモリに与える影響については、KVキャッシュガイドをご覧ください。

Qwen 3.8 27Bは12GBで動かせますか？

提供されたAD-IQ2_XXSの結果では、16kと32kでは12GBに収まりましたが、64kでは収まりませんでした。これらの実行では品質は評価されていません。

11.25 GiBのAD-IQ3_XXSファイルは8kで11,689 MiBを使用し、16kでは起動に失敗しました。より小さい8.36 GiBのAD-IQ2_XXSファイルは16kで9,255 MiB、32kで10,295 MiBを使用し、64kでは失敗しました。生成速度は46.1 tokens/sでした。モニターへの出力も担うデスクトップGPUでは、32kの結果で残る余裕はごくわずかです。

別途行われたベンダーによる比較では、Prismは、思考モードの14のベンチマーク全体で、IQ2_XXSのQwen3.8-27Bビルドが72.59、FP16が86.32だったと報告しています。これは、著者が速度とメモリ使用量を測定したAD-IQ2_XXSファイルそのものの品質評価ではありません。

12GB VRAMで27Bモデルを使うなら、Bonsai 2を使用してください。標準のllama.cppを使う場合は、代わりにQwen3.5-9B、Ornith 1.5 9B、MiMoを使用してください。より高品質なQwen 3.8 27Bの量子化版には、16 GB GPUまたはRTX 3090クラスの24 GBカードに移行してください。詳しくはQwen 3.8ガイドをご覧ください。

これらのモデルをAtomic Chatで動かす方法

ベンチマーク測定では、単独で動作するllama.cppを使用しています。Atomic Chatで利用できるバックエンドとメモリ使用量は、プラットフォームやアプリのバージョンによって異なる場合があります。これらの実行結果は、インストール済みのアプリで8つすべてのモデルが動くことを保証するものではありません。選んだモデルに対応する最新のバックエンドを使用してください。Bonsai 2 PTQ1_0にはPrismの別のランタイムが必要なため、このビルドについてはBonsaiセットアップガイドを参照してください。

1. Atomic Chatをインストールします。Settings → Model ProvidersでLlama.cppプロバイダーを選び、必要に応じてFind optimal backendを使用してください。
2. Modelsを開き、選んだモデルのセクションにリンクされているリポジトリを検索します。
3. Download Optionsで、表に記載された量子化形式とファイルサイズに一致するものを選びます。ダウンロードしてから、New chatを選んでください。ファイル名を正確に一致させるには、リンク先のリポジトリを使用してください。
4. コンテキスト長16kから始めてください。Fit context to device memoryが有効な場合は、コンテキスト長を手動で設定する前に無効にします。割り当てを増やす前にメモリ使用量を確認してください。

コンピューターにすでに保存されているGGUFには、Settings → Model Providers → Llama.cpp → Importを使用してください。バックエンドがモデルのアーキテクチャを認識しない場合は、より小さな量子化版で解決すると考えず、対応するバックエンドに更新してください。

12GB VRAMでOllamaのモデルを使う場合は、ここに記載したファイルサイズとコンテキストの割り当てを、計画時の目安として使用してください。Ollamaのモデルのパッケージ構成、デフォルト設定、バックエンドによって、メモリ使用量と速度の結果は変わる可能性があります。テストしたfp16 KVキャッシュ設定では、Granite Q6_Kのコンテキスト長は16kにとどめてください。著者は32kでメモリ不足による失敗を報告しています。

よくある質問

12GB VRAMに最適なLLMは何ですか？

第一候補はGemma 4 12B QAT Q4_0です。提供されたRTX 3080 Tiの結果では、16kで90.0 tokens/s、7,816 MiBと報告されています。別途実施したRTX 4070での視覚的な2つの課題にも、どちらも合格しました。

ローカルLLMに12GB VRAMは十分ですか？

はい。12 GB GPUでは、GPUへのレイヤーオフロードを使い、一部の8B-12BモデルをQ6またはQ4で動かせます。入力埋め込みは引き続きシステムRAMを使用する場合があります。一部の低ビット27Bモデルも収まりますが、より高品質なQwen 3.8 27Bの量子化版では、コンテキストやデスクトップ用途に残るVRAMが少なすぎます。

12GB GPUで27Bモデルを動かせますか？

はい。提供された表では、GPUへのレイヤーオフロードを指定したBonsai 2 27Bの使用量は、16kで7,052 MiB、64kの割り当てで10,172 MiBでした。Prismのllama.cppフォークが必要です。提供されたAD-IQ3_XXSビルドは16kで失敗しました。AD-IQ2_XXSは32kで収まりましたが、これらの実行では品質評価を行っていません。

12GB VRAMではどの量子化形式を使うべきですか？

8B-9BモデルにはQ6_Kを使用してください。Gemma 4 12Bには、GoogleのQAT Q4_0ビルドを使用してください。LFM2.5-2.6BやGemma 4 E4Bなどの小型モデルならQ8_0が収まります。GGUFのファイルサイズだけでなく、使う予定のコンテキスト長でのVRAM総使用量を確認してください。

12GB VRAMではどの程度のコンテキスト長を使えますか？

16kから始めてください。テストした8つのモデルのうち7つは64kの割り当てで読み込めたと報告されていますが、Granite 4.2 8Bは32kでメモリ不足になりました。VRAM使用量はパラメータ数だけでなく、アーキテクチャ、KVキャッシュの種類、OS、画面表示への使用状況、ランタイムにも左右されます。

RTX 3060 12GBは2026年もローカルAIに適していますか？

はい。これらの量子化版のサイズはRTX 3060 12GBでの出発点として役立ちますが、選んだコンテキスト長とバックエンドでメモリ使用量を確認してください。ここではRTX 3060 12GBの速度は測定していません。より新しい12GBカードでも、公称VRAM容量は同じです。新しいというだけで、より大きな量子化版が収まるようになるわけではありません。