NVIDIA、DGX Spark上のGSM8K生成処理量が42.5％増と報告

NVIDIA は十月二十七日、DGX Spark 一台で Ling-3.0-flash の推論を速める三つの方法を報告した。バッチ数は一で、対象は総パラメータ千二百四十億、出力単位ごとに五十一億を活性化する混合エキスパートモデルだ。分析では生成中の重み読み取りが主な制約となり、エキスパート計算と出力層の投影が目立った。原記事には実測のベンチマークがあるため「数値試験はない」とは言えない。ただし NVIDIA 自身の測定であり、本媒体が再実験した結果や別のモデルに共通する保証でもない。

最初の変更は、基準となる FlashInfer MXFP4 のエキスパート処理を、モデルの形状に合わせて作る Humming カーネルへ置き換える。入力三万二千、出力二千のテキスト単位を使った合成負荷では、一単位の生成時間が二七・七一ミリ秒から二五・三五ミリ秒へ変わり、処理量は毎秒三六・〇九から三九・四五単位になった。会社が示す改善率は九・三％だ。次に出力を担う言語モデルのヘッドだけをオンラインで FP8 に量子化する。この層は元の設定では BF16 の重みを毎回読み取るため、FP8 化でその読み取り量を半減できる。Humming と組み合わせた合成試験では毎秒四三・九四単位となり、基準より二一・七％高い。

三番目はモデル内蔵の NEXTN 層を使う複数単位予測だ。候補を先に作ってまとめて確かめ、受け入れられた分だけ連続した生成手順を省く。合成負荷では一回当たり平均三・九〇単位が受理され、三つを組み合わせると毎秒一〇二・八八単位、基準より一八五・一％高かった。ただし FP8 とこの方式を同時に使うには、候補側と本体が出力ヘッドのモジュール全体を共有する必要がある。重みだけを共有すると解釈が食い違い、受理長が一・〇〇まで落ち、未最適化の構成より遅くなる場合があるという。設定がオンでも正しい実行経路が働いているか確かめる必要がある。

より実際の質問に近い比較として、記事は GSM8K の全千三百十九問でも測定した。双方で五例の提示や抽出条件をそろえた結果、生成処理量は毎秒三七・八一から五三・八九単位へ増え、改善率は四二・五％だった。平均の要求時間は一五・二一秒から一一・四九秒となり、二四・五％短い。測定した正答率は九六・八九％から九六・八二％で、NVIDIA は統計上検出可能な変化はないと記す。最初の出力までの平均時間は〇・二〇七秒から〇・二一四秒へわずかに延びており、改善したとは書けない。

合成負荷の一八五・一％と GSM8K の四二・五％は交換できない。合成出力は反復的で候補が受理されやすく、GSM8K では平均受理長が二・六八に下がる。出力長やサンプリングも異なる。従って「混合エキスパート推論が一律に三倍速い」という見出しは不正確だ。自社で試すならモデル、機器、ソフトウエア版と基準構成を固定し、実際の要求分布で処理量、最初の出力までの時間、最終回答の品質を一緒に記録する。三つの仕組みは相補的だが、正しい統合と負荷に応じた測定が成果の前提となる。

正答率の小さな差を「完全に同じ品質」と言い切ることも避ける。記事の判断はこの問題集合で統計上検出できる変化がなかったという意味で、すべての回答や別の課題まで等しいと保証するものではない。