24GB GPU で動作する最強ローカルLLM比較

本格的なローカル推論を行うには、24GB の VRAM を備えた単一の GPU が実質的な最低ラインとなります。この容量は、実際に能力を発揮できるモデルを動かすのに十分であり、一方で 1 つの GPU に収まるサイズでもあります。RTX 3090 や RTX 4090 はまさにこのカテゴリに該当します。

重要なのは、あなたが所有しているカードそのものよりも、そのカードに適したモデルを選定することです。

かつての愛好家たちは、70B の量子化モデルを無理やり GPU に詰め込むことを良しとしました。しかし、そのアドバイスはもはや時代遅れです。2026 年において有効な戦略は、現代的な 20B〜35B クラスのモデルを採用し、余裕を持って動かすことです。これにより、コンテキスト長を確保しつつ、コーディングやチャット、エージェント処理でも十分な速度で応答できます。

本ガイドでは、実際に 24GB に収まるモデルと、それぞれがなぜ推奨されるのか、そして 24GB の VRAM がどのように配分されるのかについて解説します。

24GB の VRAM は実際にはどこに消費されるか

推論時にメモリを消費するのは主に 3 つの要素です。この内訳を適切に調整できるかが、モデルが GPU に収まるかどうかを決定づけます。

まず一つ目は「モデルの重み（weights）」です。そのサイズはパラメータ数と量子化方式によって決まります。家庭での推論で一般的なデフォルト設定である Q4_K_M 量子化の場合、1 パラメータあたり約 0.58 バイトを消費します。つまり、32B モデルであれば重みだけで 18〜20GB の容量が必要となります。

ここで注意すべきは、Mixtral 型の Mixture-of-Experts（MoE）モデルです。これはよくある罠で、トークンごとにルーティングされるのは少数のエキスパートであっても、すべてのエキスパートが VRAM に常駐し続けます。したがって、MoE モデルのメモリ容量を算出する際は、アクティブなパラメータ数ではなく、総パラメータ数を基準に sizing する必要があります。

二つ目は「KV キャッシュ」です。これはコンテキスト長に応じてサイズが増大します。長いプロンプトや長時間のセッションほど、多くの VRAM を消費します。

三つ目は、推論サーバーのスタックによるランタイムオーバーヘッドです。安全策として、短いコンテキストの場合でも KV キャッシュとランタイム用に 1〜2GB を余裕を持って確保しておくのが定石です。

24GB の GPU で動かすための鍵となるのが量子化です。Q4_K_M は、品質とメモリ使用量のバランスが取れた標準的な選択肢と言えます。Q5_K_M や Q6_K_M を選べば品質は向上しますが、その分メモリ消費も増えます。一方、Q8_0 や BF16 は、24GB の単一 GPU で 30B クラスのモデルを動かすには通常大きすぎます。

以下のインタラクティブツールでは、量子化方式を切り替えて各モデルがどの程度収まるかをリアルタイムで確認できます。

(function(){var f=document.getElementById("mtp24gb");

window.addEventListener("message",function(e){if(f&&e.source===f.contentWindow&&e.data&&e.data.__mtpH){f.style.height=e.data.__mtpH+"px";}});})();

24GB GPU で動作するローカル LLM 6選

以下に紹介する 6 つのモデルは、すべて Apache 2.0 または MIT のような寛容なライセンスの下で公開されています。いずれも Q4_K_M 量子化であれば、単一の 24GB GPU に収まり、コンテキスト長にも余裕を持って確保できます。これらはそれぞれ得意とするタスク別にグループ化しています。

Qwen3.6-27B — 総合性能とエージェント型コーディングに最適

Alibaba の Qwen3.6-27B は、この GPU 向けに選べる最も強力なデフォルトモデルです。これは 2026 年 4 月に Apache 2.0 ライセンスで公開された、密度の高い 27B パラメータのモデルです。リリースの焦点は、エージェント型コーディング、リポジトリレベルでの推論、そしてフロントエンドワークフローにあります。Q4_K_M で動作させる場合、約 16GB のメモリが必要となり、コンテキスト長のために十分な余裕が残ります。詳細なモデルカードや変更履歴は、Qwen3.6 の GitHub リポジトリで確認できます。

Qwen3.6-35B-A3B — 最速の汎用オプション

Qwen3.6-35B-A3B は、総パラメータ数 350 億、1 トークンあたり約 30 億のパラメータが活性化される Mixture-of-Experts（MoE）モデルです。各ステップで重みの一部しか使われないため、同サイズの密結合モデルに比べて推論速度は格段に速くなります。ただしメモリ使用量は総パラメータ数に基づいて計算されるため、Q4_K_M 量化では約 20GB の容量が必要になります。これはギリギリですが実用的な範囲であり、汎用チャットやツール利用における高速化を最優先する場合に適しています。

Gemma 4 26B — マルチモーダルかつ多言語対応

Google DeepMind は 2026 年 4 月 2 日、Apache 2.0 ライセンスの下で Gemma 4 をリリースしました。これは DeepMind の公式ページでも明記されている通り、完全なオープンライセンスを付与された最初の世代です。Gemma シリーズにはエッジ向けモデルや 12B の統一型マルチモーダルモデルに加え、38 億のパラメータが活性化する 26B MoE モデル、そしてより大規模な密結合のフラッグシップモデルが含まれています。視覚情報の入力と 140 以上の言語対応が必要な場合、この 26B MoE が 24GB GPU を使う際の最適な選択肢となります。

Mistral Small 3.2 24B — 洗練された日常アシスタント

Mistral の Small シリーズは、低遅延を要する日常的なアシスタントワークロードを対象に設計されています。Small 3.1 ではマルチモーダル入力と長いコンテキストウィンドウが追加され、Small 3.2 では指示の遵守性がさらに洗練されました。これは Apache 2.0 ライセンスの下で提供される 24B の密結合モデルで、本リストの中で最も軽量な部類に属します。Q4_K_M 量化では約 14GB のメモリ使用量です。この余裕があるため、より重い 32B モデルでは対応しきれないほど長いコンテキストを扱えるようになります。2026 年にも Mistral はより大規模な後継モデルをリリースしましたが、それらは単一 GPU で動作する範囲を超えています。

gpt-oss-20b — 推論が必要な場合の簡単な代替案

OpenAI の gpt-oss-20b は、Apache 2.0 ライセンスの下で公開されているオープンウェイトの推論モデルです。Mixture-of-Experts（MoE）アーキテクチャを採用しており、総パラメータ数は 21B ですが、トークン生成時にアクティブになるのは 3.6B です。ネイティブの MXFP4 形式（4 ビット量子化）で提供されており、メモリ使用量は約 14GB と余裕を持って動作します。構造的な推論やツール利用には強く優れていますが、広範な世界知識についてはやや劣ります。

DeepSeek-R1-Distill-Qwen-32B — 最良の推論性能と 24GB への最適適合

DeepSeek は R1 の推論プロセスを学習データとして活用し、より軽量な密結合モデルへと圧縮しました。その中で DeepSeek-R1-Distill-Qwen-32B は Qwen2.5 をベースに構築された 32B バリアントで、MIT ライセンスの下で公開されています。Q4_K_M（4 ビット量子化）でのメモリ使用量は約 18〜20GB と、本ガイドで紹介するモデルの中で最も狭い範囲に収まるのが特徴です。思考の連鎖（Chain of Thought）を可視化するトークンを出力するため、慎重な検討が必要な問題解決に適しています。Hugging Face の bartowski 氏による事前構築済みの GGUF バージョンも利用可能です。

24GB では動作しないモデルたち

2026 年現在の最先端オープンモデルは、大規模なスパース MoE システムです。性能や推論能力は非常に高いものの、単一のコンシューマー向け GPU で動かすことはできません。例えば Z.ai の GLM-5.2 は総パラメータ数約 753B の MoE モデルであり、Moonshot の Kimi K2.7 も約 1T に達します。DeepSeek は 2026 年 4 月に V4 を公開プレビューとしてリリースし、V4-Pro チェックポイントは約 1.6T パラメータを有しています。また、Alibaba の Qwen3.5-397B や Mistral Large 3 も同様にサーバークラスに分類される規模です。

MoE モデルのメモリ使用量は総パラメータ数に基づいて計算されるため、これらを実行するには複数 GPU を接続した環境か、大容量メモリを備えたユニファイドシステムが必要です。API として利用する価値は十分にあるものの、単一の 24GB GPU で動作させるという観点からは対象外となります。

これらのモデルをローカル環境で動かす方法

主に 3 つのランタイムが、ほぼすべての環境に対応しています。Ollama は最もシンプルな選択肢で、自動的な量子化の選択と OpenAI 互換 API を提供します。llama.cpp は GGUF 形式の量子化やオフロード設定を細かく制御したい場合に適しています。一方、vLLM は大量の並列処理を扱うサーバー向けに設計され、スループット性能に特化しています。

まずは、自分の主な用途に最も適したモデルを選びましょう。単に読み込める最大のファイルサイズで選ぶ必要はありません。コンテキスト長は適切に管理し、GPU が得意とする分野に集中させることが重要です。クラウドのエンドポイントへデータを一切送信せず、ローカル環境で本格的な AI を動かすことができます。

重要なポイント

• 24GB は実用的な下限ラインです。無理に最大の 70B モデルを圧縮して動かそうとするのではなく、サイズに合った 20B〜35B のモデルを実行すべきです。
• Qwen3.6-27B が単一モデルとしては最も強力なデフォルト選択肢です。一方、DeepSeek-R1-Distill-Qwen-32B は約 18〜20GB のメモリで動作するため、限られたリソースでは最も緊密にフィットする選択肢となります。
• MoE（Mixture of Experts）モデルの場合、メモリの使用量は全パラメータの合計に基づいて計算されます。つまり、トークン生成時に実際にルーティングされるエキスパートが少数であっても、すべてのエキスパートはメモリ上に常駐し続ける必要があります。
• 量子化がサイズ調整の鍵となります。Q4_K_M が家庭用環境でのデフォルト設定です。Q8_0 や BF16 では、24GB の GPU 1 枚で 30B モデルを動かすのはほぼ不可能です。
• GLM-5.2、Kimi K2.7、DeepSeek V4、そして Mistral Large 3 はサーバークラスモデルであり、単一の 24GB GPU では動作しません。