0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nabe2030(Makoto Watanabe)

DGX Spark で Mistral Small 4 119B (UD-Q4_K_M) を動かす

0
Posted at

はじめに

過去記事① では DGX Spark で Gemma 4 と Qwen 3.5 を、過去記事② では Qwen 3.6 への世代交代を、前回記事 では Nemotron 3 Super 120B-A12B で 100B+ クラスの MoE に踏み込みました。

前回 Nemotron 3 Super を動かしてみて、「100B+ MoE は速度を犠牲にして品質を取るポジション」 という大まかな印象は得られたのですが、活性パラメータが 12B でやや重めでした。1 つのデータポイントだけで「100B+ MoE はこういうもの」と決めつけるのは早い気がしていたので、別の 100B+ MoE で並べてみたいと思っていました。

そこで注目したのが Mistral Small 4 119B (Mistral-Small-4-119B-2603) です。総パラ 119B / 活性 6.5B (128 expert のうち 4 つ active)。Nemotron 3 Super とほぼ同じサイズ感ながら、活性パラが半分という構成です。「同じ 100B+ MoE でも活性パラが小さくなると速度・品質はどう変わるか」という観点で見るには良い対比になりそうです。

結論を先に書きます。

  • DGX Spark の 128 GiB ユニファイドメモリに UD-Q4_K_M (約 68.7 GiB, 3 シャード) がそのまま載ります。前回 Nemotron 3 Super (Q4_K, 65 GiB 帯) と同じ感覚で扱えます
  • 速度は 「pp は同帯 MoE より遅め、tg はむしろ速い」 という構図。pp2048 = 207.7 t/s で Nemotron 3 Super (727 t/s) の約 1/3.5、tg32 = 32.86 t/s で Nemotron (19.5 t/s) の約 1.69 倍
  • ロング pp はほぼ「半減を倍々で続ける」曲線で、pp512 → pp16384 で約 1/10.5 まで落ちます
  • JCQ Thinking OFF は 94.28% (1,055/1,119)。Nemotron 3 Super の 97.86% から -3.58pt、Qwen 3.5/3.6 の 35B-A3B 帯にも 2pt ほど届かず
  • VLM は 3 タスクとも parse 100%。Caption は 38 秒と軽くはないが、JSON 抽出 10 秒・PPE 検出 21 秒は API 用途では扱いやすい印象

Mistral Small 4 119B とは

Mistral AI が 2026 年 3 月に公開した MoE モデルです。Mistral 系は元々 7B / Mixtral 8x7B など「重みは出すがエコシステムは絞る」ケースが多いと言われているようですが、今回の Mistral Small 4 119B は Apache 2.0 で 100B+ クラスを公開 している点が大きな特徴です。

項目 内容
開発元 Mistral AI
リリース 2026 年 3 月
総パラメータ 119B
アクティブパラメータ 6.5B (128 Expert のうち 4 つ active)
アーキテクチャ MoE (Mistral 系)
Expert FFN size 2048
学習コンテキスト長 1,048,576 (1M)
ライセンス Apache 2.0
想定用途 多言語対話・コード・指示追従・VLM

なぜこのモデルか

前回記事の Nemotron 3 Super (活性 12B) と総パラが近く、活性が半分という構成なので、「100B+ MoE で活性パラを変えると何が変わるか」 という比較軸が成立します。Apache 2.0 で商用ハードルが低いのも後押しでした。Mistral 系は多言語と構造化出力に強いという公式の宣伝もあるので、JCQ 単体では出ない強みがあるかもしれません。

なぜ UD-Q4_K_M か

llama.cpp に Mistral Small 4 サポートが入ったのは PR #20649 経由で、b8388 以降に含まれています。今回使った b8922 で問題なく動きました。量子化は Unsloth Dynamic 2.0 の UD-Q4_K_M (約 68.7 GiB) を選びました。BF16 (約 240 GiB) は載らず、Q8_0 でも 128 GiB に対して窮屈になる帯。前回記事と同じ Q4_K 帯に揃えると、サイズ感の比較もしやすくなります。

1. 検証環境

項目 値
ハードウェア NVIDIA DGX Spark (GB10 Grace Blackwell, 統合メモリ 128 GiB)
VRAM (統合) 約 122,570 MiB (ggml_cuda_init 報告値)
OS / CUDA Ubuntu 系 (Linux 6.14) / CUDA 13.0
llama.cpp b8922 (commit 13d36cf89、CUDA バックエンド、SM121a)
主要 PR #20649 (Mistral Small 4 サポート) 取り込み済み

対象モデル (GGUF):

ファイル 量子化 サイズ 出所
Mistral-Small-4-119B-2603-UD-Q4_K_M-00001..3.gguf UD-Q4_K_M 68.69 GiB (3 シャード) unsloth/Mistral-Small-4-119B-2603-GGUF
mmproj-F16.gguf F16 (VLM 用) 別ロード 同上

GGUF メタデータからは general.name = "Mistral-Small-4-119B-2603"、mistral4.expert_count = 128、mistral4.expert_used_count = 4、mistral4.expert_feed_forward_length = 2048、n_ctx_train = 1,048,576 (1M) が読めました。

llama-server 起動

llama-server \
  -m ~/models/mistral-small4-119b-unsloth/UD-Q4_K_M/Mistral-Small-4-119B-2603-UD-Q4_K_M-00001-of-00003.gguf \
  --mmproj ~/models/mistral-small4-119b-unsloth/UD-Q4_K_M/mmproj-F16.gguf \
  -ngl 99 \                              # 全レイヤを GPU にオフロード
  -fa 1 \                                # Flash Attention を有効化
  --no-mmap \                            # mmap 無効 (DGX Spark 統合メモリ前提)
  -c 4096 \                              # コンテキスト長 4096
  --port 8080

3 シャード分割の GGUF ですが、-m には先頭シャードを指定するだけで、残り 2 つも自動でロードされます。-c 4096 は JCQ・VLM 共通で使った値で、サーバ実体ログでも n_ctx = 4096 を確認しています。

llama-bench

llama-bench \
  -m <model.gguf> \
  -ngl 99 \                              # 全レイヤを GPU にオフロード
  -fa 1 \                                # Flash Attention を有効化
  -mmp 0 \                               # mmap 無効
  -p 512,2048,4096,8192,16384 \          # プロンプト長を 5 段階で振る
  -n 32                                  # 生成 32 トークン

比較対象モデル (過去ベンチからの参考値)

過去記事で測った MoE モデルの値を「同カテゴリ MoE 横並び」として並べます。ビルドは過去側が b8672、今回が b8922 で揃っていない点は念のため明示します。pp は llama.cpp のバージョン差で数倍ぶれることもあるため、本記事の比較は おおよその傾向把握のための参考値 として読んでいただくのが安全だと思います。同一ビルドでの再測は今後の宿題として残しています。

モデル 量子化 サイズ 出典日付 / ビルド
Mistral Small 4 119B-A6.5B (今回) UD-Q4_K_M 68.69 GiB 2026-04-26 / b8922
Nemotron 3 Super 120B-A12B (前回記事) Q4_K 65.1 GiB 2026-04-16 / b8672
Qwen 3.6-35B-A3B (過去記事②) MXFP4 約 21 GiB 2026-04-18 / b8672
Qwen 3.5-35B-A3B (過去記事①) MXFP4 20.1 GiB 2026-04-08 / b8672
Gemma 4-26B-A4B (過去記事①) F16 47.0 GiB 2026-04-08 / b8672

2. 読み込みとセットアップ

llama.cpp 本体での Mistral Small 4 サポートは PR #20649 経由で b8922 に取り込まれています。今回はこのビルドでそのまま動かせました。気になった点を挙げておきます。

  • 3 シャード分割の GGUF。00001-of-00003.gguf を -m に指定するだけで、残り 2 つも自動でロードされます。68.7 GiB を 3 つに分割した形なので、ディスク I/O 観点でもキャッシュに収まりやすく扱いやすい印象でした。
  • VRAM 消費 (統合メモリ報告値)。約 122 GiB の reported VRAM のうち、UD-Q4_K_M ロード後で 70 GiB 強を持っていく計算になります。常駐で他モデルを並走させるには窮屈になりやすいので、他のツールとの同居を想定する場合は配分を事前に詰めておきたいところです。
  • enable_thinking deprecated 警告。llama-server 起動時に次のメッセージが出ます。
Setting 'enable_thinking' via --chat-template-kwargs is deprecated.
Use --reasoning on / --reasoning off instead.

今回使った JCQ ハーネスは enable_thinking を chat template kwargs で渡す形なので、Thinking ON 相当のはずの実行も中身は素の生成と同じ挙動になっていそうな疑いが残りました (後述 5 章)。

ロード自体に詰まったところは無く、サーバ起動から JCQ 応答までは比較的すんなり通った印象です。

3. 速度: 短文・中文 (pp2048 / tg32)

llama-bench の数値を、同カテゴリ MoE の過去ベンチと並べます。pp 側は前回記事 Nemotron で取っていた pp2048 に揃え、tg は tg32 (-n 32) で揃えました。短文 pp512 / tg128 は本記事末尾の付表に置いています。

pp2048 比較
　　　　図 1: pp2048 — Mistral Small 4 119B-A6.5B (UD-Q4_K_M) と過去 MoE の参考値

  • pp は活性パラメータが大きいほど不利、という構図がそのまま見えます
  • Mistral Small 4 (活性 6.5B) は 207.7 t/s、Nemotron 3 Super (活性 12B) は 727 t/s、35B-A3B 帯 (活性 3〜4B) は 2,200〜2,800 t/s 帯
  • ビルド差 (b8672 vs b8922) は乗っていますが、100B+ MoE は pp 側で 35B-A3B 帯と同じ速度は出ない という方向は言えそうです
  • 同じ 100B+ MoE でも Nemotron が 3.5 倍速い点は、活性 6.5B vs 12B の差とビルド差の両方が乗っての差だと思います。同一ビルドで切り分けるのは今後の宿題

tg32 比較
　　　　　　　　　　　　　　　　　図 2: tg32 — 同上

  • tg は活性 6.5B が効いて Nemotron より速くなりました (32.86 vs 19.5 t/s, 約 1.69 倍)
  • 35B-A3B 帯の MoE には及ばない (Qwen 3.5 / 3.6 で 58〜63 t/s, Gemma 4 で 26.5 t/s)
  • Mistral Small 4 はその中間という位置で、活性パラのサイズに概ね順番通り並んでいるように見えます
  • 「100B+ MoE で対話の体感を取りたいなら活性パラの小さい側を選ぶ」 という選び方が成立しそうな気がしています

4. 速度: ロング pp (pp512 → pp16384)

llama-bench の -p を 512 / 2048 / 4096 / 8192 / 16384 に振った場合の pp スループットを並べます。今回は Mistral Small 4 単独の曲線で、過去 MoE のロング pp は同形式で取れていない値があるため省きました (こちらも今後の宿題)。

pp ロング劣化曲線
　　　　　　図 3: ロング pp スループット — Mistral Small 4 119B (UD-Q4_K_M)

  • プロンプト長に対してほぼ「半減を倍々で続ける」曲線
  • pp512 → pp2048 で約 55% 落ち、4096 でさらに半減、8192 でほぼ半減、16384 でも半減
  • pp512 → pp16384 で 約 9.6% (1/10.5) まで落ち込み
  • 長文 RAG・巨大ログ解析を一気に飲み込ませる用途では、Mistral Small 4 はそのままだと厳しめだと思います
  • 8K プロンプトでも 68 t/s 帯まで落ちるので、入力フェーズの待ち時間は体感できるレベル
  • 対話・段階生成の用途なら最初の重さは 1 回ぶん。tg は前章のとおり 33 t/s 帯で出続けるので、長いシステムプロンプトを 1 回乗せたあとは生成で取り戻していく形になりそうな気がしています

5. 品質: JCommonsenseQA (Thinking OFF)

JCQ v1.1 全 1,119 問を 3-shot で投げ、Thinking OFF 構成で正答率を測りました。サーバは -c 4096 構成です。

JCQ 正答率
　　　　　　図 4: JCQ 正答率 (Thinking OFF, 3-shot, 1,119 問) — MoE 横並び

モデル 正解数 / 1,119 正解率
Nemotron 3 Super 120B-A12B (Q4_K, 参考値 b8672) 1,095 / 1,119 97.86%
Gemma 4-26B-A4B (F16, 参考値 b8672) 1,080 / 1,119 96.51%
Qwen 3.5-35B-A3B (MXFP4, 参考値 b8672) 1,076 / 1,119 96.16%
Qwen 3.6-35B-A3B (MXFP4, 参考値 b8672) 1,074 / 1,119 95.98%
Mistral Small 4 119B-A6.5B UD-Q4_K_M (今回) 1,055 / 1,119 94.28%
  • 同 100B+ MoE の Nemotron 3 Super との差が 3.58pt (40 問)。「総パラ 119B だから当然強い」とはならず、JCQ という問題セット単体では Nemotron 側が頭ひとつ抜けた形
  • 35B-A3B 帯の MoE にも 2pt 弱及ばず (Qwen 3.5 / 3.6 / Gemma 4 に対して)。総パラサイズの優位がそのまま JCQ 正答率に出てくるわけではない、という結果
  • Mistral 系は多言語・コード・指示追従を売りにしているモデルなので、JCQ 単体だけで品質を語るのは無理がある、という前提は置きたい
  • ビルド差 (b8672 → b8922) で量子化精度が動いた可能性は残るので、Nemotron 3 Super を b8922 で再測する形でこの差をもう一度見てみたい論点

Thinking ON 構成について

enable_thinking=on を --chat-template-kwargs 経由で渡したパスでも、JCQ の正答率は 94.28% で Thinking OFF とまったく同値 (1,055/1,119) という結果になりました。サーバ起動ログには次のメッセージが出ています。

Setting 'enable_thinking' via --chat-template-kwargs is deprecated.
Use --reasoning on / --reasoning off instead.

Mistral Small 4 のチャットテンプレートが enable_thinking キーを参照しない形になっているためか、Thinking 相当のスイッチが効かないまま素の生成と同じ経路で評価されてしまっている可能性が高そうです。正しくは llama.cpp 側の --reasoning on/off フラグで切り替えるべき と思っているので、Thinking 込みの評価は本記事ではいったん見送り、別記事で --reasoning を使った形に揃えて再測する予定にしています。

参考までに、過去 MoE での Thinking ON / OFF の差は次の通りでした (前回記事および過去記事②から)。

モデル Thinking OFF Thinking ON 差分
Qwen 3.6-35B-A3B 95.98% 96.43% +0.45pt
Nemotron 3 Super 120B 97.86% 97.59% -0.27pt
Gemma 4 26B-A4B 96.51% 95.80% -0.71pt
Qwen 3.5-35B-A3B 96.16% 89.28% -6.88pt

「Thinking で大崩れしない」傾向のモデルが増えてきている中で、Mistral Small 4 がどこに入るのかは興味深いところです。

6. VLM: caption / JSON 抽出 / PPE 検出

llama-server のマルチモーダル経由で次の 3 タスクを投げました。

  • Caption: 画像 5 件 × 1 質問、フリーフォームの説明 (max_tokens=1024)
  • JSON 抽出: 画像 5 件、所定スキーマで JSON 出力、parse 可否を集計
  • PPE 検出: 作業現場画像 3 件、PPE (ヘルメット等) 装着状況を JSON で報告

VLM サマリ
　図 5: VLM タスク別レイテンシと parse 成功率 — Mistral Small 4 119B (UD-Q4_K_M) 単独

タスク サンプル数 平均レイテンシ (s) parse 成功率
Caption 5 38.27 (free-form, parse 概念なし)
JSON 抽出 5 10.18 100% (5/5)
PPE 検出 3 20.82 100% (3/3)
  • 3 タスクとも parse 失敗ゼロ。Caption は free-form なので parse の概念が無いものの、JSON 抽出と PPE 検出はスキーマつきで 5/5・3/3 で、Mistral Small 4 は 構造化出力に対する追従性が高そう な印象
  • レイテンシは tg 33 t/s 帯がそのまま体感に効いている形。Caption の 38 秒は軽くはないですが、JSON 抽出が 10 秒前後と扱いやすいレンジ
  • VLM のサンプル数は caption 5 / JSON 5 / PPE 3 と少ないので、特に PPE は 3 件で全勝/全敗が成立するレンジ。本格運用前には対象タスクの画像で再現性を取り直すのが無難だと思います
  • 過去 MoE 記事 (過去記事①②) では VLM の同形式の値が揃っていなかったので、横並びは今回は割愛

7. このモデルのメリット・デメリット

メリット デメリット
Apache 2.0 で 100B+ MoE が使える JCQ は同帯の Nemotron に -3.58pt
同帯 Nemotron より tg 33 t/s で速い pp はロングプロンプトで急峻に落ちる
VLM 構造化出力 100% (JSON / PPE) サイズ 68.7 GiB で他ツールとの同居は窮屈
1M コンテキスト学習済み Thinking モードの正しい評価は別記事に持ち越し

8. DGX Spark でどのモデルを選ぶか

用途 推奨モデル 理由
日常チャット・コーディング Qwen 3.6-35B-A3B (MXFP4) 最速、Thinking 劣化なし、Apache 2.0
Vision + テキスト Gemma 4 26B-A4B (F16) または Mistral Small 4 119B (UD-Q4_K_M) Gemma は軽量・Mistral は構造化出力強い
テキスト品質重視 Nemotron 3 Super 120B (Q4_K) JCQ 97.86%、Thinking 劣化が小さい
教師データ (合成データ) 生成 Nemotron 3 Super 120B (Q4_K) 比較した中で精度が高い
Apache 2.0 で 100B+ MoE が必要 Mistral Small 4 119B (UD-Q4_K_M) ライセンスと総パラのバランス

Mistral Small 4 119B は、「Apache 2.0 で 100B+ MoE が手元の DGX Spark で動く」 という事実そのものに価値がある、というのが今回触ってみた所感です。日本語常識推論の 1 軸では Nemotron や 35B-A3B 帯に届きませんでしたが、ライセンスの軽さ・構造化出力の安定性・1M コンテキスト学習という組み合わせは他のモデルでは代替しづらく、用途次第でしっかり居場所がありそうな気がしています。

9. まとめ と 今後の予定

  • DGX Spark + llama.cpp (CUDA, b8922) で Mistral Small 4 119B を速度 / JCQ / VLM の 3 軸で動かしてみました (UD-Q4_K_M, 約 68.7 GiB)
  • 速度は 「pp は 100B+ MoE 帯の中でも遅め、tg は同帯では速め、ロング pp で急峻に落ちる」 という、活性 6.5B MoE に典型的な傾向
  • 品質 (JCQ) では Nemotron 3 Super を含む過去 MoE 群に届かない 94.28%。日本語常識推論だけで決め打ちはできないので、別タスクでの確認は引き続き必要
  • VLM では 構造化出力 100%・レイテンシも実用域 で、用途とのマッチが良ければ手堅い候補
  • 100B 超 / Apache 2.0 の MoE が DGX Spark の 128 GiB ユニファイドメモリにそのまま載って動く こと自体が、しばらく経っても変わらない実利だと思っています

今回触れていない / 持ち越した論点:

  • Thinking モードの正しい再評価 (--reasoning on/off)。enable_thinking 経由が deprecated だったため、フラグを正しい形に揃えて別途測り直す予定
  • 過去 MoE 群の b8922 同一ビルドでの再測。Nemotron 3 Super 120B-A12B などを今回と同じ b8922 で取り直すと、ビルド差の寄与を切り分けて見られる
  • 量子化バリアント比較 (UD-IQ4_XS / UD-Q5_K_M / Q8_0 など)
  • ロング pp の急峻な低下の原因切り分け (-fa / --no-mmap / バッチ・サブグループ周りの効き)。曲線がここまで綺麗に半減を繰り返すのは MoE ルーティング側の理由がありそうですが、推測の域を出ないので別途追いたい

付表: 短文 pp512 / tg128 (Mistral Small 4 単独)

llama-bench short の値も載せておきます (-p 512 -n 128)。

指標 値
pp512 378.04 ± 1.17 t/s
tg128 33.39 ± 0.24 t/s

ロング側の値:

プロンプト長 pp スループット (t/s)
512 375.35 ± 2.86
2048 207.72 ± 0.80
4096 124.19 ± 0.06
8192 68.27 ± 0.04
16384 35.85 ± 0.01
tg32 32.86 ± 0.86

参考リンク

モデル・ツール

過去記事

検証スクリプト

※ 数値はすべて 2026-04-26 時点の実測値で、llama.cpp のビルドや量子化バリアントが変われば再現値も動く可能性がある点に留意してください。過去 MoE の値は出典時点の b8672 ビルドのもので、本記事の Mistral Small 4 (b8922) とはビルドが揃っていない参考値です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?