Qwen3.6 on KnightLiブログ

Hermes + Qwen3.6：ローカル Agent の低コスト構築案

Mon, 04 May 2026 06:40:30 +0800

この記事は、ローカル Agent の構築案を整理したものだ。WSL2 上で llama.cpp を使って Qwen3.6 GGUF モデルを動かし、Hermes Agent をローカルの OpenAI-compatible API に接続する。これにより、自分の PC 上で長時間動作するローカル AI アシスタントを用意でき、オンラインサービスの Token 消費に縛られにくくなる。

この構成は、ローカル AI Agent を試したい人、データのプライバシーと長期的な管理性を重視する人に向いている。日常の質問応答、執筆、コード補助、資料整理、簡単な自動化タスクに使える。ただし、モデルが大きいほど VRAM 要件も高くなる。原文の例では Qwen3.6-27B を使っており、24GB VRAM のほうが安定しやすい。VRAM が少ない場合は、小さいモデルや低い量子化版を選ぶ。

構成

全体の流れはシンプルだ。

Windows に WSL2 と Ubuntu 24.04 をインストールする。
WSL2 内に CUDA Toolkit を入れ、llama.cpp をビルドする。
Qwen3.6 GGUF モデルをダウンロードする。
llama-server でローカルモデルサービスを起動する。
Hermes Agent をインストールし、http://localhost:8080/v1 に接続する。
任意で起動スクリプトを書き、WSL2 起動時にモデルサービスを自動起動する。

Hermes は Agent 機能を担当し、Qwen3.6 はローカル LLM 機能を担当する。組み合わせることで、PC をローカルのプライベート AI アシスタントにできる。

WSL2 と Ubuntu のインストール

Windows PowerShell を管理者として開き、次を実行する。

1
2

wsl --install
wsl --set-default-version 2

再起動後、Ubuntu 24.04 をインストールする。

`1`	`wsl --install -d Ubuntu-24.04`

インストール後、Ubuntu がユーザー名とパスワードの設定を求める。Ubuntu に入ったら、まず NVIDIA GPU が WSL2 から見えているか確認する。

`1`	`nvidia-smi`

GPU が認識されない場合は、Windows 側の NVIDIA ドライバを更新する。WSL2 は Windows ドライバを継承するが、CUDA Toolkit は WSL2 内に別途インストールする必要がある。

Python と基本ツールのインストール

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

続いて、ビルドツール、Git、CMake も必要になる。

`1`	`sudo apt install -y cmake build-essential git`

llama.cpp のビルド

まずソースコードを取得する。

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

WSL2 内で CUDA が使える状態なら、そのままビルドできる。

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 は RTX 40 シリーズなど Ada アーキテクチャ向けだ。別の GPU では実際のアーキテクチャに合わせて変更する。

CUDA Toolkit がないというエラーが出る場合は、先に WSL2 内で CUDA Toolkit をインストールする。

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

環境変数を設定する。

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

その後、再ビルドする。

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Qwen3.6 GGUF モデルのダウンロード

原文の例では、unsloth/Qwen3.6-27B-GGUF の Qwen3.6-27B-UD-Q4_K_XL.gguf を使っている。

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

このファイルは約 17GB。Hugging Face のダウンロードが遅い場合は、ModelScope などのミラーを使う。VRAM が足りない場合は 27B を無理に使わず、小さいモデルか低い量子化版を選ぶ。

ローカルモデルサービスを起動する

自分のモデルファイル名に合わせて llama-server を起動する。

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

起動後、Windows のブラウザで次を開く。

`1`	`http://localhost:8080`

Hermes Agent や他の OpenAI-compatible クライアントから呼び出す場合、API アドレスは通常次になる。

`1`	`http://localhost:8080/v1`

Thinking モードの使い分け

Qwen3.6 はデフォルトで Thinking モードが有効になる場合がある。複雑な推論、難しいコード問題、多段階分析には向いているが、速度は遅くなる。

Thinking モードを無効にしたい場合は、サービスを停止して --chat-template-kwargs を追加する。

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

Thinking を無効にすると、簡単な Q&A、執筆、コード補完、コード説明は速くなる。一方、複雑なアルゴリズム設計、難しい Debug、アーキテクチャ分析では Thinking を有効にするほうがよい。

Hermes Agent のインストール

llama-server を動かしたまま、新しい WSL2 ターミナルを開いて Hermes Agent をインストールする。

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

インストールスクリプトは Python、Node.js、ripgrep、ffmpeg などの依存関係を処理する。モデル endpoint の設定では custom endpoint を選ぶ。

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自動認識

ローカルの llama-server では、API Key は任意のプレースホルダでよい。設定後は Telegram、WeChat、QQ、Discord などのチャットツールと接続し、Hermes Agent からローカルモデルを呼び出してタスクを実行できる。

モデルサービスの自動起動

WSL2 ターミナルを開いたときにモデルサービスを自動起動するスクリプトを用意できる。

スクリプトを作成する。

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

.bashrc に追記する。

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

これで WSL2 ターミナルを開くたびに、llama-server が動いていなければ自動起動する。すでに動いている場合はスキップされ、重複起動を避けられる。

注意事項

27B モデルは VRAM 要件が高い。24GB VRAM のほうが安定しやすく、VRAM が少ない場合は小さいモデルにする。
--ctx-size 65536 は VRAM と RAM の負荷を大きく増やす。不安定な場合は 32768 かそれ以下に下げる。
WSL2 内の CUDA Toolkit と Windows 側の GPU ドライバの両方が正常である必要がある。どちらかが問題を起こすと、CUDA のビルドや実行に失敗する。
Hermes Agent がローカルサービスへ接続する仕組みは OpenAI-compatible API 呼び出しであり、重要なのは http://localhost:8080/v1 が正常に応答すること。
スマホや他の端末からアクセスする場合は、Windows Firewall、LAN アドレス、セキュリティ分離を追加で扱う。ローカルモデルサービスを直接インターネットへ公開しない。

Qwen3.6 をローカルで動かす：27B と 35B-A3B の量子化版に必要なVRAM

Fri, 01 May 2026 12:02:00 +0800

Qwen3.6 でローカル部署の対象として特に重要な公開重み版は、主に次の2つです。

Qwen3.6-27B：27B の dense モデル。
Qwen3.6-35B-A3B：35B total / 3B active の MoE モデル。

Qwen3.6-Plus や Qwen3.6-Max のようなオンライン製品名や API モデル名もあります。ただし、完全な公開重みと安定した量子化ファイルがないモデルは、ローカルVRAM表には向きません。この記事では、Hugging Face の重みと GGUF 量子化ファイルをもとに部署できるバージョンだけを扱います。

/05/10 の Gemma 4 表と同じように、まず次の2つを分けて考える必要があります。

GGUF ファイルサイズ：モデル重みファイルそのものの大きさ。
実際のVRAM使用量：重み、KV cache、コンテキスト長、ランタイムバックエンド、マルチモーダルモジュール、バッチサイズで決まる。

Qwen3.6 は標準のコンテキストが非常に長く、公式モデルカードでは 262,144 tokens をネイティブでサポートし、1,010,000 tokens まで拡張可能とされています。そのため、表の「最低VRAM」は短い、または中程度のコンテキストを前提にした目安です。 128K、256K、またはそれ以上のコンテキストを本当に使う場合は、KV cache 用にかなり多くの余裕が必要です。

まず結論

VRAM	比較的向く選択	避けたい選択
8GB	27B / 35B-A3B の 2-bit 極限テスト。品質リスクは高い	Q4 以上
12GB	27B Q2/Q3、35B-A3B Q2/Q3 の短コンテキスト	27B Q4 の長コンテキスト
16GB	27B Q3/Q4、35B-A3B Q3/IQ4_XS	35B-A3B Q4 の長コンテキスト
24GB	27B Q4/Q5/Q6、35B-A3B Q4	35B-A3B Q8、BF16
32GB	27B Q8、35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8、27B の長めのコンテキストをより余裕を持って実行	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	通常のローカルチャットで BF16 を追う必要はない

24GB GPU なら、重点的に見るべきなのは次の3つです。

Qwen3.6-27B Q4_K_M
Qwen3.6-27B Q5_K_M
Qwen3.6-35B-A3B UD-Q4_K_M

16GB VRAM しかない場合は、低ビット幅版から始め、いきなり超長コンテキストを使わないほうが安全です。

公式重みサイズ

以下は、公式 Hugging Face リポジトリの model.safetensors.index.json から確認できる BF16 重みサイズです。元のモデル規模を見るための参考になります。

モデル	アーキテクチャ	公式 BF16 重みサイズ	公式コンテキスト
`Qwen3.6-27B`	27B dense	55.56GB	ネイティブ 262K、1,010K まで拡張可能
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	ネイティブ 262K、1,010K まで拡張可能

35B-A3B は各ステップで約 3B パラメータだけを有効化しますが、完全な MoE 重みを読み込む必要があります。そのため、3B 小型モデルのようにVRAMを見積もることはできません。

Qwen3.6-27B VRAM表

Qwen3.6-27B は dense モデルで、安定した挙動が強みです。一方で推論コストは従来の 27B モデルに近くなります。ローカル部署の観点では、35B-A3B より計算量は重いものの、VRAM要件は見積もりやすいです。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_XXS`	9.39GB	12GB	16GB	極限低VRAMテスト
`UD-IQ2_M`	10.85GB	12GB	16GB	低VRAMでの可用性優先
`UD-Q2_K_XL`	11.85GB	14GB	18GB	低ビット幅の折衷案
`UD-IQ3_XXS`	11.99GB	14GB	18GB	VRAMを抑えた 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit 入門
`Q3_K_M`	13.59GB	16GB	20GB	3-bit の一般的な折衷案
`IQ4_XS`	15.44GB	20GB	24GB	Q4 に近い省VRAM選択
`IQ4_NL`	16.07GB	20GB	24GB	品質とサイズのバランス
`Q4_K_M`	16.82GB	20GB	24GB	27B の標準的なおすすめ
`Q5_K_M`	19.51GB	24GB	32GB	より高品質な量子化
`Q6_K`	22.52GB	28GB	32GB	品質優先
`Q8_0`	28.60GB	32GB	40GB	原精度に近い実行
`BF16`	53.80GB	64GB	80GB	研究、評価、精度比較

普通のローカルコーディングやチャットなら、Q4_K_M が最もおすすめしやすい出発点です。 24GB GPU なら Q4_K_M は比較的快適に動かせますが、長いコンテキストを使う場合は量子化サイズかコンテキスト長を下げるほうが安全です。

Qwen3.6-35B-A3B VRAM表

Qwen3.6-35B-A3B は MoE モデルで、35B total、各ステップで約 3B パラメータを有効化します。速度と能力のバランスがよく、特にローカル Agent、ツール呼び出し、コード作業に向いています。

ただし、MoE の 3B active は主に計算量に効くものであり、VRAMが 3B モデル相当で済むという意味ではありません。完全に動かすには専門家重みを読み込む必要があります。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_XXS`	10.76GB	12GB	16GB	極限低VRAMテスト
`UD-IQ2_M`	11.52GB	14GB	16GB	低VRAMでの可用性優先
`UD-Q2_K_XL`	12.29GB	14GB	18GB	低ビット幅の折衷案
`UD-IQ3_XXS`	13.21GB	16GB	20GB	VRAMを抑えた 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit 入門
`UD-Q3_K_M`	16.60GB	20GB	24GB	3-bit の一般的な折衷案
`UD-IQ4_XS`	17.73GB	20GB	24GB	品質とサイズのバランス
`UD-IQ4_NL`	18.04GB	20GB	24GB	Q4 に近いおすすめ選択
`UD-Q4_K_M`	22.13GB	24GB	32GB	35B-A3B の標準的なおすすめ
`UD-Q5_K_M`	26.46GB	32GB	40GB	より高品質な量子化
`UD-Q6_K`	29.31GB	32GB	48GB	品質優先
`Q8_0`	36.90GB	48GB	64GB	原精度に近い実行
`BF16`	69.37GB	80GB	96GB	研究、評価、精度比較

24GB VRAM なら UD-Q4_K_M が有力ですが、コンテキストは上げすぎないほうがよいです。 128K 以上のコンテキストに余裕を残したい場合、UD-IQ4_XS、UD-IQ4_NL、または 3-bit 版のほうが現実的です。

27B と 35B-A3B の選び方

目的	よりおすすめ
dense モデルの安定性	`Qwen3.6-27B`
速い応答、Agent、ツール呼び出し	`Qwen3.6-35B-A3B`
24GB VRAM での日常ローカル利用	`35B-A3B UD-Q4_K_M` または `27B Q4_K_M`
16GB VRAM での試用	どちらも 2-bit/3-bit。長コンテキストは避ける
長コンテキスト優先	低ビット量子化にして KV cache の余裕を残す
32GB+ VRAM で品質優先	`27B Q5/Q6` または `35B-A3B Q5/Q6`

コードを書いたり、Agent を動かしたり、ツール呼び出しを使うなら、35B-A3B を先に試す価値があります。 dense モデルの安定性や一貫性を重視するなら、27B のほうがわかりやすい選択です。

長コンテキストが大量のVRAMを使う理由

Qwen3.6 のモデルカードでは、複雑なタスクで長めのコンテキストを保つことが推奨されており、128K 以上のコンテキストが思考能力に役立つとも述べられています。しかしローカル部署では、長コンテキストは大きな KV cache を意味します。

実際のVRAM使用量に影響する要素は次の通りです。

KV cache：コンテキストが長いほど使用量が増える。
視覚入力を有効にするかどうか：Qwen3.6 は視覚エンコーダを持つため、マルチモーダル利用では追加コストがある。
--language-model-only を使うかどうか：vLLM などでは、視覚部分をスキップすると KV cache 用のメモリを一部空けられる。
バッチサイズと並列性：並列性が高いほどVRAM要求も高くなる。
KV cache 量子化：q8_0、q4_0 などはVRAMを節約できるが、細部に影響する場合がある。
ランタイム差：llama.cpp、vLLM、SGLang、KTransformers、LM Studio の使用量は完全には同じではない。

そのため、GGUF ファイルサイズだけを見てはいけません。ファイルがすでにVRAM上限に近い場合、モデルは読み込めても、長い出力や長コンテキスト生成で OOM になる可能性があります。

どう選ぶか

ローカルで Qwen3.6 を試したいだけなら：

12GB VRAM：27B UD-IQ2_M または 35B-A3B UD-IQ2_M。コンテキストは短くする。
16GB VRAM：27B Q3_K_M または 35B-A3B UD-IQ3_XXS。
24GB VRAM：27B Q4_K_M、35B-A3B UD-IQ4_NL、35B-A3B UD-Q4_K_M を優先。
32GB VRAM：27B Q5/Q6 または 35B-A3B Q5/Q6 を検討。
48GB 以上：Q8_0 を試すか、長コンテキスト用に余裕を残す。

多くのユーザーに BF16 は不要です。 Qwen3.6 のローカル部署で重要なのは、ファイルサイズの大きさではなく、VRAM、コンテキスト長、速度、出力品質のバランスです。