どのローカルAIモデルを動かすべきか？ 2026年10月版 GPU、コンテキスト、コーディングガイド

最良のローカルコーディングモデルは、プロジェクトを十分にメモリへ保持し、役に立つ速度で読み取れるモデルです。 モデルサイズは今も重要です。ただし、システムRAMへオフロードして初めて収まるモデルは、安定したコンテキストウィンドウを持つ小型モデルより使いにくいことが多くあります。

モデルとメモリ予算を一緒に選んでください。ティアリストからモデルを選び、不適切なハードウェアへ無理に載せないでください。

このガイドは短いオートコンプリート用プロンプトではなく、コーディングエージェントを扱います。エージェントは修正を書く前に、ファイル、ツール出力、コンパイラーエラー、テスト結果を読みます。これらの入力がコンテキストを消費し、ハードウェアの判断を変えます。

動画は参考資料です #

次の動画は、複数のGPUメモリ帯でローカルモデルを比較します。実践的なモデル選択の観察と、報告されたハードウェア結果を確認する資料として役立ちます。この記事では、メモリの挙動、エージェントのコンテキスト、プロンプト処理、総所有コストを軸に、別の方法で判断を整理します。

ティアリストが失敗する理由 #

モデルのティアリストは通常、パラメーター数をGPUメモリ量に対応させます。この近道は最初の見積もりには役立ちます。コーディングエージェントが実際のリポジトリを読み始めると、役に立ちません。

モデルの重みが最初の割り当てです。KVキャッシュが増加する割り当てです。アクティブなコンテキストのアテンションキーとバリューを保持するため、ランタイムは生成したトークンごとにプロンプト全体を再計算せずに済みます。

モデルファイルがカードに収まることは、使えるエージェントの証明ではありません。 ランタイムには、キャッシュ、一時バッファー、ツール定義、次の応答のための空きが必要です。

コンテキストが本当の予算です #

コーディングエージェントはソースファイル以外にもコンテキストを使います。システム指示、ツールスキーマ、ディレクトリ一覧、シェル出力、コンパイラーメッセージ、テスト結果、過去の会話も予算に含まれます。

詳細なツール定義を持つ3つのMCP接続は、エージェントがプロジェクトファイルを開く前に数千トークンを消費することがあります。小さなデフォルトコンテキストでは、コード用の余地がほとんど残りません。エージェントは応答しますが、複数手順の修正に必要な作業セットを失います。

Ollamaの ランタイムFAQ は、デフォルトコンテキストを4,096トークンとしています。OLLAMA_CONTEXT_LENGTHでデフォルト値が変わり、OLLAMA_NUM_PARALLELで同時リクエスト数に応じて必要メモリが増えます。ローカルベンチマークを単一リクエストの結果と比較する前に、両方の値を記録してください。

OLLAMA_CONTEXT_LENGTH=32768 OLLAMA_NUM_PARALLEL=1 ollama serve

この例は、1つのアクティブなリクエストに対して32Kのデフォルトを設定します。プロジェクトファイル用に32Kトークンを予約するわけではありません。指示、ツール定義、入力、出力は今もウィンドウを共有します。

シンプルなコンテキスト記録 #

GPUを比較する前に、次の値を記録してください。

• プロジェクトサイズ: 通常のタスクに含まれるファイル数と、おおよそのソース行数。
• ツールのオーバーヘッド: システムプロンプト、MCPスキーマ、シェルツール、エディター指示。
• エラーペイロード: 通常のコンパイラー出力とテスト出力の長さ。
• 目標コンテキスト: 切り詰めずに保持したい最大プロンプト。
• 応答用の余白: 予定するパッチと説明のために確保する領域。

この結果をワークロード仕様として使います。1ファイルずつ編集する開発者と、モノレポ全体でAPIを追跡させる開発者では、必要なメモリが異なります。

KVキャッシュが順位を変えます #

パラメーター数が近い2つのモデルでも、コンテキストコストは異なることがあります。すべての層が増加するキャッシュに寄与する密なモデルは、ハイブリッドアテンション設計のモデルより多くのメモリを必要とすることがあります。

参考資料で扱われた27Bコーディングモデルの1つは、完全アテンション層を一部だけ使い、他の層では固定サイズの要約を使います。報告された128Kコンテキストのキャッシュコストは9GB未満です。同程度のサイズで、すべての層が完全に増加するアテンションを使うモデルは、同じコンテキスト長で21GBを超えると報告されています。

これらの数値は、特定のモデルアーキテクチャとランタイム設定のものです。一般的なメモリ公式ではなく、アーキテクチャを確認する理由として扱ってください。

メモリを購入する前にモデルアーキテクチャを確認してください。 パラメーター数だけでは、長いコーディングセッションのコストは分かりません。

GPUメモリ帯で選ぶ #

4GBから8GB #

小型の密なモデルが実用的な選択です。カードに収まり、素早く応答し、オートコンプリート、短い説明、狭い範囲のファイル編集に適しています。

CPUオフロードを使う大きなモデルでも文章は生成できますが、応答時間が制約になります。コーディングエージェントはファイル読み取りとツール呼び出しを何度も行います。4トークン毎秒の構成では、モデルが技術的に動いていても、修正のたびに長く待つことになります。

Mixture-of-expertsモデルも選択肢です。アクティブな部分が小さいため計算負荷が下がり、全重みは一部がシステムメモリに置かれます。十分なRAMと高速な転送経路が必要です。

この帯域では、大型モデルを追う前にシステムRAMを増やしてください。 バス上のデータ移動に時間を使う大型モデルより、安定した小型モデルの方が優れています。

12GBから16GB #

この帯域では27Bコーディングモデルが視野に入りますが、量子化の選択が中心になります。17GB近い標準4ビット版は、ランタイムのオーバーヘッドを含めると16GBカードに収まりません。

13GB近い3ビット版なら、コンテキスト用の余裕が増えます。12GBカードでは、2ビット版か、より小さいmixture-of-expertsモデルに寄ります。品質は量子化方式とキャリブレーションに依存するため、同じビット深度でもコーディング結果が異なります。

量子化モデルをダウンロードする前に確認してください。

• 量子化の作成者とリリースノート
• キャリブレーションデータと評価結果
• トークナイザーの互換性
• ツール呼び出しのテスト
• 選んだ量子化でのコンテキスト長
• Ollama、llama.cpp、選んだフロントエンドでのランタイム対応

「2ビット」や「3ビット」だけで品質を説明しないでください。 パッキング方式とキャリブレーション記録が重要です。

24GBから32GB #

27Bコーディングモデルでは、最も柔軟な範囲です。24GBカードには、実用的なコンテキストを持つ4ビット版が収まることが多いものの、完全な128Kウィンドウは残りのメモリを超えることがあります。32GBカードなら、キャッシュと一時割り当てに余裕ができます。

この範囲では所有コストも説明しやすくなります。2枚のカードへ分割する複雑さなしに、1枚のGPUで処理できます。マルチGPU構成より消費電力が少なく、ソフトウェア対応の確認も容易です。

24GBから32GBは、頻繁な非公開コーディングに適した所有帯域です。 弱いオフロード挙動を避けつつ、デスクトップケースにデータセンター用ハードウェアを詰め込まずに済みます。

48GB以上 #

メモリが増えても、新しいモデルが必要になるとは限りません。同じ27Bモデルを48GBカードで8ビット精度で動かし、キャッシュを増やして妥協を減らせます。改善するのは一貫性、コンテキストの余裕、出力品質であり、推論能力の新しい段階ではありません。

128GBでは判断が変わります。より大きなmixture-of-expertsモデルが可能になりますが、プロンプト処理が深刻な問題になります。モデルが素早く生成しても、大きなリポジトリや新しいツール結果の読み込みに長い時間がかかることがあります。

大型モデルでは、プリフィル速度とデコード速度を分けて測定してください。 プロンプトの読み込みが遅ければ、その後の回答が速くてもエージェントの作業では遅く感じます。

デコード速度はテストの半分です #

デコード速度は、生成トークン毎秒を測ります。「モデルはどれだけ速く書くか」という指標です。プリフィル速度は、プロンプト処理を測ります。「モデルはどれだけ速く読むか」という指標です。

エージェントは多くの時間を読み取りに使います。ツール呼び出しのたびに新しいテキストが加わります。次の応答が始まる前に、長いソースファイル、スタックトレース、テストログがプロンプトへ入ります。

自分のプロンプトサイズでベンチマークしてください。 短い合成プロンプトでは、リポジトリ作業で重要なコストが隠れます。

まずランタイム設定を試す #

ハードウェア更新は、性能改善の最初の手段ではありません。購入ページを開く前にランタイム設定を試してください。

マルチトークン予測 #

モデルとバックエンドの組み合わせによっては、複数の未来トークンを予測し、1回の処理で検証できます。この機能は、ランタイムフラグや対応するドラフト設定として提供されることがあります。

参考資料のテストでは、一部のハイエンドカードで大きな向上が報告されています。結果はモデルファイル、バックエンド、ドライバー、カードで変わります。Apple Metalの経路では、変換中に必要な機能が維持されないことがあります。

推論レベル #

最大推論で提供されるモデルは、結果を返す前の内部処理に長い時間を使います。コード修正では、中程度の推論の方がバランスが良いことがあります。明確なエラーメッセージと対象ファイルがすでに決まっている場合は特に有効です。

簡単なテストマトリックスを使います。

1. 同じバグ修正タスクを、低、中、高の推論で実行します。
2. 最初のトークンまでの時間、合計時間、パッチ成功、テスト結果を記録します。
3. 短いプロンプトと、リポジトリ規模のプロンプトで繰り返します。
4. 最も高いトークン速度ではなく、タスクを最もよく完了できる設定を残します。

対応するマルチトークン経路と中程度の推論は、良い出発点です。 デフォルトにする前に、自分のコードで品質を確認してください。

ローカルハードウェアか、レンタルGPUか #

たまに使うならレンタル計算が有利です。カードを一年中購入、冷却、更新、給電する代わりに、アクティブなセッションへ支払います。

頻繁、非公開、オフラインのワークロードなら所有ハードウェアが有利です。待ち時間がなくなり、繰り返しテスト用の安定した環境も得られます。

損益分岐点はカレンダー時間ではなく、アクティブ時間で計算します。電気、ストレージ、冷却、保守、ランタイムを維持する時間を含めてください。

たまの実験のために購入するハイエンドGPUは、趣味の支出です。 非公開作業に毎日使う24GBから32GBのシステムの方が、経済的な根拠を持ちます。

より良い購入チェックリスト #

モデルとGPUを比較するときは、次の順序を使います。

1. タスクを定義する。 オートコンプリート、単一ファイル修正、リポジトリエージェント、長コンテキスト分析。
2. プロンプトを測る。 通常のシステム指示、ツールスキーマ、ファイル、テスト出力を数える。
3. キャッシュの挙動を確認する。 アーキテクチャの説明とコンテキストメモリの測定を探す。
4. 量子化を選ぶ。 ビット数だけでなく、該当するアップロードの品質結果を確認する。
5. プリフィルとデコードを試す。 自分のリポジトリのプロンプトを使う。
6. 推論を調整する。 複数の推論レベルで、完了したタスクの時間を比較する。
7. プライバシーと保守を試す。 ソースコードがどこへ送られ、誰がバックエンドを保守するか確認する。
8. レンタル費用を比較する。 想定アクティブ時間を使い、所有システムの見積もりへ電力を含める。

最終推奨 #

12GB未満では、十分なシステムRAMを備えた小型モデルかmixture-of-expertsモデルを動かしてください。 オフロードにほとんどの時間を使う構成へ、27Bの密モデルを無理に載せないでください。

12GBから16GBでは、量子化品質と管理されたコンテキスト目標に集中してください。 ツール対応の、十分にテストした2ビットまたは3ビット版は、きれいに収まらない4ビットファイルより役立ちます。

24GBから32GBでは、27Bコーディングモデルが非公開の毎日の作業における実用的なデフォルトになります。 宣伝された最大ウィンドウ全体が使えると考える前に、コンテキスト使用量とプロンプト速度を測定してください。

48GB以上では、より大きなモデルへ移る前に、追加メモリを精度、キャッシュの余地、安定したセッションへ使ってください。 128GBの領域へ入ったら、容量そのものよりプロンプトを読む速度とレンタルの経済性へ注意を向けます。

モデル名は出発点にすぎません。重要なのは、モデル、ランタイム、ツール、キャッシュがそれぞれ必要な分を使った後、プロジェクトのコンテキストがどれだけ残るかです。

関連記事 #

• Qwen 27B向け32GB VRAM：ローカルAIハードウェアガイド , 27Bワークロード向けのハードウェア構成を解説します。
• Vast.aiでのLlama 3.1 8BとQwen3.8 27B GPUベンチマーク , レンタルGPUの測定結果と長いコンテキストの制限を扱います。
• 2026年のローカルAI：27BモデルがSonnet 4.6を上回る , モデル品質、量子化、ローカルハードウェアの経済性を扱います。