Qwen3.6-27Bとは？Dense 27BコーディングLLMをローカルGPUで動かすガイド

Qwen3.6-27Bは、Alibabaのマルチモーダル（テキスト・画像・動画対応）Dense 27BオープンウェイトLLMで、とくにコーディング性能で注目を集めている。前世代フラッグシップのQwen3.5-397B-A17B（MoE型・総パラメータ397B・アクティブ17B）を主要なコーディングベンチマークで上回ったとされ、しかもDense 27Bというコンパクトな構成にまとまっている。

気になるのは「27Bクラスは自宅のGPUで動かせるのか」という点である。16GB VRAM帯のコンシューマGPUでもコンテキスト次第で射程に入りつつあり（Q4_K_M本体は約16.8GB。実行にはこれにKVキャッシュやバッファ分のメモリが加わる）、その前提を整理していく。

Qwen3.6-27Bの概要｜コーディングに強いマルチモーダルDense 27B LLM

Qwen3.6-27Bは、AlibabaのオープンウェイトのマルチモーダルLLM（テキスト・画像・動画入力に対応し、262Kトークンのネイティブ文脈長を持つ）である。注目される理由はシンプルで、前世代のMoE型フラッグシップQwen3.5-397B-A17Bをコーディングベンチマークで上回ったとAlibabaが公式に主張しているからだ。モデルカードと評価指標はQwen 公式ブログで公開されており、量子化バリエーション一覧の最新状況はHugging Face Qwen 公式リポジトリから確認できる。

Dense 27BとMoE 397Bの違い

Qwen3.5-397B-A17Bは、総パラメータ397B・アクティブ17BのMixture of Experts（MoE）構成である。推論時に動くのは17B相当だが、モデル全体をメモリに載せる必要があるため、ストレージ・メモリへの負担が非常に大きいという欠点があった。一方のQwen3.6-27Bは、27BパラメータすべてがDense構成。モデルの総サイズが桁違いに小さく、ロード時のハードルが下がっている。

Denseモデルはアーキテクチャがシンプルで、推論エンジン（llama.cpp 公式リポジトリ等）のサポートも幅広い。MoE構成は推論時のexpert routingに専用の最適化が必要になるが、Dense版はMoEのexpert routingを持たない分、推論ランタイム側の対応が取りやすい傾向がある（ただしQwen3.6-27B自体はGated DeltaNetとGated Attentionを組み合わせた構成で、対応状況はランタイムの実装・版に依存する）。個人ユーザーがローカルで触る前提なら、同等性能で済むならDenseの方が扱いやすい構図である。

コーディング用途での位置付け

Alibabaの公式発表によると、Qwen3.6-27BはSWE-bench系・エージェンティックコーディング系の主要ベンチマークで前世代フラッグシップを上回るとされる。SWE-benchはGitHubの実リポジトリから収集された課題集で、コーディングLLMの実用評価指標として定着している（SWE-bench 公式）。「27Bクラスでフラッグシップ級」という主張は、ローカルLLMユーザーにとって大きなトピックといってよい。

もっとも、ベンチマーク値はあくまで公式主張ベース。実際の使用感がどこまで追いついているかは、コミュニティでの検証で見えてくる。エージェント連携時の指示追従性、長いコンテキストでの一貫性、関数呼び出し精度など、ベンチマーク単独では測れない要素が残っている。ベンチマークの評価ハーネスと実際の編集ワークフローは性質が異なるため、SWE-benchの強さがそのまま日常の編集精度に一致するとは限らず、最終的には自分の環境とタスクで確認するしかない領域である。同じくローカルで動くコーディング特化モデルの実測はqwen3-coder:30bの検証でも取り上げている。

ローカル実行の前提｜16GB VRAM帯で27Bクラスを動かす

「27Bと聞くと重そう」と思うかもしれない。実際、公式配布重みはBF16（16bit精度）で、無量子化のままロードするには一般的なコンシューマGPUのVRAMでは足りない計算になる。16bitは1パラメータ2バイトなので、27Bモデルは単純計算で約54GBの重みデータを抱える。コンシューマGPUの上位機種であるRTX 5090でも32GBで、単体では無量子化版を載せ切れない。ここで効いてくるのが量子化という手法である。

量子化の考え方（Q4_K_M系がなぜ主流か）

量子化とは、モデルの重みを低精度（4bit、5bit等）に圧縮してメモリ使用量を削減する技術である。精度を下げる以上、品質には多少の劣化が伴うが、Q4_K_M（4bit量子化の一種）あたりが「品質とメモリのバランスが良い」として広く採用されている。GGUFフォーマットや量子化の手順はllama.cpp公式リポジトリで確認できる。各量子化方式の精度・サイズと16GB VRAMでの選び分けは量子化フォーマットの選び方で詳しく比較している。

Qwen3.6-27BもUnslothがGGUF形式のQ4_K_M量子化版を配布しており、4bit量子化済みモデルは16GB VRAM帯のGPUでも、重みだけで約16.8GB（Unsloth GGUF）あり、KVキャッシュ込みでは16GB単独では収まらない場合がある。Unsloth公式は、Qwen3.6-27Bが18GB RAM構成で動作すると案内している（必要容量や速度は量子化方式・GPUへの配置割合・コンテキスト長・ランタイム設定で変わる）。配布物はHugging Face Unsloth プロフィールで確認できる。Denseの27Bが、量子化を挟むことで「RTX 5080クラスならコンテキストを切り詰めて動かせる選択肢」に近づいている、というのが現時点の状況である。

推奨されるGPU VRAM帯と構成例

当サイトの検証環境（RTX 5080 VRAM 16GB + RTX 5060 Ti VRAM 16GB / i7-14700F / RAM 96GB）で、Ollama配布のqwen3.6:27b（4bit量子化・ダウンロードサイズ約17GB）を実際にロードして生成速度を計測した。結果は下表のとおりである。

ポイントは、RTX 5080の公称16GB VRAMのうち、監視ツール上で認識された容量は約15.9GiBで、表示・ドライバ予約等を除いて実際に利用できたのは約14.1GiBだった点である。Q4_K_M本体は約16.8GB（≒15.7GiB）で、これにKVキャッシュやランタイムのバッファが加わるため、この構成では全量がGPUに載り切らず、ollama ps のPROCESSOR表示で約83%がGPU・約17%がCPUという配置になった（あくまで配置比率で、ファイルの厳密なバイト割合ではない）。本構成では、CPUオフロードを伴うRTX 5080単体のほうが、全量GPU配置となったデュアル構成より生成速度・プロンプト処理速度ともに低かった。ただしこの差にはCPUオフロードだけでなく、GPU数・モデルの分割方法・GPU間通信・使える計算資源の違いも含まれるため、各要因の寄与は分離していない。とくにプロンプト処理（入力の読み込み）の差は大きく（表参照）、長いコードや長文脈を渡すほど体感差として効いてくる。全量をGPUに載せて回したいなら、余裕のあるVRAMが要る（実測では16GB×2のデュアルで全レイヤーがGPUに載った）。同じRTX 5080＋RTX 5060 Tiの構成で16GBであふれるモデルを2枚目のGPUでオフロード解消し約1.9倍に伸ばした実測も別途取り上げている。

dense 27B と MoE 35B-A3B の使い分け（実行速度の観点）

実行速度で押さえておきたいのが、同じ検証環境で姉妹モデルのMoE版・Qwen3.6-35B-A3B（総パラメータ35B・推論時の稼働3B）を測ると、RTX 5080単体で約68 tokens/sec、デュアルで約124 tokens/secと、本記事の実測範囲では dense 27B より生成速度が高かった点だ。35B-A3B側の数値は同一検証環境・同方式（think無効・短文生成）の測定だが、両者で完全に条件が揃わない場合は参考値として見てほしい。MoE版が速いのは推論時に動くのが3B相当にとどまる仕様と整合的だが、本測定ではactive parameter数・メモリ配置・レイヤー構成・GPU間通信といった要因の寄与を分離してはいない。いずれにせよ「モデルの総サイズが小さい＝速い」とは限らない。一方、回答品質・一貫性・長文脈での挙動は本記事では同条件で評価していないため、品質面の優劣は判断材料に含めていない。速度重視ならMoE版、量子化後の必要VRAMの小ささを取るならdense版、という切り分けが実行要件の観点からの目安になる。両者を品質・AI用途の面から突き合わせた比較はQwen3.6 35B-A3B vs 27B の比較記事で扱っている。

ソフトウェア環境｜llama.cppとUnslothの位置付け

モデルが手に入っても、動かす側の環境が揃っていなければ意味がない。Qwen3.6-27Bをローカルで動かす際の定番構成は、llama.cppベースのサーバーとUnsloth配布のGGUFという組み合わせである。

llama.cpp系サーバーでの起動の流れ

llama.cppプロジェクトに含まれるllama-serverは、OpenAI互換APIを立てられる推論サーバーである。インストールはbrew install llama.cpp（macOS系）またはGitHubリリースからのバイナリ取得で済む。Linux/Windows向けのビルド手順はllama.cpp build ドキュメントに集約されている。

起動の流れをざっくり追うと、-hf unsloth/Qwen3.6-27B-GGUF:Q4_K_MのようにHuggingFace上のモデル指定を渡すだけで、初回はキャッシュディレクトリにモデルが自動ダウンロードされ、2回目以降はローカルキャッシュから即座にロードされる仕組みである。コンテキスト長の指定（-c）、JinjaテンプレートやreasoningモードのON/OFFなど、細かい挙動はフラグで制御できる。

典型的な起動コマンドは以下の形になる。

llama-server -hf unsloth/Qwen3.6-27B-GGUF:Q4_K_M -c 16384 --port 8080 -ngl all

-ngl allはGPUに乗せるレイヤー数の指定で、all（または十分大きな数値）を渡すと可能な限り全レイヤーをGPUに載せる動きになる。VRAMが足りない場合は数値を下げてCPU側にオフロードする調整が効く。コマンド一発でOpenAI互換APIサーバーが立ち上がり、そこにClineやAiderといったエージェントコーディングツールをぶら下げることで、「ローカルLLMでコーディング」というワークフローが成立する。これが現実的な構成である。

Unsloth配布のGGUFを使う意味

オリジナルのモデル重みをそのまま使うのではなく、Unsloth配布のGGUFを使う理由は主に2つ。ひとつは量子化バリエーションの入手性である。UnslothのリポジトリではQ4_K_Mをはじめ複数のGGUF量子化とmmprojがまとめて配布されており、llama.cppから直接取得しやすい。もうひとつはllama.cppとの互換性の取りやすさ。主要なllama.cpp/Ollamaでの利用を想定して用意されているため、対応版で使えば「落としてきたらそのまま動かない」というトラブルが起きにくい（互換性は使用する版・配布物で確認する）。

llama.cppとUnsloth GGUFは、ローカル実行で広く使われている構成の一つである。Qwen3.6-27BもこのエコシステムにQ4_K_M等のバリエーションで乗っているため、既存のワークフローをほぼそのまま流用できる。Ollama モデルライブラリからも量子化版が配布されており、qwen3.6:27b タグでローカル推論に使える。モデル自体はテキスト・画像・動画に対応するが、ランタイム側の入力対応は別で、Ollamaの現行タグはテキスト・画像対応として登録されている。視覚エンコーダの mmproj を別ファイルで持つ配布物もあるため、画像・動画入力まで使う場合は、使用するランタイムの版と配布物の対応状況を確認するのが無難である。

トラブルシュート｜ローカル運用で詰まりやすいポイント

27Bクラスを16GB VRAMで動かす境界線では、いくつか典型的なトラブルが報告されている。事前に把握しておくと初動が早い。

VRAM不足によるロード失敗

Q4_K_M版でも、コンテキスト長を長めに取るとKVキャッシュ分でVRAMが膨らむ。16GB環境でコンテキスト長を大きく取ると、KVキャッシュ等の増加でロード時や推論中にCUDA out-of-memoryになる可能性がある。本記事の検証では-c 8192で計測したが、安定するコンテキスト長は環境依存である。OOMが出たらコンテキスト長や並列数を下げ、余裕を見ながら広げるのが無難である。コンテキスト長を伸ばしたときの16GBでのKVキャッシュ膨張とあふれない設定の実測も参考になる。FlashAttention（-fa）はAttention計算時のメモリ効率を高め得るが、KVキャッシュそのものを量子化・圧縮する設定ではない。KV容量を直接減らすなら、対応バックエンドで --cache-type-k / --cache-type-v によるKV量子化を検討する（品質・互換性は個別確認）。

初回ロードが遅い

Q4_K_M版でも約16.8GB（Unsloth GGUF）のファイルサイズがある。初回はHugging Faceから丸ごとダウンロードするため、回線によっては数十分かかる。ダウンロード後の再ロードは、モデルデータがOSのページキャッシュに残っていれば短縮される場合がある。ただし所要時間は空きRAM・mmap設定・ストレージ速度・他プロセスの使用状況で変わり、必ず数秒になるわけではない。HDDではSSDよりロード時間が長くなりやすいため、NVMe SSDの空き容量を確保しておくのが望ましい。

コンテキスト長の指定ミス

モデルカードに記載された最大コンテキスト長を超える-cを指定すると、起動時にエラーになるかメモリ不足で落ちる。Qwen3.6-27Bのネイティブ文脈長は262,144トークンで、モデルカード上はYaRN等で約1,010,000トークンまで拡張可とされるが、拡張には対応ランタイム・追加メモリ・長文品質の個別確認が要る。量子化版や16GB VRAM環境では実メモリに収まる範囲を確認してから指定するのが安全である。公称の262,144トークンを超える拡張は、Qwen公式が示すYaRN一式の設定を対応ランタイムへ与える必要があり、llama.cpp側のQwen3.6対応状況と全引数を確認する（--rope-scaling単独で公式拡張を再現できるとは限らない）。長文時の精度はトレードオフになり得る。

エージェントツール連携での詰まり

ClineやAiderなどはOpenAI互換エンドポイントを利用できる。一方、Claude CodeをOllamaにつなぐ場合はOllamaのAnthropic互換APIを使うなど、接続方式はツールやプロバイダ設定によって異なる。llama-serverの既定エンドポイント（http://localhost:8080/v1）を使う場合、ストリーミング応答やtool callingの仕様差で挙動がズレることがある。問題が出たらモデルのチャットテンプレート（--chat-template）と推論側のJinjaテンプレート設定を確認するのが基本ルートである。

クラウドとローカルの選び方｜コーディングLLMの現在地

興味深いのが、Qwen3.6-27Bとクラウド側の動きが並走している点である。同時期にAnthropicのClaude Opus 4.8が一般提供されており、こちらも「難しいコーディング作業への強さ」を押し出している。プロンプト追従性の向上や長時間タスクの一貫性強化など、クラウド側の上位モデルも地味にアップデートを重ねている。

読者が直面する選択軸はこうなる。精度・プロンプト追従・長文一貫性を重視するなら、エージェンティックコーディングに強いClaude Opus 4.8のようなクラウドモデル（本記事でQwen3.6-27Bとの同条件の品質比較は行っていないため、優劣は結論づけない）。一方、プライバシー・ランニングコスト・オフライン性・APIレート制限からの解放を優先するなら、ローカルでQwen3.6-27Bクラスを回す、という構図である。

Claude Opus 4.8のようなクラウドAPIは従量課金で、最新の単価はAnthropic公式の価格ページで確認できる。日常的に大量のコード生成・レビューを回すなら、月額で見ると無視できない金額になり得る。一方、ローカル27Bクラスは初期のGPU・RAM等の投資と電力・保守はかかるものの、トークン従量課金が発生しないため、既存機材を活かせて生成量が多いワークロードほど限界費用の面でメリットが出やすい。

「ローカル27Bがフラッグシップに迫る」という意味は、単に性能面の話ではなく、コスト構造を前提にした選択肢が現実的になっているということである。品質差が縮まるほど、「じゃあローカルで十分」と判断する局面が増えていくはずだ。実運用では「機密性の高いコードはローカル、難所だけクラウドAPIに投げる」というハイブリッドが落としどころになりやすい。

今後の展望｜27BクラスDenseが当たり前になる

Qwen3.6-27Bが示す方向性は明確である。「MoE型の巨大フラッグシップを、Dense型の中規模モデルで置き換える」という流れが、コーディング用途で現実味を帯びている。

3〜12か月先の観測ポイントは3つある。

ひとつは他社の追従である。Meta・Google・DeepSeek等のオープンウェイト勢が、似たサイズ帯でコーディング特化モデルを出してくるかどうか。ふたつめはツールチェーン側の最適化。llama.cppやOllamaが27Bクラスを想定したメモリ効率改善を入れてくるか。みっつめはエージェントツールとの統合。Cline、Aider、Claude Code等のエージェントコーディングツールがローカルLLMをバックエンドとした場合のUXがどこまで洗練されるか。

この3つが揃ってくると、「16GB VRAMのGPU1枚で、コーディングはローカル27Bで完結」という運用が一般化する可能性がある。動きを追っておきたい領域である。

コーディング性能を重点強化したDense 27Bが、MoE型フラッグシップに迫るという構図は、コンシューマGPU市場とオープンウェイトLLMの接点が一段深まったタイミングを示している——というのが現時点での筆者の見方である。クラウド一択でも、ローカル一択でもなく、ワークロードごとに選び分ける設計が成立する時期に入った。

まとめ

Qwen3.6-27BはDense 27Bというコンパクトな構成で、前世代MoEフラッグシップのQwen3.5-397B-A17Bをコーディング用途で上回ったと主張するオープンウェイトLLMである。16GB VRAM帯のコンシューマGPUでも4bit量子化版なら射程に入るが、本記事の実測では本体＋KV等が載り切らずCPUオフロードを伴う。全量をGPUに載せて快適に回すなら、実測では16GB×2のデュアル構成で全レイヤーがGPUに載った。

クラウド側ではClaude Opus 4.8のような上位モデルが同時期に強化されており、「品質・追従性を重視するならクラウド、コスト・プライバシー・オフライン性を重視するならローカル27Bクラス」という使い分けの軸がはっきりしてきた（本記事で両者の同条件比較はしていない）。ローカルLLMで日常的にコーディングを回すなら、Qwen3.6-27BをUnsloth GGUF + llama-serverで動かす構成を試してみる価値がある。まずは手元の環境でQ4_K_M版をロードし、実際のコーディングタスクで触ってみるところから始めるのが最短ルートである。

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

参考資料

• Hugging Face 公式: Qwen リポジトリ
• llama.cpp 公式: ビルドドキュメント
• Hugging Face 公式: Unsloth プロフィール
• Anthropic 公式: Claude API 価格ページ