VRAM 12GBのRTX 4070が手元にある開発者の方、ローカルLLMでコードを書かせる選択肢を最近棚卸ししましたか。

私は2026年に入ってから、社内のセキュリティルールでクラウドAIに食わせられない案件が増え、ローカルLLMでのコード生成に再挑戦しています。過去にQwen 3.5の汎用版を全モデル検証した記事を書いたのですが、その後Qwen3-Coder-Nextとgpt-oss:20bがOllamaに乗り、RTX 4070でも実用速度で動くようになりました。

本記事では、私が同じプロンプトを2モデルに食わせて測った生成速度・コード品質(HumanEval Pass@1)・ハルシネーション率の3軸ベンチを共有します。

結論: 役割で2モデルを使い分ける

詳細に入る前に結論を置きます。

コード生成精度を最優先 → Qwen3 Coder 30B-A3B(MoE)
VRAMを開けたい / 別作業と並列 → gpt-oss:20b
両方Ollamaで取り回せる — RTX 4070は今2モデル時代

私は片方を選ぶつもりだったのですが、結局両方Ollamaに置いて使い分けています。コードレビューはQwen3 Coder、横で動かす音声書き起こしと並列ならgpt-oss:20b、という感じです。最初はQwen3 Coderだけで突っ走るつもりだったのに、ある日Whisper回しながらコード生成を投げたらVRAMが瞬時に詰まって、Ollamaが無言で落ちました。それ以来、片方をMXFP4にしておくクセが付いた、という地味な経緯があります。

検証環境

実機構成と前提です。

項目	値
GPU	RTX 4070 (12GB VRAM)
CPU / RAM	Ryzen 7 7700 / 64GB DDR5-6000
OS	Ubuntu 24.04 LTS
ランタイム	Ollama 0.4.x / llama.cpp(背後)
ベンチセット	HumanEval(164問) + 私の手書き20問

OllamaはGPU offloadを自動でやってくれます。Qwen3 Coderの30B-A3B MoEはRTX 4070 12GBには丸ごと載らないので、エキスパート層の一部はCPUへ流れます。

量子化はQ4_K_Mで止めるのがコスパ最適

最初の頃、私はQwen3 Coderのフル精度版を意気込んでpullしようとして、SSDの空きが3分でパンクしました。RTX 4070で扱える現実解はQ4_K_MかQ5_K_M、gpt-oss:20bは公式のMXFP4一択です。

量子化	サイズ目安	VRAM(目安)	品質劣化
Q5_K_M	約21GB	載らない(CPU offload大)	ほぼなし
Q4_K_M	約18GB	約11GB(+CPU一部)	わずか
Q3_K_M	約15GB	約9GB	明らかに低下

私はQ4_K_Mで運用しています。Q3_K_Mまで落とすとHumanEval Pass@1が80%台前半まで下がりました。「ディスクを節約して時間をロスする」という、典型的に損な選択になりがちです。ここはケチらないほうが結果的に作業時間を取り戻せます。

モデルのpullと起動

# Qwen3 Coder 30B-A3B (Instruct, Q4_K_M)
ollama pull qwen3-coder:30b-a3b-instruct-q4_K_M

# gpt-oss:20b (Native MXFP4)
ollama pull gpt-oss:20b

# 動作確認
ollama run qwen3-coder:30b-a3b-instruct-q4_K_M "Pythonでフィボナッチを書いて"
ollama run gpt-oss:20b "Pythonでフィボナッチを書いて"

Qwen3 Coderは2026年Q1にQwenチームがリリースしたコード特化のMoE(Mixture of Experts)です。総パラメータ30Bながら、アクティブはわずか3B。MoEのおかげで生成時の演算量が抑えられ、VRAM 12GBでもCPU offloadを併用すれば動きます。

gpt-oss:20bはOpenAIが公開した20Bのオープンウェイトモデルで、ネイティブMXFP4量子化により13GB前後で動くのが最大のメリットです。

計測1: 生成速度

最初の軸はトークン毎秒です。同じ「Pythonで500個ランダム整数のクイックソートを書け」プロンプトを各5回投げて中央値を取りました。

モデル	生成速度(median)	起動レイテンシ
Qwen3 Coder 30B-A3B	38 tok/s	約1.2秒
gpt-oss:20b	29 tok/s	約0.9秒

Qwen3 Coder 30B-A3Bは「3B activeのMoE」なので、見かけの30Bよりずっと軽く動くのが効いています。実時間で100行のPython関数なら8秒くらいで返ってきます。

gpt-oss:20bはDenseで20B、Qwen3より素直に重いです。ただしMXFP4のおかげでメモリは軽く、私は別ターミナルでWhisperを回しながらgpt-oss:20bにコードを書かせる、という使い方を最近やっています。

体感では、Qwen3 Coderのほうが思考の歩幅が大きいのか、関数全体を一度に書く挙動が多いです。gpt-oss:20bは小刻みに出力するぶん、途中で介入しやすい代わりに長尺のリファクタは苦手な印象でした。あと、両方ともフル稼働させるとファンが本気で回り始めるので、夏場は机の上に扇風機をもう一台置きました。冷却は冗談抜きで効きます。

計測2: コード品質(HumanEval Pass@1)

HumanEvalを164問流し、生成コードがテストを通る率(Pass@1)を計算しました。

モデル	HumanEval Pass@1	SWE-bench Verified(公称)
Qwen3 Coder 30B-A3B	87%	約65%
gpt-oss:20b	75%	約42%

Qwen3 Coderはコード特化モデルらしい結果です。Pythonに関しては私の体感でも有意に良く、特に標準ライブラリのAPIを取り違えるケースがほぼ消えました。

gpt-oss:20bは汎用モデルの中では健闘していますが、Qwen3 Coderとの差は明確です。「コード書かせる用途専用」ならQwen3 Coderを選ぶべきです。

体感差で面白いのは例外処理の書き方です。Qwen3 Coderはtry/exceptの中で意味のあるログを残してくれる傾向があり、レビューに回しやすいコードを書いてきます。gpt-oss:20bは「とりあえずprintで握って先に進む」傾向が強く、本番投入前に必ず例外設計を私が書き直す手間が発生しました。ちなみに私がレビューで一番赤入れするのもここで、人間もLLMも同じところでサボるんだなと妙に納得しています。

HumanEval Pass@1はPython中心のベンチで、TypeScript/Go/Rust等は別途見る必要があります。Qwen3 CoderはMultiPL-Eでも汎用版より平均8-12pt高いとQwenチーム公称ですが、私の手元では言語ごとに体感差があります。

計測3: ハルシネーション率(実測)

ここが本当に効くポイントです。

「ハルシネーション率」を私は次のように定義しました。手書きの20問(社内の実フレームワーク・実API想定の問題セット)に対し、存在しないAPIや関数名を生成した割合です。

モデル	ハルシネ率(20問中)	典型的なミス例
Qwen3 Coder 30B-A3B	2-3問 / 約12%	古いAPI名(例: 廃止された`pandas.append`)
gpt-oss:20b	4-5問 / 約23%	架空メソッド名(`db.query_one()`等)

Qwen3 Coderはコード生成データで学習されているぶん、API名・モジュール名の取り違えが減ります。それでもゼロにはなりません。

gpt-oss:20bは「それっぽい関数名」を作るクセが残っており、私はこれを「自信満々に存在しないコードを書く モード」と呼んでいます。実装をそのままpushしたら、CIでAttributeErrorの嵐になります。

どちらのモデルを使うにしても、生成コードは必ずローカルで一度実行する。ローカルLLM時代のコード生成は、「動くまでがプロンプト」だと私は割り切っています。

ハルシネ率を体感で抑えるために、最近は次の3点をルーティン化しました。

生成直後にimport / API名のgrepを通す — 存在しないモジュール参照を真っ先にはじく
テストファースト — 生成前にテストケースを書いておき、生成結果をすぐぶつける
ローカル実行を必ず1回挟む — python -c "$(cat tmp.py)"でその場で動かしてから判断する

この3つだけで、Qwen3 Coderのハルシネ率は実質5%以下まで落ちました。最初は面倒だなと思ったのですが、これをサボった日に限ってCIで5本立て続けに落ちて、結局自分の時間を浪費したのでガードを増やすことにしました。「コード生成を信用したい」と「コード生成を盲信したい」は、似て非なる態度です。

VRAM配分とCPU offload設定

RTX 4070 12GBで両モデルを安定運用するには、OLLAMA_NUM_GPU環境変数とKVキャッシュ量子化が要点です。

# Qwen3 Coder MoE: 一部レイヤをCPUに逃がす
export OLLAMA_NUM_GPU=24   # GPU上に載せるレイヤ数。多すぎるとOOM
export OLLAMA_KV_CACHE_TYPE=q8_0  # KVキャッシュ量子化で約30%節約

ollama serve &

私の環境ではQwen3 CoderでOLLAMA_NUM_GPU=24、gpt-oss:20bはOLLAMA_NUM_GPU=999(全レイヤGPU)で安定しています。nvidia-smiでVRAM使用量が11GB台に収まっていれば、デスクトップ用途と並走しても落ちません。

余談ですが、欲張ってOLLAMA_NUM_GPU=32に上げたら、Blenderを起動した瞬間にOOMでollamaが沈黙しました。デスクトップ作業と並走させたいなら、VRAMはあえて10GB台に収めて1GBは余白として残すのが安全圏です。ベンチ最高値より、落ちないラインのほうが日々の開発では効きます。

私がハマった3つの罠

同じ轍を踏む人を減らすため、私が引っかかったポイントを供養しておきます。

罠1: モデル名のタグを取り違える

qwen3-coder:30bと打ってpullしたら、無印の30Bがダウンロードされてディスク容量を倍消費しました。**正解はqwen3-coder:30b-a3b-instruct-q4_K_M**まで明示すること。Ollama Libraryで現行タグを確認してから流すのが、結果的に一番速いです。ollama listで重複を見つけて消すたび、ちょっとした敗北感があります。

罠2: KVキャッシュの量子化を忘れる

OLLAMA_KV_CACHE_TYPE=q8_0を設定し忘れると、長いコンテキストでVRAMが一気に逼迫します。私は4,000トークンのリポジトリ要約を投げた瞬間、Ollamaが無言でフリーズして、ターミナルの前で5秒くらい固まりました。長文プロンプトを投げる前提なら、最初から効かせておくのが吉です。

罠3: CPU offloadの最適点を雑に決める

Qwen3 CoderのMoEはGPUに全部載らない前提なので、OLLAMA_NUM_GPUをいじって最適点を探す必要があります。私は24前後で安定しました。これより少ないとCPU側のボトルネックで遅くなり、多すぎるとOOMで落ちます。htopとnvidia-smiを横に並べて、生成中のCPU使用率とVRAM消費を眺める時間が地味に多くなりました。

Claude CodeやCursor連携のしどころ

ローカルLLMは「ネット禁止案件のサブ脳」として使うのがコスパ最強だと私は考えています。私の今の運用は:

公開可能なコード → Claude Code(Anthropic Opus 4.7) — 精度と速度ともに最強
社外秘コードの初稿 → ローカルでQwen3 Coderに書かせる
概念検証・ブレスト → gpt-oss:20bにラフに食わせる
CIや夜間ジョブ → ローカルで完結(API課金なし)

Qwen3 CoderはOllama経由でClaude CodeやCursorのカスタムバックエンドにも刺せます。OLLAMA_HOST=0.0.0.0:11434で外向きに開けて、CursorのModel ProviderをOllama互換に設定するだけです。

Cursor側の手順だけ書いておきます。設定のModelsからOpenAI compatibleを選び、Base URLにhttp://localhost:11434/v1、モデル名にqwen3-coder:30b-a3b-instruct-q4_K_Mを入れます。社外秘リポジトリで仮想環境を切って試すのに、最近は便利に使っています。クラウドAIに食わせられないコードでも、Cursorの補完UIだけはそのまま使えるのが本当に助かっています。

まとめ

ローカルLLMでコードを書かせる2026年の選択肢、私の答えはこうです。

Qwen3 Coder 30B-A3B — コード精度・ハルシネ率で頭ひとつ抜けている
gpt-oss:20b — VRAM軽量・別作業と並走したい時の保険
RTX 4070でも両方動く時代になった — 1年前は無理だった

「ローカルではコード生成は無理」というのは2024年頃の常識でした。MoEの一般化とMXFP4のおかげで、RTX 4070でも本気のコード支援ができる年になっています。

あなたのGPUと使っているモデルの組み合わせ、ぜひコメントで教えてください。私は次にQwen3 Coder 480Bのリモート構成を検討中ですが、家用GPU 1枚で完結する範囲をどこまで広げられるかには、まだ興味があります。

ローカルLLM×開発の実用Tipsを体系化したい方は、私のZenn無料Book「Claude Code Quickstart」を併せてどうぞ。Ollama連携でClaude Codeのサブ脳としてローカルLLMを使う例も載せています。
Claude Code Quickstart (Kenimoto)