--- title: NVIDIA RTX GPU別・VRAM容量別 最適Ollamaコーディングモデルガイド description: >- NVIDIA RTXのVRAM容量別に、Qwen3.8、Muse Glimmer、Qwen3 Coder、小型ビルドを含む現行Ollamaコーディング候補を比較。コンテキスト用のメモリも確保してください。 updatedDate: 2026-10-14T00:00:00.000Z date: 2026-06-15T00:00:00.000Z location: サンフランシスコ（カリフォルニア州）– 2026年6月15日 image: /images/ollama-coding-models-by-nvidia-rtx-vram-hero.jpg keywords: >- best ollama model rtx 5090, ollama coding model 24gb vram, rtx 3090 local llm coding, qwen3 coder rtx 4090, 16gb vram coding model, local coding model by gpu faq: - question: RTX 5090に最適なOllamaコーディングモデルは？ answer: >- Qwen3.8 27B、Muse Glimmer 30B、Qwen3 Coder 30Bを比較してください。前者2つはコンテキストやランタイムオーバーヘッドを含まないダウンロードサイズが約18GBです。32GBのRTX 5090なら余裕がありますが、実際のビルドとコンテキストサイズで測定してください。 - question: 24GBのRTX 3090や4090で30Bコーディングモデルは動きますか？ answer: >- Qwen3 Coder 30Bは24GB環境の候補です。Qwen3.8 27BとMuse Glimmer 30Bもダウンロードサイズは約18GBです。収まるかどうかは量子化、コンテキストの状態、ランタイムバッファ次第です。短いコンテキストから始めて、GPUの実際の割り当てを確認してください。 - question: VRAM 16GBに収まるコーディングモデルは？ answer: >- Gemma 4 E4BやQwen3 8B、またはQwen3 14Bの検証済み小型量子化ビルドを試してください。gpt-oss 20Bはダウンロードが約14GBで、コンテキストが伸びると厳しくなります。MoEのアクティブパラメータ数がストレージ要件を決めるわけではありません。 locale: ja-jp translationKey: ollama-coding-models-by-nvidia-rtx-vram --- モデル一覧は**2026年10月14日**時点で確認済みです。以下の候補はワークロード別に試すための順序であり、新たに厳密なコーディングベンチマークを実施したわけではありません。モデルの重みだけでなく、コンテキストやランタイムバッファ用のメモリも確保してください。 最適なローカルコーディングモデルとは、GPUのVRAMに**完全に**収まり、かつコンテキスト用の余裕が残る最大サイズのモデルです。この「余裕」は想像以上に重要です。VRAMに収まっている間は60トークン/秒で動作する32Bモデルでも、システムRAMに溢れた瞬間に1〜2トークン/秒まで低下します。数十回のツール呼び出しをループするコーディングエージェントにとって、これは「使える」と「諦める」の分かれ目です。 つまり問題は「最高のOllamaコーディングモデルは何か」ではなく、「自分のGPUに収まる最高のモデルは何か」ということです。本ガイドでは、現行のNVIDIA RTXコンシューマーGPUに収まるコーディングモデル、期待できる速度、そしてローカル推論を諦めてクラウドモデルに切り替えるべきタイミングを整理します。 モデル自体のランキングについては、[コーディングエージェント向けベストOllamaモデル](/ja-jp/blog/コーディングエージェント向けおすすめ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](https://ollama.com/library/qwen3.8)と[Muse Glimmer](https://ollama.com/library/muse-glimmer)のデフォルトダウンロードは約18GBで、32GBカードならコンテキストとランタイムバッファにある程度の余裕が残ります。 ```bash 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環境では余裕が少なくなります。最大コンテキストウィンドウが収まるとは思わず、実際のコンテキスト割り当てを確認してください。 ```bash ollama pull qwen3.8:27b ``` 量子化の種類によって品質とメモリ使用量の両方が変化します。モデル公開者が提供するタグを使用し、自分のGPUでタスクの正答率とレイテンシを比較してください。 ## 16GB：RTX 5070 Ti、4070 Ti Super、4060 Ti 16GB **Gemma 4 E4B**、**Qwen3 8B**、または**Qwen3 14B**の検証済み小型ビルドから始めてください。コンテキストとランタイムバッファ用の余裕を確保してください。 ```bash 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](https://haimaker.ai)** — エージェント内でOllamaと併用できるよう設定できるクラウドプロバイダー。比較したいクラウドモデルを1つのキーで利用可能 - **Ollama** — RTXカード上でローカルモデルを実行し、OpenAI互換APIをlocalhostで提供 - **コーディングエージェント** — OpenCode、OpenClaw、またはOpenAI互換のエージェントを、安価な作業にはローカルエンドポイントに、それ以外にはクラウドエンドポイントに向ける HAIMAKERでローカルとクラウドモデルをルーティング ## まとめ 実際のGPUに収まるモデルとコンテキストサイズを選んでください。24〜32GBのハードウェアでは現行のワークステーション候補を、それ以下では小型ビルドをテストしましょう。新しいモデルは、許容できるレイテンシでタスクを正確に完了できて初めて有用です。 --- *モデル自体のランキングについては、[コーディングエージェント向けベストOllamaモデル](/ja-jp/blog/コーディングエージェント向けおすすめollamaモデル/)を参照してください。OpenClawに特化したローカルセットアップについては、[OpenClaw向けベストローカルモデル](/ja-jp/blog/openclaw向けおすすめローカルllm/)を参照してください。*