AI INFRAAWS2026.09.09

AWS、Qwen3.8-2.4TをHyperPodとvLLMで動かす手順を公開

AWSはQwen3.8-2.4T-A95BをAmazon SageMaker HyperPodとvLLMでdeployする手順を公開しました。2.4兆parameters、95B activated parameters、262K native context、NVFP4量子化、OpenAI-compatible endpointを扱います。

ROOT AI EDITORIAL

ここがポイント

open-weight frontier級modelは、model選定よりもGPU capacity、weight配置、autoscaling、health check、data capture、障害復旧が導入条件になります。self-hostingの自由度と運用責任を同時に評価する必要があります。

2.4兆parameter級open-weight modelをHyperPodで動かす手順です

AWSは2026年9月9日、Qwen3.8-2.4T-A95BをAmazon SageMaker HyperPodとvLLMでdeployする実装手順を公開しました。Qwen teamが2026年8月12日に公開したopen-weight modelを対象に、ml.p6-b300 instance上でOpenAI互換endpointとして動かす構成を説明しています。記事は、巨大modelを単にdownloadする話ではなく、cluster準備、量子化、推論operator、endpoint運用までを一連の本番workflowとして扱っています。

NVFP4量子化とreasoning controlまで含めています

発表によると、Qwen3.8-2.4T-A95Bは合計2.4兆parameters、tokenごとのactivated parametersは95Bです。native contextは262K tokensで、1M tokensまで拡張できると説明されています。AWSの構成では、NVFP4 quantization、vLLM、built-in reasoning、tool calling、native Multi-Token Prediction speculative decodingを扱います。model weightsはHugging Face上のTransformers formatを前提にし、約1.2TBへ圧縮されたcommunity quantizationを単一8-GPU nodeで扱う設計です。

self-hosted frontier級modelは運用設計が中心になります

企業がopen-weight modelを選ぶ理由は、dataを自社基盤に置けること、inference挙動を調整できること、token課金を避けやすいことです。一方で、2.4兆parameter級のmodelはGPUを用意すれば終わるものではありません。model取得、storage、GPU割当、health check、autoscaling、rolling update、endpoint監視を同時に管理する必要があります。AWSはHyperPod Inference Operatorで、宣言的なresource定義からこれらを扱う流れを示しています。

導入判断ではcapacityと失敗時復旧を先に見ます

実務での論点は、benchmark値よりも継続稼働の条件です。記事ではml.p6-b300.48xlargeにreserved capacityが必要で、Flexible Training Plansで確保する説明があります。長文agentやcoding agentをself-hostする組織は、cold start、model weight配置、node障害、data capture、cost上限を事前に設計する必要があります。open-weight採用は自由度を増やしますが、運用責任も自社側に戻るため、managed APIとの役割分担が重要になります。

公式発表を読む