Qwen 3.8 Max をローカルにデプロイする方法：ハードウェア、vLLM、SGLang、量子化に関するガイド

ローカルで Qwen3.8-Max を実行することは今や可能ですが、「Qwen 3.8 Max をローカルで」という表現には重要な注意点が一つあります。Alibaba のホスト型 Max 製品とダウンロード可能なチェックポイントは密接に関連していますが、同一の製品ではありません。

Qwen は 2026 年 8 月上旬にホスト型 Max サービスを最初に提供し、2026 年 8 月 12 日に Qwen3.8-2.4T-A95B をオープンウェイトとして公開しました（リンク）。このチェックポイントこそが、実際に自社インフラにデプロイするモデルです。

これは一般的な「ゲーミング PC 上の Ollama」チュートリアルではありません。非量子化チェックポイントは 2.4 兆パラメータの Mixture-of-Experts モデルであり、現行の vLLM レシピでは BF16 ウェイトのサイズが 4.45 TiB とされています。実運用志向の 4-bit 浮動小数点変種でも、ウェイト容量はおおよそ 1.3～1.5 TiB に達します。

簡潔な答え: 完全な Qwen 3.8 Max クラスのセルフホスティングはデータセンター導入です。実用的なプロダクションの出発点は 8× B300 または 8× MI355X GPU 上の FP4 チェックポイント です。H200 でのデプロイにはさらに多くの GPU が必要です。一般的なワークステーションでは Qwen3.8-27B を使用してください。

Qwen 3.8 Max と実際にデプロイするオープンモデルの違い

ダウンロード可能な Qwen3.8-2.4T-A95B チェックポイントは、1 トークンあたり約 95B パラメータがアクティブな 2.4T パラメータの因果言語モデルと公式に説明されています。ホスト型 Max サービスは、現行のオープンチェックポイントにはないプロダクト層の機能を追加しています。

ホスト型製品は、テキスト・画像・動画入力と 1,000,000 トークンのコンテキストを提供します。対照的に、オープンチェックポイントはテキスト専用で、ネイティブのコンテキストは 262,144 トークンです。アプリケーションがマルチモーダル入力やマネージドの組み込みツールに依存する場合、この差は重要です。

Qwen 3.8 のアーキテクチャと仕様

CometAPI は「What is Qwen3.8 Max」でモデル背景を既に扱っているため、このデプロイガイドではメモリ、並列化、サービングに影響する詳細に絞って解説します。

Qwen チームの SGLang Qwen3.8 デプロイガイドで使用されている公式の Qwen ハイブリッド・モデル・アーキテクチャ。

「95B のアクティブパラメータ」を、95B モデル相当のメモリフットプリントと解釈しないでください。スパース活性化はトークン当たりの計算量を減らしますが、サービングシステムは依然として全エキスパートのウェイトセットにアクセスする必要があります。

Qwen 3.8 Max ベンチマークのスナップショット

CometAPI の既存の Qwen3.8 Max 概要でベンチマークは詳述されているため、本記事では公式の Qwen モデルカードのベンチマーク表から、デプロイに関係するサブセットのみを取り上げます。

Qwen チーム によって公開された公式の Qwen3.8 パフォーマンスグラフィック。

このサブセットで Qwen3.7-Max に対する最大の改善は PaperBench と FrontierSWE です。Qwen3.8-Max は SWE-bench Pro と PaperBench で GPT-5.6 Sol を上回る一方、Terminal Bench 2.1 では GPT-5.6 Sol が先行しています。デプロイ判断では、これらは能力の文脈として扱い、以下のメモリやサービングスループット測定をより運用面の指標としてください。

ベンチマーク表は普遍的なランキングではありません。ハーネス、タイムアウト、コンテキスト制限、ツールアクセス、量子化により結果は変わり得ます。使用予定のチェックポイント、精度、サービングエンジン、プロンプト分布を厳密に一致させてベンチマークを行ってください。

ローカルデプロイに Qwen3.8 はどんなハードウェアを必要とするか？

Qwen3.8-2.4T-A95B の GPU 要件

これが主要なデプロイ論点です。現行の vLLM Qwen3.8 レシピ は、チェックポイントのフットプリントと実運用を想定した GPU 台数（ランタイムの余裕込み）を公開しており、単純にパラメータ数から VRAM を見積もるより有用です。

本当に Qwen3.8 をセルフホストする必要がある多くの組織にとって、実用的な出発点は FP4 です。NVIDIA 側の注目構成は 8× B300 での NVFP4 W4A4 で、AMD 側の対応は 8× MI355X での MXFP4 です。

8× H200 サーバーは、これら推奨のフルモデルデプロイには足りません。公式レシピでは FP4 に 16× H200、FP8 に 32、BF16 に 48 を割り当てています。

Qwen3.8-27B の VRAM 要件

Qwen3.8-27B は実用的なワークステーションクラスの代替です。生のウェイトメモリは BF16 で約 54 GB、FP8 で 27 GB、4-bit で 13.5 GB です。ランタイムのオーバーヘッドと KV キャッシュにより、特に長いコンテキスト長では実際の必要量が増加します。

これらはパラメータ数から導いた計画用の概算です。プロダクションのハードウェアを選定する前に、正確なチェックポイント、量子化形式、サービングエンジン、コンテキスト長、KV キャッシュ設定で確認してください。

Qwen3.8 はコンシューマ向け GPU で動作するか？

フルの Qwen3.8-2.4T-A95B モデルは、強い量子化を行っても一般的なコンシューマ GPU では実用的ではありません。コミュニティプロジェクトは 4 台の DGX Spark を跨いだ 397 GB の UD-Q1_0 ビルドという極端な圧縮のデモを示しましたが、これは品質重視のサービングにおける基準ではなく、実験的な極端量子化のアプローチです。

ワークステーションやホームラボには、より適切なのは Qwen3.8-27B です。オープンウェイトは 2026 年 8 月 14 日に公開されました。このモデルはホスティングが桁違いに容易で、「ローカル」が 1 台のワークステーションを意味する場合に適した選択です。

Qwen 3.8 Max をインストールする前に

インストールコマンドを実行する前にインフラを計画してください。Linux、互換のアクセラレータスタック、チェックポイント用の十分なローカルまたは共有ストレージ、高帯域の GPU 相互接続、およびノードを跨ぐ場合は分散推論向けに設計されたネットワークが必要です。vLLM レシピは現在、vLLM nightly と Transformers 5.4.0 以降 を推奨しています。

bash

uv venv
source .venv/bin/activate

uv pip install -U vllm \
  --extra-index-url https://wheels.vllm.ai/nightly

uv pip install -U "transformers>=5.4.0"

vLLM で Qwen 3.8 を FP8 でデプロイする方法

Qwen 提供のチェックポイントを使いたく、かつマルチノードインフラが許容できる場合、FP8 は賢明な選択です。公式チェックポイントは Qwen/Qwen3.8-2.4T-A95B-FP8 です。

2 ノード・16 GPU の B300 クラスデプロイでは、ヘッドノードで以下を実行します。

bash

export HEAD_ADDR="10.0.0.10"

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 0 \
  --master-addr "$HEAD_ADDR" \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3
On the worker node, use the same topology with a different node rank and no API server:

bash

export HEAD_ADDR="10.0.0.10"

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 1 \
  --master-addr "$HEAD_ADDR" \
  --headless \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3

この 16 GPU の例を H200 サーバーにサイズ変更せずにそのまま移植しないでください。同じ FP8 変種でも、vLLM レシピでは現在 32× H200 と見積もられています。

1 台の 8× B300 サーバーで Qwen 3.8 を動かす方法

NVIDIA Blackwell では、最も実用的なフルモデル構成は NVFP4 です。vLLM は現在、8 基の B300 にまたがるテンソル並列で NVFP4 W4A4 を検証しています。

bash

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

Inferact の NVFP4 ビルドは、元の BF16 の Qwen アーティファクトではなく量子化チェックポイントです。BF16 や FP8 の代替として扱う前に、自組織の受け入れセットでモデル品質を検証してください。

SGLang で Qwen 3.8 をデプロイする方法

SGLang は 8 月 12 日に Qwen3.8 の Day-0 サポート を追加しており、高スループットサービング、プレフィックスキャッシュ、エキスパート並列、推測デコーディング、プレフィル／デコードの分離において特に魅力的です。

bash

SGLANG_ENABLE_MOE_DEFERRED_FINALIZE=1 \
SGLANG_FLASHINFER_MNNVL_CUTEDSL_AR_FUSION=1 \
sglang serve \
  --trust-remote-code \
  --model-path RadixArk/Qwen3.8-2.4T-A95B-NVFP4 \
  --tp-size 8 \
  --context-length 200000 \
  --preferred-sampling-params '{"top_k": 20}' \
  --attention-backend trtllm_mha \
  --linear-attn-prefill-backend flashinfer \
  --linear-attn-decode-backend flashinfer \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --host 0.0.0.0 \
  --port 30000

SGLang は、MTP を用いた TP8 B300 でバッチサイズ 1 の場合に 346 出力トークン／秒を報告しており、分離サービング構成では総合スループットがさらに大きくなります。これらの数値はサービングスタックの測定値であり、モデル品質のベンチマークではないと解釈してください。

ローカルの OpenAI 互換エンドポイントをテストする

vLLM と SGLang はどちらも OpenAI 互換の API を公開しているため、アプリケーション統合は容易です。

python

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
    timeout=3600,
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-2.4T-A95B-FP8",
    messages=[
        {
            "role": "user",
            "content": "Design a fault-tolerant Redis architecture for three regions."
        }
    ],
    temperature=1.0,
    top_p=0.95,
    max_tokens=8192,
)

print(response.choices[0].message.content)

公式のモデルカードは、ベースラインのサンプリングパラメータとして temperature=1.0、top_p=0.95、top_k=20 を推奨しています。エージェント的な作業では、最終的な可視回答だけでなく推論にも十分な出力予算を残してください。

1M コンテキストウィンドウを有効にする

Qwen3.8-2.4T-A95B オープンチェックポイントは 262,144 トークンのネイティブコンテキストを持ち、約 1.01M まで拡張できます。vLLM レシピは以下のパターンを記しています:

bash

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \
vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --max-model-len 1010000 \
  --hf-overrides '{"max_position_embeddings": 1010000}' \
  --reasoning-parser qwen3 \
  ...

サポートされるからといって 1M をデフォルトにしないでください。最大コンテキストを大きくするとキャッシュ容量を多く予約し、同時実行性が大幅に低下する可能性があります。--max-model-len は実際のワークロードに合わせて設定してください。

Qwen3.8 の推論性能を向上させるには？

単一ユーザーのレイテンシを下げるために MTP-3 を使用する

Qwen3.8 は Multi-Token Prediction を含みます。vLLM の公開測定では、MTP-3 により FP8 TP16 の場合にユーザー当たりの出力が 130 から 307 tok/s に、NVFP4 TP8 で 133 から 304 tok/s に向上します。

bash

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

fastsafetensors を使って起動時間を短縮する

テラバイト規模のモデルでは、起動時間が重要です。ある vLLM の計測では、fastsafetensors と遅延読み込みによりウェイトのロード時間が 545 s から 306 s に短縮されました。

bash

--load-format fastsafetensors \
--safetensors-load-strategy lazy

エキスパート並列を使って同時スループットを増やす

高い同時実行を求める場合、Qwen3.8 は 512 のルーティッド・エキスパートを持つため、エキスパート並列レイアウトが有効です。vLLM は FP8 EP で最大 3,200 total tok/s/GPU、最適化された NVFP4 DEP16 構成で最大 4,300 total tok/s/GPU を報告しています。

--max-model-len を適切に設定して VRAM と同時実行のバランスを取る

--max-model-len はワークロードが本当に必要とする最長シーケンス長に設定してください。値が大きいほど KV キャッシュの予約が増え、メモリ圧力が高まり、モデルウェイトが既に収まっていても同時処理数が減ることがあります。

モデルが宣伝する最大コンテキストではなく、代表的な本番パーセンタイルから始めてください。同じ精度、バッチパターン、サービングエンジンでロードテストし、実際の要求がより長いコンテキストを必要とする場合のみ引き上げます。

Qwen 3.8 Max のローカルデプロイと API の比較

オープンウェイトは、ローカル推論が自動的に経済的であることを意味しません。適切な判断は、稼働率、データ常駐要件、要員体制、可用性目標、そしてマネージドモデルのマルチモーダル機能が本当に必要かどうかに依存します。

既に適切なアクセラレータを保有し、持続的に高い稼働率が見込める場合、セルフホスティングは正当化できます。もしこのモデルのためだけにクラスターを調達するなら、通常は CometAPI 上の Qwen3.8-Max のほうが摩擦が少ないでしょう。既存の API ガイドはホスト型の統合を、料金ガイドはコストモデルを扱っているため、本記事はローカルデプロイに焦点を当てています。

Qwen 3.8 のローカルデプロイでよくある問題

サーバーが起動時に GPU メモリ不足になる

キャッシュが原因なら --max-model-len をまず下げてください。ウェイト自体が収まらない場合、コンテキストを削っても根本解決にはならないため、検証済みの低精度チェックポイントに移行するか GPU を追加してください。

テンソル並列のサイズが無効で失敗する

Qwen3.8 はフルアテンション層に 64 のアテンションヘッドを持つため、vLLM は TP が 64 を割り切ることを要求します。単純な TP サイズは 1、2、4、8、16、32 です。合計 VRAM 容量だけではトポロジは決められません。

サーバーの起動に長時間かかる

1～数テラバイトのウェイトのロードに加え、カーネルの JIT もあり、起動には数分を要します。VLLM_ENGINE_READY_TIMEOUT_S を増やし、短い起動時間を前提にせず実際の推論エンドポイントをプローブしてください。

ローカルモデルが画像を処理できない

それは想定どおりです。オープンな 2.4T チェックポイントはテキスト専用です。マルチモーダル入力はマネージドの Qwen3.8-Max 製品に属します。~~

Qwen3.8-2.4T-A95B のオープンチェックポイントはテキスト専用です。この制限は Qwen3.8-2.4T-A95B に固有です。Qwen3.8-27B は、別途ビジョン投影ファイルをロードした場合に視覚入力をサポートします。

1M コンテキストでスループットが大幅に低下する

--max-model-len を、ワークロードが実際に必要とする最長シーケンスに下げてください。サポートされる最大のコンテキストウィンドウが最適な本番設定とは限りません。ワークロード要件、KV キャッシュ使用量、同時実行性のバランスが取れるコンテキスト制限を選びましょう。

Ollama や LM Studio は Qwen 3.8 Max を実行できるか？

エコシステムは、llama.cpp スタイルの推論のために強く量子化された Qwen3.8 ウェイトをパッケージ化できますが、それを一般的なデスクトップの Ollama ワークフローと混同すべきではありません。数百 GB を占める量子化ビルドは、依然として数百 GB のアクセス可能なメモリを要求し、品質と性能に大きなトレードオフを伴います。

通常のローカル開発には、Qwen3.8-27B が適切なターゲットです。極端なコミュニティ量子化により異例のハードウェアで技術的に起動できるとしても、フルの 2.4T モデルはサーバー／クラスター向けモデルとして扱うべきです。

どのデプロイ方法を選ぶべきか？

NVIDIA Blackwell では、8× B300 の NVFP4 デプロイが現在もっともすっきりしたフルモデルの出発点です。AMD では、8× MI355X の MXFP4 が対応する実用構成です。チェックポイントの出所と品質をインフラ規模より優先する場合は FP8 を、最大忠実度が複数ラック規模のメモリ要件を正当化する場合にのみ BF16 を選びましょう。

ワークステーションには Qwen3.8-27B を。GPU クラスター運用なしで Max の機能が必要なアプリチームには、ホスト型の Qwen3.8-Max（CometAPI） を推奨します。

結論

Qwen3.8-Max は初期の API 提供以来の重要な境界を越えました。すなわち、Max クラスの Qwen ファミリーにおいて、組織が完全に自社インフラで運用可能な 2.4T のオープンチェックポイントが登場したことです。

しかし、オープンウェイトはコンシューマハードウェアを意味しません。4.45 TiB の BF16 フットプリント、2.27 TiB の FP8 チェックポイント、1.3～1.5 TiB の FP4 変種により、Qwen3.8-2.4T-A95B は入手可能なオープンモデルの中でも最もインフラ負荷が大きい部類に入ります。実用面の救いは、vLLM と SGLang が既にこのアーキテクチャをサポートしていること、そして FP4 により 1 ノードの 8× B300 または 8× MI355X デプロイが現実的になることです。

データ制御、持続的な稼働率、インフラ所有がクラスターを正当化する場合はセルフホストを。それ以外はマネージドの Max API を使用するか、「ワークステーション 1 台で強力な Qwen モデル」を望むなら Qwen3.8-27B を選びましょう。