RTX 5080で動かすコーディング用ローカルLLM実測比較

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

RTX 5080で同じプロンプト・同じ量子化条件のもと、コード特化のcodestral:22bと汎用の14Bクラス2種（phi4:14b / qwen3:14b）を実測したところ、速度最速はphi4:14bの82.6 tokens/sec、最遅はcodestral:22bの33.2 tokens/sec。ほぼ2.5倍の差がつきました。ただし「最速＝最良」とは限らないのがコーディング用途の難しいところ。速度だけで選ぶと、IDE常駐時にVRAMが足りずフリーズする、補完の言語カバレッジが弱くて使い物にならない、といった落とし穴にハマります。この記事では3モデルを実測データで比較し、対話型アシスタント用途とバッチコード生成用途でどちらを選ぶべきか、決断に必要な材料を提示していきます。

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

コーディング用ローカルLLMを評価する軸は、tokens/sec（生成速度）だけでは足りません。実務でIDEから呼び出すときに効いてくるのは、TTFT（初回トークンが出るまでの時間）とVRAMマージン（IDE/ブラウザと並走できる余裕）の2つ。この3軸を同時に見ないと、ベンチ表ではトップだったモデルが実使用で遅く感じるという逆転が起きます。

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

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

tokens/secは「1秒間に何トークン出力できるか」という連続生成の速度指標。バッチ処理では主役ですが、対話型のコード補完では脇役になります。IDEで補完を呼び出すと、ユーザーが体感するのは「Enterを押してから最初の1文字が出るまでの待ち時間」と「そこから数十トークン出力する速さ」の合計。つまりTTFTが遅ければ、後段のtok/sがいくら速くてもストレスが残る構造です。

もうひとつ見落とされがちなのが、VRAMマージンの問題。モデルがVRAMを埋め切ってしまうと、IDEのGPU支援やブラウザのハードウェアアクセラレーション、画像生成系の常駐ツールと競合します。VRAMから溢れた処理はCPU側にフォールバックし、その瞬間に速度は文字どおり崩壊する。tok/sの数字だけでは、この「運用時の余裕」は測れません。

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

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

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

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

当サイトの検証環境はRTX 5080（16GB GDDR7）、CPU i7-14700F、RAM 96GB、NVIDIAドライバ595.97、Ollama 0.20.7、OSはWindows 10。計測日は2026年4月19日で、Ollamaを経由して3モデルを同一プロンプト・同一量子化プリセット（Q4_K_M系）で走らせています。

3モデルの位置づけ

比較対象に選んだのは次の3モデルです。それぞれ狙いが明確に違うため、同じ条件で走らせると「コーディング用途での適材適所」が浮かび上がります。

codestral:22bは、コード生成特化モデルの代表格。多言語のコード補完・生成に強く、モデルサイズも22Bクラスと大きめ。品質重視の選択肢にあたります。

phi4:14bは、汎用LLMとして設計された14Bクラスのモデル。コード専用ではないものの、推論・論理・プログラミングを含む幅広いタスクで高い水準を示すモデルで、ベンチマーク界隈でも「14Bクラスの速度と精度のバランス型」として扱われています。

qwen3:14bは、最新世代の汎用14Bモデル。phi4:14bとサイズ帯は同じですが、世代が新しく、多言語（特に日本語と中国語）の扱いに強みがあると言われます。コード生成の実務で日本語コメントや仕様書からの実装をさせる場合に候補に入る1本。

この3モデルで「コード特化22B」「汎用14B・英語系」「汎用14B・多言語最新」という3つの方向性を比較する形になっています。

同一プロンプトでの比較ルール

比較の公平性を確保するため、同一プロンプトを使い、量子化もQ4_K_M系に統一。コンテキスト長やサンプリング温度などもデフォルト値で揃えています。tokens/sec、TTFT、VRAM使用量、消費電力、GPU温度を1プロンプトあたり計測し、平均値を記録。速度以外に電力効率も横に並べることで、「常駐させっぱなしで電気代が気になる」という実務の観点もカバーしました。

Willitrunaiが公開しているCodestral 2 25.08のRTX 5080ベンチでは51.5 tokens/secという数字が報告されている一方、当サイトの実測は33.2 tokens/sec。この差分は後半パートで突合しますが、先に結論を書いておくと、Codestralのバージョン差（従来版と2系の差）かQ4_K_Mの内部バリエーションの可能性が高いと考えます。数値は必ず「何を、どのバージョンで、どう量子化したか」とセットで読む。これが実測比較の基本ルール。

実測結果｜tokens/sec とVRAM使用量の比較表

当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM / Ollama 0.20.7）で計測した3モデルの数値を以下に並べます。見るべきは速度・VRAM・消費電力の3点。TTFTは次のH2で別途扱います。

速度ランキング

最速はphi4:14bの82.6 tokens/sec、2位がqwen3:14bの79.1 tokens/secで差はわずか約4%。事実上の同着です。codestral:22bは33.2 tokens/secで、14Bクラスのおよそ2.5分の1。パラメータ数が1.5倍になると速度は4割以下に落ちる、という現実的な目安が見て取れます。

注目したいのは消費電力の差。phi4:14bとqwen3:14bはGPUをフル活用して300W近くを消費する一方、codestral:22bは170Wと控えめです。これはモデルが大きくVRAM帯域がボトルネックになっている結果で、GPUが遊んでいる時間が多いことを示唆します。温度もcodestralだけ54.0°Cと明確に低く、「重たいけれどGPUを使い切れていない」という姿が数字に出ている、と読むのが自然。

VRAM占有の差

VRAM使用量はcodestral:22bが14.2GB、phi4:14bが11.0GB、qwen3:14bが10.7GB。16GB GPUに対してcodestralは約89%を占有しており、残り約1.7GB。この余裕の少なさがIDE並走時に牙を剥きます。対する14Bクラスは約11GB前後で収まり、およそ5GBのマージンが残る。このマージンの差がそのまま「IDEやCopilotを裏で走らせる余地」になります。

Hardware-Corner公開のRTX 5080向けLLMベンチマークでは、14Bクラスのモデルが約80 tokens/secという一般報告が出ており、当サイトの実測（phi4:14b 82.6 / qwen3:14b 79.1）とほぼ一致。独立した計測環境で同水準の数値が出ることは、今回のベンチマークの信頼性を裏付ける材料になります。

TTFT（初回応答時間）がもたらす体感差

tokens/secは「走り出してからの速さ」で、TTFTは「走り出すまでの速さ」。対話型コード補完ではTTFTが体感を支配します。当サイトの計測では、phi4:14bのTTFTが1818ms、qwen3:14bに関してはソース値の範囲内で14Bクラスとして同水準、codestral:22bは2771ms。codestralの初回応答は、phi4に比べて約950ms遅いという結果でした。

1秒弱の差は数字で見ると小さく感じますが、IDEで補完を1日何百回も呼ぶ使い方では累積が効いてきます。毎回1秒待たされる作業を300回繰り返せば、単純計算で5分の追加待ち時間。加えて「押した瞬間に反応がない」という主観的ストレスは、秒数以上に大きい。Cursor / Continue.devのようにインラインで候補が出るUIだと、TTFTの遅れはそのままタイピングのリズムを崩します。

逆にバッチ処理、たとえば「READMEを英訳してほしい」「このファイル全体にdocstringを追加してほしい」といった数千トークン級のリクエストでは、TTFTの数百ms差は全体時間の数%以下に埋もれる。この文脈ではcodestral:22bの生成品質が効いてきます。コード特化モデルが出す補完はインポート文の抜けが少ない、言語ごとのイディオムに忠実、といった「最終成果物の手直しコスト」で差をつけるからです。

ここは用途で割り切るのが正解。キーを押すたびに呼ぶ使い方ならphi4:14bまたはqwen3:14b、「投げてコーヒーを淹れている間に戻ってくる」使い方ならcodestral:22bに寄せる。同じGPUで同じモデル群を比較しても、使い方次第で勝者が変わるのがコーディング用途の面白いところ。

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

16GB VRAMのRTX 5080でcodestral:22bを常駐させると、VRAM使用量14.2GBに対して残りは約1.7GB。この状態でVS Code + GPU支援のかかったブラウザ + Slackクライアント、あたりを同時に走らせると、GPU側のVRAMは簡単に枯渇します。

参考になるのがRedditのComfyUIコミュニティで報告されている事例。大規模ワークフロー実行時にVAEのエンコード/デコードがCPUに落ち、GPU使用率100%→CPU使用率30%への遷移、さらにシステムメモリ50GB消費、ブラウザフリーズといった症状が出る。コメントでは「インストールが壊れている」「カスタムノードが悪さしている」といった指摘もありますが、本質はVRAM枯渇時のフォールバック挙動が重く、そこから雪崩式に遅くなるという点。コーディング用途でも同じ種類の事故が起きます。

同じ16GBクラスのGPUでも、「どれだけ余らせるか」で運用の安定性が変わる。これはLLMでもComfyUIでも共通する観点。

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

phi4:14bやqwen3:14bの場合、VRAMは11GB前後で済み、残り約5GB。VS Codeやブラウザを立ち上げた状態でも破綻しません。IDEのGitHub Copilot連携や、ブラウザで開いた軽めのローカルDashboardなどを並走させられる余裕があります。14Bクラスは「常駐型モデル」として設計されたわけではないのに、結果として常駐運用に向いている、というのが実務上の結論。

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

22Bクラス常駐時の落とし穴

codestral:22bを16GB環境で活かすなら「ピンポイント運用」が鉄則です。IDEから呼び続けるのではなく、CLIからバッチ処理の直前にロードして、終わり次第unloadする。Ollamaはモデル切り替えをキャッシュしてくれるため、同じモデルを短時間で再ロードするならコストは抑えられます。この運用戦略の詳細は、後半のH2-8で改めて掘り下げます。

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

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

14Bクラスは公開データと一致

Hardware-Corner（hardware-corner.net）が公開しているRTX 5080のLocal LLMベンチマークでは、14Bクラスのモデルで「約80 tok/s」という水準が報告されています。当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM）で計測したphi4:14bの82.5 tok/s、qwen3:14bの79.1 tok/sは、ほぼこのレンジに収まる数値。ドライバやOllamaバージョンが異なる条件でも、このクラスは安定して80 tok/s前後に着地するという見立てが成り立ちます。

複数の観測点が近い値に集中するということは、14Bクラス+RTX 5080の組み合わせが「成熟した構成」であることを意味します。量子化プリセットや微妙なチューニングで大きくブレない、再現性の高い領域。ここを基準に他の選択肢を評価すると判断がぶれません。

codestralは報告値と差がある

一方で悩ましいのがcodestralの数値。Willitrunai（willitrunai.com）が公開しているCodestral 2 25.08 on RTX 5080 16GBのページでは51.5 tok/sという報告が出ていますが、当サイトの実測は33.3 tok/s。約35%の差があり、これは量子化プリセットのブレだけでは説明しにくい幅。

考えられる原因は2つあります。1つ目はCodestralのバージョン差。2025年8月リリースのCodestral 2系と、それ以前のCodestral系でアーキテクチャや最適化が異なる可能性があります。2つ目はQ4_K_Mの内部変動。同じ名前のプリセットでも配布元・変換バージョンで実効性能に差が出ることがあり、これはOllama公式のタグとHugging Faceの派生タグで起きやすい現象。

どちらが正しいかを断定する材料は揃っていません。ただ「codestral:22bはモデルのバージョンと配布元で速度が大きく変わる可能性がある」という認識は持っておくべき。同じ環境でも、pull元を変えれば50 tok/s出る可能性は残されています。

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

数字の突合が終わったところで、ここからは実際にどのモデルをどう選ぶかの話。コーディング用途は「対話型アシスタント」と「バッチコード生成」で必要な性能が異なるため、分けて推奨を出します。

IDE常駐型のベスト解

Cursor、Continue.dev、Cline、Aiderのように、IDE内で対話しながらコードを書く用途。ここではphi4:14bを推奨します。理由は3つ。TTFT 1818msで初回応答が最も速いこと、82.5 tok/sで長文生成でもストレスが少ないこと、VRAM 11.0GBでIDEや他のツールとの並走に耐えること。この3つが揃う14Bクラスは、対話型補完のために設計されたかのようにバランスが取れています。

qwen3:14bも対話型の有力候補。tok/sはphi4よりわずかに落ちる79.1ですが、日本語でのコメント生成や自然言語による指示解釈では最新世代のアーキテクチャ分が効きます。和製コード資産を扱うなら、qwen3:14bの方が違和感の少ない出力になるケースもある。日本語指示が多ければqwen3、英語中心ならphi4、という住み分けが現実的。

バッチ生成向きの選択

一方、CLIから大量のコードを一括生成したい、ドキュメント整形を走らせたい、コードレビューをバッチ実行したい、という用途ならcodestral:22b一択です。33.3 tok/sと遅めですが、コード特化モデルとしての言語カバレッジ（Python・JavaScript・TypeScript・Rust・Go・C++・Javaなど幅広い言語での学習）と、関数生成の精度で14Bクラスを上回ります。

バッチ処理ならTTFT 2771msも問題になりません。起動コストは初回だけで、あとは連続的にトークンを吐き続けるだけ。IDEのUIに表示されるわけではないので、ユーザーが「遅い」と感じる局面が少ない。夜間にまとめて回すなら、速度よりも一発で通る精度の方が総合時間を短縮します。

切り替え運用の実際

「対話もバッチも両方やりたい」という読者は少なくありません。その場合はphi4:14bを常駐、codestral:22bをオンデマンドというハイブリッド運用が実務的な答え。

Ollamaはモデルのロードをキャッシュするため、直近で使ったモデルの再ロードは比較的速い。普段はphi4:14bでIDE補完、大きなリファクタや関数一括生成が必要になったときだけcodestral:22bを呼び出す、という使い分けがきれいにハマります。マイナビニュースが指摘した「AIは叩き台、最終判断は人間」という設計思想をそのまま適用するなら、速度重視の叩き台をphi4、精度重視の本番生成を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年現在でも主力。ここで3モデルをどう運用するかを整理しておきます。

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

16GB環境での割り切りは明快。常駐させていいのは14Bクラスまで。20B超のモデルは必要なときだけロードして、使い終わったらアンロードする運用に統一します。

Ollamaのモデルキャッシュは直近利用モデルをRAMに残すため、96GB RAMのような余裕がある環境では、2〜3モデルの切り替えでも体感の遅さは少ない。ただしVRAMは別。GPUへのロード時間は毎回かかるので、頻繁に切り替えるなら常駐型を決めておくべき。

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

表に出ている「VRAM使用量」はモデル本体のロード分。実際の推論時にはKVキャッシュが追加で消費されます。長文コンテキスト（例: コードベース全体を読み込ませるような使い方）では、このKVキャッシュだけで数GB積み上がることもあります。

codestral:22bの14.2GBという値は、短めの入力での計測値。長文プロンプトを入れれば15GBを超え、16GB VRAMでは確実にOOMが出ます。20Bクラスを16GB環境で常用するなら、コンテキスト長を絞るかnum_ctxを制限するのが前提。これを怠ると、ベンチマークでは動いていたモデルが実運用でいきなり落ちる、という事態を招きます。

当サイトで計測した全モデルの消費電力や温度データを見ても、codestral:22bはTDPギリギリまで使わず170Wで動作。つまりVRAMがボトルネックで計算リソースを使い切れていない、という読み方もできる。16GBでは20Bクラスの本気を引き出せていない、という見方が妥当。

よくある質問

Q. codestral:22b をQ8量子化で動かせますか？

Q8（約22GB想定）は16GB VRAMに収まらず、RTX 5080では動作しません。Q8を動かすなら24GB以上のVRAMが必要で、RTX 3090中古やRTX 5090クラスが現実解。16GB環境ではQ4_K_Mが上限と割り切ってください。

Q. phi4:14bとqwen3:14b、コーディング用途ならどちらを選ぶべきですか？

tok/sとTTFTはphi4がわずかに上（82.5 tok/s、TTFT 1818ms）、qwen3は79.1 tok/sで僅差。日本語コメントや日本語指示を多用するならqwen3、英語中心のプロジェクトならphi4が向きます。どちらか一方で大きく困ることはありません。

Q. CursorやContinue.devからローカルLLMに接続できますか？

どちらもOllamaのローカルエンドポイント（デフォルトはlocalhost:11434）に接続可能。Continue.devは公式にOllamaをサポートしており、設定ファイルでモデル名を指定するだけで動きます。Cursorはカスタムモデル設定でベースURLを指定すれば利用できます。

Q. GPUを持っていない場合、CPU推論でも実用になりますか？

phi4:14bのQ4クラスをCPU推論（DDR5-6000デュアルチャネル環境）で動かすと、体感で5〜10 tok/s程度に落ちます。対話型補完としては厳しく、バッチ生成でも時間はかかります。コーディング用途で快適さを求めるなら、16GB VRAMクラスのGPUが実質的な下限。

Q. RTX 5060 Ti 16GBでも同じ結果になりますか？

VRAM容量は同じ16GBなので、モデルがロードできるかどうかの条件は変わりません。ただしCUDAコア数と帯域幅でRTX 5080に劣るため、tok/sは2〜3割落ちる想定。それでも14Bクラスなら50〜60 tok/sは出る見込みで、コーディング用途として十分実用的。

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

3モデルを同一環境で比較した結果をひと言で整理すると、速度最優先ならphi4:14b、コード精度最優先ならcodestral:22b、日本語を含むバランス重視ならqwen3:14b。16GB環境でIDEを並走させるなら14Bクラス2本のどちらかが現実解で、22Bクラスはバッチ用のスポット起用。この3択を覚えておけば、コーディング用ローカルLLMの選定で迷うことは減ります。

GPUの買い替えを検討している読者には、RTX 5080が2026年4月時点で20万円前後、RTX 5070 Tiが17万円台という価格帯。AI用途での実効性能差は10〜20%程度なので、予算が厳しければRTX 5070 Ti、余裕があればRTX 5080、という選び方が無難。16GB VRAMを確保することが何より大事で、12GBクラスでは14Bモデルを量子化しても常駐運用には厳しい、という結論は変わりません。

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

おすすめパーツ 価格まとめ

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