Qwen3.8-2.4T-A95BをAmazon SageMaker HyperPodで展開

2026 年 8 月 12 日、アリババの Qwen チームが Qwen3.8-2.4T-A95B をリリースしました。これは、Qwen-Max クラスのモデルがオープンウェイトとして公開された初のケースです。

同モデルは総パラメータ数 2.4 兆（1 トークンあたり 950 億が活性化）、ハイブリッドな線形とフルアテンションを併せ持つアーキテクチャ、そしてネイティブで最大 262K トークンのコンテキスト長（拡張すれば 1M トークンまで対応）を備えています。Qwen3.8 は、多段階のコーディングや長期にわたる計画策定、自律的なツール利用など、最も負荷の高いエージェントタスクや推論ワークロードを対象としています。

オープンウェイトモデルを選べば、インフラ内でのデータ管理が完結し、推論動作のカスタマイズも可能になります。さらに、大規模運用時のトークンあたりの API 利用料も不要です。その代わり、運用面での課題は避けられません。2.4T パラメータモデルをホストするには、専用設計の GPU インフラと最適化されたサービングスタックが必要です。

本稿では、ml.p6-b300 インスタンス（8 基の NVIDIA B300 Blackwell Ultra GPU を搭載）上で Amazon SageMaker HyperPod にて vLLM を用いて Qwen3.8-2.4T-A95B をデプロイする方法を解説します。クラスターの構築から OpenAI 互換エンドポイントの提供まで、NVFP4 量子化や組み込み推論機能、ツール呼び出し、ネイティブなマルチトークン予測（MTP）によるスペキュレーションデコーディングに対応した vLLM の設定に至るまでの全工程をカバーします。

本シリーズは、Amazon SageMaker HyperPod上でトリリオンパラメータ級のオープンモデルをデプロイする方法を紹介するものです。前回の投稿ではKimi K3のデプロイについて取り上げましたので、そちらも併せてご覧ください。

Qwen3.8-2.4T-A95B の概要

Qwen3.8-2.4T-A95Bは、Qwen3.8-Maxのオープンウェイト版として公開されたモデルで、Qwenファミリーの中で最も大規模かつ高性能なモデルです。デプロイに関連する主要なアーキテクチャの詳細を以下にまとめます。

アーキテクチャ

ハイブリッドアテンション設計は、効率的な長文コンテキスト推論の鍵となります。92層中69層を占める「Gated DeltaNet」層では、線形アテンションと有界な再帰状態を採用し、増大する KV キャッシュに代わり固定サイズのメモリを使用します。一方、残りの 23 層である「Gated Attention」層は、高忠実度のトークン間相互作用を実現するために完全な二次アテンションを利用しています。この 3:1 の比率により、コンテキストが 100 万トークンに近づいても計算量とメモリ使用量を一定範囲内に抑えることが可能です。これは、多数のターンにわたってツール出力やコード、推論トレースを蓄積するエージェントワークロードにとって極めて重要な特性です。

微細な MoE（Mixture of Experts）アーキテクチャは、少数の大規模な専門家ではなく、512 の小規模な専門家に容量を分散させることで、ルーティング効率と特化性を向上させます。順伝播ごとにアクティブになるパラメータ数は約 95B に過ぎないため、サービスコストは全パラメータ数（2.4T）ではなく、実際に使用されるパラメータ数に基づいて算出されます。

機能と推論制御

Qwen3.8 は、マルチステップのコーディングや自律的なツール利用、長期にわたる計画策定、複雑な研究ワークフローといったエージェント実行を目的として設計されています。

開発者は、reasoning_effort パラメータ（low、medium、high）を通じて組み込みの推論制御機能を利用できます。

リクエストごとに計算資源と推論深度をトレードオフできます。複雑な多段階問題にはリソースを増やし、大量処理が必要なタスクでは減らすことで柔軟に対応可能です。

モデルの重みと量子化

オープンウェイトは、標準的な Transformers フォーマットで Hugging Face に公開されています。コミュニティによる量子化には MXFP4 や NVFP4（W4A4）があり、これによりモデルは約 1.2TB に圧縮されます。このサイズなら、B300 Blackwell Ultra GPU を搭載した 8 GPU ノード 1 台に収めることが可能です。

ベンチマークのハイライト

ベンダーが実施したベンチマークによると、Qwen3.8-2.4T-A95 は研究ワークフロー（PaperBench 93.0）、指示従順性（IFBench 82.8）、ターミナルベースのコーディング（86.6）において特に高い性能を発揮します。主要なカテゴリでは最先端モデルと互角の性能を示しますが、より難易度の高いリポジトリレベルのタスク（SWE-bench Pro）や一般的なツール利用（Toolathlon）ではまだ改善の余地があります。

独自 API に代わるセルフホスト型ソリューションを検討する組織にとって、これらの結果は Qwen3.8-2.4T-A95 をコーディングエージェントや研究パイプライン向けの信頼できる最先端クラスの選択肢として位置づけるものです。

大規模 MoE 推論に Amazon SageMaker HyperPod が適している理由

2.4T パラメータモデルのデプロイは、単なる GPU の問題ではありません。モデルのダウンロード、コンテナスケジューリング、ヘルスモニタリング、オートスケーリング、ノード障害への対応など、手動介入なしで実行できるオーケストレーションが不可欠です。Amazon SageMaker HyperPod は、まさにこの種のワークロードのために設計されたサービスです。

図 1: Amazon SageMaker HyperPod の高レベルアーキテクチャ

EKS によるオーケストレーション

HyperPod クラスターは、管理プレーンとして Amazon Elastic Kubernetes Service (Amazon EKS) を利用します。これにより、kubectl や Helm チャート、カスタムリソース定義など、Kubernetes の機能全体を活用できる一方で、AWS がネットワーク、ストレージ、GPU ドライバーのインストール、NVIDIA デバイスプラグインといった基盤インフラのライフサイクル管理を担います。

推論オペレーター

HyperPod Inference Operator（自動インストールまたは EKS Add-on として導入）は、InferenceEndpointConfig という単一のカスタムリソース定義 (CRD) を提供します。これにより、モデル、コンテナイメージ、GPU リソースの要求、vLLM の起動引数などを宣言的に指定できます。オペレーターが担当するのは以下の業務です。

• モデル重みのダウンロード（Hugging Face Hub、Amazon Simple Storage Service (Amazon S3)、または Amazon FSx から）
• コンテナのスケジューリングと GPU 割り当て
• ヘルスチェックと準備状態の確認
• ローリングアップデートとエンドポイントのライフサイクル管理
• KEDA を用いた自動スケーリング（Amazon CloudWatch または Prometheus メトリクスに基づく）

柔軟なトレーニングプランによる予約容量

ml.p6-b300.48xlarge インスタンスタイプには、予約された容量が必要です。Flexible Training Plans は、HyperPod クラスターに直接割り当て可能な GPU のコミットメント予約を提供します。オンデマンドプールとの競合はなく、起動時の容量不足リスクもありません。

耐障害性。 HyperPod はノードの健康状態を継続的に監視し、劣化したノードを自動的に置き換えます。24 時間稼働する推論ワークロードにおいて、これはハードウェア障害の検出や復旧を手動で行う運用負荷を大幅に軽減します。

追加の推論機能 (Inference Operator v3.x)：

• Disaggregated Prefill and Decode (DPD) – 事前計算（prefill）とデコードを別々の GPU プールに分離し、同時負荷下でもトークンごとのレイテンシを予測可能にします。

• Inference data capture – エンドポイント、ロードバランサー、またはポッドレベルで入出力データをログ記録します。

• Local NVMe model deployment – 重み付けデータをノードローカルのストレージから読み込み、コールドスタート時の遅延を削減します。

• Amazon Route 53 DNS management – エンドポイント用のカスタムドメインレコードを自動生成します。

つまり、デプロイする対象（what）を YAML マニフェストで記述するだけで、HyperPod が大規模かつ信頼性の高い実行方法（how）を自動的に処理してくれます。

インフラのサイズ調整：モデルに合わせたハードウェア選定

p6-b300 インスタンス

ml.p6-b300.48xlarge は、Qwen3.8 の単一ノードでの推論サービスに必要な計算密度を提供します。

NVFP4 量子化の必要性

BF16 精度において、Qwen3.8 の 2.4T パラメータは重みだけで約 4.8 TB のメモリを必要とします。これは単一の 8 GPU ノードの容量を超えています。一方、NVFP4（W4A4）量子化ではパラメータあたりのビット数を約 4 ビットに圧縮し、重みの総サイズを約 1.2 TB に抑えます。これなら p6-b300 インスタンスが持つ合計 2.1 TB の GPU メモリに余裕を持って収まり、KV キャッシュや活性化値のための領域も確保できます。

メモリ予算の概算

単一の p6-b300 ノードにおけるメモリ使用量の内訳は以下の通りです。

ハイブリッドアテンションアーキテクチャがここでの大きな利点です。69 層の DeltaNet レイヤーは、コンテキスト長に関わらず固定サイズの再帰状態を維持します。これは、従来のモデルのように KV キャッシュが各レイヤーごとに線形に増加するのと対照的です。文脈依存のメモリ成長に関与するのは、23 層のフルアテンションレイヤーのみです。

スループットの予想値

NVIDIA の GB300 NVL72（FP8、72 GPU）における Day-0 ベンチマークからの参考数値は以下の通りです。スループットは GPU あたり 4,000 トークン/秒以上、ユーザーあたり 350 トークン/秒を超えます。NVIDIA FP4 を搭載した単一の 8 GPU ノード（p6-b300）では、集約スループットはこれより低くなりますが、中程度の並行処理を想定した本番環境での推論ワークロードには十分に適しています。

キャパシティの調達

ml.p6-b300.48xlarge インスタンスタイプはオンデマンドでは利用できません。HyperPod クラスターに対して GPU の可用性を保証するFlexible Training Plan（柔軟なトレーニングプラン）を通じてキャパシティを確保する必要があります。インスタンスグループを設定する際は、ターゲットの Availability Zone をプランのアロケーションと一致させるようにしてください。

vLLM 設定の詳細解説

このセクションでは、単一の p6-b300 ノード上で Qwen3.8 を動作させるための vLLM サービングパラメータについて詳しく説明します。本設定は、B300（NVFP4）向け Qwen3.8 の vLLM レシピ に基づいています。

ベースとなるサービングコマンド

vllm serve の完全な呼び出しは以下の通りです。

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

主要フラグの説明：

• --tensor-parallel-size 8 – モデルを 8 枚の B300 GPU にシャードします。

• --quantization nvfp4 – NVIDIA の FP4 (W4A4) 量子化を有効にし、2.4T パラメータを持つモデルを 2.1 TB の GPU メモリに収まるようにします。

• --load-format fastsafetensors – 重みの非シリアライズ処理を高速化し、コールドスタート時の起動時間を短縮します。

• --trust-remote-code – Hugging Face 上の Qwen3.8 で使用されるカスタムモデル定義コードを実行するために必須です。

「--enable-prefix-caching」は、プロンプトの共通部分を持つリクエスト間で計算済みの KV キャッシュを再利用する機能です。システムプロンプトや会話履歴が繰り返し出現する多段階のエージェント対話において、この設定は極めて重要です。

「--moe-backend auto」は、ハードウェアに最適な MoE（Mixture of Experts）ディスパッチカーネルを vLLM が自動的に選択することを可能にします。

推論モード（思考モード）

--reasoning-parser qwen3 フラグは、モデルの出力ブロックから推論内容を抽出します。主な動作は以下の通りです： （原文の技術表記: ...）

Qwen3.8 の推論機能は、モデル側で追加のフラグを設定しなくてもデフォルトで有効になっています。

API からのレスポンスでは、思考プロセスを示す reasoning_content と、最終的な回答である content が分離して返されます。

特定の要求ごとにこの思考機能を無効化したい場合は、クライアント呼び出し時に extra_body={"chat_template_kwargs": {"enable_thinking": False}} を指定してください。

構造化出力（guided_json、guided_regex）は推論機能と併用可能です。構造化出力エンジンが制約するのは content フィールドのみです。

ツール呼び出し（関数呼び出し）

--enable-auto-tool-choice および --tool-call-parser qwen3 フラグを使用すると、OpenAI 互換の関数呼び出しが可能になります。

• tool_choice パラメータには、auto、required、none、および特定の関数名を指定できます。

ツール呼び出しは、content フィールドのみから解析されます。reasoning_content は関数呼び出しの解析対象にはなりません。これにより、モデルが「どのツールを呼ぶか」について推論した上で、構造化された呼び出しを別個に出力することが可能になります。

ツール定義で tool_choice="auto" と strict: true を設定すると、vLLM はツールの引数に対してスキーマ制約付きのデコーディングを適用し、有効な JSON 出力を実現します。

推測的デコーディング（ネイティブ MTP）

--speculative-config '{"method":"mtp","num_speculative_tokens":1}' フラグを使用すると、Qwen3.8 に内蔵されたドラフトヘッドを活用したマルチトークン予測が可能になります。

• Qwen3.8 は MTP に対応してトレーニングされており、軽量なドラフトヘッドがモデルの重みに含まれています。別途ドラフトモデルをダウンロードしたり、設定を追加したりする必要はありません。

ドラフトヘッドは、次の N トークンを並列で予測し、その後 1 回の順伝播で検証を行います。承認されたトークンは個別のデコードステップをスキップするため、スループットが向上します。

num_speculative_tokens: 1 は安全な初期設定値です。スループットが重要なワークロードでは、vLLM の /metrics エンドポイントを通じて監視し、承認率が十分に高いことを確認した上で、2〜3 に増やすことができます。

MTP は、ドラフトステップにおいてモデルの既存の隠れ状態を再利用するため、遅延オーバーヘッドは最小限に抑えられます。

SageMaker HyperPod でのデプロイ手順

本記事で取り上げた完全なデプロイマニフェストとスクリプトは、GitHub リポジトリ で公開されています。

前提条件

モデルのデプロイを行う前に、p6-b300 の容量を備えた稼働中の HyperPod クラスターが必要です。

• EKS オーケストレーションによる HyperPod クラスターの作成

Amazon SageMaker AI コンソールで「HyperPod Clusters」に移動し、「Create（作成）」を選択します。「Orchestrated by Amazon EKS」を選び、デフォルトのネットワーク設定と IAM を使用する「Quick Setup」か、既存の VPC とサブネットを利用する「Custom Setup」のいずれかを選択してください。Inference Operator が自動的にインストールされるよう、「Use default Helm charts and add-ons（デフォルトの Helm チャートおよびアドオンを使用）」が選択されていることを確認します。

• 柔軟なトレーニングプランのプロビジョニング

インスタンスタイプグループの設定で、容量ソースとして「Training plan」を選択します。ml.p6-b300.48xlarge をカバーし、必要なインスタンス数と期間を指定したプランを作成するか、既存のプランにアタッチしてください。ターゲット可用性ゾーンは、プランのアロケーションと一致するように設定します。

• p6-b300 ワーカーグループの追加

ml.p6-b300.48xlarge インスタンスを少なくとも 1 つ含むインスタンスタイプグループを追加し、クラスターが健全な GPU ノードを持つ「Active」状態になるまで待ちます。

• アクセスの確認

クラスターへの接続が可能か確認します：

kubectl get nodes
# Expect node(s) with nvidia.com/gpu: 8 capacity

InferenceEndpointConfig マニフェスト

vLLM 設定で Qwen3.8 をデプロイするには、以下の InferenceEndpointConfig を適用してください。