NVIDIA、DGX Spark（ディージーエックス スパーク）でLing-3.0-flashを速める3手法を公開GSM8K全1,319問でデコード+42.5%、精度はほぼ同じと報告

NVIDIAは2026年10月27日（米国時間）、NVIDIA DGX Spark（ディージーエックス スパーク）でInclusion AIのモデル Ling-3.0-flash の生成を速める3つの手法を、技術ブログ「3 Ways to Boost MoE Inference on NVIDIA DGX Spark」で公開しました。公開時刻は協定世界時15:00、日本時間では10月28日0:00です。NVIDIAの測定では、GSM8Kのテスト全1,319問でデコード速度が37.81から53.89トークン/秒（+42.5%）になり、正答率は96.89%から96.82%でした。

3行まとめ

1. NVIDIAがDGX Spark上のLing-3.0-flash（総パラメータ124B・アクティブ5.1B）を速める3手法（Humming MoEカーネル・FP8 LMヘッド・MTP投機的デコード）を公開
2. GSM8K全1,319問で、デコード速度+42.5%・平均レイテンシ24.5%減、正答率は96.89%→96.82%（NVIDIA測定）
3. 3つを重ねるにはドラフトモデルがLMヘッド全体を共有する必要があり、怠ると最適化なしより遅くなると同社が警告

本記事の内容は、日本時間10月28日0時台に公式ページで確認したものです。

何をしたのか：重み読み出しがボトルネックだった

NVIDIAのブログによると、バッチサイズ1でLing-3.0-flashをDGX Sparkに載せて調べたところ、デコードはメモリ律速で、モデルの重みを読む時間が実行時間を決めていました。中でも目立ったのが、MoE（混合エキスパート）の計算と、語彙全体のスコアを出す出力層（LMヘッド）の射影だったと説明しています。

そこで「1ステップあたりの重み読み出しを減らす」と「1回の検証でより多くのトークンを出す」の2方向から、次の3手法を試しています。

検証したモデルと基準の設定

評価に使ったのは Ling-3.0-flash-fp4 です。NVIDIAの記述では、総パラメータ1,240億・1トークンあたりアクティブ51億のMoEで、42層のうち35層がKimi Delta Attention（KDA）の線形アテンション、7層がMLA（multi-head latent attention）です。各MoE層は512個のrouted expertから8個を選び、共有expertも1つ使います。エージェント用途向けに、ネイティブで256Kトークンの文脈を持ち、1Mトークンまで拡張できるとも書かれています。

基準（ベースライン）は、公式cookbookのW4A8構成です。FlashInferのMXFP4 MoEカーネル、NVIDIA CUTLASSの密行列GEMM、--enable-fp32-lm-head オプションの組み合わせで、LMヘッドは隠れ次元2,560から語彙157,184への射影です。

手法ごとの効果は？

以下は、入力32Kトークン・出力2Kトークンの合成ワークロード（バッチサイズ1）での、NVIDIA掲載の数字です。TPOT は1出力トークンあたりの時間です。

① Humming：実行時にシェイプ専用のカーネルを作る

Humming は humming-kernels というpipパッケージで入る独立のカーネルライブラリです。NVIDIAによると、NVRTC（実行時コンパイル）で実際のM/N/K、データ型、GPU世代に合わせたCUBINを作り、~/.humming/cache に保存します。Ling-3.0-flashの比較的狭い moe_intermediate_size（768）にも合わせられ、カーネル1つのコンパイルは数秒で済む一方、FlashInfer CUTLASS経路はninjaで97ターゲットをコンパイルし数十分かかる、との説明です。

② FP8 LMヘッド：BF16の出力層を半分の読み出しに

NVIDIAによると、チェックポイントではLMヘッドがBF16のまま modules_to_not_convert に入っており、ロード時に量子化されません。生成のたびに157,184×2,560の重みブロックを丸ごと読むため、帯域が詰まる環境では圧縮の効果が大きい、という考え方です。LMヘッドを作るときだけ動的FP8の設定を適用し、残りはチェックポイント本来のFP8/MXFP4のまま読み込みます。有効化は環境変数 SGLANG_ENABLE_FP8_LM_HEAD=1 で、ベースラインの --enable-fp32-lm-head とは同時に使えません。

③ MTP：ステップ数を減らす

Ling-3.0-flashにはNEXTN予測層（num_nextn_predict_layers: 1）が入っていて、追加の学習やダウンロードなしにドラフトモデルとして使えます。設定は3ステップ先まで下書きし、4トークン分を一度に検証する形です。1回の検証コストは通常の1ステップの約2.26倍で、その主因はアテンションではなくMoEのexpert活性化だとNVIDIAは説明しています。通常のデコードは1トークンでexpertを8個動かしますが、検証は4トークンを処理するため最大32個が動きうる、という計算です。

実タスクで測るとどうなる？

合成ワークロードの+185.1%は、NVIDIA自身が「繰り返しが多く単純なサンプリングのため、投機的デコードの効果を系統的に過大評価する」と書いています。そこで同社は、GSM8Kテスト全1,319問（5-shot、temperature 0.6、top_p 0.95、top_k 29、max_tokens 32,768、思考の連鎖あり）で、3手法以外の条件をそろえて比較しました。

合成と実タスクで差が出る理由として、NVIDIAは3点を挙げています。出力の繰り返しが多いと下書きが通りやすい（受理長は合成3.90、GSM8K 2.68）、サンプリングが違う（合成は貪欲、実評価は確率的）、出力長が違う（合成は2K固定、GSM8Kの中央値は約310トークンで、①②の固定的な削減効果が短い出力に薄まる）、の3つです。

3つ重ねると遅くなることがある？

あります。ブログが注記（Note）として書いている点です。FP8 LMヘッドとMTPを同時に有効にするとき、ドラフトモデルはLMヘッドの重みテンソルだけでなくモジュール全体をターゲットと共有する必要があります。NVIDIAによると、元のLingのNEXTN実装にはそのインターフェースがなく、そのままだとフレームワークが黙って別経路に落ちます。ドラフト側はFP8の重みを受け取りながらBF16として解釈するため、受理長が1.00まで下がり、スループットは最適化なしの構成より低くなります。

NVIDIAは、全体をつなぐにはLing cookbookの手順に従うよう案内し、「起動時に各最適化が有効かを確認する。後の性能数値から設定状態を推測するより確実だ」と結んでいます。エラーが出ずに遅くなるだけなので、数字を見ないと気づきにくい種類の罠です。

日本の読者はどう使えるのか

このブログは英語の技術解説で、実装コードと手順はLing cookbookのノートブック（dgx-spark-sglang-ling-3-flash-mxfp4-humming.ipynb）にあると案内されています。DGX Spark本体の日本での価格や取り扱いは、今回取得したページには出てきません。DGX Sparkの最近の動きは、8台クラスターの公式サポートや、GTC BerlinでのDGX Spark 64GBの提供開始の記事にまとめています。

公式ページを日本時間0時に開いて分かったこと

日本時間10月28日0時1分に公式ブログを取得した時点で、本文の公開時刻は日本時間0:00で、ほぼ公開直後でした。続けて0時1分台にcookbookのノートブックのページも取得しましたが、取得できた文字は「730行・29KB」というファイル情報とメニュー類が中心で、ノートブックのセルの中身（コードや手順）は読み取れませんでした。そのため、実際にどのコマンドで有効化するのかは、本記事ではブログの記述を超えて確認できていません。Hugging FaceのinclusionAIの組織ページ（同じ時刻帯に取得）の一覧には、Ling-3.1-flashやLing-3.0-flash-UBTreeなどの名前が並んでいましたが、ブログが使ったLing-3.0-flash-fp4という名前は、今回取得できた範囲の一覧には見当たりませんでした（一覧が一部である可能性があります）。

数字はバッチサイズ1・GSM8Kでの同社測定

• 数字はすべてNVIDIAの測定です。 筆者は試していません。環境の詳細（ソフトウェアのバージョンなど）は、今回取得したブログ本文には書かれていませんでした。
• バッチサイズ1の結果です。 1人が1本ずつ使うローカル利用の想定で、複数同時リクエストでの傾向は、今回確認したページには載っていません。
• 精度の確認はGSM8Kのみです。 −0.08ポイントは同社が「統計的に検出できる変化なし」とした結果で、ほかのタスクでの精度は今回のページでは確認できませんでした。
• ブログ冒頭の「AI-Generated Summary」は、NVIDIA Nemotronによる自動要約と明記されています。本記事は要約ではなく本文の表と記述から数字を取っています。
• ライセンスや提供条件は、今回取得したブログ本文には書かれていません（Ling-3.0-flashの利用条件は、Hugging Faceのモデルページ側で確認が必要です）。

参照した3ページ（日本時間10月28日0時1分台に取得）

• NVIDIA Technical Blog「3 Ways to Boost MoE Inference on NVIDIA DGX Spark」（2026年10月27日、著者 Yang Liu）: https://developer.nvidia.com/blog/3-ways-to-boost-moe-inference-on-nvidia-dgx-spark/ （日本時間10月28日0:01確認）
• inclusionAI ling-cookbook（DGX Spark・SGLang・Humming のノートブック）: https://github.com/inclusionAI/ling-cookbook/blob/main/guide/local-deploy/ling-3.0-flash/dgx-spark-sglang-ling-3-flash-mxfp4-humming.ipynb （同0:01確認・セルの中身は未取得）
• inclusionAI（Hugging Face）: https://huggingface.co/inclusionAI （同0:01台確認）

本記事は続報があり次第更新します。