はじめに伝えておくが、先日リリースされた「Qwen 3.6 27B」の性能はちょっと異常だ。 大げさではなく、少し前の「Claude 3.5 Sonnet」と同等レベルと言っていいほど、実用的なコーディング性能をローカル環境で叩き出している。

しかし、この知性を自宅でまともに飼い慣らすには、どうしても超えなければならない「VRAMの壁」が存在する。RTX 4090やRadeon RX 7900 XTX(VRAM 24GB)で必死に動かしている猛者も見かけるが、モデルとKVキャッシュの量子化を「知能が劣化しないギリギリ」まで下げたとしても、実用レベルのコンテキストを確保するにはVRAMは最低32GB必要になってしまうのが現実だ。

また、商用モデルと大差ない驚異的なコーディング性能を持つ一方で、Qwen 3.6 27Bは「DENSEモデル」であるため、生成速度はかなり遅い。 個人的には、軽いスクリプト作成や修正タスクはMoE(Mixture of Experts)構造で高速な「Gemma 4 26B A4B」に任せ、深い思考と論理的なシステム設計が必要な重いタスクは「Qwen 3.6 27B」一択だと思っている。Gemma 4もベンチマークの数値以上に優秀だと感じているし、Qwen側が多少ベンチマーク用にチューニングされている可能性は否めないが、それでもこの最新の27B DENSEモデルの圧倒的なIQは本物だ。

今回は、このバケモノモデルを使って、API代を一切気にせずClaude Codeを使い倒す「夢のローカルコーディング環境」の作り方を解説する。

OSとハードウェア:Radeonなら迷わずLinuxネイティブへ

まず環境についてだが、Radeon系のGPUを使うのであれば、個人的にはUbuntuなどのLinuxネイティブ環境を強くおすすめしたい。

WSL2のセットアップの手間までは行かないにせよ、Windows環境下でのROCmは急に使えなくなったり、謎のVRAMオーバーヘッドが発生するなど、いらぬトラブルに見舞われる可能性がある。Vulkanで動かす逃げ道もあるにはあるが、AI開発のI/O効率を考えればLinuxに軍配が上がる。 NVIDIA製GPUであればWindows・Linuxどちらでも素直に動くが、ファイルアクセスの速さを考慮するとやはりLinuxが快適だ。

……とはいえ、「キャバ嬢でもわかる」と銘打った手前、読者の多くはユニファイドメモリを搭載したピカピカのMacをお使いかと思う。
Mac勢はメモリさえ足りていれば環境はあまり気にしなくていいので、そのまま進めてほしい。

(※Claude Code自体の基本的な使い方や導入方法については、以前の記事で詳しく解説しているのでそちらを参考にしてほしい)

【実用編】Claude Code × ローカルLLM(Qwen3.5 35B A3B)で実現する、無料・爆速のハイブリッドコーディング環境
ターミナルから直接コードベース全体を把握し、自律的にタスクをこなす「Claude Code」。強力なツールであることは間違いないが、唯一にして最大の弱点が「APIコスト」だ。プロジェクトのコンテキストを大量に消費するため

LM Studioでの最適化:VRAM 32GBの限界を引き出す設定

この記事を見ている時点で環境構築までは終わっていると思うので、今回の本題である「Qwen 3.6 27Bを絶対に破綻させないモデル設定」について解説していく。 設定UIが直感的でわかりやすい「LM Studio」を使う前提で進める。

1. コンテキスト長(Context Length):最低13万、推奨15万〜20万

ローカルAIで最もVRAMを食いつぶすのがこのコンテキスト(文脈)の保持だ。 結論から言うと、最低でも130,000(130k)、できれば150,000〜200,000を確保してほしい。

最新モデルは100万トークンなどの超ロングコンテキストをサポートしているが、コンテキストが肥大化すると推論速度が極端に落ち、精度も劣化していく。ツール側でコンテキスト圧縮(古いやり取りの要約・忘却)は行われるものの、そもそもバッファ上限が狭すぎると頻繁に圧縮処理が走り、コードの文脈を見失う原因になる。大規模なリファクタリングを行わない限り、20万程度で天井を打たせて都度圧縮させる運用が最も安定する。

2. モデルの量子化(Quantization):Q4_K_XLが知能の分水嶺

モデルのサイズを圧縮する量子化だが、コーディングタスクにおいては「Q4_K_M」以下まで下げてしまうと、論理推論の精度が露骨に落ちて使い物にならなくなる。

VRAM 48GBのグラボを積んでいる変態的環境であれば「Q6」や「Q8」で劣化ゼロのまま回せるが、普段私が使っている「Radeon AI PRO R9700」のような32GB VRAMの環境であれば、「Q4_K_XL」または「Q5_K_M」が限界ラインとなる。この設定なら、商用APIに肉薄する天才的なコーディング能力を失わずに済む。

3. VRAMとRAMを使い切る「神設定」

LM Studioの右側パネルから、以下の設定を必ず行おう。これを間違えると一瞬でOOM(Out of Memory)でクラッシュする。

  • Flash Attention:必ず有効化(メモリ消費を劇的に抑えつつ計算を高速化する必須機能)
  • Unified KV Cache:有効
  • KVキャッシュをGPUメモリにオフロード(Offload KV cache to GPU):有効
  • mmap()を使用:有効(モデルのロード時間を短縮)
  • モデルをメモリに保持(Keep model in memory):有効

※注意:モデルをメモリに保持するには、膨大なシステムRAMが必要になる。メインメモリは最低64GB、推奨は96GBだ。私は128GB(64GB×2)を積んで余裕を持たせている。

4. KVキャッシュの量子化:Q8で品質を担保する

コンテキストを保持するための「KVキャッシュ」も量子化できる。ここを下げすぎると長文になった途端にAIが痴呆化するため、以下がベストバランスだ。

  • K-Cache:Q8_0
  • V-Cache:Q8_0

FP16のままだと32GBのVRAMは一瞬で消し飛ぶが、Q8_0に設定することで、生成品質をほとんど落とさずにコンテキスト長を10万以上に押し上げることが可能になる。

もしあなたがRTX 5090を余らせていたり、メモリ128GBのMac Studioを持っているのであれば、ぜひこの設定を参考にコーディングを走らせてみてほしい。

注意点:天才ゆえの「遅さ」とツールの使い分け

最後に一つだけ強烈な注意点がある。
設定が決まれば、Qwen 3.6 27Bは並の100B(1000億)パラメータ超えモデルを凌駕する天才的な出力をする。しかし、DENSEモデル(全パラメータが毎トークン稼働するモデル)であるため、生成速度はとにかく遅い。

特に、Claude Codeのように「ターミナルのログからファイルの依存関係まで、バカみたいにコンテキストを消費・再読み込みするツール」と組み合わせると、1つの重い改修タスクに平気で2時間ほどかかることがある。

そのため、ローカルAI開発ではタスクの重さとコンテキストの消費量に合わせた「ツールの使い分け」が必須だ。現在の最適なスタメンは以下のようになる。

  • Claude Code:全自動のターミナル操作と、複雑なリファクタリングの丸投げ用。ただし商用API向けに作られているため、ローカルだと挙動が重くなりがち。
  • OpenCode(大本命):完全無料のオープンソースAIコーディングエージェント。「OSS版Claude Code」とも呼ばれ、ターミナル(TUI)だけでなくVS CodeやCursorのIDE拡張機能としても動く。プロバイダー非依存のためLM Studio(ローカルLLM)との連携が極めてスムーズで、今のローカル環境構築において最もおすすめしたい最強の選択肢だ。
  • Roo Code:VS Code内で、ピンポイントにファイル間を跨いだ修正をさせる場合に重宝する。
  • Aider / OpenHands:ターミナルで対話しながら、部分的なコード修正を爆速で重ねていくアジャイルな用途に最適。

【ワンポイント・アドバイス】 AIエージェントを使う際、コンテキスト長は「最低13万(130k)、推奨15万」を確保してほしい。バッファをケチると、エージェントがすぐに上限に達し「過去の会話の要約(コンテキスト圧縮)」を頻繁に繰り返し始める。ローカル環境でこれをやられると、再計算で凄まじい時間が溶けるだけでなく、コードの細かい仕様記憶が劣化してAIが痴呆化する。「一度のタスク内でなるべく圧縮を走らせず、広いコンテキストで逃げ切る」のが、ローカルAIを快適に使い倒す最大のコツだ。

GearTuneをチェックして最新ニュースをお見逃しなく。