「DGX Sparkの推論性能を上げるには、もっと大きなGPUが必要なのか？」——そう思っていた人にとって、今回のNVIDIAの発表は気になるニュースだ。
2026年10月27日、NVIDIAは公式技術ブログで、DGX Spark上のローカルLLMをソフトウェア最適化で高速化する3つの手法を公開した。対象モデルを使った検証では、実際の問題集を処理したときの生成速度が42.5%向上。一方、条件を単純化したテストでは「185.1%向上」という目を引く数字も出ている。
ただし「DGX Sparkなら何でも185%速くなる」と受け取るのは早計。この記事では、何を変えたら速くなったのか／どの数字を信用すべきか／自分の環境で試すときの注意点を、NVIDIAの一次情報をもとに整理する。
結論：実タスクでは42.5%向上。「185%」は合成テストの数字
今回の検証対象は、Inclusion AIのMoEモデル「Ling-3.0-flash」。総パラメータ1240億（124B）のうち、1トークンあたり約51億（5.1B）が有効になる設計で、DGX Spark上で同時処理数1（バッチサイズ1）として評価された。
まずは最も重要な数字を比較しよう。NVIDIAは算数問題のベンチマーク「GSM8K」全1,319問で、最適化前と3手法を組み合わせた構成を比較している。
| 指標 | 最適化前 | 最適化後 |
|---|---|---|
| 生成速度（Decode） | 37.81 tokens/秒 | 53.89 tokens/秒（+42.5%） |
| 平均応答時間 | 15.21秒 | 11.49秒（-24.5%） |
| トークン間時間（TPOT） | 26.45ms | 18.56ms（-29.8%） |
| GSM8K正答率 | 96.89% | 96.82%（約-0.08ポイント） |
| 初回トークン時間（TTFT） | 0.207秒 | 0.214秒 |
ここが大切だ。トークン生成速度は42.5%増加したが、回答全体の待ち時間は24.5%減。単純に「チャットが42.5%早く終わる」と言い換えるのは正確ではない。また、TTFTは改善せず、ほぼ横ばいだった。
何を変えたのか？ 高速化を生んだ3つの工夫
① MoEの計算部分を「Humming」に置き換える
MoE（Mixture of Experts）は、多数の「専門家」から必要なものを選んで計算する仕組みだ。そこで使う計算カーネルを、従来のFlashInfer MXFP4バックエンドからHummingに変更した。
Hummingは実行対象の行列形状やGPUアーキテクチャに合わせてカーネルをコンパイルする。NVIDIAが示した合成テストでは、これだけで36.09→39.45 tokens/秒（+9.3%）となった。まずは無駄な計算やメモリアクセスを減らす、比較的イメージしやすい最適化だ。
② LMヘッドをFP8化して、メモリから読むデータを減らす
LLMは次の単語を決める際、語彙全体のスコアを計算する「LMヘッド」を使う。このモデルではLMヘッドの重みがBF16形式で保持されていた。
ここをFP8量子化すれば、この部分の重みを読み込むデータ量を理論上半分にできる。DGX Sparkのように、推論がメモリ帯域に制約される場面で効いてくる。
Hummingに加えてLMヘッドをFP8化した合成テストでは、43.94 tokens/秒（最適化前から+21.7%）。なお、NVIDIAが示すSGLANG_ENABLE_FP8_LM_HEAD=1はSGLang側の構成に関する設定で、すべての推論エンジンにそのまま通用する共通オプションではない。
③ MTP投機的デコードで、複数トークンをまとめて確かめる
最も大きな伸びを生んだのがMTP（Multi-Token Prediction）による投機的デコードだ。次の1トークンを順番に生成する代わりに、候補を先読みし、まとめて検証して採用する。
Ling-3.0-flashにはNEXTNという予測層が含まれており、追加の別モデルをダウンロードせず活用できる。合成テストでは3手法を組み合わせて36.09→102.88 tokens/秒（+185.1%）に到達した。
ただし、このテストは入力32Kトークン、出力2Kトークン、バッチサイズ1、単純化した生成条件。実利用で常に約2.85倍の速度が得られるという意味ではない。
なぜ「185%」が実タスクでは「42.5%」になったのか
鍵になるのは、投機的デコードで先読みしたトークンがどれだけ正しく採用されたかだ。合成テストでは1回あたり平均3.90トークンを採用できたが、GSM8Kでは2.68トークンだった。
実際の文章や推論は合成テストより予測しにくい。さらに温度などのサンプリング設定、回答の長さも違う。先読みが当たりにくければ、検証の手間に対する見返りは小さくなる。
つまり、性能評価は「一番派手なベンチマーク数字」ではなく「自分の用途に近い負荷」で判断する必要がある。コーディングAI、長文分析、複数人の同時チャットでは、結果が変わる可能性が高い。
要注意：3つを同時に有効化すると、逆に遅くなることも
今回の記事で、むしろ技術者が見逃せないのはここだ。NVIDIAはFP8化したLMヘッドとMTPを組み合わせる際の実装上の落とし穴も説明している。
ドラフト側のモデルと本体側のモデルで、単にLMヘッドの重みだけを共有すると整合が取れない場合がある。元のLing NEXTN実装では、必要なモジュール全体の共有インターフェースがなく、ドラフト側がFP8重みをBF16として扱ってしまうケースがあった。
その場合、先読みトークンの採用数は平均1.00まで落ち、最適化なしの構成よりも低速になるという。解決には両者がLMヘッドのモジュール全体を共有する適切な実装が必要で、NVIDIAは公式Cookbookの手順を案内している。
設定項目をONにしただけで「高速化できた」と判断しないこと。起動ログやバックエンドの選択、MTPの採用率、実測のTPOTとTPSまで確認して初めて効果を評価できる。
DGX Sparkユーザーは何を試すべき？
手元のDGX Sparkを高速化したいなら、最初に「自分が今、何に待たされているか」を切り分けたい。
- 1人で長文を生成する用途：単一リクエストのdecode TPS、TPOT、MTP採用率を重視。今回の研究に近い条件。
- 複数人が同時に使う用途：総TPSだけでなく、利用者別TPS、TTFT、P95待ち時間、GPUメモリ使用量を記録。
- 既存のQwenなどを使う用途：今回の結果はLing-3.0-flashと指定のSGLang構成に対するもの。別モデルやllama.cpp、vLLMなどで同じ改善率を保証するものではない。
- 本番相当環境：変更前の設定と測定結果を保存し、1項目ずつ変更して効果を比較。精度・エラー率・メモリ圧迫も合わせてチェック。
当ブログでも以前、DGX Spark上でStrataとllama.cppを比較した実測記事を公開している。あちらは推論エンジンと同時実行条件の比較、今回はモデル・カーネル・デコード方式の最適化という別の視点だ。両方を一緒に眺めると、「速い構成」が必ずしも1つではないことが見えてくる。
FAQ：今回の発表で気になる3つの疑問
Q. DGX Sparkをアップデートするだけで42.5%速くなる？
いいえ。これは特定モデルと推論スタックで3つの最適化を適切に組み合わせた検証結果。OSアップデートだけで全LLMに適用される数字ではない。
Q. 最大185%高速化というニュースは誇張？
数字そのものはNVIDIAの合成テストでの測定値だ。ただしGSM8K全問での改善率とは条件が異なるため、実利用の代表値として185%だけを強調するのは不適切だ。
Q. 精度を落として速くしたの？
GSM8Kでは96.89%から96.82%と小さな差にとどまり、NVIDIAは統計的に検出できる精度変化はなかったとしている。ただし、日本語、プログラミング、長文要約などでの精度維持は別途検証が必要だ。
まとめ：DGX Sparkは「買い替え」以外でもまだ速くできる
今回の技術ブログの面白さは、ハードウェアを増やすのではなく、メモリ転送の削減と生成アルゴリズムの改善で数字を伸ばしたことにある。
現実的に受け止めたい成果は、Ling-3.0-flashのGSM8K検証で生成速度が42.5%向上し、平均応答時間が24.5%短縮したという点。そしてもう一つの教訓は、最適化には相互作用があり、「機能を全部ON」にすればよいわけではない、ということだ。
ローカルAIを日常的に使うなら、モデル名だけでなくバックエンド・量子化・投機的デコード・同時実行数を含めて構成を選ぶ時代になってきた。
一次情報・関連資料
- NVIDIA Technical Blog：3 Ways to Boost MoE Inference on NVIDIA DGX Spark（2026年10月27日）
- Inclusion AI公式：DGX Spark向けLing 3.0 Flash／SGLang Cookbook
- ベア三郎ブログ：DGX Spark実測 Strata vs llama.cpp
※2026年10月28日時点で公開済みの資料に基づく解説です。数値はNVIDIA公表の検証結果であり、ベア三郎ブログ独自の追試結果ではありません。環境・モデル・負荷によって性能は異なります。
コメント