コーディング用ローカルLLM 5モデルをVRAM 16GBで比較｜日本語長文生成で速度・VRAMを実測

コーディング用ローカルLLMとは、IDEから呼び出してコード補完や生成に使う自前推論の言語モデルのこと。

VRAM 16GBクラスのGPU（本記事は主にRTX 5080で計測し、同じ16GBで下位クラスのRTX 5060 Ti 16GBの実測も併記します）で、同じプロンプト・同じ量子化（Q4_K_M）のもと、系統の異なる5モデル――汎用14B denseのphi4:14b / qwen3:14b、コード特化MoEのqwen3-coder:30b / deepseek-coder-v2:16b-lite、コード特化denseのcodestral:22b――を実測しました。RTX 5080での日本語長文生成では、汎用14BとコードMoEの生成速度がおよそ68〜74 tokens/secで横並びになり、コード特化denseのcodestral:22b（Q4_K_M）だけが21.94 tokens/secと突出して遅く、上位グループのおよそ3分の1にとどまりました。ただしこの横並びには読み解きの注意点があります。コード特化MoEのqwen3-coder:30bはモデル総サイズが16GBを超えるため、単一の16GB GPUでは約26%がCPU側へ配置された状態で動いており、単GPUの数値は本来の速度より抑えられていると考えられます（外部GPUを足した2枚構成では約2倍に伸びました。後述）。本検証で測ったのは、5モデル共通の日本語長文プロンプト（コード生成の指示ではありません。全文は後掲）での生成速度・VRAM使用量・生成前処理時間（モデルのロード時間＋プロンプト評価時間）で、コード生成速度・コード精度・FIM補完の品質は計測していません。ボード電力とGPU温度も取得していますが、生成完了直後に1回だけ読んだ値のため参考値の扱いです。この記事では5モデルの実測データを軸に、対話型アシスタント用途とバッチコード生成用途でどれを選ぶべきか、決断に必要な材料を整理します。

速さの数字だけで選ぶと外す理由は、ベンチマーク数値の読み取り方で詳しく整理している。

コーディング用ローカルLLMに求められる3要素

コーディング用ローカルLLMを評価する軸は、tokens/sec（生成速度）だけでは足りません。実務でIDEから呼び出すときに効いてくるのは、生成前処理時間（モデルのロード時間＋プロンプト評価時間）とVRAMマージン（IDE/ブラウザと並走できる余裕）も含めた複数軸。これらを揃えて見ないと、tok/sの数字だけで選んだモデルが、VRAM不足で常駐できなかったり並走時に破綻したりする、という取りこぼしが起きます。

マイナビの無料Copilot検証記事が指摘しているとおり、「AIは作業の代行ではなく、優秀なアシスタント」という位置づけが現実的です。関数生成やデータ分析の設計は叩き台として任せ、最終判断は人間が下す。ローカルLLMも同じ前提で評価したほうが、選定の軸がぶれません。コード品質を最優先するのか、叩き台を速く量産することを優先するのか。この問いを立てた瞬間、3軸の重み付けが決まります。

なぜ tok/s だけでは判断できないか

tokens/secは「1秒間に何トークン出力できるか」という連続生成の速度指標。バッチ処理では主役ですが、対話型のコード補完では脇役になります。IDEで補完を呼び出したときの所要時間は「リクエストを送ってから最初の1文字が出るまで」と「そこから数十トークン出力するまで」の合計で決まる構造で、前段が長ければ後段のtok/sが速くても総時間は縮みません。本検証で計測したのは、このうちOllama内部の生成前処理時間（モデルのロード時間＋プロンプト評価時間）で、リクエスト送信から最初のトークンが届くまでの時間そのものは測っていません。

もうひとつ見落とされがちなのが、VRAMマージンの問題。モデルがVRAMを埋め切ってしまうと、IDEのGPU支援やブラウザのハードウェアアクセラレーション、画像生成系の常駐ツールと競合します。VRAMが逼迫すると、あふれた分が共有メモリ（システムRAM）へ退避したりCPU/GPU分割で処理されたりして、生成速度や操作性が目に見えて落ちることがあります。tok/sの数字だけでは、この「運用時の余裕」は測れません。

対話型補完とバッチ生成で必要な性能は違う

Cursor / Continue.dev のようなIDE内対話型アシスタントでは、短い補完が繰り返し呼び出されます。100トークン未満の出力が多く、生成そのものより前段の待ち時間が総時間に占める割合が大きくなる使い方。逆にCLIから「このファイル全体をドキュメント化」「このクラスを別言語に移植」といったバッチリクエストを投げる用途では、1回あたり数千トークンの連続生成になり、tok/sが支配的な指標となります。

つまり用途が違えば向くモデルも違う。同じRTX 5080でも、対話補完に強い構成とバッチ生成に強い構成は別物、と割り切ったほうが判断がクリアになります。

検証環境と比較対象モデルの概要

計測は当サイトの検証環境で行い、5モデルをOllama経由・同一プロンプト・同一量子化（すべてQ4_K_M）で走らせました。環境・計測条件・指標の定義は以下のとおりです。

検証環境（ハードウェア・ソフトウェア）

※2機はVRAM容量こそ同じ16GBですが、GPU本体の基本スペック（メモリ帯域・CUDAコア数・電力枠）が違うだけでなく、上表のとおり接続条件も異なります。RTX 5060 Ti 16GBでも同一の5モデルを計測しており、結果は後半で併記します。

計測条件（5モデル共通）

• 量子化：全モデルQ4_K_M
• プロンプト：5モデル共通で、日本語の長文回答を求める1本のプロンプト（全文は下記に掲載）
• 生成パラメータ：seed=42固定 / think:false / num_predict=512 / コンテキスト長 num_ctx=8192
• 試行回数：各モデル3回
• サンプリング（temperature / top_p / top_k）：各モデルのOllamaデフォルトのままで、明示的には統一していません
  ※この点は結果を読むうえでの限界として後述します

ご覧のとおり、計測に使ったのはコードを書かせる指示ではなく、汎用の日本語長文生成です。本記事はコーディング用途でのモデル選びを主題にしていますが、掲載したtokens/secやVRAM使用量はこの日本語生成タスクでの実測値であり、コード生成タスクで同じ数値が出るとは限りません。5モデルすべてを共通プロンプト・共通の主要条件で回した相対比較の材料としては使えるものの、「コード生成時の速度」そのものとしては読めない、という前提で数字を見てください。コード生成時の速度・VRAM使用量は本検証では計測していません。

指標の定義と集計方法

• tokens/sec：生成トークン数を生成時間で割った値。各モデル3回計測の中央値と、実測レンジ（最小〜最大）を併記しました
  ※サンプル数は各3回と限られるため、中央値だけでなくレンジを添えて数値の振れ幅がわかるようにしています
• 生成前処理時間：Ollama APIがstream=falseの応答で返すload_duration（モデル読み込み時間）とprompt_eval_duration（プロンプト評価時間）の合計。本文ではモデルをVRAMへ常駐させた2回目以降（warm）の中央値を用います
  ※これはOllama内部の処理時間であって、リクエスト送信から最初のトークンが届くまでの時間（TTFT）ではありません。stream=falseの応答では最初のトークンの到着時刻を取得できないため、本記事はTTFTそのものを計測していません
  ※warmではload_durationがほぼ0になるため、warmの生成前処理時間はほぼプロンプト評価時間にあたります。初回ロード（cold）はモデル読み込み時間を含むため別扱いです
• 生成完了直後のボード電力・GPU温度・VRAM使用量（3回中最大）：各試行の生成完了直後にnvidia-smiで1回取得したスナップショット（ボード電力・温度・GPU全体メモリ使用量＝ベースライン込み）で、その3試行分のうち最大値を掲載しています
  ※生成中を連続サンプリングした値ではないため、時系列のピークでも定常値でもありません。生成が終わってから取得するまでにクロックや電力が下がることがあり、モデルごとに生成時間も違います
  ※tokens/secや生成前処理時間の中央値とは集計方法が異なります
  ※このため本記事では、ボード電力とGPU温度をモデル比較の評価軸には使わず、参考値として併記するにとどめます。電力を正式な比較軸にするには、生成中の連続取得で平均W・最大W・J/token（1トークンあたりの消費エネルギー）まで算出する必要がありますが、本記事では未測定です
  ※VRAMは生成中に大きく上下する類の値ではないため、モデルをロードした状態での占有を見る参考としては使えます（ただし後述のとおりnum_ctxに依存します）
• GPUへの常駐状況：Ollamaのsize_vram÷size（モデルのうちVRAMに載っている割合）で確認しました。14Bクラスとdeepseek-coder-v2はほぼ100%が常駐。qwen3-coder:30bは約74%・codestral:22bは約94%にとどまり、残りはシステムRAMへ退避していました
  ※この実態は後半で詳しく扱います

5モデルの位置づけ

比較対象は系統の異なる5モデル。大きく「汎用14B dense」「コード特化MoE」「コード特化dense」の3系統に分かれます。共通の条件で走らせると、系統ごとの速度とVRAMの傾向が浮かび上がります。

汎用14B dense（phi4:14b / qwen3:14b）：コード専用ではない汎用モデルですが、推論・論理・プログラミングを含む幅広いタスクをこなす14Bクラスです。phi4:14bはベンチマーク界隈で「14Bクラスの速度と精度のバランス型」として扱われます。qwen3:14bはQwenのQwen3世代の汎用14Bで、多言語（特に日本語・中国語）に強みがあるとされますが、日本語でのコード品質は本検証では測定していません（QwenにはQwen3.5系など後続世代も存在し、本記事の対象はあくまで14Bのqwen3:14bです）。

コード特化MoE（qwen3-coder:30b / deepseek-coder-v2:16b-lite）：コード生成向けに設計されたMixture-of-Experts（MoE）モデルです。qwen3-coder:30bは総パラメータ30B級・アクティブ約3.3Bのコード特化MoEで、2026年7月時点でOllamaのライブラリからQ4_K_M版を取得しました（Qwenにはこの後にQwen3-Coder-Nextなどの後続も公開されており、「現行最新」ではなく本記事で選定した一例という位置づけです）。deepseek-coder-v2:16b-liteもコード特化のMoEです。MoEは推論ごとに全パラメータのうち一部の専門家（expert）だけを使うため、モデルサイズのわりに1トークンあたりの演算量が抑えられるのが構造上の特徴です。ただし演算に使うのが一部でも、モデルの全パラメータ（全expert）はいつでも呼び出せるようメモリ上に置いておく必要があります。つまりMoEでもファイルサイズが小さくなるわけではなく、qwen3-coder:30bのようにファイルサイズが16GBを超えるモデルは、単一の16GB GPUには載り切りません（この帰結は後述します）。

コード特化dense（codestral:22b）：Mistral系のコード生成特化モデルで、全パラメータを毎回使うdense構成の22Bクラスです。多言語のコード補完・FIM（Fill-In-the-Middle＝前後の文脈に挟まれた穴埋め）補完を狙って設計された系統です。ただしFIM対応はcodestral固有ではなく、deepseek-coder-v2 LiteもFIMを学習しており、OllamaのテンプレートでもSuffix入力（前後の文脈を渡す形）に対応します。本検証で測ったのは日本語長文生成での速度・VRAM使用量・生成前処理時間で、FIM補完の品質そのものは計測していないため、FIMの得手不得手でこの2モデルの優劣を判断することはできません。したがって本記事ではcodestralを「コード特化denseの候補」という位置づけにとどめ、高精度だと結論づけることはしません。

コード生成の精度（正答率）については、各配布元や第三者がベンチマーク値を公表していますが、量子化・プロンプト・評価条件が本検証と異なるうえ、当サイトでは精度を計測していません。特定のスコアを並べると速度実測と同じ土俵の比較に見えてしまうため、本記事ではあえて具体的な数値は載せず、精度は「別途、実際のタスクで確かめる次元」として速度・VRAMの実測とは切り分けて扱います。

同一プロンプトでの比較ルールと再現条件

比較の公平性を確保するため、同一プロンプトを使い、量子化は5モデルすべてQ4_K_Mに統一しています。ここは重要な前提で、Ollamaのデフォルトのcodestral:22bタグはQ4_0量子化のため、そのままでは他モデル（Q4_K_M）と量子化が揃いません。そこで本検証ではcodestralもQ4_K_M版（codestral:22b-v0.1-q4_K_M）を用い、量子化プリセットを揃えたうえで比較しています。

追試できるよう、検証に用いた各モデルの完全タグ・量子化・Ollama digest（先頭12桁）を残します（プロンプト全文は前掲の「検証環境と比較対象モデルの概要」に掲載しました）。phi4:14b（Q4_K_M / digest ac896e5b8b34）、qwen3:14b（Q4_K_M / bdbd181c33f2）、deepseek-coder-v2:16b-lite-instruct-q4_K_M（dac6ff6589c9）、qwen3-coder:30b（Q4_K_M / 06c1097efce0）、codestral:22b-v0.1-q4_K_M（9a43e868fd2c）。計測条件はseed=42・think:false・num_predict=512・num_ctx=8192で固定（サンプリングのtemperature/top_p/top_kは各モデルのデフォルトのまま）、tokens/sec・生成前処理時間・VRAM使用量（GPU全体使用量）・ボード電力・GPU温度を各モデル3回計測し、tokens/secと生成前処理時間は中央値（tokens/secは実測レンジ＝最小〜最大も併記）、ボード電力・GPU温度・VRAM使用量は各試行の生成完了直後にnvidia-smiで1回取得したスナップショット3回分のうち最大値を掲載しています。共通のプロンプト・量子化・主要な生成条件（seed / num_predict / num_ctx）を揃えて比較していますが、サンプリング設定（temperature / top_p / top_k）は各モデル固有のデフォルトを維持しており、完全に同一の生成条件ではありません。

速度以外にVRAM使用量も横に並べることで、VRAM占有が気になるという実務の観点もカバーしました（ボード電力とGPU温度は前述のとおり生成完了直後の参考値として併記します）。なお、毎秒何トークンという数字は量子化・コンテキスト長・ランタイム版などの測定条件込みでしか比較できません。外部サイトの公開値と当サイトの実測を突き合わせる際の注意は、後半のH2「他サイトの公開ベンチマークとの突合」で扱います。

実測結果｜5モデルのtokens/sec・VRAM比較表

当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM / Ollama 0.32.3）で計測した5モデルの数値を、日本語長文生成タスクでの速度が速い順に並べます。VRAM使用量はnvidia-smiのGPU全体使用量（ベースライン込み）です。見るべきは速度とVRAMの2点で、ボード電力とGPU温度は生成完了直後のスナップショットのため参考値として併記します。生成前処理時間は次のH2で別途扱います。

※tokens/secは各モデル3回計測の中央値で、レンジは実測の最小〜最大。速度はいずれも5モデル共通の日本語長文生成タスクでの値です。生成前処理時間・VRAM・ボード電力・温度はとくに断りがなければRTX 5080での値です。生成前処理時間はload_durationとprompt_eval_durationの合計（Ollama内部の処理時間）で、TTFTそのものではありません。ボード電力・GPU温度・VRAM使用量は、各試行の生成完了直後にnvidia-smiで1回取得したスナップショット3回分のうち最大値です（生成中を連続サンプリングした値ではないため時系列のピークではなく、モデル間のピーク電力や電力効率を比較できる指標ではありません。tokens/secや生成前処理時間の中央値とは集計方法が異なります）。RTX 5060 Tiの行は同じ5モデルを別クラスの16GB GPU（OCuLink接続）で計測した参考値で、詳細は後半の「同じ16GBでもGPUクラスで変わる｜RTX 5060 Tiとの比較」で扱います。VRAMはnvidia-smiのGPU全体使用量（ベースライン込み）で、num_ctx=8192 の条件で観測した値です。num_ctx を変えれば必要なKVキャッシュも変わるため、この値をモデルが必要とするVRAMの上限とみなすことはできません。VRAM常駐率はOllamaが報告するsize_vram（VRAMに載ったサイズ）÷size（モデル総サイズ）で、qwen3-coder:30bとcodestral:22bは一部がVRAMに載り切らずシステムRAMへ退避しています（後述）。

速度ランキング

ここで比べているのは、5モデル共通の日本語長文生成タスクでのデコード速度です。最速はphi4:14bの74.33 tokens/sec、続いてqwen3:14b 73.14、deepseek-coder-v2 71.07、qwen3-coder:30b 68.95と、汎用14B denseとコード特化MoEはおよそ68〜74 tok/sの範囲に固まりました。上位4モデルの差は約10%以内で、速度だけ見れば実用上ほぼ同じ帯域です。これに対してcodestral:22b（Q4_K_M）は21.94 tokens/secと突出して遅く、上位グループのおよそ3分の1。コード特化denseという系統が、この環境では速度面で大きく不利に出ています。

注意したいのは、速さ・遅さの原因を単純に「パラメータ数」や「MoEかdenseか」だけで語れない点です。総パラメータ30B級のqwen3-coder:30bが68.95 tok/sと上位に並ぶのは、MoEで1トークンあたりの演算量が小さいためと読めますが、後述のとおりこのモデルは16GBに載り切らず約26%がCPU側へ配置されており、単GPUの68.95は本来の速度より抑えられた値だと考えられます（外部GPUを足した2枚構成では154.72 tok/sまで伸びました）。一方で22Bのcodestralが21.94 tok/sと最も遅いのは、全パラメータを毎回使うdense構成で1トークンあたりの演算が重いことに加え、こちらも16GBぎりぎり（VRAM常駐率約94%）で一部がRAMへこぼれていることが響いていると考えられます。いずれも今回の特定モデル・この量子化での観測であり、「何Bなら何tok/s」という一般法則として持ち出せるものではありません。

なお電力の数値も取得していますが、本記事では比較軸に置きません。参考値として、各試行の生成完了直後に取得したボード電力は、deepseek-coder-v2で103.8W、qwen3-coder:30bで111.4Wでした（汎用14Bクラスは290W前後、codestral:22bは172.6W。5モデル分は前掲の表のとおり）。ただし生成中を連続計測した値ではなく、モデル間のピーク電力や電力効率を比較できる指標ではありません。生成が終わってから取得するまでにクロックや電力が下がることがあり、生成にかかる時間もモデルごとに違うためです。電力を正式な比較軸にするには、生成中に連続取得して平均W・最大W・J/token（1トークンあたりの消費エネルギー）まで算出する必要がありますが、本記事では未測定です。GPU温度（生成完了直後・3回中最大で57〜63℃）も同じ扱いで、この電力と温度からボトルネックの所在（メモリ帯域か実行効率か）を判断することもできません。

VRAM占有の差

VRAM使用量（GPU全体使用量）は系統順にきれいに並びました。汎用14Bクラスが約11.5〜11.7GiB（qwen3 11.5 / phi4 11.7）と最も軽く、次いでdeepseek-coder-v2が約13.3GiB、qwen3-coder:30bが約14.8GiB、codestralが約15.6GiB。16GB（16384MiB）のRTX 5080に対して、codestralはGPU全体で約97%を占め、残りは約0.4GiBしかありません。qwen3-coder:30bでも残りは約1.2GiB。対して14Bクラスは残り4GiB超（phi4で約4.3GiB、qwen3で約4.5GiB）のマージンがあり、deepseek-coder-v2は約2.7GiBが残ります。このマージンの差が、そのまま「IDEやブラウザ、Copilot連携を裏で走らせられる余地」になります。

ここで示したVRAMは、num_ctx=8192 で観測したGPU全体使用量です。num_ctx をより大きく設定すれば、KVキャッシュに必要なメモリの分だけさらに増えます。外部の公開ベンチマークとの突合は後段のH2で扱いますが、この「条件込みでしか読めない」性質はVRAMにも当てはまります。

qwen3-coder:30bはなぜ単GPUで遅いのか｜VRAM退避の実態

ここまで「qwen3-coder:30bは16GBに載り切らない」と繰り返してきた根拠を、実測で示します。Ollama APIが報告するモデル総サイズ（size）とVRAMに載ったサイズ（size_vram）を比べると、qwen3-coder:30b（Q4_K_M）はsizeが約18.26GBに対しsize_vramが約13.53GB。VRAMに載っているのは74.1%で、残る約26%はGPUのVRAMではなくCPU側のシステムRAMに置かれていました。実際、このモデルをロードするとシステムRAMの使用量が約5.51GB増え、nvidia-smiで見た5080のVRAM使用量（GPU全体）は16GB中およそ14.8GiBまで埋まっていました（前掲の表の値）。

この配置は、Ollama側の表示でも確認できます。計測時の ollama ps で見たqwen3-coder:30bは、SIZE 19 GB / PROCESSOR 26%/74% CPU/GPU / CONTEXT 8192という表示でした（SIZE欄はCLI側の表示で、前掲のAPI値である約18.26GBとは桁の丸め・単位表記が異なります）。PROCESSORの26%/74%はAPIのsize_vram÷size（約74.1%）と一致しており、モデルの約26%は最初からCPU側に配置された状態で動いていたことになります。Ollamaがロード状況を100% GPUと表示するのはsize_vramとsizeが一致する場合で、一部がCPU側へ回るとこのように割合表示になります。ロード直後に ollama ps を見れば、どの程度がCPU側に置かれているかはその場で判断できます。なお本記事では便宜上この状態を「VRAM退避」とも呼びますが、生成の途中でVRAMから追い出されるのではなく、ロード時点で一部がCPU側に割り当てられている状態を指します。

この配置は、qwen3-coderの単GPU速度を抑える方向に働きます。単GPUの5080では、生成のたびにCPU側へ回った約26%分をシステムRAM経由で扱う必要があり、VRAM内で完結する場合よりアクセスが遅くなるためです。実際、外部GPU（RTX 5060 Ti 16GB）をOCuLinkで足した2枚構成で走らせると154.72 tok/s（単GPUの約2倍）まで伸びました（この2枚構成は測定環境が異なるため「参考：異構成テスト」として扱います）。この伸びには、単GPU時のCPU配置が解消または減少したことが大きく寄与した可能性があります。ただし2枚構成では同時に、2枚分の演算資源とメモリ帯域、Ollamaによる複数GPUへのモデル分散、異種GPU構成（RTX 5080＋RTX 5060 Ti）、OCuLink経由の転送条件も加わります。2枚構成での ollama ps の表示や各GPUのVRAM使用量、システムRAMの増加量は計測していないため、「退避が完全に解消した」と断定することも、各要因の寄与率を分離することもできません。codestralも約6.4%がVRAMの外にあり16GBぎりぎり、14Bクラスとdeepseek-coder-v2は完全常駐、という違いが速度差の背景にあると考えられます。

生成前処理時間（ロード＋プロンプト評価）は常駐後どれも0.2秒未満

tokens/secが「走り出してからの速さ」なら、生成前処理時間は「走り出すまでにOllama内部でかかる時間」。モデルのロード時間（load_duration）とプロンプト評価時間（prompt_eval_duration）の合計です。当サイトの計測では、warm状態（モデルをVRAMに常駐させた2回目以降）の中央値がcodestral:22b 108.1ms、phi4:14b 138.5ms、deepseek-coder-v2 139.4ms、qwen3-coder:30b 172.9ms、qwen3:14b 185.3ms。5モデルすべてが0.1〜0.2秒の範囲に収まり、最大差は約77msでした。この値はstream=falseの応答から算出したOllama内部の処理時間で、リクエスト送信から最初のトークンが手元に届くまでの時間（TTFT）ではありません。実際の応答の速さを扱うにはstream=trueで最初のチャンクの到着時刻を壁時計で測る必要があり、本記事では計測していません。

注意したいのは、この数字がモデル常駐後（warm）の値だという点。VRAMを多く使うモデル（codestral・qwen3-coder:30b）ほど、初めてVRAMへ読み込む初回（cold）のロードは重くなります。この重さは、モデルが keep_alive でロード状態を維持している間は再発しません。ただしOllamaはデフォルトで約5分後にモデルをアンロードするため、その後に再利用すると再ロードが発生します。ロード状態が続いている間のwarm生成前処理時間はむしろ短い側に来ることもあり、codestralは5モデルで最短の108.1ms。逆に14Bクラスは初回ロードが軽い代わり、warmの生成前処理時間は138〜185msとやや長めでした。

つまり、モデルを常駐させる前提なら、5モデル間の生成前処理時間の差（最大約77ms）は選定の決め手になりにくい。ここで効いてくるのは連続生成の速さ（tok/s）とVRAMマージンの方です。「READMEを英訳してほしい」「このファイル全体にdocstringを追加してほしい」といった数千トークン級のバッチ処理では、たとえば70 tok/sで1000トークンを生成すると生成だけで約14秒かかる計算になり、数十msの前処理差は全体時間に埋もれます。この文脈でcodestralをあえて選ぶ理由があるとすれば、FIM補完向けに設計されたコード特化denseという位置づけですが（同じくFIMに対応するdeepseek-coder-v2という選択肢もあります）、コード精度もFIMの補完品質も本検証では計測しておらず、高精度だと結論づけることはできません。実際の補完品質は用途ごとに確かめる前提で捉えてください。

用途別の選び分けは、生成前処理時間ではなくtok/s・VRAMマージン、そして「コード特化かどうか」で判断するのが実態に合います。短い補完を繰り返す対話用途なら、速くてVRAMに余裕のある汎用14BかコードMoE。速度を保ちつつコード特化設計も効かせたいなら、完全にVRAMへ載るコード特化MoEのdeepseek-coder-v2（qwen3-coder:30bはVRAMに余裕のある環境向き）。FIM補完（前後の文脈に挟まれた穴埋め）を重視するなら、対応するcodestralとdeepseek-coder-v2が候補ですが、いずれもFIMの補完品質は本検証では測っていない――という整理になります。同じGPUで同じモデル群を比較しても、使い方次第で向く構成が変わるのがコーディング用途の勘どころです。

IDE並走時のVRAMマージンとリソース競合

16GB VRAMのRTX 5080でcodestral:22b（Q4_K_M）を常駐させると、VRAM使用量（GPU全体使用量）は約15.6GiBに達し、残りは約0.4GiB。qwen3-coder:30bでも約14.8GiBで残り約1.2GiBです。この状態でVS Code＋GPU支援のかかったブラウザ＋チャットクライアントを同時に走らせると、GPU側のVRAMは簡単に逼迫します。

VRAMが逼迫すると、あふれた分が共有メモリ（システムRAM）へ退避したり、CPU/GPU分割で処理されたりして、生成速度や操作性が目に見えて落ちることがあります。どの程度落ちるかは並走するアプリのVRAM要求とドライバの挙動しだいで一概には言えませんが、「VRAMを使い切る手前で運用する」のが安全側の設計です。ベンチマークの瞬間値では動いていても、実運用で他アプリと競合した瞬間に失速する、という取りこぼしを避けられます。

同じ16GBクラスのGPUでも、「どれだけ余らせるか」で運用の安定性は変わります。これはローカルLLMに限らず、GPUメモリを食う常駐ツール全般に共通する観点です。

14Bクラスの余裕マージン

phi4:14bやqwen3:14bの場合、VRAMは約11.5〜11.7GiB（GPU全体使用量）で済み、残りは4GiB超。VS Codeやブラウザを立ち上げた状態でも破綻しにくく、IDEのGitHub Copilot連携や、ブラウザで開いた軽めのローカルDashboardなどを並走させる余裕があります。コード特化MoEのdeepseek-coder-v2（約13.3GiB・残り約2.7GiB）やqwen3-coder:30b（約14.8GiB・残り約1.2GiB）はその中間で、deepseekは並走の余地がそれなりに残る一方、qwen3-coder:30bは単体運用寄りです。14Bクラスは「常駐型モデル」として設計されたわけではないのに、結果として常駐運用に向いている、というのが実務上の結論です。

さらに14Bクラスは生成速度が速いので、リクエストが溜まってもすぐに消化できます。VRAMとスループットの両面で、IDE並走の相性が良いと言えます。

22B・30B級を常駐させる際の落とし穴

codestral:22bやqwen3-coder:30bのようにVRAMをほぼ使い切るモデルを16GB環境で活かすなら、「ピンポイント運用」が現実的です。IDEから常時呼び続けるのではなく、CLIからバッチ処理の直前にロードして、終わったら解放する。Ollamaは使用したモデルをデフォルトで約5分間ロード状態に保ち、保持時間は keep_alive で変更できます。ロード状態が続いている間は、モデルの配置に応じてVRAMやシステムRAMが占有されたまま。頻繁に使うモデルはkeep_aliveを長めにすれば再ロードを抑えられる一方、その分メモリを押さえ続けるので、並走したい他モデルやアプリとはトレードオフになります。この運用戦略の詳細は、後半のH2「16GB VRAM環境での運用戦略」で改めて掘り下げます。

他サイトの公開ベンチマークとの突合

自分のところで出した数字だけを並べても、それが妥当なのかは判断できません。外部の公開ベンチマークと突き合わせて、どこが一致し、どこが食い違うのかを見ていきましょう。

14Bクラスは公開データと同オーダー

Hardware-Corner（hardware-corner.net）が公開しているRTX 5080のLocal LLMベンチマークでは、14Bクラス（4bit・16kコンテキスト）で約64 tok/sという水準が報告されています。当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM）で計測したphi4:14bの74.33 tok/s、qwen3:14bの73.14 tok/sはこれより高めですが、両者は測定条件が揃っていません。差の要因としてはコンテキスト長・量子化の細部・ランタイム版などが考えられるものの、条件を揃えた再計測ではないため原因を特定はできません。

重要なのは、外部の独立した計測も同じ数十tok/sのオーダーに収まっており、当サイトの数値が桁違いの異常値ではないと確認できる点です。裏を返せば、「毎秒何トークン」という数字は測定条件込みでしか比較できず、単一の値を鵜呑みにできないことも示しています。

codestralの外部公開値との突合

codestralの外部値には注意が必要です。WillItRunAI（willitrunai.com）のCodestralページには複数GPUの数値が並びますが、これらは実機計測ではなくモデル化された推定値です。RTX 5080欄は約25.6 tok/sの推定で、当サイトが以前引用していた51.5 tok/sは別GPU（RX 7900 XTX）欄の値でした。つまり「RTX 5080で51.5 tok/s」という比較自体が誤りで、そもそも推定値である以上、当サイトの実機実測（Q4_K_M版で21.94 tok/s）と直接は比較できません。

参考までに、推定値（約25.6）と当サイト実測（21.94）はどちらも20台のオーダーではあります。ただし片方が推定・片方が実測である点、量子化版が揃っているとは限らない点から、この差の大小を云々するのは適切ではありません。

codestralは配布元・変換バージョン・量子化（同じ22bでもQ4_0とQ4_K_Mで実効速度が変わります）によって数字が動くため、必ず「どの版を、どの量子化で計測したか」とセットで読む必要があります。数値だけを取り出して他サイトと比べるのは、この系統ではとくに危険です。

用途別の推奨｜対話型アシスタント vs バッチコード生成

数字の突合が終わったところで、ここからは実際にどのモデルをどう選ぶかの話。コーディング用途は「対話型アシスタント」と「バッチコード生成」で必要な性能が異なるため、分けて整理します。ここで挙げるのは、本検証の速度・VRAM配置と各モデルの公称設計を踏まえた運用候補であって、コード生成の速度や精度を比べた結論ではありません。

IDE常駐型の運用候補

Cursor、Continue.dev、ClineなどのIDE統合ツールや、AiderのようなCLI型ツールで対話しながらコードを書く用途では、速度とVRAMマージンが効きます。候補は汎用14B（phi4:14b / qwen3:14b）とコード特化MoE（deepseek-coder-v2 / qwen3-coder:30b）。純粋な速度とVRAMの軽さならphi4:14bが扱いやすく、生成速度74.33 tok/s（codestral 21.94 tok/sの3倍以上）、VRAM約11.7GiB（GPU全体使用量）で残り約4.3GiBをIDEやブラウザに回せ、warmの生成前処理時間も138.5msでした。コード特化の設計を効かせつつIDE並走の余地も残したいならdeepseek-coder-v2（71.07 tok/s・VRAM約13.3GiB・完全常駐で残り約2.7GiB）が、速度とVRAMマージンのバランスを取りやすい候補です。qwen3-coder:30bは速度こそ68.95 tok/sと僅差ですが、VRAM約14.8GiBで残りが約1.2GiBと少ないため、IDE並走よりは単体運用寄りです。

qwen3:14bも対話型の有力候補です。tok/sはphi4よりわずかに落ちる73.14で、QwenのQwen3世代として多言語（日本語・中国語）に強みがあるとされます。ただし日本語でのコード品質やコメント生成の優劣は本検証では測定していないため、「日本語ならqwen3、英語ならphi4」と言い切れる段階にはありません。和製コード資産での使い勝手は、実際のタスクでの検証が必要です。

バッチ生成向きの選択

CLIから大量のコードを一括生成する、ドキュメント整形を走らせる、コードレビューをバッチ実行する、といった用途では、スループット（tok/s）とVRAMへの収まり方が効きます。この観点でまず扱いやすいのは、完全にVRAMへ載るコード特化MoEのdeepseek-coder-v2（71.07 tok/s・VRAM約13.3GiB）です。qwen3-coder:30bは単一16GB GPUでは前述のCPU側配置があり68.95 tok/sにとどまりますが、外部GPUを足した2枚構成では154.72 tok/sまで伸びました（複数の条件が同時に変わるため、要因は分離できません）。汎用14Bも速度は同等でVRAMはさらに軽い（約11.5〜11.7GiB）ものの、コード特化として設計された系統ではありません。なお、ここで挙げた速度はいずれも日本語長文生成タスクでの実測値で、コード生成時のスループットは計測していません。

一方でcodestral:22bは、コード特化denseとして多言語のコード補完・FIM補完向けに設計された系統です。ただし本検証での実測速度は21.94 tok/sと5モデルで最も遅く、VRAMも約15.6GiBと最も重い。速度・VRAMのいずれもコストが大きいため、選ぶ理由があるとすればFIM補完向けという設計上の位置づけに限られますが、FIM対応はdeepseek-coder-v2も同様で、補完品質は本記事では計測していません。コード精度そのものも本記事では測っておらず、他系統より高精度だと結論づけることはできません。実際の補完品質は、ご自身のコードベースで確かめる前提で捉えてください。

前処理の面では、codestralのwarm生成前処理時間は108.1msと5モデルで最も短い値でした。初めてVRAMにロードする初回だけは読み込みが重く、この重さはモデルが keep_alive でロード状態を維持している間は再発しません（デフォルトでは約5分後にアンロードされるため、その後に再利用すると再ロードが発生します）。ただしバッチ処理の総時間を左右するのは数十msの前処理差ではなく、21.94 tok/sという生成速度そのものです。スループットを重視するなら、コード特化MoEのほうが総合時間で有利になりやすい構図です。

切り替え運用の実際

「対話もバッチも両方やりたい」なら、VRAMに余裕のあるモデルを常駐させ、重いモデルをオンデマンドで呼ぶハイブリッド運用が実務的です。たとえば普段はphi4:14bかdeepseek-coder-v2を常駐させてIDE補完に使い、大きなリファクタや一括生成のときだけqwen3-coder:30bやcodestralをオンデマンドで呼び出す、という使い分けがハマります。

Ollamaは使用したモデルをデフォルトで約5分間ロード状態に保ち、この時間は keep_alive で変更できます。ロード中は、モデルの配置に応じてVRAMやシステムRAMが占有されたまま。保持時間を延ばせば頻用モデルの再ロードを抑えられる一方、占有もその分続くため、切り替えたい他モデルとはトレードオフです。本記事で扱うモデルは1本でVRAMの大部分を使うため、16GB環境でVRAMを使い切るcodestralやqwen3-coder:30bを挟むなら、常駐モデルを先に解放してから呼ぶ形になりやすく、切り替えのたびにロード時間が発生する点は織り込んでおきます。マイナビニュースが指摘した「AIは叩き台、最終判断は人間」という設計方針を踏まえれば、速度とVRAMマージン重視の常用をMoEや14Bに、コード特化設計を試したい本番生成をcodestralに、といった役割分担が一例です（コード精度は本検証では未計測のため、最終判断は人間が行う前提で使い分けます）。

AIコーディングツール全般の動作環境については、姉妹サイトの Claude Code推奨スペック解説 系の記事も参考になります。ローカルLLMと商用APIを併用する構成では、GPU負荷の発生タイミングが重要になってきます。

16GB VRAM環境での運用戦略

RTX 5080やRTX 4080、RTX 5070 Ti、RTX 5060 Ti 16GB、中古のRTX 4060 Ti 16GBなど、16GB VRAMクラスのGPUは2026年現在でも主力。ここで5モデルをどう運用するかを整理しておきます。

同じ16GBでもGPUクラスで変わる｜RTX 5060 Tiとの比較

VRAMの容量が同じ16GBでも、GPUのクラスが違えば速度は変わります。参考として、RTX 5060 Ti 16GBで同じ5モデルを計測しました。RTX 5060 TiはRTX 5080に対して、公称のメモリ帯域（448GB/s vs 960GB/s）（NVIDIA公式の比較ページに記載。個別の製品ページにはバス幅までしか載っていない）・演算資源（4608 vs 10752 CUDAコア）・電力枠（カード消費電力で最大180W vs 360W）がいずれも小さく、加えて本検証ではOCuLink経由の外付け接続（RTX 5080はPCIeスロット直結）という違いもあります。結果は、モデルによりRTX 5080の約21〜62%の生成速度でした。

14BクラスとcodestralはRTX 5080の約6割（phi4 約59% / qwen3 約59% / codestral 約62%）。MoE系は落ち幅が大きく、deepseek-coder-v2が約42%、qwen3-coder:30bは約21%（14.34 tok/s）まで下がりました。同じGPUの組み合わせでもモデルによって落ち幅が3倍近く違うため、単一の要因では説明できません。qwen3-coder:30bはモデル総サイズが約18.26GBあり、16GBのRTX 5060 Tiでも全体は載らないため、VRAM外に置かれた分を扱うコストが加わることは想定されます。ただしメモリ帯域・演算資源・電力枠・接続形態（OCuLink）のどれがどれだけ効いたかは、この比較だけでは分離できません。

それでもRTX 5060 TiはRTX 5080やRTX 5070 Tiより下位のクラスにあたり、16GBのVRAMを確保する入口としては候補に挙がります（実売価格は市況で動くため、購入時点で各ショップの価格を確認してください）。完全にVRAMへ収まる14Bクラスやdeepseek-coder-v2を短〜中コンテキストで使う用途なら、RTX 5080の約4〜6割の速度でも実用の範囲です。逆に16GBを超えるモデル（qwen3-coder:30bなど）を単GPUで速く回したい用途には向きません。用途とモデルサイズでRTX 5080とRTX 5060 Tiを選び分けるのが実態に合います。

常駐vsオンデマンドの線引き

16GB環境での割り切りは、今回のようにIDEを並走させる運用を重視するなら明快です。VRAMマージンを確保しやすいのは14Bクラス（残り4GiB超）とdeepseek-coder-v2（残り約2.7GiB）まで。qwen3-coder:30bやcodestralはVRAMをほぼ使い切るため、必要なときにロードして使い終わったら解放する運用に寄せます。これは「常駐は14Bまで」という一般的な上限ではなく、あくまでIDE・ブラウザを同時に走らせる前提での運用推奨です。単体で全画面をLLMに割り当てるなら、qwen3-coder:30bやcodestralを常駐させても動作自体はします。

Ollamaは使用したモデルをkeep_aliveの間はロード状態に保つため、短時間での再利用ならロードコストを抑えられます。ただしVRAMは有限で、本記事で扱うモデルは1本でVRAMの大部分を使うため、16GB環境では別モデルをロードする前に先のモデルの解放が必要になりやすい点は変わりません（Ollama自体は、メモリに余裕があれば複数のモデルを同時にロードできます）。頻繁に切り替えるなら、常駐させるモデルを1つ決めておくのが安全です。

KVキャッシュの影響を忘れない

本記事の表に載せたVRAM使用量は、num_ctx=8192 の条件で各試行の生成完了直後に取得したGPU全体使用量です。つまり、このコンテキスト長のために確保されたKVキャッシュ分はすでに含まれています。注意すべきは、これが設定するコンテキスト長に依存する点。コードベース全体を読み込ませるつもりで num_ctx をより大きく設定すると、KVキャッシュに必要なメモリが増え、GPU全体使用量は表の値より増えます。

codestralの約15.6GiB（GPU全体使用量）は、num_ctx=8192 での値です。num_ctx をより大きく設定するとKVキャッシュに必要なメモリが増え、CPU側への配置が増えたり、16GB VRAMに収まらずメモリ不足が起きたりする可能性があります。qwen3-coder:30b（約14.8GiB）も同様に余裕は小さく、num_ctx=8192 の時点ですでに約26%がシステムRAMへ退避しているため、コンテキスト長を広げたときの影響はさらに大きくなります。VRAMをほぼ使い切るモデルを16GB環境で使うなら、num_ctx を必要な範囲に絞るのが前提です。なお、実際の入力が長くなった場合の挙動は、本検証では測定していません。

16GB環境で効いてくるのは、結局のところ系統（MoE/dense）とVRAMへの収まり方です。完全にVRAMへ載るdeepseek-coder-v2は速度とVRAMマージンの両方を確保しやすく、16GBに載り切らないqwen3-coder:30bは単GPUだと速度が抑えられ、codestral:22bはVRAMをほぼ使い切りながら日本語長文生成の速度も最下位。num_ctxを広げるほど、この収まり方の差が効いてきます。なお表に併記したボード電力とGPU温度は生成完了直後のスナップショットで、モデル間の電力効率を比較できる値ではないため、運用の判断材料には使っていません。

まとめ：迷ったらこれを選択

5モデルをRTX 5080（16GB）で比較した結果を整理します。日本語長文生成タスクでの生成速度は汎用14B dense（phi4:14b 74.33 / qwen3:14b 73.14）とコード特化MoE（deepseek-coder-v2 71.07 / qwen3-coder:30b 68.95）がほぼ横並びで、コード特化denseのcodestral:22b（Q4_K_M）だけが21.94 tok/sと突出して遅い。ただしqwen3-coder:30bの68.95は、モデルが16GBに載り切らず約26%がCPU側へ配置された状態での値で、本来の速度より抑えられていると考えられます。ボード電力とGPU温度も併記していますが、これらは各試行の生成完了直後に1回取得したスナップショットで、モデル間のピーク電力や電力効率を比較できる値ではないため、本記事では選定の根拠に使っていません。VRAMは14Bクラスが最も軽く、codestralが最も重い。下位クラスのRTX 5060 Ti（メモリ帯域・演算資源・電力枠がいずれも小さく、接続もOCuLink）では、モデルによりRTX 5080の約21〜62%の速度でした。

本検証の速度・VRAM配置と各モデルの公称設計を踏まえた運用候補としては、速度とVRAMマージンとコード特化設計を両立させたいなら、完全にVRAMへ載るコード特化MoEのdeepseek-coder-v2（qwen3-coder:30bはVRAMに余裕のある環境向き）、FIM補完を重視するならcodestralとdeepseek-coder-v2（いずれもFIM対応・品質は本検証未計測）、純粋な汎用用途なら14Bクラス。16GB環境でIDEを並走させるなら、VRAMに余裕のある14Bかdeepseek-coder-v2が常用しやすく、qwen3-coder:30bやcodestralはオンデマンド起用が現実的です。なお本記事で計測したのは日本語長文生成タスクでの生成速度・VRAM使用量・生成前処理時間（ボード電力とGPU温度は生成完了直後の参考値）で、コード生成速度・コード精度・FIM補完の品質は測定範囲外です。各配布元や第三者が公表する精度ベンチマークは評価条件が本検証と異なるため、実際の用途では自分のコードベースで別途確かめる前提で捉えてください。

なお、qwen3-coder:30bはRTX 5080に外部GPU（RTX 5060 Ti 16GB）をOCuLinkで足した2枚構成で走らせると154.72 tok/sと約2倍に伸びました（測定環境が異なるため「参考：異構成テスト」）。この伸びには、単GPU時にCPU側へ配置されていた分が解消または減少したことが大きく寄与した可能性があります。ただし2枚構成では2枚分の演算資源とメモリ帯域、Ollamaによる複数GPUへのモデル分散、異種GPU構成（RTX 5080＋RTX 5060 Ti）、OCuLink経由の転送条件も同時に加わるため、寄与率は分離できません。Ollamaは1枚に収まらないモデルを複数GPUへ分散配置しますが、各GPUへの具体的な分割方法は本検証では確認していません。2枚構成での ollama ps の表示や各GPUのVRAM使用量は計測していないため、「退避が完全に解消した」とも言えません。実測として言えるのは、16GBに載り切らないモデルでGPUを足した構成が単GPUの約2倍の生成速度になった、という結果です。

GPUの買い替えを検討している読者に向けて、価格と性能差の注意も添えます。財経新聞（zaikei.co.jp）はRTX 5080とRTX 5070 Tiを比較し、13タイトルの4K平均でRTX 5080が約17.5%高速、価格差は時点により約39%（定価とセール価格の差）と報じています。ただしこの約17.5%はゲームベンチマークの性能差であって、本記事で見たローカルLLM推論の速度差ではありません。「ゲームで17%速い＝LLMでも17%速い」とは言えず、AI用途での優劣は同一条件でLLMを実測しない限り判断できない点に注意してください。実売価格は市況で大きく動く（2026年はGPUメモリ価格高騰の影響で単体グラボが品薄気味）ため、購入時点の各ショップ価格を必ず確認しましょう。同じ16GBで下位クラスのRTX 5060 Tiも選択肢ですが、本記事で併記したとおりメモリ帯域・演算資源・電力枠がいずれも小さく、本検証での生成速度はRTX 5080の約21〜62%にとどまりました。

VRAMについては、16GBを確保できると選択肢が広がるのは確かですが、12GBクラスが使えないわけではありません。12GBでも14Bクラスの4bit量子化は、コンテキスト長を小さく取れば動作します。num_ctxを大きく設定する場合や、IDE・ブラウザとの並走でVRAM余裕が小さくなる場面で差が出る、という理解が正確です。IDEを並走させる本記事の運用を前提にするなら、16GB以上が快適という位置づけになります。

本記事は AIハードウェア図鑑 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。