はじめに

Qwen3.6-27B のコミュニティファインチューンとして、DavidAU 氏の Qwen3.6-27B-Fable-Fusion-711 が公開されています。ARC-C で 0.711 を出し、ベースの Qwen3.6-27B を 7 指標中 6 つで上回った（残り 1 つは同点）と主張しているモデルです。

本記事では、このモデルを RTX 4090 24GB × 4枚（WSL2 + Docker）で BF16 フル精度・画像入力ありで動かす ところまでを扱います。

ModelScope ミラーからダウンロードするとファイルが足りず、そのままでは起動しません（実際に止まりました）
Qwen3.6 は 64 層中 48 層が線形アテンションというハイブリッド構成で、KV キャッシュの考え方が通常の 27B と根本的に違います。ここを理解しないとパラメータを間違えます
起動スクリプトはそのままコピーして使える形で置いてあります

前回の Muse Glimmer 30B の記事と同じマシンでの検証なので、あわせて読むと差分が見えると思います。

このモデルは Heretic による de-censoring（拒否応答の除去）が施されたバリアントです。作者の計測では拒否率がベースの 99/100 に対して 4/100 とされています。業務利用する場合は、ガードレールをアプリケーション側で別途用意することを前提にしてください。本記事はあくまでデプロイ手順の技術検証です。

1. モデルの構成を読む

1.1 基本情報

config.json から実際の値を拾うと以下のとおりです。

項目	内容
ベースモデル	Qwen/Qwen3.6-27B
制作	DavidAU（多段ファインチューン）/ Nightmedia（マージ・ベンチ）/ TeichAI（Polaris データセット）/ armand0e（Fable トレース）/ trohrbaugh（Heretic 処理）
ライセンス	Apache 2.0
architectures	`Qwen3_5ForConditionalGeneration`
model_type	`qwen3_5`
総パラメータ数	約 27B（Vision encoder 含む）
層数	64
Hidden dimension	5120
FFN 中間次元	17408
Attention パターン	`linear_attention` × 3 → `full_attention` × 1 の繰り返し（`full_attention_interval: 4`）
Attention heads (Q / KV)	24 / 4
Head dimension	256
partial_rotary_factor	0.25
線形アテンション	Gated DeltaNet、key heads 16 / value heads 48、head dim 128、conv kernel 4
MTP	`mtp_num_hidden_layers: 1`
Vision encoder	depth 27、hidden 1152、patch size 16、spatial merge 2
語彙サイズ	248,320
コンテキスト長	262,144（`rope_type: default`、YaRN 不要）
BF16 チェックポイント	実測 51.7 GiB

1.2 ベンチマーク（作者公開値）

Nightmedia 氏による mxfp8 での計測値です。

モデル	arc/c	arc/e	boolq	hswag	obkqa	piqa	wino
Fable-Fusion-711	0.711	0.879	0.910	0.790	0.514	0.823	0.763
Qwen3.6-27B-Instruct（ベース）	0.647	0.803	0.910	0.773	0.450	0.806	0.742
Qwen3.6-35B-A3B-Instruct	0.581	0.757	0.892	0.751	0.428	0.803	0.688

de-censoring 側の数値も公開されています。

指標	本モデル	ベース Qwen3.6-27B
KL divergence	0.0469	0（定義上）
Refusals	4 / 100	99 / 100

第三者検証では、公開重みが作者の主張する 4/100 を再現しなかったという報告もあります。ベンチマーク値は「作者の主張」として受け取り、自分のユースケースで確認するのが妥当です。

1.3 ここが重要：64層中48層が線形アテンション

このモデルを扱ううえで一番効いてくるのがこの構造です。

config.json の layer_types を見ると、64 層のうち full_attention はわずか 16 層、残り 48 層は linear_attention（Gated DeltaNet）です。これが KV キャッシュの見積もりを通常の Dense モデルと全く別物にします。

KV キャッシュ（full attention 層のみ、トークン長に比例）

4 KV heads × 256 head_dim × 2 (K/V) × 2 byte = 4 KB / 層 / token
4 KB × 16 層 = 64 KB / token

27B クラスとしては破格に安いです。128K コンテキストでもたった 8 GiB です。

線形アテンションの状態（シーケンス単位、トークン長に非依存）

48 value heads × 128 × 128 × 4 byte (fp32) = 3 MiB / 層 / シーケンス
3 MiB × 48 層 = 約 144 MiB / シーケンス

つまりこのモデルは、

コンテキストを伸ばすのは安い
同時実行数を増やすのは高い

という、通常の Transformer とは逆の経済性を持っています。--max-num-seqs を安易に上げてはいけない、というのが実務上の結論です。

2. 検証環境

項目	内容
GPU	NVIDIA GeForce RTX 4090 24GB × 4
GPU 接続	PCIe のみ（NVLink なし、P2P 非対応）
OS	Windows + WSL2 (Ubuntu)
ドライバ	591.86 / CUDA 13.1
コンテナ	Docker（nvidia runtime 有効）
イメージ	`vllm/vllm-openai:v0.21.0`
vLLM	0.21.0（Qwen3.6 は 0.19.0 以上が必要）

vLLM が 0.19.0 未満だと Gated DeltaNet 系のレイヤーを解決できません。前回 Muse Glimmer 用に使った :muse-glimmer タグの専用イメージは流用できないので注意してください。

3. 事前準備

3.1 GPU を空ける

BF16 51.7 GiB を TP=4 で分散するので、4枚とも空いている必要があります。

nvidia-smi
docker ps

私の環境では MinerU と OCR のコンテナが GPU0 / GPU3 を掴んでいたので止めました。

docker update --restart=no <container-name>
docker stop <container-name>

3.2 モデルのダウンロード

ModelScope のミラーから取得します。

pip install -U modelscope
modelscope download \
  --model Zoupers/Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-MTP \
  --local_dir /root/HuggingFaceCache/FF711-27B

WSL2 では /mnt/c/...（9p 経由）ではなく /root/...（ext4）に置いてください。読み込み速度が段違いです。

4. ハマりどころ

4.1 ModelScope ミラーには設定ファイルが3つ足りない

これが最大の落とし穴でした。起動するといきなり落ちます。

OSError: Can't load image processor for '/models/FF711-27B'.
... make sure '/models/FF711-27B' is the correct path to a directory
containing a preprocessor_config.json file

config.json の architectures が Qwen3_5ForConditionalGeneration（マルチモーダル）なので、vLLM は image processor をロードしにいきます。ところが ModelScope ミラー側にファイルがありません。HF 本家と比較すると以下が欠落していました。

ファイル	ModelScope (Zoupers)	HF (DavidAU)
`preprocessor_config.json`	✗	✓
`video_preprocessor_config.json`	✗	✓
`vocab.json`	✗	✓

重み側は問題ありません。model.safetensors.index.json を確認すると vision 系テンソルが 333 個ちゃんと入っています。純粋に設定ファイルの同期漏れです。

対処：この 3 ファイルは HF 本家とベースの Qwen3.6-27B で sha256 まで完全に一致 します（実際に照合しました）。ファインチューンで前処理パラメータは変わらないので、ModelScope 上の公式ベースから持ってくれば十分です。

cd /root/HuggingFaceCache
modelscope download --model Qwen/Qwen3.6-27B \
  preprocessor_config.json video_preprocessor_config.json vocab.json \
  --local_dir ./_qwen36_cfg
cp ./_qwen36_cfg/{preprocessor_config.json,video_preprocessor_config.json,vocab.json} \
   ./FF711-27B/

4.2 `mmproj-*.gguf` は不要

GGUF リポジトリ側に mmproj-BF16.gguf などが置いてあり、モデルカードにも「画像を使うには mmproj が必要」と書かれています。これに引っ張られそうになりますが、llama.cpp 系専用の話です。

GGUF 量子化では vision encoder が別ファイルに切り出されるため LM Studio や KoboldCpp では別途必要になりますが、safetensors + vLLM の経路では vision encoder は本体の重みに含まれています。ダウンロード不要です。

4.3 Prefix caching と Mamba 層の組み合わせは experimental

起動ログに出ます。

Mamba cache mode is set to 'align' for Qwen3_5ForConditionalGeneration
by default when prefix caching is enabled
Warning: Prefix caching in Mamba cache 'align' mode is currently enabled.
Its support for Mamba layers is experimental.

64 層中 48 層が線形アテンションなので、この experimental の重みは軽くありません。マルチターンで出力が微妙におかしくなった場合は、まず --enable-prefix-caching を外して切り分けてください。

4.4 無視してよい警告

[transformers] `Qwen2VLImageProcessorFast` is deprecated.

→ preprocessor_config.json の image_processor_type が旧名のまま。互換動作するので放置で問題ありません。

Unknown vLLM environment variable detected: VLLM_WSL2_ENABLE_PIN_MEMORY

→ 0.21.0 では変数名が整理されたようですが、WSL2 では Using 'pin_memory=False' as WSL is detected に落ちて正常に起動します。

5. KV キャッシュの実測

まず素直に起動して、実際に何がどれだけ確保されるかを見ます。

docker logs ff711-vllm 2>&1 | grep -iE "Available KV cache|GPU KV cache size|Maximum concurrency"

max_model_len=65536 / max_num_seqs=8 / gpu_memory_utilization=0.88 での結果です。

Available KV cache memory: 6.44 GiB
GPU KV cache size: 391,759 tokens
Maximum concurrency for 65,536 tokens per request: 5.98x

検算してみます。

6.44 GiB × 4枚         = 25.76 GiB
25.76 GiB ÷ 64 KB/token = 約 42.2 万 token（理論値）
実際の表示               = 39.2 万 token
差分                     = 約 1.9 GiB

この差分 1.9 GiB が、1.3 節で計算した線形アテンションのシーケンス状態（144 MiB × 8 seq ≒ 1.15 GiB）と conv state です。設定から予測した値と実測がきれいに一致したので、モデルの挙動理解は正しいと判断できます。

nvidia-smi 側はこうなります。

GPU0: 21801MiB / 24564MiB   ← ディスプレイ出力分で他より約 600MiB 多い
GPU1: 21225MiB / 24564MiB
GPU2: 21202MiB / 24564MiB
GPU3: 21202MiB / 24564MiB

推論中の GPU 使用率は 62〜64%、消費電力は 190W / 450W 程度でした。使用率が出ているのに電力が上がらないのは、PCIe 経由の allreduce 待ちで止まっている時間が長いためです。4090 は P2P 非対応なので、この構成では避けられません。

コンテキスト長の決め方

プールは 39.2 万トークンで固定なので、コンテキストを伸ばすと同時実行数と直接トレードオフします。

`--max-model-len`	理論同時実行数
65,536	5.98x
131,072	2.99x
262,144	1.49x

Qwen 公式は「思考能力を保つため 128K 以上を維持することを推奨」としています。加えて画像入力を使う場合、画像だけで数万トークンを消費します（後述）。私は 131,072 を選びました。

6. 起動スクリプト

~/myvllm/ff711-vllm.sh として保存し chmod +x してください。

#!/usr/bin/env bash
set -euo pipefail

MODEL_DIR="${MODEL_DIR:-/root/HuggingFaceCache/FF711-27B}"
IMAGE="${IMAGE:-vllm/vllm-openai:v0.21.0}"
SERVED_MODEL_NAME="${SERVED_MODEL_NAME:-ff711}"
PORT="${PORT:-8000}"
API_KEY="${API_KEY:-sk-dummy}"

# Fixed 4-GPU setup. BF16 weights measure 51.7GiB (12.9GiB/card at TP=4).
GPU_DEVICES="${GPU_DEVICES:-3,2,1,0}"
TP_SIZE="${TP_SIZE:-4}"

# Only 16 of 64 layers are full_attention -> ~64KB/token.
# Measured pool at util 0.88: 6.44GiB/card = 391,759 tokens.
MAX_MODEL_LEN="${MAX_MODEL_LEN:-131072}"

# GPU0 also drives the display (~600MiB, fluctuates). 0.90 is the ceiling.
GPU_MEMORY_UTILIZATION="${GPU_MEMORY_UTILIZATION:-0.88}"

# The 48 linear-attention layers hold a per-sequence recurrent state
# (~144MiB/seq) that does NOT shrink with context.
# Long context is cheap here; concurrency is not.
MAX_NUM_SEQS="${MAX_NUM_SEQS:-8}"
MAX_NUM_BATCHED_TOKENS="${MAX_NUM_BATCHED_TOKENS:-8192}"

# Empty on the first run; pin it afterwards from the startup log.
KV_CACHE_MEMORY="${KV_CACHE_MEMORY:-}"

LIMIT_MM_PER_PROMPT="${LIMIT_MM_PER_PROMPT:-{\"image\":3}}"

# MTP tensors ARE in model.safetensors.index.json, but acceptance rate
# after a multi-stage merge is unverified. Off by default.
ENABLE_MTP="${ENABLE_MTP:-false}"
NUM_SPECULATIVE_TOKENS="${NUM_SPECULATIVE_TOKENS:-2}"

ENABLE_TOOL_CALL="${ENABLE_TOOL_CALL:-true}"
# "Prefix caching in Mamba cache 'align' mode is experimental".
# If multi-turn output goes subtly wrong, set this to false FIRST.
ENABLE_PREFIX_CACHING="${ENABLE_PREFIX_CACHING:-true}"

if [ ! -d "${MODEL_DIR}" ]; then
  echo "ERROR: model directory not found: ${MODEL_DIR}"
  exit 1
fi

# The ModelScope mirror ships none of these. Pull them from Qwen/Qwen3.6-27B.
MISSING=()
for f in preprocessor_config.json video_preprocessor_config.json vocab.json; do
  [ -f "${MODEL_DIR}/${f}" ] || MISSING+=("$f")
done
if [ ${#MISSING[@]} -gt 0 ]; then
  echo "ERROR: missing config files in ${MODEL_DIR}: ${MISSING[*]}"
  exit 1
fi

VLLM_ARGS=(
  --model /models/FF711-27B
  --served-model-name "${SERVED_MODEL_NAME}"
  --trust-remote-code
  --tensor-parallel-size "${TP_SIZE}"
  --max-model-len "${MAX_MODEL_LEN}"
  --gpu-memory-utilization "${GPU_MEMORY_UTILIZATION}"
  --max-num-seqs "${MAX_NUM_SEQS}"
  --max-num-batched-tokens "${MAX_NUM_BATCHED_TOKENS}"
  --limit-mm-per-prompt "${LIMIT_MM_PER_PROMPT}"
  --generation-config auto
  --api-key "${API_KEY}"
  --host 0.0.0.0
  --port "${PORT}"
)

[ -n "${KV_CACHE_MEMORY}" ] && VLLM_ARGS+=(--kv-cache-memory "${KV_CACHE_MEMORY}")

if [ "${ENABLE_PREFIX_CACHING}" = "true" ]; then
  VLLM_ARGS+=(--enable-prefix-caching)
fi

if [ "${ENABLE_MTP}" = "true" ]; then
  VLLM_ARGS+=(--speculative-config \
    "{\"method\":\"qwen3_next_mtp\",\"num_speculative_tokens\":${NUM_SPECULATIVE_TOKENS}}")
fi

# Qwen3.6 thinks by default. No /think soft switch - clients disable it
# per request via chat_template_kwargs. No --chat-template: the checkpoint
# ships chat_template.jinja itself.
if [ "${ENABLE_TOOL_CALL}" = "true" ]; then
  VLLM_ARGS+=(
    --enable-auto-tool-choice
    --reasoning-parser qwen3
    --tool-call-parser qwen3_coder
  )
fi

docker run --rm -it \
  --name ff711-vllm \
  --gpus "\"device=${GPU_DEVICES}\"" \
  --network host \
  --ipc=host \
  --shm-size 32g \
  --ulimit memlock=-1 \
  --ulimit stack=67108864 \
  -v "${MODEL_DIR}:/models/FF711-27B:ro" \
  -e CUDA_DEVICE_ORDER=PCI_BUS_ID \
  -e CUDA_VISIBLE_DEVICES=0,1,2,3 \
  -e PYTORCH_NVML_BASED_CUDA_CHECK=1 \
  -e VLLM_WSL2_ENABLE_PIN_MEMORY=1 \
  -e TRANSFORMERS_OFFLINE=1 \
  -e HF_DATASETS_OFFLINE=1 \
  -e HF_HUB_OFFLINE=1 \
  -e HF_HOME=/root/HuggingFaceCache \
  -e HUGGINGFACE_HUB_CACHE=/root/HuggingFaceCache \
  -e VLLM_WORKER_MULTIPROC_METHOD=spawn \
  -e NCCL_P2P_DISABLE=1 \
  -e NCCL_IB_DISABLE=1 \
  -e NCCL_SHM_DISABLE=0 \
  "${IMAGE}" \
  "${VLLM_ARGS[@]}"

各設定の意図

設定	理由
`--tensor-parallel-size 4`	BF16 51.7GiB を4枚に分散。PP は 24GB カードでは OOM（Muse Glimmer で検証済み）
`--max-model-len 131072`	公式が 128K 以上を推奨。画像 3 枚で数万トークン消費するため 64K では足りない
`--gpu-memory-utilization 0.88`	GPU0 の画面出力分。0.90 に上げても約 3 万トークンしか増えず、リスクに見合わない
`--max-num-seqs 8`	線形アテンションのシーケンス状態が高い。4 に下げても 0.6GiB しか戻らないので 8 で妥協
`--reasoning-parser qwen3`	Qwen3.6 は既定で `<think>` を出力する
`--tool-call-parser qwen3_coder`	Qwen 公式の vLLM レシピと同じ
`--generation-config auto`	同梱の `generation_config.json`（temperature 1.0 / top_p 0.95 / top_k 20）を採用
`--trust-remote-code`	マージ由来の設定差分を吸収するため保険で付与
`NCCL_P2P_DISABLE=1`	4090 はハードウェアとして P2P 非対応

KV プールを固定する

初回起動でログの値を確認したら、そこから 0.15 GiB ほど引いた値を固定します。

KV_CACHE_MEMORY=6764573184   # 6.3 GiB

GPU0 のディスプレイ使用量は Windows 側の操作で変動するので、実測値ぴったりを入れると「ある日ブラウザを開いたら起動しなくなる」ことがあります。固定すると profiling をスキップして起動も速くなります。

7. 動作確認

7.1 テキスト

curl -s localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer sk-dummy" \
  -H "Content-Type: application/json" -d '{
  "model": "ff711",
  "messages": [{"role": "user", "content": "RAG について日本語で説明してください。"}],
  "temperature": 1.0, "top_p": 0.95, "top_k": 20, "max_tokens": 1024
}'

7.2 思考モードの切り替え

Qwen3.6 は既定で思考します。/think /no_think のソフトスイッチは廃止されているので、リクエスト単位で指定します。

{
  "chat_template_kwargs": {"enable_thinking": false}
}

逆に、エージェント用途で過去ターンの思考を保持したい場合は Qwen3.6 の新機能が使えます。

{
  "chat_template_kwargs": {"enable_thinking": true, "preserve_thinking": true}
}

推論の一貫性が上がるうえ、同じ思考を繰り返さなくなるためトークン消費が減り、KV キャッシュのヒット率も改善するとされています。

7.3 サンプリングパラメータ

Qwen 公式推奨は用途で分かれます。--generation-config auto でサーバ側に入るのは思考モードの値なので、instruct 側はクライアントから明示的に送る必要があります。

用途	temperature	top_p	top_k	presence_penalty
思考モード・汎用	1.0	0.95	20	0.0
思考モード・精密なコーディング	0.6	0.95	20	0.0
instruct（思考なし）	0.7	0.80	20	1.5

7.4 画像入力

curl -s localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer sk-dummy" \
  -H "Content-Type: application/json" -d '{
  "model": "ff711",
  "messages": [{"role": "user", "content": [
    {"type": "image_url", "image_url": {"url": "https://example.com/sample.png"}},
    {"type": "text", "text": "この画像の内容を日本語で説明してください。"}
  ]}],
  "temperature": 1.0, "top_p": 0.95, "max_tokens": 1024
}'

8. 画像トークンの上限は必ず見直す

画像入力を使うなら、ここが一番効くチューニングポイントです。

preprocessor_config.json の既定値はこうなっています。

{
    "size": {"longest_edge": 16777216, "shortest_edge": 65536},
    "patch_size": 16,
    "merge_size": 2
}

patch 16・merge 2×2 なので、1 画像あたりのトークン数は ピクセル数 ÷ 1024 です。

`longest_edge`	1画像あたり	3画像合計
16,777,216（既定）	16,384 tok	49,152 tok
4,194,304	4,096 tok	12,288 tok
2,097,152	2,048 tok	6,144 tok

既定の 16M ピクセルは超巨大画像や長尺動画のための余裕であって、スクリーンショットや文書 1 ページには過剰です。しかも vLLM は起動時の profiling で最悪ケース分の encoder budget を予約するため、使っていなくても KV キャッシュを削られます。

cd /root/HuggingFaceCache/FF711-27B
python3 - << 'EOF'
import json
p='preprocessor_config.json'
d=json.load(open(p))
d['size']['longest_edge']=4194304
json.dump(d,open(p,'w'),indent=4)
EOF

--mm-processor-kwargs で渡す方法もありますが、ビルドによって受理されるキーが違うので、設定ファイルを直接書き換えるほうが確実です。文書 OCR 用途なら 8,388,608 くらいまでに留めるのが無難でしょう。

9. MTP（Multi-Token Prediction）について

このモデル名の末尾にある「MTP」は、Qwen3.6 の Multi-Token Prediction ヘッドを保持していることを指します。vLLM では投機デコードとして有効化できます。

--speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'

model.safetensors.index.json を確認したところ、mtp.layers.0.* が 15 テンソル分きちんと登録されていました（model-mtp-restored.safetensors に格納）。重みのロード自体は通るはずです。

ただし本記事では既定で無効にしています。

多段ファインチューン・マージを経た後の受理率が未検証である
作者自身が「temperature は 1 以下、repetition_penalty は 1（無効）を維持すること。受理率が 50% を下回るなら通常版のほうが速い」と明記している
受理率が低い場合、投機デコードはエラーを出さずに単に遅くなるため、気づきにくい

有効化して使う場合は、必ず受理率をログで確認してから本採用してください。

10. 最終的なパラメータ

パラメータ	値	決定理由
並列方式	TP=4	PP は 24GB カードでは OOM
`--max-model-len`	131072	公式推奨の 128K 以上。画像分の消費も考慮
`--gpu-memory-utilization`	0.88	GPU0 の画面出力分の余裕
`--max-num-seqs`	8	線形アテンションのシーケンス状態が高価
`--max-num-batched-tokens`	8192	encoder budget との連動。下げすぎない
`--limit-mm-per-prompt`	`{"image":3}`	要件が3枚。予約は最悪ケース基準なので増やさない
`preprocessor_config.json` の `longest_edge`	4,194,304	既定の 16M は過剰。KV への影響が最も大きい
`--speculative-config`	未使用	受理率が未検証

11. まとめ

RTX 4090 24GB × 4枚（WSL2 + Docker）で Qwen3.6-27B ベースの Fable-Fusion-711 は BF16 フル精度・画像入力ありで動きます
ModelScope ミラーは preprocessor_config.json / video_preprocessor_config.json / vocab.json が欠落しています。ベースの Qwen3.6-27B から持ってくれば sha256 まで一致するので安全に補完できます
GGUF 側の mmproj-*.gguf は llama.cpp 専用。safetensors + vLLM では不要です
64層中48層が線形アテンションという構造が全てを決めます。KV は 64KB/token と安く長文に強い一方、シーケンス状態が 144MiB/seq と高いので同時実行数は上げられません
実測 KV プールは 6.44 GiB/枚 = 391,759 token。設定から計算した理論値と 1.9 GiB の差があり、それが線形アテンションの状態分と一致しました
画像を使うなら longest_edge の見直しが最優先。既定のままだと 1 画像で 16,384 トークンを予約します
vLLM は 0.19.0 以上が必須。Muse Glimmer 用の専用イメージは流用できません

スループットの実測とベースの Qwen3.6-27B との日本語比較は、次回まとめようと思います。

参考リンク