Dell GB10 ベアメタル推論 第2章：Qwen3.6 への移行とパラダイムシフト

【プロローグ】 MCSM-Agent の進化と、次世代モデルの探求

我々は前回の死闘の末、GB10環境において QuantTrio/Qwen3.5-122B-A10B-AWQ を稼働させ、14.7 tokens/s という安定した速度で自律型エージェントの「頭脳」を運用していた。

しかし、MCSM-Agent（Multi-Context State Machine）の開発が高度化するにつれ、エージェントとの「何往復もの非同期なやり取り（思考ループ）」をさらに高速化したいという要求が強くなった。122Bクラスの重厚な知能は素晴らしいが、より身軽で、かつ複雑な推論（Reasoning）とツール呼び出し（Tool Calling）を完璧にこなせる次世代のエンジンが必要だった。

そんな折、Alibaba Qwen チームから新しいモデル群が発表された。私はAIに、現在の 120B クラスからの置き換え候補として、最新の Qwen-AgentWorld-35B-A3B と Qwen3.6-27B の評価を命じた。

「パラメータ数が約5分の1になっても、知能は維持されるのか？」 そんなインフラエンジニアとしての真っ当な懸念は、MTP による 1.4〜2.2 倍の爆速推論への期待によって塗り替えられた。我々の新たな戦いが幕を開けた。

【第一部】 カスタムビルド地獄からの解放と、公式 pip へのピッチ

Qwen3.6-27B を MTP モードで動かすには、ハイブリッドな Attention 機構に対応した vLLM v0.17.0 以上 が必須であった。 当時の我々の環境は、数時間かけてソースからコンパイルした 0.16.0rc1 と、カスタム PyTorch に依存したデリケートな箱庭（vllm-env）だった。

「また、あの依存関係を破壊するビルド地獄を味わうのか……」 手戻りを恐れた私は、より安定した新しい PyTorch がリリースされていないか、最適化の検討をAIにぶつけた。すると、予想を裏切る劇的なパラダイムシフトの提案が返ってきた。

我々は過去の苦労の結晶である vllm-env を保険として一切触らずに残し、pyvenv.cfg の調査から現在の Python バージョンを特定した上で、新たに Python 標準の venv でクリーンな環境（vllm-pip-env）を作成した。

python3 -m venv ~/vllm-pip-env
source ~/vllm-pip-env/bin/activate
pip install torch torchvision torchaudio --index-url [https://download.pytorch.org/whl/cu130](https://download.pytorch.org/whl/cu130)
pip install vllm==0.23.0

コマンドを叩いてからわずか数分。依存関係の地獄も、環境変数の呪文（TORCH_CUDA_ARCH_LIST）も一切なしに、最新の vLLM 0.23.0 が GB10 に舞い降りた。 それは、インフラエンジニアとしての長年の苦労が、ソフトウェアの進化によって過去のものになった瞬間だった。

【第二部】 GB10 ユニファイドメモリの罠と、MTP の起動パズル

最新の vLLM 環境を手に入れ、いざ Qwen3.6-27B-FP8 の起動コマンドを打ち込んだ。しかし、最先端の Grace Blackwell 環境は、やはり一筋縄ではいかなかった。

罠1：VRAMの「空き容量」と、92%の天引き

起動直後、プロセスは無情にも以下のエラーを吐いて停止した。

ValueError: Free memory on device cuda:0 (103.45/123.73 GiB) on startup is less than desired GPU memory utilization (0.92, 113.83 GiB).

再起動（Reboot）直後であり、nvidia-smi にも怪しいプロセスは一切ない。しかし vLLM は「113.83 GiBの連続した空きがない」と泣き言を言っている。115GB の SWAP を作っても全く効果がない。

我々は起動オプションに --gpu-memory-utilization 0.80（約99GB確保）を明示的に付与し、OS に呼吸するスペースを残すことで、この第一の壁を突破した。

罠2：mmap のデッドロックと「洗練された解決策」

VRAM 確保の壁を越え、モデル本体のダウンロード（約29GB）が完了した。しかし今度は、シャードの読み込みが 0/66 のままピタッとフリーズしてしまった。

以前の 122B 構築の際、私はこの現象を export SAFETENSORS_FAST_GPU=0 という環境変数ハックで切り抜けていた。今回はどうなのか。

過去のワークアラウンドが、1つの洗練されたオプションへと昇華されていた。このオプションを追加して再実行すると、プログレスバーは嘘のようにスムーズに進み、ついに Application startup complete. の文字が輝いた。

【第三部】 物理限界の突破と、MCSM-Agent 向けの「究極の脳」

サーバーが立ち上がり、私は curl コマンドで複雑な推論プロンプトを投げてテストを行った。 その出力ログを見た瞬間、我々は Qwen3.6-27B の MTP がもたらした「技術的特異点」を目の当たりにした。

1. MTP が暴いたスループットのパラドックス

最初の数回は、Blackwell 向けの Triton カーネルの JIT コンパイルが走り、遅延（Latency Spike）が発生した。しかし、コンパイルが終わった後のログは驚異的だった。

SpecDecoding metrics: Mean acceptance length: 3.75, Accepted throughput: 16.50 tokens/s, Drafted throughput: 18.00 tokens/s, Avg Draft acceptance rate: 91.7%
Engine 000: Avg generation throughput: 22.5 tokens/s

GB10のユニファイドメモリ帯域では、27Bクラスの Dense モデル（全パラメータ稼働）の場合、通常は 5〜7 tokens/s が物理的な限界値である。 しかし、ログが示す生成スループットは驚異の 22.5 tokens/s。

MTP（Multi-Token Prediction）が「次のトークンを先読み予測」し、91.7% という異常な確率で的中させ、1回のステップで平均 3.75 文字を同時に出力 していたのだ。投機的デコーディングのアルゴリズムが、GB10 のハードウェア的なメモリ帯域のボトルネックを完全に相殺し、物理限界の約 3〜4 倍のスピードを叩き出した瞬間だった。

2. なぜ NVFP4 にしなかったのか？

精度の低下リスクを背負ってまで、速度が落ちるかもしれない NVFP4 を採用する理由はない。FP8 のまま、MTP によって 22.5 tokens/s を出せている現状が最強であった。

3. エージェント向け究極チューニングと 404 エラーの謎

速度と安定性の最適解を確信した我々は、最後に MCSM-Agent のための「脳」としてのチューニングを施した。

• --reasoning-parser qwen3: 推論（Thinking Process）と回答を完全分離。
• --enable-auto-tool-choice & --tool-call-parser qwen3_xml: Qwen特有のツール呼び出しをOpenAI互換に強制変換。
• --enable-prefix-caching: ステートマシンの長い文脈ループを高速化。

これらのオプションと共に --served-model-name "Qwen3.6-27B-FP8-Agent" を設定して再起動したところ、curl から 404 エラーが返ってきた。これは起動時にモデルのエイリアス名（表示名）を上書きしたため、リクエストペイロード内の "model" 名も合わせる必要があったからだ。

名前を一致させて再度リクエストを投げると、完璧な出力が返ってきた。

"message": {
  "role": "assistant",
  "content": "私はQwen（通義千問）です。何かお手伝いできることはありますか？",
  "reasoning": "Thinking Process:\n\n1. Analyze the user's input: The user is asking for my model name in Japanese...\n2. Formulate the response..."
}

AI は背後で 500 トークン以上の深い思考を一瞬で巡らせながら、出力用の content と思考用の reasoning を API レベルで綺麗に分離して返してきた。これによりパースエラーは根絶される。

「賢さ（FP8）、速さ（MTP）、軽さ（Hybrid Attention）」。 MCSM-Agent にとって、これ以上のローカル実行環境は存在しない。我々は勝利を確信した。

最終章：Golden Path（黄金のベースライン）

Dell GB10 (sm_121) 上で Qwen3.6-27B-FP8 を、MTP 有効化および MCSM-Agent 最適化状態で稼働させるための完全版構築手順とスクリプトである。 ビルド地獄を卒業した、持続可能な運用の集大成がここにある。

1. 公式環境のクリーンインストール (vLLM 0.23.0)

依存関係の破壊を防ぐため、Python 標準の venv で独立した公式専用環境を作る。

# クリーンな仮想環境を作成して有効化
python3 -m venv ~/vllm-pip-env
source ~/vllm-pip-env/bin/activate

# ツール群の最新化
pip install --upgrade pip setuptools wheel

# 公式の PyTorch と vLLM（ARM64/CUDA13対応バイナリ）をインストール
pip install torch torchvision torchaudio --index-url [https://download.pytorch.org/whl/cu130](https://download.pytorch.org/whl/cu130)
pip install vllm==0.23.0

2. MCSM-Agent 向け vLLM 起動スクリプト (start.sh)

MCSM-Agent の「脳」としてツール呼び出しと高速状態遷移をこなすための、最適化オプションをすべて盛り込んだ完全版スクリプト。

#!/bin/bash

# 構築した公式venv環境のパスを指定
ENV_DIR="/home/hayashi/vllm-pip-env"
LOG_FILE="${ENV_DIR}/log_vllm_Qwen3.6-27B-FP8_Agent.log"

# MTP対応のFP8モデル
MODEL="Qwen/Qwen3.6-27B-FP8"
PORT="8000"

source "${ENV_DIR}/bin/activate"

if [ -f "$LOG_FILE" ]; then
    rm "$LOG_FILE"
fi

# 過去のワークアラウンド（SAFETENSORS_FAST_GPU=0）は不要。eager オプションで安全にロード
nohup vllm serve "$MODEL" \
  --served-model-name "Qwen3.6-27B-FP8-Agent" \
  --language-model-only \
  --max-model-len 131072 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --enable-prefix-caching \
  --kv-cache-dtype fp8 \
  --mamba-cache-dtype float16 \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}' \
  --max-num-batched-tokens 8192 \
  --gpu-memory-utilization 0.80 \
  --safetensors-load-strategy eager \
  --host 0.0.0.0 \
  --port "$PORT" > "$LOG_FILE" 2>&1 &

echo "vLLM has started with model: $MODEL (MTP Enabled / Agent Mode)"
echo "Log file: $LOG_FILE"

前回の 122B-AWQ の戦いから数ヶ月。インフラの進化は、我々をカスタムビルドの泥沼から救い出し、ソフトウェアアーキテクチャ（MTP）の力でハードウェアの限界を突破させた。 この黄金のベースラインの上に、次世代の MCSM-Agent が構築されていく。MCSM-Agent を動かすだけの Local LLM なのですが、これだけでもいろいろありますね。