はじめに
2026年8月13日 午前1時(JST)頃、Alibaba の Qwen チームから Qwen3.8-2.4T-A95B のモデルウェイトが公開されました。8月3日の発表時点で「Max クラスとしては初のオープンウェイト化」と予告されていた、2.4T パラメータのフラッグシップモデルです。
フィックスターズでは、2週間前の Kimi-K3 の Day1 デプロイ検証に続き、今回もウェイト公開の当日に NVIDIA B300 x8 のシングルノード環境へデプロイし、推論性能のベンチマークを実施しました。本記事はその速報です。計測条件は前回と揃えてあるので、Kimi-K3 との直接比較もできます。
Qwen3.8-2.4T-A95B とは
Qwen3.8-2.4T-A95B は Alibaba Qwen チームが開発したフロンティアクラスの MoE(Mixture of Experts)モデルです。主な仕様は以下のとおりです。
| 項目 | 仕様 |
|---|---|
| 総パラメータ数 | 2.4T(2兆4000億) |
| アクティブパラメータ数 | 95B(950億) |
| アーキテクチャ | Qwen3.5 アーキテクチャベースの MoE |
| アテンション方式 | ハイブリッド: Gated DeltaNet(線形アテンション、全体の約75%) + GQA(約25%) |
| 公開ウェイトの精度 | BF16 / FP8 |
| コンテキスト長 | 256K トークン(1M トークンに拡張可能) |
| マルチモーダル | ネイティブ対応(テキスト・画像・動画入力) |
| 投機的デコーディング | MTP(Multi-Token Prediction)モジュール内蔵 |
| 推論モード | reasoning effort を low / medium / xhigh で設定可能 |
| ライセンス | Qwen3.8-Max License(独自ライセンス) |
アーキテクチャは Qwen3.5 / Qwen3-Next 系のハイブリッド構成の順当なスケールアップです。レイヤーの約75%が Gated DeltaNet(線形アテンション)、残り約25%が通常の GQA(query 64 ヘッド / key-value 4 ヘッド)で、これに疎な MoE と内蔵 MTP が組み合わさります。詳細は SGLang cookbook のモデル紹介にまとまっています。
推論サーバの並列戦略の観点で興味深いのは、Kimi-K3 のときに効果が大きかった DCP(Decode Context Parallelism)が、Qwen3.8 では推奨構成に入っていない点です。これは、75% を占める線形アテンション部分はロングコンテキストでも KV キャッシュ負荷が増えにくく、残る GQA 部分も KV ヘッドが 4 と少ないため TP8 ではヘッドが 2 倍に複製されるだけで済み、MLA 主体の Kimi-K3 に比べて DCP の効果が小さいためと考えられます。
発表時のメッセージングは「コーディングと長時間の自律エージェントワーク」に振り切っています。10日以上の無人自律コーディング、約500ターンに及ぶチップ設計最適化、1年分の EC 運営シミュレーションといった、長期タスクの実績が前面に出ているのが特徴です。API 側では OpenAI 互換に加えて Anthropic 互換インターフェースも提供されており、既存のコーディングエージェントに差し込みやすい設計です。
今週中に小型の Qwen3.8-27B もオープンウェイト化が予定されており、こちらはローカル・エッジ向けの選択肢になります。本記事ではフラッグシップの Qwen3.8-2.4T-A95B のみを扱います。
超大規模オープンウェイトモデルの Day1 デプロイ検証は、2週間前の Kimi-K3(2.8T)に続いて今回が 2 回目です。
検証環境
| 項目 | 内容 |
|---|---|
| GPU | NVIDIA B300 SXM6 x8(シングルノード) |
| GPU メモリ | 275.04 GB x8(nvidia-smi 読み) |
| 推論エンジン | SGLang(lmsysorg/sglang:qwen38 イメージ) |
| 並列構成 | TP=8 |
| 投機的デコーディング | 内蔵 MTP モデル(NEXTN) |
推論エンジンは今回も SGLang を選択しました。NVFP4 量子化ウェイトが Day-0 でサポートされていたこと(後述のとおり、これが 1 ノード動作の生命線です)、DSpark ドラフトまで Day-0 対応が揃っていたこと(今回は内蔵 MTP を使ったため未使用)、そして前回の Kimi-K3 と条件を揃えて比較するためです。
メモリフットプリントの検討
総パラメータ 2.4T のモデルは、BF16 でウェイトだけで約 4.8TB、FP8 でも約 2.4TB となり、本環境の GPU メモリ合計(約 2.2TB)には収まりません。1 ノードで動かすには 4bit 級(約 1.2〜1.5TB)まで落とす必要があります。
Qwen から公式に提供されているウェイトは BF16 または FP8 精度のため、そのままでは 1 ノードに収まりません。今回は SGLang 公式から提供されている NVFP4 量子化ウェイト RadixArk/Qwen3.8-2.4T-A95B-NVFP4 を使用してデプロイしました。面白いことに、この NVFP4 版はモデル本体のリリースより約 4 時間早く Hugging Face 上にアップロードされていました。SGLang 側が Day-0 対応をどれだけ周到に準備していたかが分かります。なお vLLM 向けには Inferact 版の NVFP4 ウェイトが用意されています。
Kimi-K3 が MXFP4 ネイティブ配布(QAT 済み)で「そのまま 1 ノード」を実現していたのと異なり、量子化による精度劣化が発生しうることに注意が必要です。モデルカードによると、Terminal-Bench 2.1 ベンチマークの精度が 86.6%(avg@10)から 87.64%(pass@1)に変化していますが、Terminal-Bench 2.1 の問題数が 89 問と少ないため誤差の範囲と考えられます。
デプロイ
ウェイトのダウンロード
ダウンロードはKimi-K3 のときに比べてスムーズでした。公開カウントダウンが Hugging Face ではなく ModelScope 側で行われていたため、Hugging Face へのアクセス集中が緩和されていたのかもしれません(今回 ModelScope 経由のダウンロードは試していません)。
ダウンロードしたのは公式 FP8 版(約 2.5TB、比較検証用)、NVFP4 版(約 1.48TB、今回のデプロイに使用)、DSpark ドラフト(約 6.6GB、結局未使用)です。NVFP4 版は終盤にやや速度が落ちたものの、問題なく完走しました。
起動コマンド
SGLang cookbook の推奨構成に従いました。
docker run --gpus all \
--shm-size 32g \
-p 30000:30000 \
-v ${HF_HOME}:/root/.cache/huggingface \
--env SGLANG_FLASHINFER_MNNVL_CUTEDSL_AR_FUSION=1 \
--ipc=host \
lmsysorg/sglang:qwen38 \
sglang serve \
--trust-remote-code \
--model-path RadixArk/Qwen3.8-2.4T-A95B-NVFP4 \
--tp-size 8 \
--moe-runner-backend flashinfer_trtllm \
--mamba-radix-cache-strategy extra_buffer \
--mamba-ssm-dtype bfloat16 \
--speculative-algorithm NEXTN \
--speculative-num-steps 3 \
--speculative-eagle-topk 1 \
--speculative-num-draft-tokens 4 \
--enable-linear-replayssm-spec \
--mem-fraction-static 0.90 \
--chunked-prefill-size 8192 \
--max-prefill-tokens 8192 \
--reasoning-parser qwen3 \
--tool-call-parser qwen3_coder \
--host 0.0.0.0 \
--port 30000
Qwen3 系アーキテクチャからの順当な巨大化ということもあり、オプションはすべて一般的なものです。Kimi-K3 の --mamba-full-memory-ratio のようにワークロードに合わせた調整が必要なモデル固有パラメータで悩む場面はなく、TP=8 も標準的な構成です。投機的デコーディングは、モデルに内蔵されている MTP モジュールを NEXTN として使います。
起動時間: 合計約 65 分
起動完了までの合計時間は約 65 分、うちウェイトのロードが本体約 57.5 分 + MTP ドラフト約 2.3 分でした。Kimi-K3 の合計約 88.8 分(うちロード約 81.4 分)より 20 分以上短いですが、それでも「一度起動したら気軽には再起動できない」規模であることは変わりません。
前回ハマった「docker logs だとモデルロード中の進捗が見えない」問題は、今回は docker run をフォアグラウンドで流しっぱなしにしていたため遭遇しませんでした。バックグラウンド起動する場合は docker logs -f で追うのが安全です。
GPU メモリ内訳と KV キャッシュ
起動後の steady state における GPU メモリ使用量の内訳です(per-rank, TP0 代表)。
| 項目 | サイズ (GB) | 備考 |
|---|---|---|
| GPU 総メモリ | 275.04 | B300 SXM6 |
| 使用中 (nvidia-smi) | 261.5 | 起動後 steady state |
| 空き | 約 13.5 | |
| └ モデルウェイト(本体) | 167.44 | Qwen3_5MoeForCausalLM, NVFP4 (modelopt_fp4) |
| └ モデルウェイト(MTP ドラフト) | 7.32 | Qwen3_5ForCausalLMMTP, NVFP4 |
| └ Mamba Cache (GDN state pool) | 29.40 | conv 0.83 + ssm 28.47 + conv_window 0.10 |
| └ GQA KV Cache | 33.72 | K 16.86 + V 16.86、1,537,600 トークン (bf16) |
| └ MTP KV Cache | 1.46 | K 0.73 + V 0.73、1,537,600 トークン (bf16) |
| └ その他 (CUDA graph / NCCL / context 等) | 約 22.2 | 残差 |
Kimi-K3 と同様にハイブリッドモデルなので、KV キャッシュに相当するプールが複数確保されます。
| プール | 容量 | 用途 |
|---|---|---|
| GQA KV | 1,537,600 トークン | 全体の約25%を占める GQA 層用。コンテキスト容量の主指標 |
| Mamba state | 844 リクエスト | Gated DeltaNet の同時実行リクエスト上限 |
| MTP KV | 1,537,600 トークン | 投機的デコーディング用ドラフトの KV |
実効コンテキストキャパシティは約 1.54M トークンです。Kimi-K3 のとき(メモリ配分の設定ミスもあって約 0.53M)の約 3 倍のトークンを、デフォルト設定のまま確保できています。線形アテンションが 75% を占めるため KV フットプリントがそもそも小さいことが効いています。なお KV は bf16 で確保されているので、FP8 KV にすれば単純計算で約 3M トークンまで倍増できるはずです。そこまで確保できれば、オフロードと組み合わせて 1M コンテキストを複数ユーザーで実用するラインが見えてきます。
ベンチマーク結果
前回の Kimi-K3 検証と同一の 2 種類の負荷でスループットとレイテンシを測定しました。
Random (ISL=8K, OSL=1K, num-prompts 200)
| 並列数 | duration (s) | out_tput (tok/s) | total_tput (tok/s) | TTFT med/p90/p99 (ms) | ITL med/p90/p99 (ms) | failed |
|---|---|---|---|---|---|---|
| 10 | 298.0 | 687.2 | 6,184.5 | 371 / 618 / 2,745 | 20.9 / 21.6 / 271 | 0 |
| 20 | 215.6 | 950.0 | 8,549.7 | 389 / 886 / 5,443 | 27.0 / 28.3 / 279 | 0 |
| 30 | 183.2 | 1,117.7 | 10,059.3 | 401 / 3,323 / 8,159 | 31.5 / 33.8 / 284 | 0 |
| 40 | 164.1 | 1,248.2 | 11,233.5 | 414 / 6,035 / 10,852 | 35.1 / 40.9 / 288 | 0 |
| 50 | 155.8 | 1,314.8 | 11,833.1 | 2,253 / 8,740 / 25,458 | 38.3 / 93.1 / 343 | 0 |
各行の入出力トークンはいずれも in 1,638,400 / out 204,800 です。Kimi-K3 では並列数 50 で 200 リクエスト中 119 が失敗しましたが、今回は全条件で失敗ゼロでした。
コーディングエージェント社内実データセット (max-duration 300, multi-turn)
今回は低並列側(1 / 2 / 4)も追加で計測しています。
| 並列数 | duration (s) | out_tput (tok/s) | total_tput (tok/s) | TTFT med/p90/p99 (ms) | ITL med/p90/p99 (ms) | failed |
|---|---|---|---|---|---|---|
| 1 | 312.5 | 238.6 | 1,249.0 | 116 / 248 / 339 | 10.1 / 10.3 / 10.5 | 0 |
| 2 | 313.2 | 431.3 | 1,802.4 | 121 / 281 / 475 | 11.4 / 11.8 / 12.0 | 0 |
| 4 | 324.9 | 614.3 | 2,821.3 | 112 / 272 / 541 | 14.3 / 14.8 / 16.9 | 0 |
| 10 | 335.9 | 961.3 | 5,383.0 | 133 / 303 / 1,851 | 21.8 / 23.0 / 69 | 0 |
| 20 | 355.4 | 1,321.1 | 7,988.7 | 165 / 437 / 641 | 28.7 / 30.4 / 108 | 0 |
| 30 | 454.9 | 1,487.1 | 7,355.3 | 179 / 638 / 761 | 34.0 / 36.4 / 137 | 0 |
| 40 | 460.9 | 1,687.9 | 8,322.6 | 193 / 662 / 1,230 | 38.9 / 42.6 / 175 | 0 |
| 50 | 438.6 | 1,942.5 | 9,080.2 | 1,604 / 3,223 / 4,867 | 41.5 / 46.6 / 189 | 0 |
スループットのスケーリング
左: total スループット(入力+出力)、右: output スループット。参考として Kimi-K3(同一ハードウェア・同一負荷)の実測値を点線で併記。並列数 50 でも失敗ゼロだが、TTFT の中央値が跳ね上がる(NEXTN 有効時の同時実行上限 48 によるキュー待ち)。
Kimi-K3 との比較
同一ハードウェア・同一負荷条件での、2.8T の Kimi-K3 との比較です。
| 項目 | Kimi-K3 (2.8T / 104B active) | Qwen3.8-2.4T-A95B (2.4T / 95B active) |
|---|---|---|
| ウェイトサイズ(実測) | 約 1.57TB (MXFP4) | 約 1.48TB (NVFP4) |
| 量子化ウェイトの提供元 | Moonshot 公式(QAT 済み) | SGLang 公式(RadixArk、事後量子化) |
| 起動時間(合計 / モデルロード) | 88.8 分 / 81.4 分 | 65.3 分 / 59.8 分 |
| KV キャッシュ容量(デフォルト設定) | 約 0.53M トークン | 約 1.54M トークン |
| Random: ピーク total tput | 5,847.6 tok/s(並列 40) | 11,833.1 tok/s(並列 50) |
| 実データ: ピーク total tput | 3,879.6 tok/s(並列 30) | 9,080.2 tok/s(並列 50) |
| 実用上の同時リクエスト上限 | 30 程度(超過で失敗発生) | 48(NEXTN の同時実行上限、超過分はキュー待ち) |
所見
率直に言って速いです。同一条件の Kimi-K3 に対して、total スループットはおおむね 2 倍。低並列側で差がとくに顕著で、実データセットの並列数 10 では 5,383.0 vs 2,477.6 tok/s と 2.2 倍の開きがあります。エージェント用途で効く ITL も、並列数 10 で中央値 21.8ms(Kimi-K3 は 38.7ms)と大幅に短縮されています。
スケーリング特性も対照的です。Kimi-K3 は並列数 30〜40 で頭打ちになり 50 で失敗が多発しましたが、Qwen3.8 は並列数 50 まで total スループットが伸び続け、失敗もゼロでした。ただし並列数 50 では TTFT の中央値が 10 倍以上に跳ね上がります。これは NEXTN(MTP)有効時に SGLang が同時実行リクエスト数を 48 に制限する(cookbook 参照)ため、超過分がキュー待ちになるからです。実用上の同時リクエスト数はこの 48 が上限と見てよさそうです。
この速度差の背景には、Gated DeltaNet + GQA という Qwen3-Next 以来の枯れたアーキテクチャの順当な巨大化であるがゆえに、推論ライブラリ側の最適化が十分に成熟している、という事情がありそうです。独自色の強いアーキテクチャを Day-1 で動かす Kimi-K3 と、実績あるアーキテクチャをスケールさせた Qwen3.8 の違いが、そのままスループットの差に表れた形です。
コーディング性能の検証(主観)
前回と同じお題「A* 経路探索の可視化ツール」を単一 HTML ファイルで実装させました。
今回はハーネスに opencode を使い、Qwen3.8-2.4T-A95B に加えて DeepSeek-V4-Flash-0731 と GLM-5.2(NVFP4)でも同じプロンプトを実行し、3 モデルの生成物を比較しました(前回の Kimi-K3 の生成物は前回記事参照)。ハーネスが前回と異なるため、Kimi-K3 との比較は参考程度としてください。
使用したプロンプト(全文)
単一のHTMLファイルでA*経路探索の可視化ツールを作ってください。
外部ライブラリ・ビルド不要、ブラウザで開くだけで動くこと。
【中核要件】
- 40x25のグリッド。マウスドラッグで壁を描ける／消せる
- スタートとゴールはドラッグで移動可能
- 探索を1ステップずつアニメーション表示する。以下を色分けして区別:
- open set（探索候補）
- closed set（探索済み）
- 今まさに展開中のノード
- 確定した最短経路（探索完了後に始点まで辿って描画）
- 再生／一時停止／1ステップ実行／速度スライダー
【比較機能（デモの目玉なので必須）】
- ヒューリスティックを切り替えられること:
マンハッタン距離 / ユークリッド距離 / h=0（=ダイクストラ法）
- 同じ盤面を左右2画面に並べ、異なるヒューリスティックで
同時に探索させる比較モード
- 展開ノード数・経路長・所要ステップ数をリアルタイム表示
【実装上の要求】
- 優先度付きキューは配列のsortではなく、二分ヒープで実装する
- gスコアが改善した場合の再オープン処理を正しく扱う
- fが同値のときのタイブレーク規則を明示し、コメントで理由を書く
- 斜め移動のON/OFF切替（ONのときコストは√2、壁の角抜けは禁止）
- 追加: セルを右ドラッグで移動コスト1〜5の重みを設定でき、
重みは色の濃さで表現する
【UI】
ダークテーマ、余白を広く取り、色は探索状態の区別が一目で付くパレット。
操作方法は画面内に簡潔に表示。
Qwen3.8-2.4T-A95B の生成物。前回と同一のジグザグ迷路・比較モードで探索実行後の状態。要求外のランダム壁生成ボタンを備える。
DeepSeek-V4-Flash-0731 の生成物。機能は揃っているが、再生ボタンが 1 ステップ実行としてしか動かないバグがあった。
GLM-5.2(NVFP4)の生成物。再オープン回数の統計表示は独自の工夫だが、重み設定が機能しなかった。
3 モデルの生成物を触り、コードを読んで気づいた点です。
- 3 モデルとも優先度付きキューは要求どおり二分ヒープ(MinHeap クラス)を手実装しており、タイブレーク規則のコメントも一応ある
- Qwen3.8 は要求外のランダム壁生成ボタンを自発的に追加しており、動作確認には便利。一方で、重みを色の濃さで表現するビジュアルは前回の Kimi-K3 の生成物のほうが分かりやすかった
- DeepSeek-V4-Flash は再生ボタンがバグっており、押しても 1 ステップしか進まない。コードを追うと原因は明快で、探索中のステータス表示で
s.closed.size()と Set のsizeプロパティをメソッド呼び出ししており、毎ステップ例外が飛んでアニメーションループが止まっていた。JavaScript の初歩的なミスが残ってしまっている - GLM-5.2 は初期状態から障害物が配置されているのは親切とも言えるが、右ドラッグでの重み変更が機能していなかった。再オープン回数を統計表示する独自の工夫は良かった
一発で全要件が破綻なく動いたという点では Qwen3.8 が今回の 3 モデルでは最も良好でした。ただし、UI の作り込みや細部の丁寧さまで含めた主観的な総合評価では、前回の Kimi-K3 の生成物にまだ一歩譲る印象です。「コーディング特化」の打ち出しから期待した圧倒的な差は、少なくともこのお題では感じられませんでした。
考察
2.4T モデルが 1 ノードで、Kimi-K3 の約 2 倍のスループットで動く。 これが今回の最大の収穫です。線形アテンション主体のハイブリッド構成により KV フットプリントが小さく、デフォルト設定のまま約 1.54M トークンの KV キャッシュを確保でき、同時 48 リクエストまで失敗なくさばけます。ITL の短さはエージェント用途に直結する強みです。
一方で、Day1 デプロイの観点では Kimi-K3 と対照的な難しさがありました。公式配布が BF16 / FP8 のみのため、1 ノード運用はサードパーティ(SGLang 公式の RadixArk)の NVFP4 量子化ウェイトに依存します。今回はそれがリリース前から準備されていたため Day1 が成立しましたが、QAT 済み低精度ウェイトを一次配布する Moonshot 方式に比べると、量子化品質の検証責任がユーザー側に残る形です。事後量子化による精度への影響は、今回は Terminal-Bench の参考値を確認したにとどまるため、継続的な評価が必要です。
運用面では、起動約 65 分は Kimi-K3 より 20 分以上短く、モデル固有のメモリ配分チューニングも不要で、デプロイの素直さが際立ちました。留意点は NEXTN 有効時の同時実行数 48 の上限と、独自ライセンス(Qwen3.8-Max License)の利用条件確認です。
コーディング品質の主観評価は、速度ほどの驚きはありませんでした。破綻なく動くものは出てきますが、細部の作り込みでは Kimi-K3 優位という印象です。推論速度・同時実行数・コンテキスト容量で選ぶなら Qwen3.8、出力の質感で選ぶなら Kimi-K3、という構図が現時点での整理です。
まとめ
Qwen3.8-2.4T-A95B のウェイト公開当日に、NVIDIA B300 x8 シングルノードへのデプロイとベンチマークを完了しました。SGLang 公式の NVFP4 ウェイト(約 1.48TB)により 1 ノードに収まり、スループットは同一条件の Kimi-K3 の約 2 倍、同時 48 リクエストまで失敗ゼロという結果でした。一方、コーディング出力の主観評価では Kimi-K3 に一歩譲り、速度と質感のトレードオフが見える結果となりました。
今回の検証も、単なる新モデルの速報にとどまらず、当社製品に直結する取り組みです。
フィックスターズは、オープンウェイト LLM と独自のパフォーマンスエンジニアリングハーネスを組み合わせたオンプレミス AI アプライアンス「Fixstars Vega」を提供しています。Vega では最新のオープンウェイトモデルを継続的に評価しており、Kimi-K3 に続く今回の Qwen3.8-2.4T-A95B の検証もその取り組みの一環です。
新しいモデルが公開されたその日から、お客様のオンプレミス環境で最新のオープンウェイトモデルを安全に活用できる。それが Vega の目指す姿です。組み込みソフトウェア開発への AI 活用にご興味があれば、ぜひ製品ページをご覧ください。
参考リンク
Discussion