Qwen 3.6 27B——RTX 4090一枚でフラッグシップ級コーディング、Apache 2.0・262Kコンテキストでローカル推論の限界を更新

なぜQwen 3.6 27Bが重要なのか

オープンソースLLMの「フラッグシップ」は長らく、数百億〜1兆パラメータ規模のモデルとMixture-of-Experts（MoE）アーキテクチャの独壇場だった。DeepSeek V4-ProやKimi K2.6はいずれも1T超のパラメータを持ち、推論にGPUクラスタが必要だ。

Qwen 3.6 27Bはそこに別の答えを示した。

27Bのdenseモデルで、コーディングベンチマークのフラッグシップ性能を、コンシューマGPU1枚で実現する。

2026年4月22日にAlibaba Qwen TeamがリリースしたQwen 3.6 27Bは、前世代フラッグシップのQwen3.5-397B（総パラメータ397B・MoE）をすべての主要コーディングベンチマークで上回りながら、RTX 4090（24GB VRAM）1枚で動く。

モデル仕様

MoEではなくdenseアーキテクチャを選択したことで、推論ロジックがシンプルになり、ローカル実行ツール（llama.cpp・Ollama）との相性が良い。

ベンチマーク

Claude Opus 4.6に対してSWE-benchmark Verifiedで4ポイント差。これは400B級MoEを超え、Claudeに肉薄するコーディング性能を27Bのdense・コンシューマGPU1枚で実現したことを意味する。

ローカル実行手順

Ollama（最速セットアップ）

# Ollamaをインストール済みの場合
ollama pull qwen3.6:27b

# チャットモードで確認
ollama run qwen3.6:27b "Implement a Redis-backed rate limiter in Python"

# APIサーバーとして起動（OpenAI互換）
ollama serve
# → http://localhost:11434 でOpenAI互換エンドポイントが起動

OpenAI互換エンドポイントのため、LangChain・LlamaIndex・OpenAI SDKをそのまま向け先変更するだけで動く。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # ダミー（ローカルなので認証不要）
)

response = client.chat.completions.create(
    model="qwen3.6:27b",
    messages=[
        {"role": "system", "content": "You are an expert software engineer."},
        {"role": "user", "content": "Review this Python function for security issues:\n\ndef execute_query(user_input):\n    conn.execute(f'SELECT * FROM users WHERE name = {user_input}')"},
    ],
)
print(response.choices[0].message.content)

llama.cpp（GGUF・量子化コントロール）

# GGUF形式をHugging Faceからダウンロード
huggingface-cli download Qwen/Qwen3.6-27B-GGUF \
    --include "qwen3.6-27b-q4_k_m.gguf"

# RTX 4090（24GB）でのフルGPUオフロード
./llama.cpp/llama-cli \
    -m qwen3.6-27b-q4_k_m.gguf \
    -n 4096 \
    --ctx-size 32768 \
    -ngl 35 \           # GPUにオフロードするレイヤー数（全層）
    --threads 8 \
    -p "Refactor the following code to be more idiomatic Rust:"

Q4_K_M量子化のVRAM消費

Qwen 3.6 27B のVRAM消費（Q4_K_M）:

  モデル重み:      ≈ 16.5 GB
  KVキャッシュ:
    ctx_size=8K  → ≈  0.8 GB  合計 ≈ 17.3 GB ✅ RTX 4090（24GB）
    ctx_size=32K → ≈  3.1 GB  合計 ≈ 19.6 GB ✅ RTX 4090（24GB）
    ctx_size=64K → ≈  6.2 GB  合計 ≈ 22.7 GB ✅ RTX 4090（24GB）
    ctx_size=128K→ ≈ 12.4 GB  合計 ≈ 28.9 GB ❌ RTX 4090では不足

  Macユーザー:
    M3 Ultra 192GB → 128Kコンテキストも余裕で動作

※KVキャッシュにTurboQuantを適用すれば128Kも24GB GPUで実現できる可能性がある（実験的）。

262Kコンテキストで何ができるか

262,144トークンはプロジェクト規模によってはコードリポジトリ全体を1プロンプトに収められる。

参考：主要リポジトリのトークン換算（概算）

  小規模SaaSプロジェクト（〜5万行）:   ≈  60K トークン  ✅ 余裕
  中規模OSS（Rails相当・20万行）:      ≈ 240K トークン  ✅ ギリギリ収まる
  大規模モノレポ（100万行+）:          ≈ 1.2M トークン  ❌ 分割が必要

リポジトリ全体の「大規模リファクタリング」「依存関係の分析」「横断的なバグ調査」などをローカルかつプライベートに実行できる。

Apache 2.0ライセンスの実践的意味

Apache 2.0の許可事項:

  ✅ 商用利用（製品に組み込む）
  ✅ ファインチューニング・追加学習
  ✅ 改変版の配布
  ✅ プロプライエタリな製品への組み込み
  ✅ クラウドサービスとして提供

  ❌ 原著作権表示の省略（表示義務あり）
  ❌ Alibabaの商標・ブランドの使用（別途許可必要）

MIT Licenseとほぼ同等の自由度で、エンタープライズ向けの製品組み込みも法的にクリア。

注意点・落とし穴

❌ コンテキスト全体をRAM/VRAMに保持する必要がある

❌ 悪い例：ナイーブな長文処理
  # 262Kトークン全部を一度に処理しようとすると...
  # → RTX 4090でも128K超はVRAM不足になる
  with open("huge_codebase.txt") as f:
      text = f.read()  # 300K tokens相当
  response = llm.invoke(text)  # OOM Error

✅ 良い例：コンテキスト戦略を使う
  # チャンク化 or ベクトルDB + RAGで関連部分のみ投入
  relevant_chunks = retriever.invoke("authentication flow")
  response = llm.invoke(relevant_chunks)  # 必要な部分だけ

❌ 動画入力はAPIモードが前提

マルチモーダル（動画入力）機能はllama.cppのローカル実行ではまだ完全サポートされていない。動画を使う場合はQwen API経由が現実的。

地政学リスク（API利用時）

本番でQwen APIを使う場合、DeepSeek V4と同様に中国企業のAPIにデータを送信することになる。機密コード・個人データのAPI経由処理は法務チェック必須。ローカル実行ならこの問題はない。

まとめ

Qwen 3.6 27Bは「フラッグシップ性能をコンシューマGPUで」という命題をdenseアーキテクチャで実現した。ローカルコーディングエージェントを構築したい開発者にとって、現時点で最も実用的な選択肢の一つだ。

Apache 2.0・262Kコンテキスト・マルチモーダル対応という組み合わせは、プロプライエタリなAPIへの依存を避けてプライベートにLLMを動かしたいプロジェクトの要件を満たす。

参考リンク

• Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model — Simon Willison
• Qwen/Qwen3.6-27B — Hugging Face
• Qwen 3.6 27B: a Local Coding Model You Can Actually Run — ai.rs
• GitHub - QwenLM/Qwen3.6
• r/MachineLearning
• r/LocalLLaMA