タグ

Qwen3.8-Max

CometAPIで構築する複数モデルに1つのAPIが必要ですか？Playgroundでワークフローを試し、モデルとコストがユースケースに合ったらAPIキーを作成してください。

guide/CometAPIリサーチ

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

以下は、Qwen 3.8 Max（開源重み Qwen3.8-2.4T-A95B）をローカルデプロイするための実践ガイドです。vLLM/SGLang、FP8/FP4、最大 1M コンテキスト、そして本番最適化の観点を網羅します。前提 - モデルは 1M コンテキスト用に事前対応済み（訓練/微調整＋RoPE/NTK/YaRN 等の長文設定が含まれる）であることが望ましい。未対応チェックポイントに単純なスケーリングを適用すると品質・安定性が大きく劣化します。 - Hopper 世代（H100/H200/B100 など）の GPU を推奨（FP8、FlashAttention 世代最適化の恩恵が大きい）。モデル取得 - 例（Hugging Face/ModelScope から LFS で取得・ローカル配置）: $ git lfs install $ git clone <MODEL_REPO_URL> /models/Qwen3.8-2.4T-A95B - trust_remote_code が必要な場合は読み込み側で有効化（セキュリティポリシーに注意）。 GPU要件の見積もり（目安） - 重み（推論のみ）: - FP16/BF16: 約 2.0 GB × 1B パラメータ → 95B なら約 190 GB - FP8（weight-only + scale/metadata 含む）: 約 1.1–1.2 GB × 1B → 95B なら約 105–115 GB - 4-bit（AWQ/GPTQ 等 weight-only）: 約 0.55–0.6 GB × 1B → 95B なら約 52–57 GB - KV キャッシュ（非常に支配的。概算・GQA 前提の目安）: - FP16 相当で約 320 KB/トークン（GQA により MHA 比で圧縮済みと仮定） - FP8 で約 160 KB/トークン、FP4 で約 80 KB/トークン - 例: 128k トークンなら FP8 KV ≈ 160 KB × 128k ≈ 約 20 GB、1M トークンなら ≈ 約 160 GB - 実運用では 1M を常時保持するのは現実的でないことが多く、スライディングウィンドウ／KV オフロード／分割プリフィル等と併用するのが一般的。量子化（FP8/FP4）の選択肢 - FP8 - Hopper 世代推奨。weight-only の FP8 チェックポイントを利用するのが安定。KV キャッシュも FP8 化できるランタイムなら併用でメモリ削減。 - FP4（4-bit） - AWQ/GPTQ/HQQ 等の weight-only 量子化チェックポイント推奨。自前量子化する場合は AutoAWQ/GPTQ ツールチェーンで生成し、vLLM/SGLang が読み込める形式で保存。 - 品質の要点 - 4-bit は大幅に省メモリだが長文・推論安定性への影響が大きい。Max クラスの長文前提なら FP8 を基準に、必要に応じて 4-bit を評価。 vLLM での起動（例） - インストール（CUDA/torch は環境に合わせる）: $ pip install "vllm>=0.5.4" - OpenAI 互換 API サーバ: $ python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen3.8-2.4T-A95B \ --tensor-parallel-size 8 \ --dtype auto \ --max-model-len 1048576 \ --gpu-memory-utilization 0.90 \ --served-model-name qwen38-max \ --host 0.0.0.0 --port 8000 - 量子化・長文向けの追加例（環境・モデル対応に依存）: - KV キャッシュ圧縮: --kv-cache-dtype fp8（対応環境）または fp16/bf16 から選択 - チャンク化プリフィル: --enable-chunked-prefill True（大規模一括投入時の帯域効率改善） - CPU オフロード（足りない場合）: --swap-space <GB>（NVMe と組み合わせ） - シャーディング: --tensor-parallel-size N を GPU 台数に合わせる - 量子化重み: --quantization awq/gptq（該当フォーマットのモデルに一致させる） - クライアント呼び出し（OpenAI 互換）: - base_url=http://<host>:8000/v1 model=qwen38-max を指定して chat/completions 等を利用。 SGLang での起動（例） - インストール: $ pip install "sglang>=0.3.2" - サーバ起動（例）: $ python -m sglang.launch_server \ --model /models/Qwen3.8-2.4T-A95B \ --tp 8 \ --host 0.0.0.0 --port 8000 - 量子化・長文向けの追加例（実装バージョンに依存）: - --quantization awq/gptq - --kv-cache-dtype fp8（対応時） - --max-context-len 1048576（モデル対応が前提） - RadixAttention/Chunked prefill/Prefill–decode 並列化などの最適化フラグを有効化 1M コンテキスト運用のポイント - モデル側前提 - 1M に対応したチェックポイントを利用（config.json の rope_scaling/positional 設定が既に含まれていることが望ましい）。 - ランタイム側 - KV キャッシュ圧縮（fp8/fp4）やオフロード（CPU/NVMe）、チャンク化プリフィル、スライディングウィンドウを併用。 - 実際は 1M を常時保持せず、重要ブロックを残しつつ古いブロックを捨てる/圧縮する戦略が現実的。 - アプリ設計 - 検索拡張（RAG）や要約・圧縮、階層化メモリを併用して実効コンテキストを制御。本番最適化チェックリスト - 性能 - FlashAttention 2/3、Tensor Cores を活かす CUDA/ドライバを整備。 - バッチング/スケジューラ（vLLM/SGLang のデフォルト）を活用。max_num_seqs、max_tokens_per_batch をワークロードに合わせ調整。 - Speculative decoding/Chunked prefill/Continuous batching を有効化（サポート時）。 - Tensor parallel の分割数を GPU 台数・NVLink 括りに合わせ最適化。 - メモリ - FP8/FP4 の weight-only＋KV 圧縮、KV の CPU/NVMe オフロードを組み合わせて「重み＋KV」の合計が収まるよう設計。 - 長文要求が少ないトラフィックは短い max_model_len のプールへ分流（SLO を層分け）。 - 安定性/運用 - ウォームアップ（典型長で事前実行）、固定長プロンプトのキャッシュ、分散障害時のヘルスチェックと自動復旧。 - プロメテウス/ログ集約でトークンレイテンシ、KV ブロック使用率、OOM 直前指標を可視化。 - ノード間は NCCL/TCP チューニング（NVLink 推奨、跨りはレイテンシ増に注意）。 - 品質 - 量子化（特に 4-bit）は長文・推論安定性を A/B 測定。重要ジョブは FP8 を基準、必要なら混在デプロイ（ルーティング）で最適化。 - セキュリティ/再現性 - trust_remote_code の管理、モデル/依存の固定（hash/pin）、容器化（Docker/OCI）と CUDA 互換層の固定。代表的な構成例（目安） - 構成A（高品質・長文重視）: 8×H100 80GB, FP8 weight-only, KV=FP8, max_model_len 128k（ピーク時のみ 512k〜1M をスイッチ）、CPU/NVMe オフロード有。 - 構成B（省メモリ・高密度）: 4×H100 80GB, 4-bit weight-only（AWQ/GPTQ）, KV=FP8, max_model_len 64k〜128k、長文要求は別プールへ転送。 - 構成C（大規模 1M 実験）: 8–16×H100 80GB 以上, FP8 weight-only, KV=FP4/FP8 併用、強オフロード＋チャンク化プリフィル＋スライディングウィンドウ、長文は分割投入。トラブル対処の要点 - OOM: max_model_len/並列度/バッチサイズを下げる、KV 圧縮/オフロードを強化、TP を増やして再配置。 - 性能伸び悩み: スループット系フラグ（chunked prefill/continuous batching/speculative）とバッチ閾値を再調整、PCIe/ネットワーク帯域を確認。 - 品質低下: 量子化ビット幅/グループサイズを緩和、FP8 に戻す、長文時のみ高精度プールを使用。補足 - 実際の起動フラグ名やサポート状況は vLLM/SGLang のバージョンで変わります。該当バージョンの --help とリリースノートを確認し、モデルの量子化形式・長文設定と揃えてください。

Deon GoodwinAIモデルとAPIの調査チーム

更新日 Sep 25, 2026 7 分読み

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

先に回答

このパターンを使う

最初のAPI呼び出しを行う。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_COMETAPI_KEY",
    base_url="https://api.cometapi.com/v1",
)

response = client.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": "Build this workflow."}],
)

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

ローカルで 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 クラスのセルフホスティングはデータセンター導入です。実用的なプロダクションの出発点はです。H200 でのデプロイにはさらに多くの GPU が必要です。一般的なワークステーションでは Qwen3.8-27B を使用してください。

学習を続ける

この記事を次の判断につなげる。

すべてのトピックを見る

AI APIガイド

モデル候補の絞り込みから、本番で動くリクエストまで到達できます。

LLM インフラストラクチャ

プロバイダーやモデルの変更に耐える AI リクエスト層を構築します。

AIエージェント

プロンプトのデモから、可観測なエージェントワークフローへ移行します。

コスト最適化

品質や信頼性のトレードオフを隠さずに、コストを下げます。

公開日 Sep 25, 2026

最終更新 Sep 25, 2026

408 回視聴

明確性、出典の帰属、最新のAPI用語について確認済みです。

仕様	Qwen3.8-Max ホスト型サービス	Qwen3.8-2.4T-A95B オープンチェックポイント
総パラメータ	2.4T	2.4T
アクティブパラメータ	~95B	~95B
アーキテクチャ	スパース MoE	スパース MoE
入力	テキスト、画像、動画	テキスト
コンテキスト	1M マネージド・コンテキスト	262,144 ネイティブ；~1.01M まで拡張可能
思考動作	管理された思考／非思考オプション	思考必須；推論負荷は設定可能
組み込みツール	マネージドサービスで提供	アプリケーション側でツール提供が必要
セルフホスティング	ウェイト管理不要	あり；オープンチェックポイント

デプロイ関連の仕様	Qwen3.8-2.4T-A95B
総／アクティブパラメータ	2.4T / 1 トークンあたり約 95B
層構成	92 層：69 Gated DeltaNet + 23 フルアテンション
MoE ルーティング	512 のルーティッド・エキスパート；10 ルーティッド + 1 共有がアクティブ
フルアテンションヘッド	64 クエリ／4 キー・バリューヘッド
ネイティブコンテキスト	262,144 トークン
拡張コンテキスト	約 1,010,000 トークンまで
Multi-Token Prediction	対応
オープンチェックポイントのモダリティ	テキストのみ

ベンチマーク	Qwen3.8-Max	Qwen3.7-Max	GPT-5.6 Sol (max)
Terminal Bench 2.1	86.6	74.5	88.8
SWE-bench Pro	67.7	60.6	64.6
PaperBench	93.0	64.8	90.5
FrontierSWE	73.5	40.7	—
CoWorkBench	74.8	64.6	71.5
GPQA Diamond	92.6	92.4	94.1

精度	ウェイトフットプリント	B300 (268 GB)	MI355X (288 GB)	H200 (141 GB)	最適用途
BF16	4.45 TiB	24 GPUs	24 GPUs	48 GPUs	最高忠実度／リサーチ
FP8	2.27 TiB	16 GPUs	16 GPUs	32 GPUs	高忠実度のプロダクション
MXFP4	1.45 TiB	—	8 GPUs	16 GPUs	実用的な AMD デプロイ
NVFP4 W4A4	1.32 TiB	8 GPUs	—	16 GPUs	実用的な NVIDIA デプロイ

精度	概算ウェイトメモリ	実用的なデプロイ指針
BF16	~54 GB	コンテキストやサービングのオーバーヘッドに応じて 64–80 GB GPU を使用
FP8 / INT8	~27 GB	実運用の余裕を考慮し 40–48 GB GPU を推奨
4-bit	~13.5 GB	中程度のコンテキスト長なら 20–24 GB のコンシューマ GPU でも可

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"

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:

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

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

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

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)

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 \
  ...

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

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

観点	セルフホスト Qwen3.8-2.4T-A95B	CometAPI 経由の Qwen3.8-Max
インフラ	マルチ GPU サーバーまたはクラスター	GPU インフラ不要
入力モダリティ	テキスト	テキスト、画像、動画
コンテキスト	262K ネイティブ；~1.01M 拡張	マネージド 1M
データ制御	最大	クラウド API
オペレーション	監視・アップグレード・HA を自前で実施	プロバイダ管理
最適適用	データ常駐、持続的な高稼働、インフラチーム	多くのアプリチーム、変動するワークロード

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

Qwen3.8-Max

Qwen3.8-Max

もっと読む

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

最初のAPI呼び出しを行う。

この記事を次の判断につなげる。

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

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

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

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

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

Qwen3.8-27B の VRAM 要件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結論