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級ぶんを保持します。本記事が扱うのはOllamaの標準タグ qwen3-coder:30b（Q4_K_M量子化・配布ファイル約19GB）で、以下のVRAMと速度の話はすべてこのタグが対象です。この構成では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とは｜ローカルで動くコーディング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）に対しqwen3-coder:30bが145.3 tok/sと5倍以上で走ったのは、アクティブパラメータが小さいMoEの特性と整合する結果です（速度差には量子化方式・メモリ帯域・カーネル実装・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をエージェントに解かせ、テストが通るパッチを書けるかを見る代表的な指標です。

ローカルで動く 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＋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日、num_ctx=8192 に固定した qwen3-coder:30b の再計測と単体GPUの測定が2026年7月30日です（7月30日の測定時もOllama・ドライバ・モデルdigestは6月18日と同一）。7月24日にも測定していますが、Ollamaの既定コンテキスト長のまま実行したため構成間で条件がずれており、比較値には採用していません。コンテキスト長は3構成すべてで num_ctx=8192 に固定し、Ollamaの /api/ps が返す context_length が実際に8192だったことを各測定で確認しています。Ollamaの既定コンテキスト長は利用可能なVRAM量に応じて変わるため、指定せずに測ると2枚構成と1枚構成で条件がずれます。実際、既定のまま測っていた7月24日時点ではRTX 5060 Ti単体が14.3 tok/sという値になっていましたが、8192に揃えて測り直すと65.6 tok/sでした。構成をまたいで速度を比べるなら、コンテキスト長を固定して測る必要があります。

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

計測したのは主に生成スループット（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回計測し、その中央値を採用（生成トークン数は 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回計測の中央値）で記録した、コーディングに使われやすいモデルと比較対象を整理したものです。tok/sは2枚構成（合計32GB）での実測です。VRAMの列はGPU全体使用量（nvidia-smi memory.used 基準）で、16GB超のモデルは両GPU合算値、16GBに収まるモデルは1枚での値を示します。

上表は2枚構成（合計32GB）で、2026年6月18日に同一条件・同一日で並べた実測です。ただし当時は num_ctx を明示指定する手段を用意しておらず、全モデルを同じ32GB構成のOllama既定コンテキストで測っています。7月30日に num_ctx=8192 で揃えた単体GPU比較とは測定系列が異なる点に注意してください（主役の qwen3-coder:30b だけは最新値は num_ctx=8192 に固定して2026年7月30日に再計測した159.4 tok/s。表は比較条件をそろえるため6月18日の値で統一しています）。同じ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単体・GPU常駐率100%）とqwen3-coder:30bの合算値より小さく、1枚に収まります。それでも速度は2枚構成のqwen3-coder:30b（145.3 tok/s）の3分の1以下（上表の2枚構成で40.2 tok/s）。VRAMの占有量だけでモデルの「軽さ」や速さは測れません。ただし「1枚に収まるか」は速度とは別問題で、qwen3-coder:30bはVRAMが大きいぶん、16GB 1枚では全層を載せきれません（当サイトが100% GPU常駐を確認したのは16GB×2の構成。num_ctx=8192 での配置量18.38GiBから見れば24GB単体も容量上の候補ですが、そちらは未計測です）。

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

ここが選定で一番重要な点です。Ollama標準タグの配布ファイルは約19GBあり、16GBの1枚には収まりません。2枚構成での常駐時、Ollamaの /api/ps が返すモデル単体のVRAM配置量は18.38GiBで、モデル全体のサイズ（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に収まる14B級までのコーディング向けモデルを選ぶほうが速度は出ます（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級までのコーディング向けモデルが現実的です。qwen3-coder:30bの速度が欲しいなら、16GBを2枚そろえて合計32GBにするか、24GB級GPUを1枚用意する方向になります。

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

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

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

常駐の管理にはkeep_aliveを使います。0 を指定すると実行後にアンロードされ、未指定時は通常5分保持されます。長く保持したい場合は 5m などの時間指定を使います。負の値（-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枚でも実用的な速度なので、より軽快さを求めるなら14B級までのモデルを、qwen3-coder:30bの速度が欲しいなら合計32GB級の構成を、という選び方になります。精度の最上位を求めるならクラウドのフロンティア（Claude Opus 5・Sonnet 5やGPT-5.6 Sol）、コスト・プライバシー・手元での速さを取るならローカルのqwen3-coder:30b、という住み分けが軸になります。

よくある質問

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

Q4_K_M版を全層GPUに常駐させるには足りません（配布ファイルが約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に収まる14B級までのモデルが現実的です。

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

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

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に収まる14B級までのコーディング向けモデルを選ぶと軽快です。

関連記事

• コーディング用ローカルLLMはRTX 5080でどれが最速か（横断比較）
• AIコーディング向けローカルLLMの必要スペック
• 16GBであふれるMoEを2枚目GPUで動かす実測
• 量子化（Q4_K_M・Q8_0・FP16）のVRAMと速度を実測比較
• 27B・32Bが16GBでどこまで動くか（よくある疑問7選）
• Ollamaを常駐・並列運用する実運用設定

参考資料

• Ollama 公式: モデルライブラリ（正確なタグ確認用）
• OpenAI 公式: GPT-5.6 の発表
• GitHub Docs: Copilot CLI で自分のLLMを使う（BYOK）
• Hugging Face: Qwen 公式リポジトリ
• Hugging Face: Qwen3-Coder-30B-A3B-Instruct モデルカード
• Ollama: qwen3-coder タグページ（Q4_K_M・配布容量）
• Ollama Docs: Context length（既定コンテキスト長の扱い）