結論
デスクトップ版RTX 3090で検証した6つのビルドの中で、総合的な第一候補はGemma 4 26B-A4B Q4_K_Mです。生成速度は159.8 tokens/s、32kでの使用量は17,430 MiBでした。まずはgemma-4-26B-A4B-it-Q4_K_M.ggufを使い、コンテキスト割り当てを32kに設定してください。検証したfp16での最大割り当ては192kで、使用量は20,789 MiBでした。
少ないメモリで手軽に使うなら、Gemma 4 12B Q4_K_Mは32kで8,486 MiBを使用し、両方のコーディング課題を1回目の試行で完了しました。Ternary Bonsai 2 27Bは測定したメモリ使用量が最も少なく、16kでのピークは7,064 MiBでしたが、Prismのllama.cppフォークを別サーバーとして実行する必要があります。5.54 GiBのファイルは、主要な速度ベンチマークとは別に検証しました。
Nemotron 3.5 Lightningは主要ベンチマークで193.7 tokens/sと最速の出力を記録しましたが、スネークゲームでは5回の試行が必要でした。Qwen3.8-27Bは元のチェックポイントについてベンダーが高いコーディング評価結果を報告していますが、今回検証した量子化版では、ブラウザで動作する各課題にそれぞれ2回の試行が必要でした。
| モデル | 検証した量子化形式 | ファイルサイズ | 32kでのVRAM使用量、Bonsaiは16k | 4kプロンプト | 生成 | 読み込めた最大割り当て | 適した用途 |
|---|---|---|---|---|---|---|---|
| Gemma 4 26B-A4B it | Q4_K_M | 15.64 GiB | 17,430 MiB | 4,506 tok/s | 159.8 tok/s | 192k | 検証した中での総合的な第一候補 |
| Ternary Bonsai 2 27B | PTQ1_0 | 5.54 GiB | ピーク7,064 MiB | 未測定 | 視覚的な動作テストのみ | 16k | 最小のメモリ使用量 |
| Qwen3.8-27B | AD-Q4_K_M | 15.94 GiB | 18,080 MiB | 1,296 tok/s | 41.8 tok/s | fp16で96k、q8_0で192k | コーディング向けの候補 |
| Nemotron 3.5 Lightning 30B-A3B | AD-IQ4_NL | 18.30 GiB | 18,342 MiB | 4,239 tok/s | 193.7 tok/s | 192k | 高速な出力と長い会話 |
| Gemma 4 12B it | Q4_K_M | 6.87 GiB | 8,486 MiB | 2,991 tok/s | 83.7 tok/s | 192k | 少ないVRAM使用量 |
| Muse Glimmer 30B | AD-Q4_K_M | 17.75 GiB | 18,116 MiB | 1,492 tok/s | 40.3 tok/s | 検証上限128k | エージェント用途を重視した選択肢 |
プロンプト処理はモデルが入力を読み取る速さを、生成はその処理後の出力の速さを測定します。5つの行には主要な速度ベンチマークと32kでのメモリ使用量を記載しています。Bonsaiには、別途実施した16kのコーディングテスト中のピークメモリ使用量を記載しています。コンテキストを割り当てて読み込めたことは、その範囲全体での回答品質を裏付けるものではありません。
新しい世代のカードについては、RTX 4090の比較とRTX 5090のベンチマークをご覧ください。今回の測定には単独で動作する推論ランタイムを使用しています。Atomic Chatの性能は、選択したバックエンドと設定によって異なります。
ベンチマークの実施方法
主要な速度ベンチマークと長いコンテキストのベンチマークは、VRAM 24,576 MiBのNVIDIA GeForce RTX 3090、NVIDIAドライバー580.65.06、llama.cpp b10988の公式CUDA 12.8ビルドを使うテスト環境で実施しました。バイナリには、Ampere GPU向けのネイティブなsm_86カーネルが含まれていました。
基本構成では、全レイヤーのGPUオフロード、並列スロット1つ、fp16のKVキャッシュを使用しました。Qwenの追加のq8_0割り当てテストは別途明記しています。速度測定では、llama-benchで4,096トークンのプロンプトを処理し、新たに128トークンを生成しました。Bonsai 2はPrism b10709フォークを使い、別途実施した視覚的なコーディングテストに参加しました。
長いコンテキストのテストでは、約8k、32k、128kトークンの文書を使用しました。事実情報を冒頭付近、中央、末尾付近に配置し、さらに2か所の情報を組み合わせる必要がある質問を用意しました。128kのテストを読み込めたモデルはすべて、4つの回答をすべて見つけ、要約にも必須の4つのトピックをすべて残しました。
RTX 3090におすすめのローカルLLM
Gemma 4 26B-A4B it:総合的な第一候補
Gemma 4 26B-A4B itは、25.2Bのパラメータを持つ混合エキスパートモデルで、トークンごとに約3.8Bのパラメータを有効化します。128個のエキスパートのうち8個と共有エキスパートに処理を振り分けるため、総パラメータ数が同程度のデンスモデルよりも大幅に速く生成できます。元のモデルはテキストと画像を入力でき、設定可能な推論と関数呼び出しに対応し、ネイティブで256kのコンテキスト長を備えています。
モデル開発元は、元のチェックポイントについて以下のスコアを報告しています。これらは、今回のRTX 3090でのGGUFテストで測定した値ではありません。
| ベンチマーク | スコア |
|---|---|
MMLU Pro 学術知識 | 82.6% |
GPQA Diamond 専門的な科学知識 | 82.3% |
LiveCodeBench v6 競技プログラミング | 77.1% |
MRCR v2, 128kで8個のneedle コンテキスト内の情報検索 | 44.1% |
このアーキテクチャはRTX 3090に特によく適しています。検証したモデルは159.8 tokens/sで生成し、4kプロンプトを4,506 tokens/sで処理しました。また、192kのfp16コンテキスト割り当てを20,789 MiBで読み込め、検証に使用したカードには約3.7 GiBのVRAMが残りました。
| 検証したファイル | 結果 |
|---|---|
| リポジトリ | AtomicChat/gemma-4-26B-A4B-it-GGUF |
| 使用したGGUFファイル名 | gemma-4-26B-A4B-it-Q4_K_M.gguf |
| ファイルサイズ | 15.64 GiB |
| 32kでのVRAM使用量 | 17,430 MiB |
| 4kプロンプト / 生成 | 4,506 / 159.8 tok/s |
| 128kの文書 | 最初のトークンまで59.3秒、事実情報4/4、要約のトピック4/4 |
| 読み込めたfp16での最大割り当て | 192k、20,789 MiB |
主なトレードオフは、長いプロンプトでの待ち時間です。128kの文書では最初のトークンが出るまで59.3秒かかったため、このカードで非常に大きな文書を扱うと、応答開始までに明確な遅延が生じます。
評価:高速な出力と、より長い文書を扱う余裕が必要なら、まずGemma 4 26B-A4Bを試してください。検証したビルドの中では総合的な第一候補です。Gemma 12Bなら、より多くのVRAMを空けておけます。
Ternary Bonsai 2 27B:最小のメモリ使用量
Ternary Bonsai 2 27Bは、3値の重みを使ってQwen3.8-27Bを大幅に圧縮したモデルです。Prismは実効1.72ビットの3値表現と説明していますが、配布版のPTQ1_0パッキングでは重みあたり約1.75ビットを使用します。
その結果、27Bモデルがわずか5.54 GiBのファイルに収まり、今回のRTX 3090でのテストでは約7,064 MiBのVRAMを使用しました。メモリ使用量は、はるかに小さなモデルと同程度です。
Prismは、H100上で思考を有効にし、EvalScopeとvLLMを使用して以下のスコアを報告しています。今回のRTX 3090でのコーディング結果は、その後の別表に記載しています。
| ベンチマーク | スコア |
|---|---|
MMLU-Redux 学術知識 | 89.09 |
AIME 2026 数学競技 | 95.83 |
LiveCodeBench 競技プログラミング | 90.07 |
IFBench, prompt-loose 指示追従 | 74.00 |
BFCL v3 関数呼び出し | 74.92 |
| 検証したファイル | 結果 |
|---|---|
| リポジトリ | prism-ml/Ternary-Bonsai-2-27B-gguf |
| 使用したGGUFファイル名 | Ternary-Bonsai-2-27B-PTQ1_0.gguf |
| ファイルサイズ | 5.54 GiB |
| ピークVRAM使用量 | 7,064 MiB |
| 跳ねる5個のボール | 1回の試行、175.7秒 |
| 自動でプレイするスネークゲーム | 2回の試行、237.9秒 |
| 検証したコンテキスト長 | 16k |
評価:ダウンロード容量の小ささと実測メモリ使用量に、Prismサーバーを別途動かすだけの価値を感じるなら、Ternary Bonsai 2を試してください。今回のコーディングテストは、その推論品質が、より容量の大きいすべての27Bビルドに匹敵することを裏付けるものではありません。必要なランタイムについては、Bonsai 2のセットアップガイドをご覧ください。
Qwen3.8-27B:コーディング向けの候補
Qwen3.8-27Bは、コーディング、調査、汎用的な支援向けに開発された、27.32Bのパラメータを持つデンスモデルです。アーキテクチャはGated DeltaNet層と従来型のアテンション層を組み合わせています。テキスト、画像、動画を入力できます。
モデル開発元は、元のチェックポイントについて以下のスコアを報告しています。これらは、今回のRTX 3090でのGGUFテストで測定した値ではありません。
| ベンチマーク | スコア |
|---|---|
GPQA Diamond 専門的な科学知識 | 89.2 |
Humanity's Last Exam 専門的な問題 | 30.8 |
SWE-bench Pro より難しいソフトウェアエンジニアリング | 61.7 |
Terminal-Bench 2.1 ターミナル操作エージェント | 73.0 |
LiveCodeBench v6 競技プログラミング | 90.3 |
Qwenの元のチェックポイントには高いコーディング評価結果が公表されていますが、それらの評価は、今回の6つの量子化ファイルを共通のテスト環境で順位付けしたものではありません。今回のAD-Q4_K_Mビルドは41.8 tokens/sで生成し、ブラウザで動作する各課題にそれぞれ2回の試行を要しました。Gemma 12BとMuseは、両方の課題を1回目の試行で完了しました。
| 検証したファイル | 結果 |
|---|---|
| リポジトリ | AtomicChat/Qwen3.8-27B-GGUF |
| 使用したGGUFファイル名 | Qwen3.8-27B-AD-Q4_K_M.gguf |
| ファイルサイズ | 15.94 GiB |
| 32kでのVRAM使用量 | 18,080 MiB |
| 4kプロンプト / 生成 | 1,296 / 41.8 tok/s |
| 読み込めたfp16での最大割り当て | 96k、22,239 MiB |
| 読み込めたq8_0 KVキャッシュでの最大割り当て | 192k、23,447 MiB |
もう1つの制約は、fp16のKVキャッシュです。Qwenは96kでは読み込めましたが、128kではメモリ不足になりました。KとVの両方のキャッシュ形式をq8_0に切り替えるとメモリ使用量が十分に減り、128kを20,951 MiB、192kを23,447 MiBで読み込めました。
評価:中程度のコンテキスト長でのコーディング用途にQwenを検討し、自分のコードベースで試してください。公表されているチェックポイントの評価は、ここで扱った2つのブラウザ向け課題よりも大規模なソフトウェア課題を対象としています。
NVIDIA Nemotron 3.5 Lightning:長い会話に最適
NVIDIA Nemotron 3.5 Lightning 30B-A3Bは、Mamba-2、アテンション、混合エキスパートの各層を組み合わせています。約30Bのパラメータを保持し、トークンごとに約3Bを有効化します。NVIDIAは、エージェントのワークフロー、ツール呼び出し、構造化出力、長時間にわたるタスク向けに設計しました。
NVIDIAは、BF16ベースラインについて以下のスコアを報告しています。これらは、今回のRTX 3090でのGGUF測定とは別のものです。
| ベンチマーク | スコア |
|---|---|
MMLU Pro 学術知識 | 81.94 |
GPQA Diamond, ツールなし 専門的な科学知識 | 75.44 |
SWE-bench Verified ソフトウェアエンジニアリング | 51.56 |
IFBench, loose 指示追従 | 71.88 |
AA-LCR 長いコンテキストでの推論 | 52.00 |
NemotronはRTX 3090で193.7 tokens/sを記録し、今回の主要な速度ベンチマークで最速でした。ハイブリッドアーキテクチャにより、コンテキスト用のメモリも少なく抑えられています。32kから192kに増やしても、実測VRAM使用量の増加はわずか1,119 MiBでした。192kの割り当てでは19,461 MiBを使用し、5 GB以上の空きが残りました。
| 検証したファイル | 結果 |
|---|---|
| リポジトリ | AtomicChat/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-GGUF |
| 使用したGGUFファイル名 | NVIDIA-Nemotron-3.5-Lightning-30B-A3B-AD-IQ4_NL.gguf |
| ファイルサイズ | 18.30 GiB |
| 32kでのVRAM使用量 | 18,342 MiB |
| 4kプロンプト / 生成 | 4,239 / 193.7 tok/s |
| 128kの文書 | 最初のトークンまで43.5秒、事実情報4/4、要約のトピック4/4 |
| 読み込めたfp16での最大割り当て | 192k、19,461 MiB |
実測した出力速度の速さと、コンテキスト割り当てに必要なメモリの少なさから、Nemotronは長いテキスト会話で試す価値があります。今回の実験では、RAGの精度や自律型エージェントの信頼性は測定していません。
評価:出力の速さを優先するならNemotronを選んでください。スネークゲームでは5回の試行を要したものの、リクエスト時間の合計は最短でした。ただし、試行の間に追加のフィードバックが必要になることを見込んでください。
Gemma 4 12B it:VRAM使用量を抑える用途に最適
Gemma 4 12B itは、Gemmaファミリーに属する、11.95Bのパラメータを持つデンスモデルです。より大きなGemma 4モデルと同じく、局所的なスライディングウィンドウアテンションと周期的なグローバルアテンションを組み合わせ、設定可能な推論とネイティブで256kのコンテキスト長を備えています。元のチェックポイントはテキスト、画像、音声、動画を入力し、テキストを生成します。今回のGGUFテストではテキストのみを使用しており、すべてのランタイムでのマルチモーダル対応を裏付けるものではありません。
モデル開発元は、元のチェックポイントについて以下のスコアを報告しています。これらは、今回のRTX 3090でのGGUFテストで測定した値ではありません。
| ベンチマーク | スコア |
|---|---|
MMLU Pro 学術知識 | 77.2% |
GPQA Diamond 専門的な科学知識 | 78.8% |
LiveCodeBench v6 競技プログラミング | 72.0% |
MRCR v2, 128kで8個のneedle コンテキスト内の情報検索 | 43.4% |
Gemma 4 12Bは比較的軽量で、今回のRTX 3090でのテストでは、Q4_K_Mチェックポイントの使用量は32kトークンでわずか8,486 MiBでした。カードには約15.7 GiBの空きが残り、ほかのタスクに使用できます。メモリ使用量は少ないものの最速ではなく、生成速度は83.7 tokens/sでしたが、ローカルで滑らかにチャットするには十分な速さです。
| 検証したファイル | 結果 |
|---|---|
| リポジトリ | AtomicChat/gemma-4-12B-it-GGUF |
| 使用したGGUFファイル名 | gemma-4-12b-it-Q4_K_M.gguf |
| ファイルサイズ | 6.87 GiB |
| 32kでのVRAM使用量 | 8,486 MiB |
| 4kプロンプト / 生成 | 2,991 / 83.7 tok/s |
| 128kの文書 | 最初のトークンまで91.1秒、事実情報4/4、要約のトピック4/4 |
| 読み込めたfp16での最大割り当て | 192k、11,205 MiB |
Gemma 4 12Bは、2つのMoEモデルよりも128kの文書を読み取るのに時間がかかりました。一方で、空きメモリはより多く残るため、GPUでほかのアプリケーションも動かす場合に役立ちます。
評価:標準ランタイムで動く、より小さなビルドが必要ならGemma 4 12Bを選んでください。32kで8,486 MiBを使用し、両方のコーディング課題を1回目の試行で完了しました。
Muse Glimmer 30B:エージェント用途を重視した選択肢
Muse Glimmer 30Bは、Muse Sparkから蒸留された、Metaのデンス型ローカルエージェントモデルです。複数段階の推論、ツールの使用、操作失敗後の復旧に向けて学習されています。
モデル開発元は、元のチェックポイントについて以下のスコアを報告しています。これらは、今回のRTX 3090でのGGUFテストで測定した値ではありません。
| ベンチマーク | スコア |
|---|---|
MCP Atlas MCPツール | 75.5 |
DeepSearch QA 詳細な調査 | 74.6 |
GPQA Diamond 専門的な科学知識 | 83.5 |
SWE-bench Pro より難しいソフトウェアエンジニアリング | 51.2 |
Terminal-Bench 2.1 ターミナル操作エージェント | 51.7 |
| 検証したファイル | 結果 |
|---|---|
| リポジトリ | AtomicChat/Muse-Glimmer-30B-GGUF |
| 使用したGGUFファイル名 | Muse-Glimmer-30B-AD-Q4_K_M.gguf |
| ファイルサイズ | 17.75 GiB |
| 32kでのVRAM使用量 | 18,116 MiB |
| 4kプロンプト / 生成 | 1,492 / 40.3 tok/s |
| 128kの文書 | 最初のトークンまで94.3秒、事実情報4/4、要約のトピック4/4 |
| 読み込めた最大割り当て | 検証上限128k、19,459 MiB |
Museは今回の比較の中で生成速度が僅差で最も遅く、文書全体の取り込みにも最も時間がかかります。選ぶ理由はスループットではなく、ツールを使う複数段階の作業に向けて学習されている点です。
評価:Metaのエージェント用途を重視したモデルをローカルで評価したいなら、Museを試してください。ブラウザで動作する両方の課題を1回目の試行で完了しましたが、この結果は自律的なツール使用を測定したものではありません。
実動テスト:スネークゲームと跳ねるボールをコーディング
6つのモデルに、視覚的に動作を確認できる2つのコーディング課題を与えました。ヘビが餌を見つけて成長する自動プレイのスネークゲームと、5個のボールが重力の下で動き、弾性衝突する物理シミュレーションです。
各モデルには、単体で動作するHTMLファイルを1つ返すよう求めました。コードでエラーが発生した場合は、ブラウザのエラー、または不具合の挙動を正確に記述した説明をモデルに送り返しました。
コーディングテストは2026年9月19日から21日にかけて、NVIDIAドライバー590.48.01を搭載した別のRTX 3090ホストで実施しました。コンテキスト長は16k、temperatureは1.0、top-pは0.95、top-kは64、seedは42です。5つのモデルはllama.cpp b10988で出力上限を8,192トークンに設定し、Bonsai 2はPrism b10709フォークで出力上限を16,384トークンに設定しました。推論強度はQwenとBonsaiが中、Museが高で、Gemma各モデルは推論を有効化したデフォルト設定、Nemotronは無効にしました。
合計生成時間は、プロンプト処理と推論を含む、モデルへのリクエスト所要時間を合算したものです。ブラウザでのテストとフィードバックにかかった時間は含みません。Bonsaiの試行回数と時間は、最終的な出力上限16,384トークンの設定での試行から数えており、事前に8kの上限で失敗した試行は含めていません。動画には、最終的に動作した出力を示しています。この2つの課題は、コーディング品質の総合的な順位を確定するものではありません。
自動でプレイするスネークゲームをコーディング
1回目の試行で動作するスネークゲームを生成したのはGemma 4 12BとMuse Glimmerだけでしたが、最終的には6つのモデルすべてが、ヘビが餌を見つけて成長し、スコアが増えるゲームを作成しました。
RTX 3090でのスネークゲームのデモをYouTubeで見る
| モデル | 試行回数 | 合計生成時間 |
|---|---|---|
| Gemma 4 26B-A4B | 2 | 99.4秒 |
| Nemotron 3.5 Lightning | 5 | 68.4秒 |
| Qwen3.8-27B | 2 | 185.6秒 |
| Muse Glimmer 30B | 1 | 150.0秒 |
| Gemma 4 12B | 1 | 71.5秒 |
| Ternary Bonsai 2 27B | 2 | 237.9秒 |
Nemotronは5回の試行を要しましたが、それでも合計生成時間は最短でした。Bonsai 2の最初のゲームはエラーなく動作したものの、餌を一度も食べませんでした。マンハッタン距離を最小化するようフィードバックを受けると、2つ目のバージョンは30秒以内にスコア18に達しました。
跳ねる5個のボールをコーディング
Gemma 4 26B-A4B、Gemma 4 12B、Muse Glimmer、Bonsai 2は、1回目の試行でシミュレーションを完成させました。Qwenは2回、Nemotronは4回の試行を要しました。
RTX 3090での跳ねるボールのデモをYouTubeで見る
| モデル | 試行回数 | 合計生成時間 | ピークVRAM使用量 |
|---|---|---|---|
| Gemma 4 26B-A4B | 1 | 36.1秒 | 17,114 MiB |
| Nemotron 3.5 Lightning | 4 | 41.0秒 | 18,268 MiB |
| Qwen3.8-27B | 2 | 182.4秒 | 17,046 MiB |
| Muse Glimmer 30B | 1 | 140.3秒 | 17,898 MiB |
| Gemma 4 12B | 1 | 57.0秒 | 8,220 MiB |
| Ternary Bonsai 2 27B | 1 | 175.7秒 | 7,064 MiB |
Gemma 4 26B-A4Bが36.1秒で最初に完成させました。Nemotronの初期バージョンでは、衝突時の力積を誤った符号で適用したため、ボールが互いに向かって加速し、隅に閉じ込められました。4つ目のバージョンで物理処理が修正されました。
ローカルLLM向けのRTX 3090、4090、5090比較
デスクトップ版RTX 3090とRTX 4090はいずれも24 GBのVRAMを搭載しているため、モデルに使えるメモリ容量は同程度です。実際に収まるかどうかは、ランタイム、コンテキスト長、ほかの用途で使用しているGPUメモリにも左右されます。ただし、4090はより新しいアーキテクチャを採用しており、大きなプロンプトを2倍以上の速さで処理できます。生成速度の優位性は、それよりも大幅に小さくなります。
RTX 5090は32 GBのVRAMを搭載しているため、より大きなモデルを収められ、生成とプロンプト処理の両方も高速です。
以下の各行では、同名のGGUFビルドを、4,096トークンのプロンプト処理 / 128トークンの生成という負荷条件で比較しています。4090と5090の値は、リンク先のGPU比較記事から引用しています。
| モデルと指標 | RTX 3090 | RTX 4090 | RTX 5090 |
|---|---|---|---|
| Qwen3.8-27B、4kプロンプト | 1,296 tok/s | 3,004 tok/s | 3,830 tok/s |
| Qwen3.8-27B、生成 | 41.8 tok/s | 48.5 tok/s | 74.2 tok/s |
| Gemma 4 26B-A4B、4kプロンプト | 4,506 tok/s | 9,970 tok/s | 11,829 tok/s |
| Gemma 4 26B-A4B、生成 | 159.8 tok/s | 194.1 tok/s | 248.6 tok/s |
この2つの例は、実用上のトレードオフを示しています。3090では生成速度が41.8 tokens/sと159.8 tokens/sを維持する一方で、大きな入力の処理には大幅に長い時間がかかりました。
QwenとGemma 26B-A4Bでは、RTX 4090が4kプロンプトを約2.2〜2.3倍の速さで処理しました。RTX 3090の生成スループットは、それぞれ約14%と18%低い値でした。これらの割合は検証した2つの構成についてのものであり、すべてのローカルLLMに当てはまるものではありません。
Atomic Chatでこれらのモデルを動かす方法
Gemma、Qwen、Nemotron、Museの場合:
- Atomic Chatをインストールし、Find optimal backendを選択します。
- Modelsを開き、選んだモデルのカードに記載されているリポジトリを検索します。
- Download Optionsを開き、表に記載されているGGUFファイル名と完全に一致するものを選択します。
- まずはコンテキスト割り当てを32kにし、全レイヤーをGPUにオフロードします。特定のタスクで必要になった場合に、コンテキスト長を増やしてください。
GGUFがすでにコンピューターにある場合は、Settings → Model Providers → llama.cpp → Importからインポートします。セルフホストLLMのセットアップ完全ガイドをご覧ください。
このカードでQwenを96k超のコンテキスト長で使うには、圧縮したKVキャッシュが必要です。128kでの同等の設定をllama.cppで直接実行するコマンドは、次のとおりです。
llama-server -m /path/to/Qwen3.8-27B-AD-Q4_K_M.gguf -ngl 999 -c 131072 \ --parallel 1 --cache-type-k q8_0 --cache-type-v q8_0
今回のテストでは、モデルは128kで20,951 MiBを割り当てて読み込めました。32kや64kで十分な通常のチャットでは、コンテキスト割り当てを小さくし、fp16を使用してください。
Ternary Bonsai 2の場合:
標準のllama.cppは、このモデルに対応していません。PTQ1_0とPQ2_0の形式が標準ランタイムでは利用できないため、PrismMLフォークが必要です。また、このモデルには大きな出力上限が必要です。今回の試行では、上限が8,192トークンの場合、完全に動作するHTMLファイルを生成できませんでした。今回のテストで動作した上限は16,384トークンでした。
Atomic Chatで使用するには、Prismのllama-serverを別途実行し、セルフホスト用のllama.cpp serverプロバイダー経由で接続します。Atomic Chatの内蔵エンジンは、現時点ではこのGGUFを読み込めません。
よくある質問
RTX 3090で動かすのに最適なLLMはどれですか?
検証した6つのビルドの中で、総合的な第一候補はGemma 4 26B-A4B Q4_K_Mです。生成速度は159.8 tokens/s、32kでの使用量は17,430 MiBでした。まずは32kから始めてください。別途検証した192kの割り当てでは20,789 MiBを使用しました。
ローカルLLMに24 GBのVRAMで足りますか?
24 GBを搭載するRTX 3090なら、現在の12B〜32Bモデルの多くを完全にGPU上で実行できます。今回の32kベンチマークに含まれる5つのモデルは、8,486〜18,342 MiBを使用しました。Ternary Bonsai 2は、別途実施した16kのコーディングテストで7,064 MiBを使用しました。
RTX 3090で70Bモデルを動かせますか?
パラメータあたりちょうど4ビットの場合、70Bの重みだけで約35 GBを占め、さらに形式固有のオーバーヘッドとランタイム用メモリが必要です。これは24 GBを超えます。一部をCPUにオフロードするか、対応するマルチGPU構成を使えば、より大きなファイルを実行できますが、性能はランタイムとGPU間の接続に左右されます。
RTX 3090でコーディングに最適なLLMはどれですか?
Qwen3.8-27Bは、元のチェックポイントについてベンダーが高いコーディング評価結果を報告しています。今回のAD-Q4_K_Mファイルは32kで18,080 MiBを使用し、41.8 tokens/sで生成しましたが、ブラウザで動作する各課題にそれぞれ2回の試行を要しました。Gemma 12BとMuseは、両方とも1回目で合格しました。これらの課題だけでは、大規模なコードベースで最も優れたモデルは決められません。
中古のRTX 3090は、2026年でもローカルAIに適していますか?
RTX 3090は24 GBのVRAMを備えており、現在もローカルAIに役立ちます。条件をそろえたQwenとGemma 26B-A4Bの例では、4090が4kプロンプトを約2.2〜2.3倍の速さで処理しました。3090の生成スループットは、それぞれ約14%と18%低い値でした。これらの数値は、この2つの構成についてのものです。中古カードの状態と価格については、別途購入判断が必要です。
RTX 3090を2枚使うと、利用可能なVRAMは2倍になりますか?
RTX 3090を2枚使うと、物理的なVRAMの合計は48 GBになります。対応する推論ランタイムなら、重みと処理を2枚に分散できますが、利用可能な容量は分割方式とオーバーヘッドによって異なります。カード間の通信が速度を制限する場合があり、2枚のカードが1枚の48 GB GPUと同じように動作するわけではありません。

