コーディングに最適なローカルLLM:8GB〜24GB VRAM別の選び方

いまコーディングに使うローカルLLMのベストは、24GBカードならQwen3 Coder 30B A3B、12〜16GBならQ4のQwen2.5 Coder 14B、8GBならQ4のQwen2.5 Coder 7Bです。 いずれも完全オフラインで動き、実コードの補完もリファクタリングもこなし、トークン単位の課金はゼロです。GPUのVRAMがモデルの必要量に足りなければ、モデルサイズを落とす前に量子化を1段下げてください。このガイドではモデルをVRAM帯に割り当て、実際に議論の的になる2つのコーディング系ファミリーを比較し、約5分でローカル生成を始められる実行コマンドで締めくくります。

自分のGPUでコーディングに使うローカルLLMはどれを選ぶべき?

まずVRAMで選び、次にモデルを選びます。重みとコンテキストがメモリに収まらなければ、モデルはそもそも動かないからです。2026年のコミュニティベンチマークと日常利用で繰り返し上位に来るのが、このショートリストです:

VRAM	モデル	量子化	ディスク上の重み	この帯で選ばれる理由
8 GB	Qwen2.5 Coder 7B Instruct	Q4_K_M	~4.7 GB	補完と小さめのリファクタで最高のトークン速度対品質比
12 GB	Qwen2.5 Coder 14B Instruct	Q4_K_M	~9.0 GB	ファイル丸ごとの編集がコンテキストに収まる。3060クラスでも30+ tok/s
16 GB	Qwen3 14B または gpt-oss-20b	Q4_K_M	~9–12 GB	曖昧な仕様での推論が強い。4090クラスなら速度も維持
24 GB	Qwen3 Coder 30B A3B	Q4_K_M	~18.6 GB	MoE:トークンごとに約3Bパラメータだけ有効化され、速度が実用域を保つ

この表を実戦で機能させるルールが2つあります:

1. KVキャッシュのために 1〜2GBのVRAM余裕を残す。Q4の14Bモデル + 8Kトークンのコンテキストは、10GBの予算には収まりません。コンテキストも合計に数えます。
2. モデルサイズを落とす前に、量子化を1段下げる。 Q5/Q4の量子化コストは品質の数%ですが、14Bの代わりに7Bにするコストはそれよりずっと大きい。

ローカルコーディングLLMに必要なVRAMはどれくらい?

正直な経験則で言えば、必要VRAM ≈ 量子化済み重み + 8bit KVキャッシュでコンテキスト1Kトークンあたり約0.125GB です。具体的な数字に直すと:

• 8 GB はQ4の7B〜8Bモデルが余裕で動きます。補完程度の長さの回答と、4K〜8Kのコンテキストが目安です。
• 12 GB はQ4の14Bにとってのスイートスポットです。モデルと、現実的な8K〜16Kのコーディングコンテキストの両方に十分な空きがあります。
• 16 GB は20Bクラスのdenseモデルと、より長いコンテキストのQwen3 14Bを解禁します。
• 24 GB はQ4のQwen3 Coder 30B A3B MoEを動かせます。自分でホストできる中で、もっともクラウド品質に近いコーディングモデルです。

CPUのみでも動きます。llama.cppはノートPCのCPUでも7B Q4を5〜10 tok/sで喜んで動かします。ただしそれは日常の主力ではなく、忍耐の鍛錬として扱ってください。ランタイムのインストールまわりはOllama vs LM Studio比較が、モデルの下に敷くローカルLLMツールの選択を扱っています。

Qwen3 Coder vs DeepSeek:コーディングならどちらが強い?

補完バー利用者が実際に問う対決ですが、答えはきれいに分かれます:

• Qwen3 Coder (30B A3B) は編集ループのために作られています。ツール呼び出しの指示フォーマットの規約に従い、一貫したdiffを出し、そして決め手としてMoE設計によりトークンごとに約3Bパラメータしか有効化しないため、24GBカード1枚で40〜60 tok/sが出ます。IDE的な用途では、応答速度こそ品質です。
• DeepSeek V3/R1系 はより上位のレベルで議論します。アーキテクチャの意思決定、厄介なアルゴリズム、多段の推論です。しかしフラッグシップは600B+パラメータあり、ローカルではマルチGPUやMacのユニファイドメモリ構成で強い量子化をかけてしか動かず、コードを書くよりコードについての文章を書くほうが速い。

ローカルでの選択:日々の主力はQwen3 Coder、DeepSeekはほぼフル精度でホストできるハードウェアがある場合だけ。 8〜16GBでは議論自体が無意味です。収まる中で最強なのはQwen2.5/3 Coderだからです。

OllamaでローカルコーディングLLMを動かすには?

5つのコマンドで、ゼロからエディタが使えるOpenAI互換APIまで行けます:

# 1. Ollamaをインストール(Linux)
curl -fsSL https://ollama.com/install.sh | sh

# 2. VRAM帯に合うモデルをpull(8GBカードの例)
ollama pull qwen2.5-coder:7b

# 3. 対話形式でチャットする
ollama run qwen2.5-coder:7b

# 4. OpenAI互換APIとして任意のツールから使う
curl http://localhost:11434/v1/chat/completions 
  -d '{
    "model": "qwen2.5-coder:7b",
    "messages": [{"role": "user", "content": "Refactor this fn to be async: add(a,b){return a+b}"}]
  }'

# 5. OPENAI_BASE_URL を期待するツールの向き先にする
export OPENAI_BASE_URL=http://localhost:11434/v1

APIキーもレート制限もトークン課金もありません。Linuxではインストーラがsystemd unitを登録するので、サーバーが不調になったら journalctl が理由を教えてくれます。サービスデバッグ用の正確なフィルタはjournalctlチートシートにあります。

ローカルLLMは実務のコーディングに耐えるのか?

編集ループにはイエス、難問にはノー。そしてその切り分けが、そのまま正しい使い方です。 14B〜30Bのローカルモデルは、リファクタリング、ボイラープレート、テストの雛形、正規表現、「このレガシー関数を説明して」を、大半のクラウドAPIの往復より速く処理します。大型のホステッドモデルに負けるのは、長いマルチファイルの推論とニッチなフレームワーク知識です。30Bモデルはフロンティアモデルより、単純に知識が少ないのです。

機能するワークフローはこうです。キーストロークの90%はローカルモデルに任せ、厄介な設計の問いだけホステッドのフロンティアモデルへ。日常業務ではコードがマシンの外に出ません。クライアントコードでは重要な話です。そしてすでに持っているVRAMが、静かにサブスクリプションを置き換えてくれます。