qwen3-coder:30bをローカルで動かす実測｜当サイト検証で最速級のコーディングLLMに必要なVRAMと選び方

qwen3-coder:30bとは、コーディング用途に特化した、Apache 2.0 で公開されているオープンウェイトのローカルLLMである。

ローカルでコード生成・補完・エージェント用途を回すなら、qwen3-coder:30bは、当サイトが測定したモデルの中では最速級の選択肢です。当サイトの検証環境（RTX 5080＋RTX 5060 Ti・Oculink・think=false・3回中央値）では、2026年7月30日の計測（num_ctx=8192固定）で159.4 tok/sを記録しました。ただし速さには前提があります。30B-A3BのMoEは、1トークンごとに動く部分（アクティブ）こそ3B級ですが、重み全体は30B級ぶんを保持します（Qwen公式の値では総30.5B・推論時に3.3Bがアクティブで、128エキスパート中8つを使う）。本記事が扱うのはOllamaの標準タグ qwen3-coder:30b（Q4_K_M量子化・配布ファイル約19GB）で、以下のVRAMと速度の話はすべてこのタグが対象です。配布ファイルの容量と、実際にGPUへ載る量は別の指標になります。当サイトで num_ctx=8192 のときのモデル配置量を測ると18.38GiBで、この構成では16GB 1枚に収まりません。159.4 tok/s はRTX 5080＋RTX 5060 Ti（合計32GB）に2枚またがり、GPU常駐率100%で動かしたときの値です。16GB 1枚に載せると約1/4がCPUへオフロードされますが、動かなくなるわけではありません。RTX 5080単体で73.7 tok/s、RTX 5060 Ti 16GB単体で65.6 tok/s。2枚構成の半分弱に落ちる代わりに、num_ctx=8192 での生成スループットに限れば1枚でも実用的な速度が残ります（いずれも2026年7月30日・num_ctx=8192で統一）。より低ビットの第三者量子化版まで含めれば16GBに収まる構成もあり得ますが、本記事の検証対象ではありません。

なぜ30B級なのに軽くて速いのか。理由はMoE（専門家混合）という構造にあります。この記事では、その仕組みと当サイトの実測値を並べ、qwen3-coder:30bが「自分のGPUで実用速度で動くか」「補完・エージェント・バッチ生成のどの用途にどの構成が合うか」を数値で判断できるところまで案内します。

この記事の要点

・qwen3-coder:30bは30B-A3BのMoE。速さはアクティブ3B級ゆえだが、重み全体は30B級ぶん保持するためVRAMは16GB超。num_ctx=8192 での実測VRAM配置量は18.38GiBで、16GB 1枚には全層常駐しない（配布ファイルは約19GBだが、これは実際にGPUが確保する量とは別の指標）。CPUオフロードなしの100% GPU常駐を当サイトで確認したのは16GB×2＝合計32GBの構成。18.38GiBなら24GB単体GPUも容量上の候補になるが、当サイトでは未計測
・当サイトの検証環境（RTX 5080＋RTX 5060 Ti・Oculink・think=false・合計32GB・num_ctx=8192）で159.4 tok/s（2026-07-30計測）。計測条件は揃わないが、2026-06-18に測ったdense型Qwen3 32B（26.0 tok/s）の6倍以上にあたる
・16GB 1枚では約1/4がCPUへオフロードされ、RTX 5080単体で73.7 tok/s、RTX 5060 Ti 16GB単体で65.6 tok/s（2026-07-30・num_ctx=8192で統一）。2枚構成の半分弱だが1枚でも実用域。オフロードを避けたいなら2枚構成（合計32GB）

qwen3-coder:30bとは｜ローカルで動くコーディングLLMの位置づけ
検証環境とテスト条件｜実測値の前提
1. 計測した項目と単位の扱い
2. 計測条件の固定
実測スループット比較｜qwen3-coder:30bは他モデルとどれだけ違うか
1. 16GB 1枚では収まらない｜当サイトでは2枚構成で100% GPU常駐を確認
2. RTX 5060 Tiで動かす場合の見方
用途別の選び方｜コード補完・エージェント・どのGPUが向く
導入と注意点｜Ollamaでの起動とつまずき所
まとめ
よくある質問
関連記事
参考資料

qwen3-coder:30bとは｜ローカルで動くコーディングLLMの位置づけ

qwen3-coder:30bは、Qwenシリーズのコーディング向けに調整されたローカル実行用のLLMです。コードの補完・生成・修正・説明といった作業を、クラウドのAPIに頼らず手元のGPUで動かせる点が最大の特徴。ChatGPTやClaudeのようなクラウドサービスをコーディングで使ってきた層が、「同じことをローカルで、課金を気にせず回したい」と考えたときの選択肢になります。

名前のとおり「coder」と付くモデルで、汎用の対話よりもプログラミングに寄せた使い方を想定しています。Ollamaのモデルライブラリから取得して動かす形が一般的。正確なバージョン体系やライセンスの細部は更新されることがあるため、最新の情報はOllamaのモデルページとQwenの公式リポジトリで確認してください。

30B級なのに「軽くて速い」理由

このモデルの核心はMoE（Mixture of Experts、専門家混合）という構造にあります。一般的なdense型モデルは、推論時に各層の重みを広く使って計算します。32Bのモデルなら1トークンごとに32B規模の重みに基づく行列演算が走るため、当然ながら重く、遅い。当サイトの検証環境でもdense型のQwen3 32B（Ollama: qwen3:32b）は26.0 tok/sにとどまりました。

一方MoEは、内部に複数の「専門家」を持ち、入力に応じてその一部だけを動かします。総パラメータは30B級でも、実際に1トークンを生成するたびに計算に使う部分はずっと小さい。だから総量の割に軽く、速く動きます。当サイトの検証で、dense型32B（26.0 tok/s・2026-06-18）に対しqwen3-coder:30bが159.4 tok/s（2026-07-30）と6倍以上で走ったのは、アクティブパラメータが小さいMoEの特性と整合する結果です。ただしこの2つは計測日もコンテキスト長の条件も違うため、倍率そのものは目安として読んでください（速度差には量子化方式・メモリ帯域・カーネル実装・GPU分割の影響も含まれます）。

ただし速さと裏腹に、VRAMは軽くありません。MoEは計算こそアクティブな一部の専門家だけで済みますが、どの専門家が呼ばれるかは入力次第なので、重み全体（30B級）はメモリに保持する必要があります。当サイトの計測では、qwen3-coder:30b がVRAMに置いた量は18.38GiB（Ollamaの /api/ps が返す size_vram）でした。同時刻の両GPU合算のGPU使用量は約20.7GiB（nvidia-smi memory.used 基準）でした。この差には、デスクトップ描画など他プロセスの常駐分のほか、推論ランタイム側が確保する分も含まれ得ます。どちらの数字で見ても16GBの1枚には収まりません。2枚（合計32GB）に分散して初めてGPU常駐率100%になりました。「アクティブが3B級だからVRAMも3B級」ではありません。速いのはMoEのおかげ、でもメモリは総パラメータぶん要る、という関係です。

クラウドのコーディングLLMと何が違うか

クラウドのコーディング支援と比べたときの違いは、主に3点に整理できます。

まずコスト。ローカル実行ならトークン課金が発生しません。補完を1日に何百回も走らせる使い方では、この差が効いてきます。次にプライバシー。ローカルで動かすモデル自体は、コードを外部の推論APIへ送りません。ただし、ツール側がWeb検索や外部モデル連携の機能を持つ場合は、その経路でデータが外に出る可能性があります。「ローカルだから絶対に外部に出ない」と無条件には言えない点に注意してください。

最後に応答の挙動。ローカルなら外部ネットワークとの往復がないぶん、最初の応答までが速い場面があります。反面、モデルの賢さはクラウドの最上位モデルに及ばないケースもある。コードの叩き台や定型的な補完はローカルで素早く回し、難しい設計判断はクラウドに任せる、という使い分けが現実的です。

複雑なコーディングではクラウド上位モデルが有力｜公開コーディングベンチで見る位置づけ

コード用途では速度だけでなく精度も判断材料になります。当サイトは精度そのものを計測していないため、ここでは各モデルが公開しているコーディング系ベンチ（SWE-bench Verified／SWE-Bench Pro／Terminal-Bench など）の発表値で位置づけを示します。SWE-bench Verifiedは、実在するGitHubのissueをエージェントに解かせ、テストが通るパッチを書けるかを見る代表的な指標です。

モデル	提供形態	公開ベンチでの位置づけ（2026年7月時点）
qwen3-coder:30b（本記事の主役）	ローカル（30B-A3B）	第三者検証では、BF16版をvLLM＋OpenHands v0.54.0で動かしSWE-bench Verified 全500件のうちインフラ上の問題があった16件を除く484件、最大100 turns という条件で Pass@1 51.9±0.2%（±は標準誤差。bfloat16・vLLM v0.9.0・最大シーケンス長131,072）。小型Coderモデルのツール呼び出しを補正する OpenHands 側の追加後処理を含む値で、素の構成のままこの数字が出るわけではない。当サイトが速度を測ったOllamaのQ4_K_M版の精度ではなく、scaffold・試行回数・turn数で変動する
Claude Sonnet 5	クラウドAPI（Claude Code）	2026年6月30日公開。公式は Frontier-Bench 等の自社評価に加え、System Card でも評価値を公表している。ただし評価harness・scaffold・turn数の条件が上記の再現評価とは異なるため、51.9% とは直接比較できない。詳細は Sonnet 5 System Card を参照
Claude Opus 5	クラウドAPI（Claude Code）	2026年7月24日公開。Anthropic公式は前世代Opus 4.8と同価格で性能が大きく改善したと説明。System Card に評価値があるが、Sonnet 5 と同じく評価条件が上記の再現評価と異なるため 51.9% とは直接比較できない。詳細は Opus 5 System Card を参照
GPT-5.6 Sol	OpenAIのクラウドモデル（Codex・ChatGPT向け）	2026年7月9日に一般提供が始まったGPT-5.6系フラッグシップ（6月26日に限定プレビュー）。CodexではFree/GoがTerra、Plus以上でSol/Terra/Lunaを選べ、既定のPower設定はSolを使う。SWE-bench Verified の同条件値は非公表

ローカルで動く qwen3-coder:30b の約52%という公開再現値は、scaffoldや試行条件に左右されるものの、30B級のローカルモデルとしては健闘している水準です。ただし複雑なエージェント型のコーディングでは、Claude Opus 5・Sonnet 5（Claude Code）や GPT-5.6 Sol（Codexで利用可能）といったクラウドの上位モデルが有力候補になります。各社で評価条件が異なるため、公開値だけから単純な総合順位は付けられません。各社はそれぞれ異なるコーディング・エージェント評価で高い性能を報告していますが、ベンチごとに対象タスクやscaffoldが違うため、数値を横並びで単純比較するのではなく、「ローカル高速モデルとクラウド高精度モデルの使い分け」を見る材料として扱うのが安全です。なお、これらは各社発表値や第三者集計の公開ベンチであって当サイトの計測ではありません。

つまり使い分けです。難所の設計やレビュー、一発の正確さが要る場面はクラウドの上位モデルに任せ、定型的な補完や大量のコード生成を課金もデータ送信も気にせず手元で高速に回す部分を qwen3-coder:30b に振る。この併用が現実的です。qwen3-coder:30bの強みは「精度の世界一」ではなく、ローカルで150 tok/s級の速さ・低コスト・プライバシーを同時に取れる点にあります。

検証環境とテスト条件｜実測値の前提

数値は測り方で変わります。この記事の実測値は、すべて当サイトの検証環境で測ったものです。RTX 5080（VRAM 16GB）と RTX 5060 Ti 16GB（OCuLink外付け）の2枚で、合計32GB。CPU・RAM・電源を含む全体像は検証環境ページにまとめてあります。

コンテキスト長: 3構成すべて num_ctx=8192 に固定（/api/ps の context_length が実際に8192であることを各測定で確認）
集計: think=false・各3回の中央値
VRAM: nvidia-smi の memory.used。2枚にまたがる場合は両GPU合算（デスクトップ描画などの常駐を含むため、16GBぴったりまでは使えません）
ソフトウェア: Ollama 0.30.7（6月18日）／0.32.3（7月24日・7月30日）、NVIDIAドライバ 610.47

Ollamaの既定コンテキスト長は利用可能なVRAM量で変わるため、指定せずに測ると1枚構成と2枚構成で条件がずれます。構成をまたぐ速度の比較には、num_ctx=8192 に固定して測り直した7月30日の値だけを使っています。

計測した項目と単位の扱い

計測したのは主に生成スループット（tokens/sec）とVRAM使用量の2つ。VRAMについては表記に2つの意味があるため、混同しないよう区別します。

ひとつは「GPU全体の使用量」。これはnvidia-smiが報告するmemory.usedの値で、デスクトップ表示など他の常駐分も含んだGPU全体の数字です。単位はMiBで、GiBへの換算は1024で割ります。この記事で「VRAM全体使用量」と書いたものはこちらを指します。もうひとつは「モデル単体のVRAM配置量」で、Ollamaの /api/ps が報告する size_vram（VRAM usage）の値です。Ollamaがそのモデルについて報告する値で、GPU全体の使用量とは別に取れます。両者は別物なので、本文ではどちらの値かを明示します。

計測条件の固定

条件をそろえないと速度は簡単にぶれます。当サイトの計測では次を固定しました。

thinkモードは比較条件をそろえるため、API呼び出し側で全モデルthink=falseに統一しています。thinking対応モデルは既定で思考トークンを生成し、それが速度や見かけの出力量に影響するため、非対応モデルと並べるときの非対称をなくす狙いです。なお、qwen3-coder:30b自体はnon-thinkingモデルで思考トークンを生成しないため、この指定は主に比較条件の統一が目的で、qwen3-coder:30bの速度を底上げするものではありません。集計は各モデル3回計測し、その中央値を採用（生成トークン数は num_predict=512、seed=42、OLLAMA_NUM_PARALLEL=1）。GPU常駐はOllamaの/api/psでVRAMに載っていることを確認したうえで測定しています。同名タグでも中身が更新されることがあるため、各モデルのdigest（sha256）も記録して同定しました。

なお、複数のOllamaプロセスや推論を同時に走らせると、他プロセスのVRAM使用分が測定値に混入します。当サイトの計測は対象モデル1つを動かした状態で行っています。

実測スループット比較｜qwen3-coder:30bは他モデルとどれだけ違うか

qwen3-coder:30bの速さは、同じ環境で測った他のモデルと並べると見当がつきます。下表は当サイトの検証環境（think=false、3回計測の中央値）で記録した、コーディングに使われやすいモデルと比較対象を整理したものです。主役の qwen3-coder:30b だけは計測条件が揃わないため表には入れず、表の後で別に示します。tok/sは2枚とも見せた状態での実測です。ただしOllamaは1枚に収まるモデルを分割しないため、16GBに収まる行（Qwen3 14B・Gemma 4 12B）は実際には片方のGPU 1枚だけで動いた値になります。VRAMの列はGPU全体使用量（nvidia-smi memory.used 基準）で、2枚にまたがったモデルは両GPU合算値、1枚で動いたモデルはその1枚の値です。

モデル	構造	tokens/sec（2枚とも見せた状態）	VRAM使用量（nvidia-smi memory.used・GPU全体／16GB 1枚に収まるか）	用途適性
Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）	MoE	122.4	約24.1GiB（合算・16GB超）	汎用＋コーディング
Codestral 22B（Ollama: codestral:22b）	dense（コード特化）	40.2	約15.5GiB（合算・16GBの縁）	コード生成（速度は控えめ）
Qwen3 14B（Ollama: qwen3:14b）	dense	43.6 （実際は1枚のみで動作）	約10.9GiB（16GB単体可）	汎用中型
Qwen3 32B（Ollama: qwen3:32b）	dense	26.0	約22.7GiB（合算・16GB超）	汎用・品質重視
Gemma 4 12B（Ollama: gemma4:12b）	dense	44.5 （実際は1枚のみで動作）	約9.4GiB（16GB単体可）	汎用中型

上表は2枚とも見せた状態で、2026年6月18日に同一条件・同一日で並べた実測です。この時はリクエスト側でコンテキスト長を指定しておらず、当時の記録からは各ロードの実効値を確定できません。そのため、7月30日に num_ctx=8192 を明示して測り直した単体GPU比較とは測定系列を分けています。主役の qwen3-coder:30b は条件をそろえた7月30日の値を使うため、この表には入れていません（159.4 tok/s・両GPU合算で約20.7GiB）。

同じ2枚構成で測った値どうしで見ると、qwen3-coder:30b はdense型32BのQwen3 32B（Ollama: qwen3:32b）（26.0 tok/s）の6倍以上、Codestral 22B（Ollama: codestral:22b）（40.2 tok/s）の3倍以上にあたります。総パラメータでは上回っているのに、速度では逆転している。MoEのアクティブパラメータが小さいことが大きく寄与したと考えられる結果です（条件が完全には揃っていないため、6倍という倍率そのものをMoEの効果として切り出すことはできません）。

なお、Qwen3 14BとGemma 4 12Bは16GBに収まるため、2枚見せても分割されず片方のGPUだけで動きます。上の値は遅い側のRTX 5060 Tiに載ったときのもので、根拠は消費電力の内訳（RTX 5080が約55Wとほぼ非稼働、RTX 5060 Tiが約149〜165Wで稼働）と、Qwen3 14Bのこの43.6 tok/sが5060 Tiだけを見せて測った43.5 tok/sとほぼ一致することです。載る先を決めたいなら CUDA_VISIBLE_DEVICES で見せるGPUを固定するのが確実です（手順はAI用途にGPUは2枚必要か）。一方qwen3-coder:30bなど16GB超のモデルは、16GB 1枚に載せるとCPUオフロードで大きく落ちます（後述）。

注目したいのが、VRAM占有と速度が必ずしも比例しない点。Codestral 22B（Ollama: codestral:22b）はRTX 5080だけを見せて動かすとGPU常駐率100%で1枚に収まりますが（約15.1GiB・2026年7月24日計測）、2枚とも見せた上表の計測では両GPUにまたがりました。同じモデルでも、見せたGPUの枚数で挙動が変わります。

その上表の40.2 tok/s は qwen3-coder:30b（159.4 tok/s）の4分の1程度で、VRAMの占有量だけでモデルの「軽さ」や速さは測れません。ただし「1枚に収まるか」は速度とは別問題です。qwen3-coder:30b はVRAMが大きいぶん16GB 1枚では全層を載せきれず、100% GPU常駐を確認できたのは16GB×2の構成でした（num_ctx=8192 での配置量18.38GiBから見れば24GB単体も容量上の候補ですが、未計測です）。

16GB 1枚では収まらない｜当サイトでは2枚構成で100% GPU常駐を確認

ここが選定で一番重要な点です。当サイトで num_ctx=8192 のときのVRAM配置量を測ると18.38GiBで、16GBの1枚には全層を載せられません（配布ファイルの容量は約19GBですが、これは実際にGPUが確保する量とは別の指標です）。2枚構成での常駐時、Ollamaの /api/ps は、モデル全体のサイズを返す size と、そのうちVRAMに載っている分を返す size_vram が両方とも18.38GiBで一致していました。つまり全層がGPUに載っています。同じときの両GPU合算のGPU使用量は約20.7GiB（nvidia-smi memory.used 基準）でした。差の約2.3GiBには、デスクトップ描画など他プロセスの常駐分のほか、推論ランタイム側が確保する分も含まれ得ます。内訳は切り分けていません。この2つは意味が違うので、本文では常に区別して示します。159.4 tok/sという速度は、RTX 5080＋RTX 5060 Ti（合計32GB）に2枚またがり、GPU常駐率100%で動かしたときの値です。

16GBのGPU1枚に載せるとどうなるか。num_ctx=8192 で揃えて測ると、RTX 5080単体は GPU常駐率74%（モデル18.26GiBのうち13.53GiBがVRAM、残りはCPU）で73.7 tok/s、RTX 5060 Ti 16GB単体は常駐率75%（18.29GiB中13.77GiB）で65.6 tok/sでした。約1/4をCPUに預けても、8Kコンテキストでの生成スループットは2枚構成の半分弱が残ります。カード間の差も1割強にとどまり、この条件では「どちらの16GBカードか」より「1枚か2枚か」のほうが効いています。ただしこれは当サイトの搭載構成（5060 Ti側はOCuLink接続）での結果で、接続経路やリンク幅、Ollamaの層分割の仕方も結果に混ざります。GPU単体の性能比として読まないでください。またコンテキスト長を伸ばせばKVキャッシュ分でVRAM消費が増え、オフロード比率が上がって速度は落ちます。「16GB 1枚で159 tok/s」は出ません。オフロードを避けたいなら2枚構成（合計32GB）が当サイトの実測です。num_ctx=8192 ならモデルの配置量は18.38GiBなので、24GB級の単体GPUも容量上の候補にはなります。ただし24GB単体での速度と、64K以上の長いコンテキストでのGPU常駐率は当サイトでは計測していません。

RTX 5060 Tiで動かす場合の見方

RTX 5060 Ti 16GBを1枚で使う場合も、qwen3-coder:30bは16GB超のためCPUオフロードが発生します。RTX 5060 TiはCUDAコア数（4608基）もメモリ帯域もRTX 5080（10752基）より小さいため、実際に num_ctx=8192 で測ると、RTX 5060 Ti 16GB単体は65.6 tok/s（GPU常駐率75%）でした。RTX 5080単体の73.7 tok/s（常駐率74%）に対して約89%で、想定より差は小さい。オフロード比率がほぼ同じなら、この条件では速度もそれほど離れないという結果です。ただしこれはGPU単体の性能比ではなく、OCuLink接続・リンク幅・オフロード分の転送・Ollamaの層分割まで含んだ当サイトの搭載構成での値です。RTX 5060 Tiでqwen3-coder:30bをCPUオフロードなしで使いたいなら、RTX 5080などと組み合わせた2枚構成にして合計32GBで載せるのが現実的です。1枚で軽快に回したいなら、量子化後に16GBへ全層常駐できるコーディング向けモデルを選ぶほうが速度は出ます（16GBカードの一例はRTX 5060 Ti 16GB）。

用途別の選び方｜コード補完・エージェント・どのGPUが向く

速度重視の補完用途か、文脈量重視のエージェント用途か。ここで構成の見方が分かれます。

リアルタイム補完を重視するなら RTX 5080を含む合計32GB級（2枚構成）が向きます。当サイトの検証環境（RTX 5080＋RTX 5060 Ti（Oculink）構成・think=false・3回中央値）ではqwen3-coder:30bが159.4 tok/sを記録しています。この値は生成開始後の出力スループットで、補完の体感を決めるもう一つの要素である最初のトークンまでの時間（TTFT）は別の指標です。本記事ではTTFT自体は計測していません。クライアント側でリクエスト送信から最初の生成トークンを含む応答チャンクを受け取るまでを測る、という計測をしていないためです。参考値として示せるのは、Ollama APIが返す load_duration と prompt_eval_duration の合計＝生成開始前の前処理時間の近似値だけになります。その中央値は2枚構成142.6ms、RTX 5080単体170.2ms、RTX 5060 Ti単体197.6ms（2026-07-30・num_ctx=8192）。初回ロード時は load_duration が大きく増えて数秒単位になるため、ここではモデル常駐済みの測定だけを集計しています。まずはCPUオフロードが起きない構成にしてスループットを確保し、常駐させたまま使うのが素直な選択になります。

ローカルエージェント・長文生成を回すなら こちらも合計32GB級（2枚構成）が無難です。長いリファクタや複数ファイルの読み書きでは生成量が増え、持続スループットがそのまま待ち時間に効きます。ただし本記事が測ったのは num_ctx=8192 での結果です。Ollamaはコーディングツールやエージェント用途に64K以上のコンテキストを推奨しており、コンテキストを広げるとKVキャッシュ分でVRAM消費が増えてGPU常駐率も下がります。64K以上を使う本格的なリポジトリ解析やエージェント運用に、本記事の測定値をそのまま当てはめることはできません。

予算を最優先するなら（1枚構成） qwen3-coder:30bは16GB 1枚には収まらずオフロードで遅くなるため、1枚構成ならむしろ、量子化後に16GBへ全層常駐できるコーディング向けモデルが現実的です。目安は14B級ですが、本記事で測ったCodestral 22B（RTX 5080だけを見せた時に約15.1GiB・常駐率100%）のように、量子化しだいで22B級でも1枚に収まります。パラメータ数の上限ではなく、収まるかどうかで選んでください。qwen3-coder:30bの速度が欲しいなら、16GBを2枚そろえて合計32GBにするか、24GB級GPUを1枚用意する方向になります。

どの構成にするか決めるなら1枚で16GBに収めるか、2枚で合計32GBにするか。必要なVRAM容量のまま、売っているグラフィックボードを厚み・補助電源・価格帯から絞り込めます。

GPU選びを開く →

Claude CodeでAnthropic提供のClaudeモデルを使う通常構成や、GitHubホスト型のCopilotモデルがメインなら 推論はクラウド側で行われるため、推論用のローカルGPUは不要です。ただしClaude Code自体はローカルモデルでも動かせます。Ollamaは v0.14.0（2026年1月）からAnthropic Messages API互換のエンドポイントを提供しており、ANTHROPIC_BASE_URL を http://localhost:11434 に向ければ、qwen3-coder:30bのようなローカルモデルをClaude Codeから使えます。ただしCopilot CLIはBYOK（自分の鍵を使う構成）に対応しており、OpenAI互換エンドポイントとしてOllamaやvLLMを指定すればローカルモデルで動かせます（対象モデルはツール呼び出しとストリーミングへの対応が必要）。Copilotアプリ側のBYOKはパブリックプレビューです。その場合はローカルGPUが効いてきます。コードを手元で完結させたい場面だけ、qwen3-coder:30bのようなローカルモデルを足す形が無理のない使い分けです。

導入と注意点｜Ollamaでの起動とつまずき所

Ollamaを入れた後は、ターミナルで ollama run qwen3-coder:30b と打つだけで取得から起動まで進みます。初回はモデルのダウンロードに時間がかかる点に注意。正確なタグはOllamaのモデルページで確認してください。

複数のOllama serveや推論プロセスを同時に立ち上げると、他プロセスのVRAM使用分が測定値や空き容量に混入します。速度が安定しないときは、まず常駐プロセスを1つに絞ること。

常駐の管理にはkeep_aliveを使います。0 を指定すると実行後にアンロードされ、未指定時は通常5分保持されます。長く保持したい場合は 5m などの時間指定を使います。負の値（-1 など）を指定すると、モデルをメモリに保持し続ける指定になります。

モデル構造	30B-A3B MoE（コーディング向け）
VRAM目安	num_ctx=8192 でのモデルVRAM配置量18.38GiB（配布ファイル約19GB）。GPU常駐率100%は合計32GB（2枚）が実測、24GB級は同条件での容量上の候補（速度は未計測）。16GB 1枚は約1/4がCPUオフロードとなり、RTX 5080単体で73.7 tok/s・RTX 5060 Ti単体で65.6 tok/s
参考速度	RTX 5080＋RTX 5060 Ti（Oculink・合計32GB・num_ctx=8192）で159.4 tok/s（2026-07-30計測）
対応GPU例	合計32GB（RTX 5080＋RTX 5060 Ti 等の2枚）。24GB級GPUは num_ctx=8192 での容量上の候補。16GB 1枚はオフロード前提

この規模のコーディングLLMで、完全オフラインでゲームやコードをどこまで自作できるかという到達点も、別記事で検証しています。

まとめ

qwen3-coder:30bは、当サイトの検証環境（RTX 5080＋RTX 5060 Ti）で159.4 tok/sを記録した、当サイトが測ったモデルの中では最速級のローカルコーディングLLMです。ただし速いのはMoE（30B-A3B）のおかげで、VRAMは重み全体ぶん必要なため16GBの1枚には収まりません。CPUオフロードなしで動かすにはRTX 5080＋RTX 5060 Ti のような合計32GB（2枚）が実測です（24GB級GPUは容量的な目安で、速度は当サイト未計測）。16GB 1枚では約1/4がCPUへオフロードされますが、RTX 5080単体で73.7 tok/s、RTX 5060 Ti単体で65.6 tok/sと、8Kコンテキストでの生成スループットは2枚構成の半分弱が残ります。短〜中程度のコード生成なら16GB 1枚でも実用的な速度なので、より軽快さを求めるなら16GBに全層常駐できるモデルを、qwen3-coder:30bの速度が欲しいなら合計32GB級の構成を、という選び方になります。精度の最上位を求めるならクラウドのフロンティア（Claude Opus 5・Sonnet 5やGPT-5.6 Sol）、コスト・プライバシー・手元での速さを取るならローカルのqwen3-coder:30b、という住み分けが軸になります。

よくある質問

Q. VRAM 16GB 1枚で足りますか？

Q4_K_M版を全層GPUに常駐させるには足りません。num_ctx=8192 での実測VRAM配置量が18.38GiBで、16GBを超えるためです（配布ファイルは約19GB）。ただし「使えない」わけではありません。num_ctx=8192 で揃えて測ると、RTX 5080単体（16GB）はGPU常駐率74%＝約1/4がCPUへオフロードされて73.7 tok/s、RTX 5060 Ti 16GB単体は常駐率75%で65.6 tok/sでした（2026-07-30計測）。2枚構成の半分弱ですが、8Kコンテキストでの生成速度としては1枚でも実用的です。159.4 tok/sを出すにはRTX 5080＋5060 Tiのような合計32GB（2枚）が実測です（24GB単体GPUは容量的には目安ですが速度は未計測）。16GB 1枚でもオフロードを許容すれば8Kコンテキストでは実用的な速度が出るので、まず1枚で試してから増設を判断する進め方もできます。より軽快に回したいなら、16GBに全層常駐できるモデルが現実的です。

Q. Claude Codeの代わりになりますか？

用途次第です。Claude Codeというツール自体はローカルモデルでも使えます。Anthropic提供のClaudeモデルを使う通常構成はクラウド推論で、精度と手軽さで優位です。一方、OllamaのAnthropic互換APIへ ANTHROPIC_BASE_URL を向ければ、qwen3-coder:30bをClaude Codeから動かし、コードを外部の推論APIへ送らない構成も取れます。両者は競合というより使い分けです。

Q. RTX 5060 Ti 1枚でも実用的ですか？

qwen3-coder:30bは16GB超のため5060 Ti 1枚ではCPUオフロードが入りますが、num_ctx=8192 で測ると65.6 tok/sでした。RTX 5080単体の73.7 tok/sと大きくは変わりません。2枚構成の半分弱にはなるので、速度を優先するなら、RTX 5080などと組み合わせた2枚構成（合計32GB）でフル常駐させる使い方が向きます。1枚で完結させたいなら、16GBに全層常駐できるコーディング向けモデルを選ぶと軽快です。