2.4兆パラメータのQwen3をシングルノードで動かす — AWSが量子化で1.2TBまで圧縮し、B300 GPU 8枚に収める手法を公開

9月10日、AWSが「Deploying Qwen3.8-2.4T-A95B on Amazon SageMaker HyperPod with vLLM」と題した記事を公開した。2.4兆パラメータという桁外れの規模を持つQwen3.8-2.4T-A95Bを、マルチノードではなくシングルノード8GPUで動かすための量子化・デプロイ手法の全貌が示されており、大規模MoEモデルの実運用に踏み込もうとするエンジニアにとって読み応えのある内容だ。

2.4兆パラメータのモデルをシングルノードで動かす

2026年8月12日（Alibabaによる公開日）、Qwen3.8-2.4T-A95Bがオープンウェイトとして公開された。Qwen-Maxクラスのモデルがオープンウェイトとして登場したのはこれが初めてであり、本記事はその直後にAWSがデプロイ手法をまとめたものだ。

このモデルの主な仕様は以下の通り。

「総パラメータ2.4兆」という数字は圧倒的だが、MoEアーキテクチャにより、1トークン処理あたりに実際に動くのは約950億パラメータに限定される。推論コストはフルの2.4兆ではなく、活性化パラメータ数に追従する構造だ。

ハイブリッドアテンション設計

92層のうち69層はGated DeltaNet（線形アテンション）、23層がGated Attention（フル二次アテンション）という3:1構成を採る。DeltaNet層はKVキャッシュの代わりに固定サイズの再帰的状態を持つため、コンテキストが100万トークン規模まで伸びてもメモリ消費が線形増加しない。ツール呼び出しや推論トレースを何ターンにもわたって積み上げるエージェント系ワークロードにとって重要な特性だ。

なぜBF16では動かないのか：NVFP4量子化が前提

BF16精度でQwen3.8の2.4兆パラメータを保持するには約4.8TBのメモリが必要となり、シングルノードには収まらない。そこで**NVFP4（W4A4）量子化を適用し、重みを1パラメータあたり約4ビットに圧縮する。結果として重みのフットプリントは約1.2TB**まで縮小される。

今回の推奨インスタンスであるml.p6-b300.48xlarge（8× NVIDIA B300 Blackwell Ultra GPU）は、GPUメモリが1枚あたり288GB HBM3e、合計2.1TB。量子化後の1.2TBを収めた上で、KVキャッシュとアクティベーション用のヘッドルームを確保できる計算だ。「8枚でギリギリ」ではなく、2.1TBのうち1.2TBを重みに割き、残り約900GBをキャッシュ・アクティベーション・バッチ処理に充てるという構成であることに注意してほしい。

量子化による精度トレードオフ

NVFP4量子化はメモリ効率に優れる一方、BF16と比較して精度劣化が生じる可能性がある。元記事はこの点に深く踏み込んでいないが、一般に4ビット量子化では数学的推論や長文生成において誤差が蓄積しやすい傾向がある。本番運用に際しては、自社タスクでの品質評価を別途実施することが推奨される。（※編集部の考察）

インスタンス入手方法について

ml.p6-b300.48xlargeはオンデマンド提供されていない。現状はAWSのFlexible Training Planによるキャパシティ予約が前提となる。Flexible Training Plan以外の選択肢として、Reserved InstanceやSavings Plansによる長期契約も一般的な手段だが、ml.p6-b300.48xlargeについてはAWSの担当チームへの個別問い合わせが実質的な入口となる点に留意したい。（※編集部の考察）

vLLMの設定：4つのポイント

記事のコアとなるのが、以下のvLLM起動コマンドだ。

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --quantization nvfp4 \
  --load-format fastsafetensors \
  --trust-remote-code \
  --enable-prefix-caching \
  --moe-backend auto \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --served-model-name Qwen3.8

① 推論モード（Thinking Mode）

--reasoning-parser qwen3を指定することで、モデルが出力する<think>...</think>ブロックをAPIレスポンス上でreasoning_content（思考トレース）とcontent（最終回答）に分離して返す。リクエスト単位でシンキングを無効化したい場合は、クライアント側でextra_body={"chat_template_kwargs": {"enable_thinking": False}}を渡せばよい。

② ツール呼び出し

--enable-auto-tool-choiceと--tool-call-parser qwen3により、OpenAI互換のファンクションコールが有効になる。tool_choice="auto"かつstrict: trueを設定すると、vLLMがツール引数のスキーマ制約デコーディングを実施し、有効なJSON出力を保証する。また、関数呼び出しのパースはcontentフィールドのみから行われるため、モデルがreasoning_contentでツール選択を思考してから、contentで構造化された呼び出しを出力するという自然な流れが実現する。

③ ネイティブMTP投機的デコーディング

--speculative-config '{"method":"mtp","num_speculative_tokens":1}'が注目ポイントだ。Qwen3.8はモデル重みの中にMulti-Token Prediction（MTP）用のドラフトヘッドを内包しており、別途ドラフトモデルをダウンロードする必要がない。ドラフトヘッドがN個のトークンを並列予測し、シングルフォワードパスで検証することでスループットが向上する。スループット重視の環境ではnum_speculative_tokensを2〜3に上げることも可能で、採用率はvLLMの/metricsエンドポイントで監視できる。

④ プレフィックスキャッシング

--enable-prefix-cachingは、システムプロンプトや会話履歴が共通するリクエスト間でKVキャッシュを再利用する機能だ。複数ターンにわたるエージェント系ワークロードでは特に効果が大きい。

SageMaker HyperPodを選ぶ理由

AWSはなぜSageMaker HyperPodを推すのか。端的に言えば、2.4Tモデルのデプロイはモデルダウンロードからヘルスモニタリング、ノード障害復旧まで含めた運用全体が問題になるからだ。

HyperPod Inference OperatorはInferenceEndpointConfigというCRD（カスタムリソース定義）1つで、モデル・コンテナイメージ・GPUリソース要求・vLLM起動引数を宣言的に記述できる。その他、KEDAを使ったAmazon CloudWatch/Prometheusメトリクスによるオートスケーリング、ノード障害時の自動置換といった運用機能も備える。

また、DPD（Disaggregated Prefill and Decode）と呼ばれる機能も提供される。これはプリフィル（プロンプト全体を処理して最初のトークンを生成するフェーズ）とデコード（後続トークンを逐次生成するフェーズ）を別々のGPUプールに分離する手法で、プリフィルの計算集約性とデコードのメモリ帯域依存性を独立してスケールさせることができる。結果として、初回応答レイテンシ（TTFT）とスループットを個別に最適化できるのが利点だ。

「YAMLマニフェストで何をデプロイするかを書けば、HyperPodがどう動かすかを管理する」というのが記事のまとめだ。

詳細はDeploying Qwen3.8-2.4T-A95B on Amazon SageMaker HyperPod with vLLMを参照していただきたい。