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

qwen3-coder:30bとは、コーディング用途に特化したオープンソースのローカルLLMである。

ローカルでコード生成・補完・エージェント用途を回すなら、qwen3-coder:30bは現状もっとも速い選択肢のひとつです。当サイトの検証環境（RTX 5080＋RTX 5060 Ti・Oculink・think=false・3回中央値）では145.3 tok/sを記録し、dense型の14Bモデルより3倍以上速く動きました。ただし速さには前提があります。30B-A3BのMoEは、1トークンごとに動く部分（アクティブ）こそ3B級ですが、重み全体は30B級ぶんを保持するため、VRAMは16GBに収まりません。当サイトの計測では両GPU合算で約19.7GiBを使い、フル速度の145 tok/sはRTX 5080＋RTX 5060 Ti（合計32GB）に2枚またがってフル常駐させて初めて出た数字です。16GBの1枚に載せると約3割がCPUにオフロードされ、15 tok/s前後まで落ちます。

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

この記事の要点

・qwen3-coder:30bは30B-A3BのMoE。速さはアクティブ3B級ゆえだが、重み全体は30B級ぶん保持するためVRAMは16GB超（当サイト計測で両GPU合算約19.7GiB）。フル速度は合計32GB（2枚）か24GB級GPUが目安
・当サイトの検証環境（RTX 5080＋RTX 5060 Ti・Oculink・think=false・合計32GB）で145.3 tok/sを記録し、同条件のdense型32Bモデル（26.0 tok/s）の5倍以上の速度
・16GB 1枚（RTX 5080やRTX 5060 Ti 16GB単体）では約3割がCPUにオフロードされ15 tok/s前後まで落ちる。フル速度には2枚構成（合計32GB）か24GB級GPUが目安

qwen3-coder:30bとは｜ローカルで動くコーディングLLMの位置づけ
検証環境とテスト条件｜実測値の前提を明示
1. 計測した項目と単位の扱い
2. 計測条件の固定
実測スループット比較｜qwen3-coder:30bは他モデルとどれだけ違うか
1. 16GB 1枚では収まらない｜2枚（合計32GB）で初めてフル速度
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トークンを生成するたびに計算に使う部分はずっと小さい。だから総量の割に軽く、速く動きます。当サイトの検証でqwen3-coder:30bが145.3 tok/sを出し、同じ環境のdense型32B（26.0 tok/s）の5倍以上で走った事実が、この「動く部分が小さい」性質を裏づけています。

ただし速さと裏腹に、VRAMは軽くありません。MoEは計算こそアクティブな一部の専門家だけで済みますが、どの専門家が呼ばれるかは入力次第なので、重み全体（30B級）はメモリに保持する必要があります。当サイトの計測では、qwen3-coder:30bの両GPU合算VRAM使用量は約19.7GiB（nvidia-smi memory.used 基準）に達し、16GBの1枚には収まりませんでした。2枚（合計32GB）に分散して初めてフル常駐しています。「アクティブが3B級だからVRAMも3B級」ではありません。速いのはMoEのおかげ、でもメモリは総パラメータぶん要る、という関係です。

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

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

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

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

精度ではクラウドのフロンティアが上｜公開コーディングベンチで見る位置づけ

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

モデル	提供形態	公開ベンチでの位置づけ（2026年6月時点）
qwen3-coder:30b（本記事の主役）	ローカル（30B-A3B）	SWE-bench Verifiedで約50%前後とされる公開再現値がある。ただしOpenHandsなどのscaffold・試行回数・turn数で変動する
Claude Sonnet 4.6	クラウドAPI（Claude Code）	Anthropic公式でSWE-bench Verified 80.2%（10試行平均・prompt modificationあり）
Claude Opus 4.8	クラウドAPI（Claude Code）	Anthropic公式発表ではOpus 4.7からの改善とClaude Code向け能力向上を説明。SWE-bench系の詳細値はOpus 4.8 System Cardを参照
GPT-5.5	OpenAIのクラウドモデル（Codex・ChatGPT向け）	OpenAI公式ではTerminal-Bench 2.0で82.7%、SWE-Bench Proで58.6%。SWE-bench Verifiedの80%台として扱うには第三者集計の出典が別途必要

ローカルで動く qwen3-coder:30b の約50%前後という公開再現値は、scaffoldや試行条件に左右されるものの、30B級のローカルモデルとしては健闘している水準です。ただしコード精度の最上位は、Claude Opus 4.8・Sonnet 4.6（Claude Code）や GPT-5.5（Codexの基盤）といったクラウドのフロンティアにあります。これらは SWE-bench Verified・SWE-Bench Pro・Terminal-Bench などの公開コーディング系ベンチで高い値を出していますが、ベンチごとに対象タスクやscaffoldが違うため、数値を横並びで単純比較するのではなく、「ローカル高速モデルとクラウド高精度モデルの使い分け」を見る材料として扱うのが安全です。なお、これらは各社発表値や第三者集計の公開ベンチであって当サイトの計測ではありません。

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

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

数値の意味を正しく読み取れるよう、計測の前提を先に示します。この記事の実測値は、すべて当サイトの検証環境（RTX 5080＋RTX 5060 Ti（Oculink）構成、もしくはRTX 5060 Ti 16GBを含む構成）で測ったものです。CPUやRAM、電源を含む構成の全体像は専用の検証環境ページにまとめてあります。数値の意味に関わるのは、どのGPU・どの設定で測ったかという測定固有の条件です。

GPUはRTX 5080（VRAM 16GB）とRTX 5060 Ti（VRAM 16GB）の2枚で、合計32GB。16GBを超えるモデルは2枚にまたがってロードされるため、その場合のVRAM使用量は両GPU合算のnvidia-smi memory.usedで示します。ソフトウェアはOllama 0.30.7、NVIDIAドライバ610.47、計測日は2026年6月18日です。

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

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

ひとつは「GPU全体の使用量」。これはnvidia-smiが報告するmemory.usedの値で、デスクトップ表示など他の常駐分も含んだGPU全体の数字です。単位はMiBで、GiBへの換算は1024で割ります。この記事で「VRAM全体使用量」と書いたものはこちらを指します。もうひとつは「モデル単体のロード増分」で、モデルを読み込む前後の差分。両者は別物なので、本文ではどちらの値かを明示します。

計測条件の固定

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

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

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

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

qwen3-coder:30bの速さは、同じ環境で測った他のモデルと並べると一目でわかります。下表は当サイトの検証環境（think=false、3回計測の中央値）で記録した、コーディングに使われやすいモデルと比較対象を整理したものです。tok/sは2枚構成（合計32GB）での実測です。VRAMの列はGPU全体使用量（nvidia-smi memory.used 基準）で、16GB超のモデルは両GPU合算値、16GBに収まるモデルは1枚での値を示します。

モデル	構造	tokens/sec（2枚構成）	VRAM使用量（16GB単体可否）	用途適性
qwen3-coder:30b	MoE（30B-A3B・動く部分は3B級）	145.3	約19.7GiB（合算・16GB超）	コード補完・生成の主力
Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）	MoE	122.4	約24.1GiB（合算・16GB超）	汎用＋コーディング
Codestral 22B（Ollama: codestral:22b）	dense（コード特化）	40.2	約14.7GiB（16GB単体可）	コード生成（速度は控えめ）
Qwen3 14B（Ollama: qwen3:14b）	dense	43.6	約10.9GiB（16GB単体可）	汎用中型
Qwen3 32B（Ollama: qwen3:32b）	dense	26.0	約22.7GiB（合算・16GB超）	汎用・品質重視
Gemma 4 12B（Ollama: gemma4:12b）	dense	44.5	約9.4GiB（16GB単体可）	汎用中型

上表は2枚構成（合計32GB）での実測です。同じ2枚構成で比べると、qwen3-coder:30bの145.3 tok/sは群を抜き、dense型32BのQwen3 32B（Ollama: qwen3:32b）（26.0 tok/s）の5倍以上、Codestral 22B（Ollama: codestral:22b）（40.2 tok/s）やQwen3 14B（Ollama: qwen3:14b）（43.6 tok/s）と比べても3倍以上の速度。総パラメータの規模ではqwen3-coder:30bが上にもかかわらず、速度では逆転しています。これがMoEとdenseの構造差です。なお、16GBに収まるモデル（Codestral・Qwen3 14B・Gemma 4 12B）は1枚で動かすほうが速くなります（Oculink越しの転送待ちがないため）。一方qwen3-coder:30bなど16GB超のモデルは、16GB 1枚に載せるとCPUオフロードで大きく落ちます（後述）。

注目したいのが、VRAM占有と速度が必ずしも比例しない点。Codestral 22B（Ollama: codestral:22b）はVRAM使用量が約14.7GiB（RTX 5080単体・16GBにフル常駐）とqwen3-coder:30bの合算約19.7GiBより小さく、1枚に収まります。それでも速度は2枚構成のqwen3-coder:30b（145.3 tok/s）の3分の1以下（上表の2枚構成で40.2 tok/s）。VRAMの占有量だけでモデルの「軽さ」や速さは測れません。ただし「1枚に収まるか」は速度とは別問題で、qwen3-coder:30bはVRAMが大きいぶん2枚（または24GB級）を要求します。

16GB 1枚では収まらない｜2枚（合計32GB）で初めてフル速度

ここが選定で一番重要な点です。qwen3-coder:30bの重みは30B級あり、当サイトの計測では両GPU合算で約19.7GiBのVRAMを使いました。つまり16GBの1枚には収まりません。145.3 tok/sという速度は、RTX 5080＋RTX 5060 Ti（合計32GB）に2枚またがってフル常駐させたときの値です。

16GBのGPU1枚に載せるとどうなるか。当サイトでRTX 5080単体（16GB）に載せたところ、重みが載りきらず約3割がCPUにオフロードされ、速度は15 tok/s前後まで落ちました（2枚フル常駐の約1/10）。CPUオフロードはVRAMの足りない分をシステムRAMで肩代わりする仕組みで、動きはしますが大幅に遅くなります。さらにコンテキスト長を伸ばせばKVキャッシュ分でVRAM消費が増え、必要量はさらに膨らみます。「16GB 1枚で145 tok/s」は出ません。フル常駐には2枚構成（合計32GB）または24GB級以上のGPUが目安です。ただし145.3 tok/sはRTX 5080＋RTX 5060 Tiの2枚構成での実測値で、24GB単体GPUで同じ速度になるとは限りません。

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

RTX 5060 Ti 16GBを1枚で使う場合も、qwen3-coder:30bは16GB超のためCPUオフロードが発生します。RTX 5060 TiはCUDAコア数（4608基）もメモリ帯域もRTX 5080（10752基）より小さいため、オフロードした状態の速度はRTX 5080単体（約15 tok/s）よりさらに落ちると見るのが妥当です（当サイトでは5060 Ti単体でのこのモデルの速度は未計測のため数値は控えます）。RTX 5060 Tiでqwen3-coder:30bをフル速度で使いたいなら、RTX 5080などと組み合わせた2枚構成にして合計32GBで載せるのが現実的です。1枚で軽快に回したいなら、16GBに収まる14B級までのコーディング向けモデルを選ぶほうが速度は出ます（16GBカードの一例はRTX 5060 Ti 16GB）。

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

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

リアルタイム補完を重視するなら
RTX 5080を含む合計32GB級（2枚構成）が向きます。当サイトの検証環境（RTX 5080＋RTX 5060 Ti（Oculink）構成・think=false・3回中央値）ではqwen3-coder:30bが145.3 tok/sを記録しており、入力に対して返答がすぐ追いついてくる感覚。補完は最初の一文字までの間が体感を決めるため、フル常駐できる構成でスループットを確保するのが素直な選択です。

ローカルエージェント・長文生成を回すなら
こちらも合計32GB級（2枚構成）。長いリファクタや複数ファイルの読み書きでは生成量が増え、持続スループットがそのまま待ち時間に効きます。コンテキストを広げるとKVキャッシュ分でVRAM消費も増えるため、フル常駐の余裕がある構成ほど安定します。

予算を最優先するなら（1枚構成）
qwen3-coder:30bは16GB 1枚には収まらずオフロードで遅くなるため、1枚構成ならむしろ16GBに収まる14B級までのコーディング向けモデルが現実的です。qwen3-coder:30bの速度が欲しいなら、16GBを2枚そろえて合計32GBにするか、24GB級GPUを1枚用意する方向になります。

Claude CodeやCopilotがメインなら
これらはクラウドのAPIで推論するため、ローカル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目安: 両GPU合算約19.7GiB（16GB超）。フル常駐は合計32GB（2枚）が実測、24GB級は容量的に目安。16GB 1枚は約3割CPUオフロードで約15 tok/s
参考速度: RTX 5080＋RTX 5060 Ti（Oculink・合計32GB）で145.3 tok/s（2026-06-18計測）
対応GPU例: 合計32GB（RTX 5080＋RTX 5060 Ti 等の2枚）/ 24GB級GPU。16GB 1枚は不足

まとめ

qwen3-coder:30bは、当サイトの検証環境（RTX 5080＋RTX 5060 Ti）で145.3 tok/sを記録した、当サイト検証では最速級のローカルコーディングLLMです。ただし速いのはMoE（30B-A3B）のおかげで、VRAMは重み全体ぶん必要なため16GBの1枚には収まりません。フル速度を出すにはRTX 5080＋RTX 5060 Ti のような合計32GB（2枚）か、24GB級GPUが目安。16GB 1枚に載せると約3割がCPUにオフロードされ15 tok/s前後まで落ちます。手元が16GB 1枚なら14B級までのモデルを、qwen3-coder:30bの速度が欲しいなら合計32GB級の構成を、という選び方になります。精度の最上位を求めるならクラウドのフロンティア（Claude Opus 4.8・Sonnet 4.6やGPT-5.5）、コスト・プライバシー・手元での速さを取るならローカルのqwen3-coder:30b、という住み分けが軸になります。

よくある質問

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

フル速度には足りません。qwen3-coder:30bの重みは両GPU合算で約19.7GiBを使い、16GBの1枚には収まりません。当サイトでRTX 5080単体（16GB）に載せたところ約3割がCPUにオフロードされ、速度は15 tok/s前後（2枚フル常駐の約1/10）まで落ちました。145 tok/sを出すにはRTX 5080＋5060 Tiのような合計32GB（2枚）が実測です（24GB単体GPUは容量的には目安ですが速度は未計測）。16GB 1枚で軽快に回したいなら、16GBに収まる14B級までのモデルが現実的です。

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

用途次第です。Claude CodeはクラウドAPIで動くため精度と手軽さで優位ですが、コードを外部の推論APIへ送りたくない場面ではローカルのqwen3-coder:30bが選択肢になります。両者は競合というより使い分けです。

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

qwen3-coder:30bは16GB超のため、5060 Ti 1枚ではCPUオフロードが入り速度は大きく落ちます（RTX 5080単体でも約15 tok/s）。5060 Tiを活かすなら、RTX 5080などと組み合わせた2枚構成（合計32GB）でフル常駐させる使い方が向きます。1枚で完結させたいなら、16GBに収まる14B級までのコーディング向けモデルを選ぶと軽快です。