Dell GB10 (Grace Blackwell) ベアメタル推論：Qwen3.5 への挑戦と決断

【プロローグ】 Qwen3.5 の登場と、ローカルエージェント「頭脳」の進化

我々はこれまで、構築したばかりのGB10環境で Qwen/Qwen3-Coder-30B-A3B-Instruct-FP8 を稼働させ、opencode の自律型コーディングエージェントのローカル・バックエンドとして活用していた。

しかし、エージェントに複雑なリファクタリングやアーキテクチャ設計を任せると、ある種の「知能の限界」を感じる場面が増えてきた。30Bクラスのモデルは「指示された作業」はこなせるが、深い文脈を維持し、複数の解決策を比較検討するといった能力においては、クラウド上の巨大なプロプライエタリ・モデルには及ばない。

そんな折、Alibabaから次世代モデル Qwen3.5 シリーズが発表された。

• Gigazine: Qwen 3.5 medium model series が発表
• Zenn: Qwen 3.5 についての考察

我々が特に注目したのは、シリーズの最高峰である 122B（1220億パラメータ）モデル だ。この規模のモデルになると、単に知識が多いだけでなく、出力を生成する前に内部で自己評価と推敲を行う「深い推論（Reasoning / Thinking Process）」が可能になる。

「GB10の128GBユニファイドメモリというハードウェア・リソースがあるなら、この122Bクラスの知能をローカルに幽閉できるのではないか？」 ここから、インフラの限界に挑む我々の本当の戦いが幕を開けた。

【第一部】 罠だらけのvLLMアップデートと、Qwen3.5-27B-FP8 の稼働検証

Qwen3.5シリーズをエージェントの頭脳として迎え入れるにあたり、我々はインフラの地盤固めから着手した。 当時GB10で稼働していたvLLM（0.16.0rc1.dev142）は、Qwen3.5の最新アーキテクチャ（reasoning_parser="qwen3" やハイブリッドなリニアアテンション等）に完全対応している保証がなかったからだ。

1. 依存関係を破壊する「AIの罠」と、エンジニアの眼力

GB10環境（sm_121）での推論は、我々が依存関係地獄を抜け出してソースからビルドしたカスタム版の torch-2.11.0a0 の上に成り立っている。単純に pip install --upgrade vllm を叩けば環境が破壊されることは分かっていたため、私はAIアシスタントに「PyTorch環境を維持したまま、vLLM本体だけをソースから更新する手順」を策定させた。

AIが提示した手順は、GitHubから最新のソースを git pull し、キャッシュを消してからビルドするというものだった。私は提案通りにコマンドを実行した。

export TORCH_CUDA_ARCH_LIST="12.1"
export VLLM_TARGET_DEVICE="cuda"
export MAX_JOBS=16
pip install -e . --no-build-isolation

しかし、長いコンパイルが終わり、意気揚々と vllm --version を叩いた私を待っていたのは、ImportError: libtorch_cuda.so: cannot open shared object file: No such file or directory という致命的なクラッシュだった。

私はAIの推測を盲信することをやめ、「実機が認識している値を直接確認する」方針へと転換した。ビルド時の膨大なログを遡り、AIにこの事実を突きつけた。

AIの提示したコマンドには、依存関係の自動更新を防ぐ --no-deps オプションが欠落していたのだ。私は直ちにリカバリ手順を実行し、カスタムPyTorchを復元した。

pip uninstall -y torch torchvision torchaudio
pip install ~/src/my_wheels/torch-2.11.0a0+git15dbd45-cp312-cp312-linux_aarch64.whl

再度 vllm --version を叩くと、ターミナルには誇らしく 0.16.0rc1.dev1001+gad9d09e2b.cu131 と表示された。GB10専用の基盤を維持したまま、vLLMをQwen3.5対応の最新版へ引き上げるという外科手術的なアップデートに勝利した瞬間だった。

2. スピードか、賢さか。モデル選定の意思決定

環境が整った後、我々は中規模クラスのモデル選定を行った。候補に挙がったのは Qwen3.5-35B-A3B（MoEモデル）と Qwen3.5-27B-FP8（Denseモデル）の2つだ。

この決断の際も、私はAIと議論を交わした。

我々がエージェントの頭脳に求めているのは「圧倒的なIQ」である。この理論的裏付けにより、我々は迷いなく Qwen3.5-27B-FP8 を採用した。

3. エージェント特化の起動オプションと、PadeAttentionの真理

モデル選定後、我々はOpenHandsなどのエージェントを極限まで快適に動かすための「究極のチューニング」に着手した。

私は、過去の知見とログの数値を元に、AIの提案に対してさらに深いシステム論的な切り込みを行った。

この対話を経て、我々はエージェント運用に不可欠な以下のオプションをすべて盛り込んだ。

• --enable-auto-tool-choice & --tool-call-parser qwen3_xml: エージェントの関数呼び出し（Tool Calling）を正しくJSONに変換させる。
• --enable-prefix-caching: 共通のプロンプトをキャッシュし、エージェントの周回ループを劇的に高速化する。
• --enforce-eager の削除: 過去のデッドロックの真犯人（mmap競合）はすでに環境変数で排除済みであると判断。安全装置を外し、CUDA Graph（事前コンパイル）を有効化してリミッターを解除した。

完成した起動コマンドがこれだ。

vllm serve Qwen/Qwen3.5-27B-FP8 \
  --trust-remote-code \
  --language-model-only \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --gpu-memory-utilization 0.75 \
  --tensor-parallel-size 1 \
  --max-model-len 65536 \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --safetensors-load-strategy eager \
  --host 0.0.0.0 --port 8000

起動ログには torch.compile と Capturing CUDA graphs の文字が踊り、見事にフルコンパイルでの起動に成功した。

4. 思考プロセスの確認と、残された「速度の違和感」

正しく動作しているか確認するため、APIを叩いて素数を出力するPythonスクリプトを書かせた。

{"role":"assistant","content":"Thinking Process:\n\n1.  **Analyze the Request:**\n    * Task: Write a Python script to output prime numbers between 1 and 100.\n    * Role: Excellent AI Programmer.\n    * Language: Japanese (concise).\n    * Constraint: \"Concise\" (簡潔に).\n\n2.  **Determine the Algorithm:**\n...

見事に reasoning が機能し、内部で深い思考プロセスを展開していることが確認できた。エージェントの知能は確実に進化していた。

しかし、実際の推論ログを確認した我々は、ある種の「違和感」を覚えた。

(APIServer pid=126243) INFO 03-04 00:52:44 [loggers.py:259] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 7.8 tokens/s...

実測スピード： 7.8 tokens/s

AIは「Denseモデル（毎回270億パラメータをロードする）とGB10の帯域幅を考えれば妥当な速度だ」と解説した。決して遅くはない。実用的な速度ではある。 しかし、最先端の Grace Blackwell をベアメタルで回しているにしては、物足りない数値だった。 「設定の方向性は間違っていない。ならば、より知能の高い122Bモデルを同じ手法で動かしてみよう」。我々は意気揚々と次のステップへ駒を進めた。しかし、それはNVFP4という底なし沼への入り口だった。

【第二部】 さらなる高みへ。122Bモデルへの挑戦と、NVFP4の絶望とパズル

エージェントの頭脳として Qwen3.5-122B-A10B を迎え入れるにあたり、最初の物理的なハードルは「メモリ容量」だった。 1220億パラメータのモデルをFP8（1パラメータ=1バイト）のままロードしようとすると、重みデータだけで120GB以上のVRAMを食いつぶす。GB10の総メモリ容量128GBに対して、KVキャッシュを置く場所が残らないため、FP8での稼働は物理的に不可能だった。

そこで我々が目をつけたのが、Blackwell世代で初搭載された最新の量子化フォーマット 「NVFP4（4ビット浮動小数点）」 だ。モデルサイズを半分の約72GBに圧縮できるこの夢の技術なら、GB10のVRAMに余裕で収まるはずだった。

しかし、意気揚々と txn545/Qwen3.5-122B-A10B-NVFP4 をロードした我々を待っていたのは、不可解な挙動とエラーの連続、そして「ユニファイドメモリの罠」だった。

罠1：致死量のメモリ要求と「100GB SWAP強行突破」

モデルのロードを開始した直後、なぜかVRAM消費が異常に膨れ上がり、Pythonのエラーすら吐かずに無言でプロセスが落ちる現象が発生した。 ログを解析した結果、原因はデッドロック回避のために入れていた --safetensors-load-strategy eager という「一括読み込みオプション」にあった。

GB10は、CPUとGPUが同じ物理メモリ（128GB）を共有する「ユニファイドメモリ（UMA）」である。 NVFP4とはいえ、一部の層は16ビットのままであるため、実際のファイルサイズは 82.8 GB あった。ここで eager を実行するとどうなるか？

「CPU用の読み込みバッファ（82.8 GB）」と「GPU用の最終配置先（82.8 GB）」を同時に要求し、瞬間的に約165.6GBのメモリを要求してしまう。 物理限界（128GB）をあっさりと突破した結果、Linuxカーネルの OOM Killer が発動し、vLLMプロセスを「システムへの脅威」とみなして問答無用で暗殺（SIGKILL）していたのだ。

正攻法なら一括読み込みをやめる場面だが、ここで私はインフラエンジニアとしての「力技（ハック）」を提案した。

私は直ちに sudo fallocate -l 100G /swapfile を実行し、100GBの巨大なSWAP領域を緊急増設した。 結果は見事だった。ロード中、SSDのアクセスランプが激しく点滅し、SWAPが猛烈な勢いで消費・解放される様子が htop で確認できた。我々はOOMの死神をすり抜け、魔の「モデルロードの壁」を完全に突破したのである。

罠2：再起動の悲劇と「VRAMサンドイッチ」の謎

最初の起動は、約10分のコンパイル（torch.compile）を経て見事に成功し、14.9 tokens/s という爆速スループットを叩き出した。 しかし悲劇は、サーバーを再起動した後に訪れた。

全く同じスクリプトを叩いたにも関わらず、今度はロードすら始まらずに瞬殺されたのだ。 AIは「裏でpythonのゾンビプロセスが生き残っている」「再起動でSWAPが消えている」と的外れな推測を並べ立てた。私は冷静に事実のみを突きつけた。

ここには、PyTorchのコンパイル機構の恐ろしい罠が潜んでいた。 初回起動時は10分かけてゆっくりコンパイルするため、PyTorchは計算用の一時データをこまめに捨て（ガベージコレクション）、メモリ消費は平穏だった。しかし再起動後は、/tmp に残っていた巨大な計算マニュアル（.soファイル群）をSSDからVRAMへ「一気読み」したため、再び 31GB の致死的なメモリスパイクを引き起こしていたのだ。

この31GBのスパイクにより、GB10のメモリは**「天井と床に挟まれた極限のサンドイッチ状態」**に陥っていた。

• 床（最低限必要なVRAM）: モデル(72GB) ＋ キャッシュ展開スパイク(31GB) ＝ 103GB
• 天井（物理的な空き容量）: 総メモリ(121GB) − OS使用分(15GB) ＝ 106GB

0.8（約97GB確保）では床に届かず「KVキャッシュ領域がマイナスになる」と自爆し、0.9（約109GB確保）では天井を突き破って即死する。このシビアな物理限界（隙間わずか3GB）の中で、キャッシュを毎回完全に消去して初期状態（10分のコンパイル）を再現するか、バッチサイズを下げてスパイクを抑え込むしか、起動する術はなかった。

罠3：DeepResearchが暴いた「NVFP4のハードウェア的な絶望」

キャッシュを消し、パラメータを精緻にチューニングし直しても、推論中に突如として CUDA driver error: an illegal instruction was encountered（不正な命令）というハードウェアレベルのクラッシュが頻発するようになった。

私はこの不毛なモグラ叩きに見切りをつけ、AIエージェント（DeepResearch）に「GB10 (sm_121) における vLLM NVFP4 推論の Illegal Instruction エラー」に関する包括的な調査を命じた。 そこで明らかになったのは、マーケティング名の裏に隠された、ソフトウェアとハードウェアの残酷なミスマッチの真実だった。

1. GB10の「TMEM欠如」: GB10（Compute Capability sm_121）には、B200等のデータセンター向けチップ（sm_100）に搭載されている専用SRAM（TMEM）や、NVFP4をネイティブに直接計算するための第5世代Tensor Core命令（tcgen05等）が物理的に存在していなかった。
2. ソフトウェアの無謀な最適化: vLLMのバックエンドであるFlashInferやTritonコンパイラは、「Blackwell世代ならSM100の命令が使えるはずだ」と盲信し、GB10に対して存在しないTMA命令やFP4専用カーネルを投げつけて自爆（Illegal instruction）していた。
3. 精度と速度の代償: GB10でNVFP4を動かすには、ソフトウェア層で無理やりFP8やFP16に展開（アンパック）する迂回ルートを通る必要がある。しかしこれは、コンパイル時に異常なメモリスパイクを生むだけでなく、推論スピードを相殺し、数学的精度まで大きく劣化させるという、AIモデルにとって最悪のトレードオフを引き起こすことが判明した。

「NVFP4を強引に動かすのは、悪手である」。 この痛みを伴う結論に至った我々は、NVFP4のパズルを完全に捨て去り、AWQ（INT4） フォーマットへと戦略的な大転換（ピッチ）を行う決断を下したのである。

【第三部】 戦略的ピッチ：AWQによる大勝利と、VRAMパズルの完成

NVFP4を強引に動かすのは悪手である。この痛みを伴う結論に至った我々は、NVFP4のパズルを完全に捨て去り、AWQ（Activation-aware Weight Quantization / INT4） フォーマットへと戦略的な大転換（ピッチ）を行う決断を下した。採用モデルは QuantTrio/Qwen3.5-122B-A10B-AWQ である。

AWQの最大の強みは、「重み（Weights）は4ビットに圧縮してVRAM消費を抑えつつ、計算の途中経過（アクティベーション）はFP16の高精度で行う」という点にある。これにより、NVFP4で直面した精度劣化を防ぎつつ、GB10のアーキテクチャ上の地雷（不正命令エラー）を完璧に回避できる。

しかし、この方針転換に対して、私はインフラエンジニアとしての懸念をAIにぶつけた。

大勝利の瞬間と、ゾンビプロセスの罠

安全策を組み込んだコマンドを1行にまとめ、いざ実行。巨大なモデルのダウンロードを経て、ついにターミナルに Application startup complete. の文字が輝いた。

私は早速テスト用の curl コマンドで推論を試みた。ストリーミングモードのターミナルには、一切の淀みなく、完璧な日本語でGB10のユニファイドメモリについて語るテキストがパラパラと出力された。

しかし、ここでちょっとした事故が起きた。

AIは sudo pkill -9 -f vllm 等での対処を提案したが、私はそれが対症療法に過ぎないことを見抜いていた。

潔く sudo reboot を実行し、SWAPを再有効化してクリーンな状態で起動すると、再びシステムは完璧に立ち上がった。

実測値が暴いた「パラドックス」の真相

起動後、継続的な推論テストを行い、サーバー側のログに記録されたスピードを確認した。

(APIServer pid=3964) INFO 03-14 22:46:35 [loggers.py:259] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 14.6 tokens/s...
(APIServer pid=3964) INFO 03-14 22:46:45 [loggers.py:259] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 14.6 tokens/s...

ここで我々は、信じられない「逆転現象」を目の当たりにした。 以前稼働させていた軽量なはずの 27B Denseモデル（FP8）の速度は 7.8 tokens/s だった。 しかし、パラメータ数が約4.5倍に膨れ上がった 122Bモデル（AWQ）の方が 14.7 tokens/s と、なんと2倍近く速いのである。

なぜこんなことが起きるのか？ このGB10特有のパラドックスは、「メモリ帯域とアクティブパラメータの算数」で完全に説明がつく。

• 27B-FP8 のロード量（遅い理由）: Denseアーキテクチャのため、1文字生成するたびに全270億パラメータが稼働する。1トークンあたりのデータ転送量は約27GB。
• 122B-A10B-AWQ のロード量（速い理由）: MoEアーキテクチャのため、1220億の知識を持ちながら、1文字生成時に稼働するのはたったの100億（10B）パラメータ。さらにAWQ（4ビット）圧縮により、データ転送量はたったの約5GB。

GB10のユニファイドメモリ環境においては、「1回の計算でメモリからGPUコアへ運ぶデータ量」がスピードのすべてを決定づける。アクティブパラメータが小さく圧縮されている122B-AWQの方が、圧倒的に通信量が少ないため、倍の速度を叩き出せたのだ。

最後の欲求：リミッター解除の壁

速度、安定性、そしてIQ。すべてを手に入れたが、私はインフラエンジニアとして「さらなる限界」を試さずにはいられなかった。

私は果敢に --enforce-eager を外し、フルパワーでのコンパイルに挑んだ。 しかし、ログは残酷な真実を告げた。

(EngineCore_DP0 pid=3441) File "/home/.../mamba/ops/causal_conv1d.py", line 1162, in causal_conv1d_update (EngineCore_DP0 pid=3441) assert num_cache_lines >= batch (EngineCore_DP0 pid=3441) AssertionError

これにより、現在の環境の「真の限界」が完全に確定した。 Qwen3.5-A10B のようなハイブリッドモデルを現在のvLLMで動かす場合、ソフトウェアのバグにより事前コンパイルは物理的に不可能である。つまり、先ほど成功させた **--enforce-eager を付けた状態の 14.7 tokens/s こそが、現在の世界最先端のソフトウェアスタックにおける「真の最高速度（完成形）」**だったのである。

【第四部】 決断：どちらをエージェントの「頭脳」に選ぶか、そしてGB10運用の真理

2つの環境構築と実測検証を終え、我々は最終的な決断を迫られた。 「自律型AIエージェントのバックエンドとして、27B-FP8 と 122B-AWQ のどちらを採用すべきか？」

一般的なAIアーキテクチャの理論によれば、それぞれに長所がある。

• Qwen3.5-27B-FP8（Dense）の強み: 全パラメータを均等に使うため、コーディング時の厳格な文法やJSONスキーマの出力において、無劣化（FP8）の恩恵を受けて極めて安定した結果を出す。事実、SWE-bench等の静的コード生成テストでは122Bを凌駕するスコアを出すことがある。
• Qwen3.5-122B-AWQ（MoE）の強み: 256のエキスパートプールがもたらす広範な知識と、圧倒的なIQ。難解なエラーログを解読し、複数のツールを駆使しながら環境構築やデバッグを自律的に行う「DevOps操作」においては、他を寄せ付けない能力（Terminal-Bench 2等で圧勝）を誇る。

【GB10環境における最終結論】 理論上は「コーディング専用のワーカーには27B、システム全体のデバッグや計画立案のマネージャーには122B」というハイブリッド運用が理想に思える。

しかし、我々がGB10で計測した**「122Bの方が2倍速い（14.5 t/s vs 7.8 t/s）」**という物理的な実測データが、すべてを決した。 エージェント運用において、推論速度（思考ループの速さ）はタスク完了時間に直結する。IQが圧倒的に高く、深い自己推敲（Thinking Process）が可能であり、しかも実機でのレスポンススピードが2倍速い。

GB10においては、迷う余地はない。 我々は QuantTrio/Qwen3.5-122B-A10B-AWQ を、メインエージェントの頭脳として正式に採用する決断を下した。

最後のインフラ的真理：CUDA Graph の無力さと Eager モードの絶対性

我々はこの長きにわたる検証の中で、GB10環境を運用する世界中のエンジニアに伝えるべき「もう一つの重要な真理」に到達した。 それは、**「--enforce-eager（事前コンパイルの無効化）こそが、GB10における絶対の正義である」**ということだ。

通常、CUDA Graph（事前コンパイル）は、CPUからGPUへの命令遅延（オーバーヘッド）を隠蔽して推論を高速化するために必須の技術とされる。しかし、Grace CPUとBlackwell GPUがC2C（Chip-to-Chip）で超広帯域直結されているGB10環境では、そもそもCPUの命令オーバーヘッドがほぼ存在しない。推論速度の真のボトルネックは「LPDDR5xメモリの帯域幅」に依存しきっている。

事実、非常に安定していた27Bモデルにおいて、わざわざ安全装置を外して10分かけてCUDA Graphを構築してみたが、速度は 7.8 tokens/s からピクリとも上がらなかった。

つまり、GB10において事前コンパイルを行うことは**「10分の不毛な起動時間と、約30GBの無駄なコンパイル用VRAM消費と、Tritonコンパイラのバグ（Illegal instruction）という莫大なリスクを背負いながら、リターン（速度向上）がゼロ」**という最悪のトレードオフだったのだ。

我々はこの事実を実測データから突き止め、不要な力技を排し、堅牢なEagerモードで稼働させることを「GB10における持続可能なベストプラクティス」として完全に確定させた。

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

Dell GB10 上で Qwen3.5-122B を最高速かつ安定して稼働させる、現時点における世界の最前線の結論スクリプトである。 もし何らかの理由で強制終了し、VRAMにゾンビプロセスが残って起動しなくなった場合は、sudo reboot を行い、この手順に戻れば確実に復旧する。

1. サーバーのクリーンアップと準備

# SWAPの有効化（ロード時の一時的なVRAM/RAM共有スパイクを逃がすため必須）
sudo swapon /swapfile

# 検証中だけど、今はこれをオンにして動いている。
export SAFETENSORS_FAST_GPU=0 は絶対に設定しないこと。

2. vLLM 起動スクリプト (start.sh)

#!/bin/bash

ENV_DIR="/home/hayashi/vllm-env"
LOG_FILE="${ENV_DIR}/log_vllm_Qwen3.5-122B_AWQ.log"
# NVFP4の罠を避け、帯域幅とGB10に最も優しいAWQモデルを指定
MODEL="QuantTrio/Qwen3.5-122B-A10B-AWQ"
PORT=8000

source "${ENV_DIR}/bin/activate"

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

# 古いコンパイルキャッシュによる汚染を防ぐため完全消去
rm -rf ~/.cache/vllm/torch_compile_cache
rm -rf /tmp/torchinductor_hayashi

# AWQ ＋ Eagerモードの最強安定設定（CUDA Graphリスクの完全排除）
nohup vllm serve "$MODEL" \
  --enforce-eager \
  --gpu-memory-utilization 0.8 \
  --reasoning-parser qwen3 \
  --enable-chunked-prefill \
  --tensor-parallel-size 1 \
  --max-model-len 65536 \
  --max-num-batched-tokens 4224 \
  --quantization awq \
  --kv-cache-dtype fp8 \
  --safetensors-load-strategy eager \
  --language-model-only \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --enable-prefix-caching \
  --host 0.0.0.0 \
  --port "$PORT" > "$LOG_FILE" 2>&1 &

echo "vLLM has started with model: $MODEL"
echo "Mode: Eager (Stable), Quantization: AWQ"

この環境を手に入れた今、我々のコーディングエージェントは1220億パラメータという真の知性を獲得した。CUDA 13の壁、ARM64の罠、そしてNVFP4の絶望から始まったインフラアーキテクトとしての執念の茨の道は、ここに強固なハイウェイとして開通したのである。