モデル一覧は2026年10月14日時点で確認済みです。以下の候補はワークロード別に試すための順序であり、新たに厳密なコーディングベンチマークを実施したわけではありません。モデルの重みだけでなく、コンテキストやランタイムバッファ用のメモリも確保してください。
最適なローカルコーディングモデルとは、GPUのVRAMに完全に収まり、かつコンテキスト用の余裕が残る最大サイズのモデルです。この「余裕」は想像以上に重要です。VRAMに収まっている間は60トークン/秒で動作する32Bモデルでも、システムRAMに溢れた瞬間に1〜2トークン/秒まで低下します。数十回のツール呼び出しをループするコーディングエージェントにとって、これは「使える」と「諦める」の分かれ目です。
つまり問題は「最高のOllamaコーディングモデルは何か」ではなく、「自分のGPUに収まる最高のモデルは何か」ということです。本ガイドでは、現行のNVIDIA RTXコンシューマーGPUに収まるコーディングモデル、期待できる速度、そしてローカル推論を諦めてクラウドモデルに切り替えるべきタイミングを整理します。
モデル自体のランキングについては、コーディングエージェント向けベストOllamaモデルを参照してください。この記事はそのハードウェア編です。
クイックマップ：GPU別モデル対応表
| GPU | VRAM | 現行テスト候補 | コンテキスト予算 |
|---|---|---|---|
| RTX 5090 | 32GB | qwen3.8:27b、muse-glimmer:30b、qwen3-coder:30b | 最初は上限を設け、拡張前に実測 |
| RTX 4090 / 3090 | 24GB | 同じワークステーション候補を適切なビルドで | 余裕が少なく、実際の割り当てを確認 |
| RTX 5070 Ti / 4070 Ti Super / 4060 Ti 16GB | 16GB | gemma4:e4b、qwen3:8b、検証済み小型14Bビルド | 短めのコンテキスト、ランタイムオーバーヘッドを考慮 |
| RTX 3060 12GB | 12GB | qwen3:8b、gemma4:e4b（ビルドが収まれば） | 短いコンテキスト |
| 8GBカード | 8GB | 実際に収まる小型GemmaまたはQwenビルド | 重み＋コンテキストで確認、モデル名だけで判断しない |
今回の更新では新たなトークン/秒のベンチマークは実施していません。旧モデルの速度数値をQwen3.8やMuse Glimmerに当てはめることはできません。代表的なタスク中にollama psを使用して、常駐状態とメモリ使用量を確認してください。
32GB：RTX 5090
同じリポジトリタスクでQwen3.8 27B、Muse Glimmer 30B、Qwen3 Coder 30Bを比較してください。Qwen3.8とMuse Glimmerのデフォルトダウンロードは約18GBで、32GBカードならコンテキストとランタイムバッファにある程度の余裕が残ります。
ollama pull qwen3.8:27b
ダウンロードサイズは実際の動作時のメモリ割り当てのすべてではありません。想定するコンテキストサイズでメモリとレイテンシを測定してからデフォルトを決めてください。Nemotron 3.5 Lightningはデフォルトダウンロードが約25GBと大きく、長いコンテキストにはさらなる余裕が必要です。
5090であっても、複雑なマルチファイルタスクは最先端のクラウドモデルの方が適しています。ローカルのOllamaプロバイダーと並べてhaimakerをクラウドプロバイダーとして設定し、ローカルモデルでタスクを完了できない場合は切り替えましょう。
HAIMAKERでローカルとクラウドモデルをルーティング24GB：RTX 4090およびRTX 3090
Qwen3.8 27B、Muse Glimmer 30B、Qwen3 Coder 30Bがこのクラスの候補です。約18GBのダウンロードは、32GBカードと比べて24GB環境では余裕が少なくなります。最大コンテキストウィンドウが収まるとは思わず、実際のコンテキスト割り当てを確認してください。
ollama pull qwen3.8:27b
量子化の種類によって品質とメモリ使用量の両方が変化します。モデル公開者が提供するタグを使用し、自分のGPUでタスクの正答率とレイテンシを比較してください。
16GB：RTX 5070 Ti、4070 Ti Super、4060 Ti 16GB
Gemma 4 E4B、Qwen3 8B、またはQwen3 14Bの検証済み小型ビルドから始めてください。コンテキストとランタイムバッファ用の余裕を確保してください。
ollama pull qwen3:8b
gpt-oss 20Bはダウンロードが約14GBのため、16GB環境ではエージェントセッション中に厳しくなることがあります。短いコンテキストなら動作する可能性がありますが、実際の割り当てを確認してください。MoEモデルのアクティブパラメータ数は計算量を表すものであり、保存が必要なエキスパート重みの量を表すものではありません。
12GB：RTX 3060 12GBおよび同等クラス
12GBでは8Bクラスがスイートスポットです。Qwen3 8Bはインタラクティブな速度で動作し、日常的なエージェント作業——見慣れないコードの説明、小さな関数の作成、テストのドラフト作成、ログの要約——をこなせます。
ollama pull qwen3:8b
14BモデルをQ4（約8GB）で12GBカードに載せることも可能ですが、コンテキストの余裕がすぐに窮屈になります。スムーズなエージェントループのためには、完全にVRAMに常駐する8Bモデルの方が、メモリを奪い合う14Bモデルより体感的に優れていることが多いです。
8GB：エントリーレベルのカード
8GBでは小型ビルドと短いコンテキストが必要です。Gemma 4 E4BやQwen3 8Bの実際のダウンロードサイズとランタイム割り当てを確認してから、収まるかどうかを判断してください。
ollama pull gemma4:e4b
期待値を適切に設定してください。このクラスはコードの説明、ボイラープレート生成、小さな単一ファイルの編集には向いています。マルチファイルのリファクタリングをコーディングエージェントに任せる場所ではありません。エージェントがファイルを開き、パッチを修正し、ツール出力を扱い始めると、小型モデルは文脈を見失います。
あらゆるベンチマークに勝つルール
モデルを完全にVRAMに収めること。それ以外はすべて二の次です。
- CPUオフロードはスループットを大幅に低下させる可能性があります。実際のモデルとオフロード構成で測定してください
- 量子化はモデルを収めるための手段です。Q4_K_Mが実用的なデフォルト、Q5/Q8はVRAMに余裕がある場合のみ
- プロンプト処理はどのカードでも高速です。ボトルネックはトークン生成であり、メモリ帯域幅に応じてスケールします
- 常駐し続ける小型モデルは、スワップする大型モデルに毎回勝ります
量子化を選ぶ際は、コンテキスト用の余裕を残してください。コンテキスト0Kでは収まっても16Kで溢れるモデルは、セッション中にスワップが発生します。これが最悪のケースです。
クラウドモデルを使うべきタイミング
プライバシー、コスト、オフライン作業が重要な場合はローカルが最適です。ただし、すべてのタスクで自動的に優れているわけではなく、どんなコンシューマーGPUでもそれは変わりません。以下の場合にはクラウドモデルを使いましょう：
- タスクが多数のファイルにまたがる場合
- バグが微妙で強力な推論が必要な場合
- 信頼性の高いツール呼び出しが必要な場合
- 変更が本番環境に影響する場合
- 生成されたすべての行をレビューする時間がない場合
実用的なセットアップはローカル優先であり、ローカル限定ではありません。RTXカード上でQwen3 Coderや14Bモデルを安価でプライベートな作業に使い、タスクが難しくなったらより強力なクラウドモデルに切り替えるのがよいでしょう。
ローカルとクラウドを一緒にルーティングする方法
- haimaker.ai — エージェント内でOllamaと併用できるよう設定できるクラウドプロバイダー。比較したいクラウドモデルを1つのキーで利用可能
- Ollama — RTXカード上でローカルモデルを実行し、OpenAI互換APIをlocalhostで提供
- コーディングエージェント — OpenCode、OpenClaw、またはOpenAI互換のエージェントを、安価な作業にはローカルエンドポイントに、それ以外にはクラウドエンドポイントに向ける
まとめ
実際のGPUに収まるモデルとコンテキストサイズを選んでください。24〜32GBのハードウェアでは現行のワークステーション候補を、それ以下では小型ビルドをテストしましょう。新しいモデルは、許容できるレイテンシでタスクを正確に完了できて初めて有用です。
モデル自体のランキングについては、コーディングエージェント向けベストOllamaモデルを参照してください。OpenClawに特化したローカルセットアップについては、OpenClaw向けベストローカルモデルを参照してください。